Last year I wrote about the IEEE xAPI Base Standard working group, and how we are continuing the process of preparing the existing xAPI 1.0.3 specification to submit to a larger audience at IEEE for consideration as a standard.
I recently participated in the group’s second in-person meeting, which makes this a good time to review the progress that we’ve made and share what’s left to do. Last year, we decided to look at pulling security and authentication out of the core xAPI specification, and to clean up the SHOULD* requirements that are currently in 1.0.3.
We have, in fact, pulled out most of the security and authentication requirements from our working draft of the xAPI specification. Security will not be ignored—we’re just going to move these requirements outside of the core specification into a “Recommended Practice for Cybersecurity in the Implementation of the Experience API (xAPI) (9274.4.2).”. IEEE standards are good for 10 years, but we expect the security and authentication practices around xAPI will evolve faster than that timeframe. Moreover, xAPI is being used and will be used in a variety of contexts that will have different security needs. We’ve also discussed each of the SHOULD* requirements in the existing spec and has consensus on most of the items based on those discussions.
At our in-person meeting this year, some serious concerns about the intelligibility of the specification were raised, specifically regarding someone’s point of view who is developing a Learning Record Provider (LRP). Certain points needed to be clarified for everyone, but we also realized the specification is skewed toward assuming the reader is building a Learning Record Store (LRS). Note, by this I mean the component that stores learning records according to the requirements of xAPI—not a larger system one might build with that capability as a centerpiece.
As a group, we decided to ensure there is a clear delineation of LRP versus LRS requirements as we make edits to the draft version of the xAPI specification to be considered for IEEE standardization. We’ll make sure the LRP requirements are front and center, as we expect more people to implement LRPs than LRSs. The way the spec talks about “authority” is an example of how the LRS focus can make the spec confusing to an LRP implementor. The spec talks about how an LRS might change authority, but doesn’t clearly state that an LRP really shouldn’t set authority. Add the fact that authority is really metadata about a statement that we’ve decided to include in the statement itself so it can be passed on in some circumstances means the end result is quite confusing.
Besides pulling the security language out and finalizing the SHOULD* items, we have many other details to pin down, such as clarifying the circumstances under which an LRS may or must reject a statement and what exactly we mean by “statement immutability.” We’ll then also need to get the specification into the expected format for an IEEE standard. Once that is done, we will submit the draft standard for balloting, which will likely result in additional changes. This continues to be painstaking work—and while we hope we can plan a longer in-person meeting soon to speed up the editing process, we are still a long way away from a final standard.
If you would like to get involved with any of these Learning Technology Standards groups, you can find contact information here.
