Implementers can break conformance for security reasons

[garemoko]

Fixes #959

I tried to keep the example as high level as possible, but maybe it's still too detailed?

Should I delete "; disabling the Document APIs entirely is not"?

[andyjohnson]

This is a great start. One thing I think I'd like to see is a mention of behaving in a non-conformant way when a security event arises. In this way, the LRS would still act (and pass a test) within a normal (scripted test) environment, but deviate in an emergency. I worry that the way it is currently written is similar to a blank check where the LRS can claim for security reasons they don't follow requirements a,b, and c.

[garemoko]

It's not changing behavior when a particular event occurs, it's changing behavior permanently in case the event occurs at some unknown point.

For conformance testing this shouldn't be an issue because: a) The breach of conformance should be narrow enough that it's an edge enough case not to be covered by conformance testing (we can't test everything). b) For known security issue(s) and reasonable work arounds, the conformance test suite should be adapted not to flag those work arounds as fails (though maybe they would still be warnings or notes). For example when testing retrieval of documents, the test suite should use content types other than html.

I also worry about a blank check which is why I included the language:

implementers are encouraged to consider both the security and interoperability implications of their implementation decisions

...

narrowly focused

...

Where possible, approaches that satisfy security concerns without breaking conformance requirements are preferred.

plus the example about what's not narrowly focused.

I'm very open to specific wording changes though!

[andyjohnson]

Per the 9/7/2016 call,

Want to add some form of "security is a separate layer of requirements" language (an LRS must have some configuration). All other requirements cannot be ignored by an LRS. This PR should be edited to remove the requirement and the example. The best practice text can remain.

[creighton]

+1

[rswetnam]

+1

[liveaspankaj]

Hi

I believe it is more of an authorisation challenge, than a security challenge or at least equally so.

And will be a more wide spread issue when people start using xAPI for some of the things it was envisioned to do. For example, give access of learner's data to learners.

Example Scenario: There are 100 statements for a learner (actor) in the LRS. But the business or policy decision wants to allow access of only 90 of them to the learner. All would agree that there can be a lot of data and a lot of types of data in the LRS that the business or organisation will not want to give access to the user.

There will be an authorisation layer built by systems that achieves this, but we might not want to say that the LRS is non-conformant, though I guess it is based on current version of spec

Example Scenario 2: (security) An IP or User Agent, or an actor is making a million calls a second and trying to bring down the LRS. LRS would want to be able to reject/block the statements, without being called non-conformant.

There are two key things that I envision that LRS's might need to do for security and/or authorisation that we might not want to call non-conformance (we could/should add a note though):

1. Reject calls based on LRS'es decision of authority or security.
2. Return data to fetch/GET request based on an extra authorisation/security layer.

However, if the LRS makes a change that would widely break interoperability should not be considered conformant. e.g. What if LRS uses XML data model instead of JSON. Or uses some specific encoding/encryption of statements during transfer. Or, changes the endpoints. We can call it a fork of xAPI, but not xAPI itself. Because that would break the essence of an API.

Pankaj

[andyjohnson]

Limits based on user role, history, or activity are certainly allowed by xAPI. Nothing to worry about there! +1 as well and merging.