Follow

Questions about Sources of Data, and Security

Avatar

Erik writes:

1.       If the content is ‘self-identifying’, what’s the mechanism for another piece of content being called the same name, and thus having aggregated results in the LRS? In other words, how is content uniquely identified?


2.       Similarly, users – if a login is not required, what if content01 says JoeSmith is taking the course and content05 says the same thing, but it’s a different JoeSmith? The only way to get around that is to require an existing account to authenticate against, correct? If not authentication is required, then the LRS is just going to have to expect duplicate usernames…? (perhaps this, and others, are addressed by ‘oAuth’ – I/we have not tried to get that far into the spec…)

3.       If the destination LRS can be sent to the content via a launching page, what’s to prevent someone else from sending a different LRS location to someone else’s content – essentially using another’s content piece to track back to their own system (hijacking)?

4.       And we have concerns about how enrollments will work – how will a system know if a user should be accessing the content…and what about transcripts – if a user wants to see their result summary…and sequencing? BUT perhaps those are all beyond the scope of xAPI/LRS as they’re so LMS-centric…and we just have to think outside that LMS box…

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments

  • Avatar
    David Ells

    Erik,

    Thanks for the great questions! I'll try my best to answer them below...

    1. xAPI activities are uniquely identified solely through their "id" field. Two different activities must use two different, unique "id" fields. In our Golf Example prototype at https://github.com/RusticiSoftware/TinCan_Prototypes/tree/master/ClientPrototypes/GolfExample_TCAPI we use activity IDs like "scorm.com/GolfExample_TCAPI" or "scorm.com/GolfExample_TCAPI/GolfAssessment.html" to talk about the course activity and an activity for an assessment, respectively. Activities with different IDs can have the same name, description, and so on (though it shouldn't make much sense for them to). Which content is allowed to create new activities or redefine existing ones (by using the same activity ID) is left up to authorization rules between the LRS and the account which the content will use for access.

    2. In xAPI, users are uniquely identified using either an email address ("mailto:joe.smith@example.org") or an account login on a particular system (ex. "http://example.org" and "JoeSmith"). Just as with activities, xAPI actors (aka users) can only be defined or added to by content that is using an account that the LRS trusts. In some cases, that may be a whole application, in other cases, the account may be specific to a user, and the content is interacting with the LRS on behalf of the user.

    3. User access to content is beyond the scope of xAPI. I would imagine content providers would require user authentication to first access the content, and then either the content or user the content is representing would need an account with the LRS where statements were being sent. Some content may be preconfigured with a specific LRS endpoint to hit, instead of accepting it from a launching LMS.

    4. Generally, users will be authenticated either a) by the application they are using, which has an account on the LRS, b) using their own individual account on the LRS, which the content will use to represent them, or c) using a combination of application and user credentials via OAuth, in which case the LRS will go through an OAuth handshake to verify both the application and the user.

Powered by Zendesk