xAPI statements in static content: agnostic of Actor and Endpoint

[James Mullaney]

Hi all,

I thought I'd share something that has been bugging me ever since I first dived into the TinCan spec and I really hope that someone can shed some light on the following...

Let me set the scene: a piece of xAPI enabled content is embedded in a page by an LMS. A user performs some activity with it and it is time to send out our ever so useful xAPI statement. The content knows the verb; it is whatever action the user just performed. The content knows what it is (self aware content, I think we can all agree, is a very scary thought indeed). Now it comes to the last part of the triplet; the actor. This is where I get stuck.

Without either the LMS having passed information to the content on initialisation or the user physically having entered a name and mailto address (or other forms of valid Agent IFIs) into the content (as with the TinCan demos) this information doesn't exist. This of course means the statement would be invalid when sent as of course Agents are mandatory elements.

So fine - lets ignore that for a second and assume that this information has been filled out by the user manually, or the LMS has called a custom predefined method (perhaps a SCORM call?) that can tell the content who is partaking. We now move onto the issue of where the content should send the constructed xAPI statement. I've seen various ways of this being handled: the user entering an endpoint w/ authentication details into a form, or a JS file being edited before content is served to the user. I've even seen endpoints being baked in at the development level (I'm looking at you Captivate...) None of these are practical when it comes to content developed to be reused across multiple ecosystems. The user probably doesn't know what xAPI is, much less the LRS endpoint information, so they are unlikely to be adding this information. The LMS however may well have a predefined endpoint setup which is now has to communicate to the content in a (currently) undefined fashion. In that situation the content would then have the missing piece of the puzzle and can happily go ahead and spit out all the xAPI it can dream up.

Now, I really can't believe I am the only one who has thought about this, and I would suspect that the answer to all of this is that the content should not be sending the xAPI statements! This job should really fall to whatever application/system/LRS is serving up the content (as it can most likely make these calls server side anyway). However if this is the case, then I'm pretty sure that content creators don't know this! It seems that TinCan was always advertised as a new/better/different way to tracking user activity compared to SCORM and it seems to me that most content creators would probably name this is a potential replacement for it. But if there aren't standard methods for communicating the missing pieces of the puzzle, then it really isn't worth content creators getting into the business of using TinCan, short of preparing Verb and Activity objects to pass to an LMS to deal with.

Am I missing something big and obvious? Part of me really hopes I am... Time to set me straight!


Edit: After writing this I've realised that this exact topic falls within one of our missions: 'Content without Borders'. I'll leave this post separate however as I believe it deserves its own conversation thread.

[Russell Duhon]

Yes, the best way to send Experience API statements is server side, and that's the way most of our larger customers are doing it. If your platform is already aware of the necessary content events and user identities integration is pretty easy, just write code that sends the appropriate statements at the appropriate times.

You will find little disagreement from me that having statement sending client side in the current launch pseudo-specification was a bad idea, though I understand why it was done -- to make it as easy as possible to shoehorn into platforms that can do SCORM launches.

Any serious contender for a modern Experience API launch specification should prefer server side statement sending, and I'd go so far as to say it should not include client side statement sending. I think it would be very reasonable to piggy back a decent bit of it on LTI, which is a very solid modern approach to launch.

If there's interest in working toward such a specification, I'm in. The key will be getting sufficient rapid authoring tool buy in. Most of them need to improve their Experience API launch support anyways, even if they stick with the existing mechanism, so hopefully their efforts can be directed somewhere more fruitful. It would probably also be a good idea to attempt to have that launch mechanism included in AICC CMI-5, to avoid duplication.

Sincerely,
Russell

On Mon, Mar 10, 2014 at 10:08 AM, James Mullaney <jmull...@aol.com> wrote:

Hi all,

I thought I'd share something that has been bugging me ever since I first dived into the TinCan spec and I really hope that someone can shed some light on the following...

Let me set the scene: a piece of xAPI enabled content is in embedded in a page by an LMS. A user performs some activity with it and it is time to send out our ever so useful xAPI statement. The content knows the verb; it is whatever action the user just performed. The content knows what it is (self aware content, I think we can all agree, is a very scary thought indeed). Now it comes to the last part of the triplet; the actor. This is where I get stuck.

--
You received this message because you are subscribed to the Google Groups "Learning Locker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to learning-lock...@googlegroups.com.
To post to this group, send email to learnin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Downes]

Russell is right that sever side tracking has a lot going for it, but in a world that's used to SCORM , client side tracking isn't going away any time soon.

Russell mentioned a psudeo specification for launching Tin Can elearning. I'm struggling to paste hyperlinks here, but you can find it if you look up my Moodle launch plugin on github and follow the link in the readme. This method passes endpoints and user information in a query string from the launch tool to the content.

Obviously there's some security challenges there, but there were security issues with SCORM and it's done ok! This launch mechanism does have serious adoption though. As far as I know every rapid authoring tool that uses Tin Can supports this launch method and I don't see that changing any time soon.

It'd be great to see an authoring tool support server side tracking, but there's a number of technical and business challenges to work through. Where will server side content be hosted? What server side technologies need to be supported? These were problems that didn't exist for SCORM (it was just insecure and there was nothing you could do), so there needs to be some really clear advantages for people to take them on.

Andrew

[Russell Duhon]

The security hole is much larger for the Experience API launch mechanism used now. I'll call it earlylaunch just so I have a label.

To name a few:

