Question: Auth2 support in spec

[tal-niv]

Hi, Some of our customers require Auth2 for compliance reasons. We are aiming to be fully compliant with xAPI, however spec indicates authentication as either basic authentication or Auth1 (which for the reason above is a show stopper for full compliance). Is Auth2 planned to be added to the spec?

Thanks.

[vbhayden]

The spec requires that one of those existing authentication methods be supported, but doesn't prohibit other ones from being implemented and used in addition to those.

Also per the spec:

The xAPI Working Group encourages LRS developers implementing Common Access Cards as an authentication method to collaborate in defining the details of this authentication method in a future version of this specification.

So, the implication seems to be that security methodologies are a a worthwhile area for community feedback, but that each LRS will have to implement whichever authentication protocols it believes valuable to its customers.

That said, I don't know of any LRS's that support OAuth2 off-hand. We used Keycloak (OpenID Connect, a profile of OAuth2) as a SSO system for the 2018 TLA demonstration to secure all services that produced xAPI statements, but OAuth2 was not supported by our LRS itself.

[tal-niv]

Thanks for the quick response! Circling back to compliance issues, we are required to support Auth2, and NOT support basic authentication or Auth1 as they are not sufficiently secure (an application is only as secure as it's weakest entry point). So adding support for Auth1 is not an option. We are able to get Auth2 working with xAPI, however, if it is not inherently a part of the spec we will be forced to declare our solution non-compliant, which we are really looking to avoid. So with regards to the outcome of the working group, are the results expected to make it into the spec. is there a schedule on that?

[bscSCORM]

We're in the process of proposing an IEEE standard based on the xAPI specification, and as part of that we've discussed the desire people have to use OAuth2, though a direction being considered there is to remove the language from the specification that calls out basic auth and OAuth1, to leave it completely up to implementors how they handle security (though I'd expect that in practice basic auth remains a popular lowest common denominator). The consensus of the folks working on that effort seemed to be that we should minimize the changes we need to make in order to get xAPI through the standardization process, which puts adding OAuth2 (vs saying less about authentication) out a ways.

I'm not sure if this language made it in regarding basic auth and OAuth1 but within the specification group and the conformance testing group we've kept in mind that an LRS may be configured to reject some requests for security reasons, it just needs to be able to be configured to accept the requests the test suite sends in order to be conformant. Therefore, it's unlikely anyone would have a problem with you passing the test suite and then turning off basic auth support after you pass. Note that in practice almost all the learning record providers out there use basic auth, so if you don't support that the system won't be very interoperable, conformance aside.

[tal-niv]

Removing the wording for basic authentication and auth1 and leaving security to implementors does solve our problem, and is generally better than having outdated (while still used) methods fixed in the standard. Do you know if (and when) this in fact takes place? Regarding interoperability, you raise a good point, we'll need to address that as well.

Thanks!

[garemoko]

There's no exact timeline for IEEE but I understand it's a long process, so think in terms of years rather than months. In the meantime, implementing both Basic (for the conformance test suite and interoperbility with other LRSs) and OAUth 2 (for your specific client) as Ben suggests is the way to go.

In regards to OAuth 2, I'd encourage you to find other large vendors implementing xAPI with OAuth 2 and follow the same approach. If you want to email andrew.downes@watershedlrs.com I may be able to put you in contact.

[tal-niv]

Thanks for that. We'll definitely take a look for the Auth2 implementation. Until the IEEE certification happens (does indeed sound like a very long project), is the xAPI standard in freeze? Is there a way to introduce some changes to the standard prior to that?

Thanks!

[garemoko]

That's correct. I don't envisage any new releases of xAPI prior to the IEEE version.

Also bear in mind that the most likely change will not be to add OAuth 2, but to remove OAuth 1. The spec already allows you to implement additional authentication methods and that won't change.

I also assume that LRSs will still need to implement basic auth if only for the purposes of conformance testing (and this will be able to be disabled for production use).

So don't wait for xAPI to add details of OAuth 2. You can implement it today and any specification or standardisation of how OAuth 2 is implemented will happen outside of xAPI.