Tin Can API xAPI Sending Secure Statements to LRS

Question

Something seems to elude me with regard to xAPI. I am going to try and keep this really simple.(and maybe even stupid)

What I understand to be true...

Any Tin Can implemented content can be launched with a launcher. The launcher is provides endpoint and auth information The endpoint DOES NOT have to be an LRS. It can be a script which then passed to the final endpoint, which is an LRS. The LRS, in this case private SCORM Cloud(sandbox), cannot receive statements without basic auth.

What I need to know...

Does the LRS generate OAuth tokens? How would someone pass the statement from Captivate, Storyline, lectora files to a the TinCan_PHP for handling secure connectioni to the LRS? Why would I use TinCan.JS, when the basic auth information is easily broadcasted to the end user, which could then be used to cause harm to the LRS?

Am I completely off track?

Thanks a lot...

Answer 1

Just some clarifications for future users on your understanding...

A launcher may provide endpoint and auth, that is one scenario and is probably based on the launch guidelines that came out with the 0.9 spec. There are other ways to handle the handshake, for instance how cmi5 does so (which isn't necessarily any more secure other than the fact that the credentials can only be requested once and are intentionally denied certain privileges such as voiding of statements).

I would consider your "script" a 'non-conformant' LRS in that it is receiving statements (in the form of xAPI requests), but doesn't provide full LRS conformance. SCORM Cloud's LRS can't receive statements without some authentication, but you are correct basic is preferred because OAuth there doesn't make much sense for production.

For the questions...

1. Yes, the LRS generates OAuth tokens, but for the most common approach the content has to have an already established relationship with that LRS and the OAuth based account has to be on the LRS (or a system the LRS is tightly coupled with, like an LMS) not with some OAuth provider in the wild (meaning you can't use accounts on Twitter, or Facebook, or Google, etc. which is the part that is often confusing for people).

2. They wouldn't, those products all already support direct communication to an LRS via the launch guidelines (Basic Auth), any system they are communicating with has to have at least enough LRS functionality to support them which includes the State API besides the Statements API.

3. TinCanJS in and of itself isn't a browser only solution, there are people running it on the server side so the language is really a separate issue. It is also possible to use TinCanJS outside the common launch paradigm, and in such situations it is possible that the user has an individual credential with the LRS in question (or a system that is coupled with the LRS) and they enter it themselves. A bookmarklet is a good example application.

The bottom line with all sets of credentials is to make sure your application is conversing with the LRS over https in which case the credential used isn't in the open, then check with the LRS provider to see if it is possible to use credentials that are short lived and have limited permissions. There is little "harm" that can be done to a properly implemented LRS short of voiding of statements or overwriting (deleting) of stored documents, both of which can be limited when using a proper permissions scheme and limited credential.

Answer 2

To answer your question, yes you are completely off track! :-)

If you're sending statements from a javascript based e-learning course to somewhere, then than connection is inherently not secure. Adding another (secure or otherwise) link in the chain after that insecure connection doesn't add to your security. You may as well send the xAPI statements directly to the LRS.

You may as well use Basic HTTP authentication too. Firstly, that's what all the authoring tools support, so you kind of have to. Secondly, using OAuth instead of Basic Auth for client side connections is like using a key lock instead of a combination lock and then leaving the key under mat. A key lock (OAuth) might be more theoretically secure than a combination lock (Basic Auth) but not in practice if you leave the key under the doormat (embedded in your client side code).

See this SO question answer for three options of what you can do about xAPI authentication security.

And just for the sake of completeness: yes, in the case of OAuth the LRS generates the tokens. See the xAPI spec for the most up to date details.