SCORM used cookies to identify the person interacting with the activity, which could be made reliably hard to spoof (without gaining direct access to a copy of someone else's cookie, and even that could be made difficult). The agent in earlylaunch is just a bit of typing away from being changed.

SCORM never leaked credentials into the browser. All someone needs to do is copy the earlylaunch credentials (even if those are somehow locked down to one agent, dealing with the above, though there's no good way to coordinate that) and send whatever statements they like about themselves (or others, if the agent isn't locked down). It is much easier to restrict the scope of data accepted for SCORM communication. Those credentials can also be used to retrieve other information from the LRS.

It wouldn't be all that difficult to design a launch specification that did not require servers to run any code embedded in content server side. In essence, the launching system would provide an xAPI proxy that filled in actor. Or perhaps the spec might even go so far as to let the content spell out 'templates' for the statements it intends to send, then use a standardized endpoint to receive the values to be filled in (plus filling in actor itself). That would have the advantage of allowing for substantial auditing of the statements that would be sent by content without having to try it and see.

There'd be two big advantages of a better launch mechanism: a clearer, stricter specification so everyone implementing it didn't have to spend lots and lots of time figuring out the annoying ways content behaves differently (we've got a big list from implementing it for launcher.saltbox.com ), making content a lot more portable, and being just a security annoyance, rather than a security nightmare like it is now.

Sincerely,
Russell

--
You received this message because you are subscribed to the Google Groups "Learning Locker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to learning-lock...@googlegroups.com.

To post to this group, send an email to learnin...@googlegroups.com.

[Andrew Downes]

Yeh, I can't argue with that!

I wonder if there's a way to make 'earlylaunch' more secure only by making changes to how it's implemented on the LMS/LRS side and without making changes to the content implementation. I just don;t see authoring tools moving to another launch mechanism any time soon, and if if they do, there's still the old versions pumping out content. Perhaps something along the lines of your template solution could be achieved by integration of the LRS with the LMS so that new credentials are generated for each launch. those credentials could be authorised only to make statements about a particular agent, particular activity ids and using particular verbs, possibly even from a particular ip address and user agent (is that possible?). It still doesn't stop the learner claiming they passed the course, but it's a move in the right direction and I don't see how client side code could ever stop that exploit. In the end, it needs to be server side for anything high stakes. 

Andrew

[James Mullaney]

Hey guys,

Thanks for all these responses - these are the exact kind of conversations I was hoping to see (and they also mean I'm not going completely mad either!).

Ben and I actually just had a call about all this with the guys over at Adapt/Kineo and I've directed them over here to take a look at the discussions and add some insight of their own (particularly interesting given they are coming at it from a content producer's POV).

Certainly it seems that defining a secure standardised launch mechanism is an answer to a lot of the problems and as we have all agreed there is really no substitute to server side generated calls where needed. I don't think it is exactly what content producers want to hear - and there are lots of ideas floating around the use of Open IDs for the user within the content (although this doesn't solve the endpoint issue). I do like the idea of content constructing all the parts of the statement it can and passing it out to a proxy defined by the launcher (as Russell mentioned) and this kind of how I've envisaged some of our locally developed content working with our own platforms whilst something bigger and better is missing.

Hopefully we'll see some insight from the guys at Kineo on this too, but good to get some initial thoughts down on paper (so to speak!)

James

[Aaron Silvers]

This is really important from a standardization perspective.

I am much more in favor of application or server-side launch mechanisms. I view this as related to making the case for tracking at a system or application level -- abstracted from the content, though... when the content is actually something interactive, I'm curious how one would implement the interactivity and track it without baking in the actual tracking into the interaction itself. For non-interactive content, there's probably one verb we can all agree for the exposure to it... but when there's an interaction, it's more contextual and therefore messy.

-a-

---

Aaron E. Silvers | MakingBetter™
857.34.BEARD | s: mrch0mp3rs | @aaronesilvers | LinkedIn

“Words words words. Business. YAY!”

--

You received this message because you are subscribed to the Google Groups "Learning Locker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to learning-lock...@googlegroups.com.

To post to this group, send email to learnin...@googlegroups.com.

[ben....@scorm.com]

Indeed, what you're describing is a perfectly reasonable thing to do. At a minimum, the credentials being sent out by "easylaunch" shouldn't grant authority to read other learner's statements, etc.

But just like SCORM doesn't require a cookie, easylaunch doesn't require limiting the authority of the token. It's just a good idea. I also think this is much less of a big deal than people are thinking it is because of the difference in the two statements below:

I assert that I did this.
Proctor asserts that I did this.

Recall that "asserter" is part of every statement. If I sniff my EasyLaunch credentials, as long as the LMS isn't sending out privileged credentials in the launch (which would just be a bad implementation), I can only make the first sort of statement. Anything important is going to have to be the second sort of statement anyway. The big missing piece here is most likely paying more attention to asserter on the reporting side. For anything important, statements need to be viewed in the context of their asserter, and the context of how much the asserter is trusted by whoever is looking at the statement.

As for server side launch, we should talk about launch mechanisms to configure server side experience providers, but we need the browser based launch mechanism as well, to support people converting from SCORM.

In the CMI-5 group, we're talking about extending 'easyLaunch', to support native app launches, and "new process" launches on the machine doing the launch. It winds up being pretty simple, and the security issues are substantially addressed by the communication being server-server. And I'll note that the CMi-5 effort seemed to be the reason we put off discussion of launch in the spec group, so if folks are concerned about launch, it makes sense to comment on that: https://github.com/AICC/CMI-5_Spec_Current/blob/master/cmi5_runtime.md#content_launch

[Andrew Downes]

Thanks for flagging up CMI5 Ben. Good call.