Auth suggestion for IEEE

[bscSCORM]

This is a set of changes for the IEEE xAPI Base Standard Working Group to consider

Creating a pull request as it seems the best way to talk about these changes.

The rationale of this suggested change is that there has been substantial interest in using authentication mechanisms, particularly OAuth 2, other than those defined in the spec. As we consider IEEE standardization, it makes sense to avoid pulling in the OAuth 1.0a language as OAuth 1.0a is obsolete.

Properly incorporating OAuth 2 into the spec would be a larger change than the working group wants to undertake as part of the standardization process, and doesn't solve the problem of handling other authentication mechanisms.

On the other hand, removing the authentication language from the spec, while large in terms of lines of change is a simple change. And it moves us in the direction of breaking the spec up into different components that are focused on one thing (in this case the Authentication piece is completely delegated to other standards and specifications that deal with Authentication specifically). This allows xAPI to be more flexible.

There are interoperability concerns about not specifying any authentication mechanism specifically, however this seems likely to be a minor problem in practice due to the existing broad usage of basic auth, it is likely to remain as a lowest common denominator anywhere that interoperability concerns dominate. OAuth 2 is also in such broad use outside of xAPI that it is very likely we'll see broad interoperability using that as well.

[garemoko]

In addition to the comment inline, I wonder if we should include a specific reference to OAuth 2 as an example additional authentication mechanism?

[garemoko]

To disagree with my yesterday self, today I'm against including a specific link to OAuth 2 because who knows what authentication will look like in 10 years.

[garemoko]

Just realised this PR is targeting the master branch but should target dev @bscSCORM

[ViktorHaag]

If we avoided putting any kind of specific authentication/authority burdens within this spec at all, then a suite of profile documents could be written that would specifically address the task of taking up one mechanism or another to provide for a way to assert and validate statement authority.

For example, when @FlorianTolk says...

While I agree that this requirement is a little bit too hard to test, we definitely need some measurable requirement that forces an LRS to protect the LRS from unauthorized sources trying to access it.

... I kind of immediately want to ask "why? maybe you're in a situation where you don't mind unfettered access, and what is an 'unauthorized source' anyway, and how do you know?" which I guess is rather the point.

One way to cross the bridge of "well the spec must say something on the matter", is using this pattern:

• have the base spec describe the way "authentication profile supplements" would be used with the base spec
• immediately write one or more, very simple such supplements

This kind of separation of concerns can help you focus on the requirements on each side: i.e. "well the base spec needs to have some way for statements to carry a suggestion of what authority made them/sent them" and "well, the authentication profile must then be able to use that information, along with other things, to help assert that those authorities are known and trusted".

If basic authentication is widely used, and is quite simple, you could start with that as your first profile supplement doc and see what separating out the content into two pieces gets you and then follow/refine that pattern?

[Lomilar]

+1 - Security should be part of a wider guide to implementing xAPI, not part of the specification.

That being said, referencing in the specification a variety of optional security methods (client side certificates, basic auth, oauth, IP restrictions, api tokens, cookies) with references to specifications for those would encourage people to do something.

Though I could understand how this could also be seen as fragmenting the marketplace.

As for proving what authority sent a statement, that should be a part of the spec. JWT or some other method of statement signing (validatable claims?) works with all security protocols.

[ViktorHaag]

I agree with that, and as long as the base spec is careful to select several widely-representative security methods, that would seem sensible and mitigate the concern about fragmentation?

I don't have a problem at all with having some form of statement signing in place for statement authority, I also think it would be useful to have it be optional and not required for those integrations where the authority is implied by the ability to send an activity statement within an authenticated context and that's all the authority that the integration really wants.

[Lomilar]

The only push back I would have @ViktorHaag is that statement signing can travel across organizational boundaries when the xAPI data is inevitably transferred to another system. Authority by implication only works within the originating system and creates (indeed almost encourages) siloing.

All that being said, statement signing is not trivial and could become a headache, so I still don't think it should be required, just strongly recommended. That statements be signed could be required for the export of xAPI statements from a LRS.

[ViktorHaag]

I don't disagree at all, @Lomilar, about the portability of data in combination with signatures. Even with LRS export of data, I'd still like to see statement signatures as optional; signing statements not already signed could be a significant burden on exporting large data streams, and might in many cases not be required.

I completely agree that signing is not trivial and could become a headache, but I'm not sure that assertions of statement authority have any real value unless they're done in a robust way. (If all we're talking about is lining in a non-authoritative declaration of statement source, to me that seems a different matter, and I hesitate to call that an 'authority'.)

[Lomilar]

Agreed. I'm wary of letting unvalidatable data leave an LRS, but everything else I agree with.

[ViktorHaag]

That's a fair concern. Like security on the transport/connection, that feels to me like a concern for best practice or implementation profile, rather than the core specification, but I think it's a valid point just the same.