Clarification request on ensuring remote launches are supported by vendors.

[LiamKearn]

Hi All!

We're in the process of implementing CMI5 for our content authoring system. We've been testing with ScormCloud and the Catapult CTS with little issues.

Specifically we want to support standardised "remote" launches from the LMS to our live servers. We already implement LTI but we're extending our support for more vendors.

We've had a bit of a communication issue with a LMS vendor. Their implementation is created as a set of plugins to LMS'ify Wordpress.

The vendor seems to interpret the following exert from the specification as referring to their own LMS session (the session):
https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md#821-overview

The AU MUST place the auth-token in the HTTP header, as defined in RFC 1945 - 11.1 Basic Authentication Scheme, in all subsequent xAPI communications with the LMS. The authorization token returned by the fetch URL MUST be limited to the duration of the session

We're trying to fetch their token as outlined in the specification, we're doing this remotely (cross origin) from our servers (not the browser). However they're requiring that we use their WordPress cookie in order for them to match to this session, it's user and use that information to authenticate said user to their LRS.

I would personally just add a parameter to fetch url that is a jwt token to identify the agent. That way no session based context is needed from the AU apart from the fetch URL.

We understand their implementation from a security/ease-of-implementation point of view but in our interpretation of the specification and it's adverts around "supporting remote launches" and more than just HTTP protocols (which would make cookie based authentication pretty annoying):
https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md#url

To accommodate "non-browser" applications, an application specific protocol MAY be used in the url:
<application>://<URL to content>

All in all I think referring to "the session" is a little ambiguous, I know that Session is defined in the definitions. I think since we've just seen a case in the wild of people ignoring the definition it might pay to be a little more explicit at the site (here) at the cost of brevity.

Any chance of a clarification or update here?

Many thanks for your work on the specification and assistance with those implementing it :)

[brianjmiller]

All in all I think referring to "the session" is a little ambiguous, I know that Session is defined in the definitions.

I understand your point, but do you have a recommendation of how to make it less ambiguous? IMO there isn't much ambiguous about a term that is defined in a set of definitions. It is pretty unreasonable for them to make a leap from the word "session" which is defined in a set of terms in a specification to have it mean something other than that definition. Them requiring anything other than that the request uses the POST method and the full URL itself is beyond the scope of the spec and very likely to break implementations as you've pointed out.

I'd go much further than requiring cookie based authentication as being "annoying", it will just continue to break implementations going forward and although I suppose it isn't in technical violation of the spec, it certainly is in violation of the intent of the spec as you've pointed out.

I think since we've just seen a case in the wild of people ignoring the definition...

In general the WG has mostly disagreed with this stance historically, as people ignoring definitions can't generally be satisfied regardless of brevity.

(Note I'm all for clarifications, especially outside of actual "requirements", I just don't know what that clarity looks like in this case.)

[LiamKearn]

Hi @brianjmiller, Thanks for the reply,

I understand your point, but do you have a recommendation of how to make it less ambiguous? IMO there isn't much ambiguous about a term that is defined in a set of definitions. It is pretty unreasonable for them to make a leap from the word "session" which is defined in a set of terms in a specification to have it mean something other than that definition.

I'm not insistent on this at all, (and you say the working group doesn't seem keen on it) but I think the AU's session is much clearer. It disambiguates the term from the MANY technical meanings in order to make any implementor question themselves, and hopefully read definitions as they should.

Personally I'd like to be surprised by an unknown/scoped term which makes me consult the documentation and have to look it up or ask someone like you (thanks for the help so far).

although I suppose it isn't in technical violation of the spec, it certainly is in violation of the intent of the spec as you've pointed out.

Well put, how the specification could solve intent disputes is beyond me! It's hard enough to deal with a closed source vendor who seems willing to argue the spec on this one.. I might refer them to the definition section on session since they argued that it's their LMS session.

If anyone from the working group could somehow make some sort of clarification around the "purity" of the fetch process that would be great. By purity I mean that it shouldn't be stateful from the AU's prospective. The LMS should be encoding state in the fetch URL not via the browser.

[MrBillMcDonald]

closed per Feb 9th meeting