xAPIsec: Towards an information security protocol for xAPI

By Shelly Blake-Plock (CEO, Yet Analytics)

Screen Shot 2015-09-23 at 12.42.46 PM

In June 2015, the White House’s Office of Management and Budget (OMB) issued a Memorandum, which mandates the exclusive use of HTTPS with HSTS across all Federal government web services. It states clearly that “all publicly accessible Federal websites and web services only provide service through a secure connection. The strongest privacy and integrity protection currently available for public web connections is Hypertext Transfer Protocol Secure (HTTPS).”

It stands to reason that as a US Department of Defense initiative, the Experience API (xAPI) should hold itself, at a minimum, to that standard.

With a thumb’s-up from ADL, my Yet Analytics’ colleague Jason Lewis and I volunteered to draft the skeleton of an open source xAPI security protocol which meets the demands of the OMB memo. I presented our initial ideas at the xAPI Bootcamp at ADL’s Alexandria Co-lab in July of 2015. The near-term goal is to produce a formal draft for public comment through the xAPI community by the end of the year. We will publish a schedule for revisions and a final draft and would then like charter community members to sign on to the protocol. The charter members will likely draft an xAPIsec certification to be published and managed through the forthcoming industry consortium that will steward xAPI.

The draft is currently open for comment on GitHub and we are actively seeking community input.

What is HTTPS?

The OMB memorandum offers a concise explanation for the layperson of what HTTPS is and what it does and does not do.

HTTPS verifies the identity of a website, or in the case of xAPI, a web service for a connecting client, and encrypts nearly all information sent between the website or service and the user. In terms of xAPI, specifically this encrypts the information sent between content published by authoring tools and other types of Activity Providers and Learning Record Stores.

The kind of information that is best protected by HTTPS includes cookies, user agent details, URLs, form submissions, and query string parameters which may be needed to send launch data, as is needed for certain profiles of xAPI, like CMI5.

HTTPS is designed to prevent this information from being read or changed while in transit.

Browsers and other HTTPS clients are configured to trust cryptographically signed certificates on behalf of web services. These certificates communicate that the web service is authentic, preventing unknown or untrusted sites and services from masquerading as something they’re not.

What is HSTS?

HTTP Strict Transport Security (HSTS) instructs web browsers to assume HTTPS going forward. It reduces the number of insecure redirects, and protects users against attacks that attempt to downgrade connections to plain HTTP.

Once HSTS is in place, domains can be submitted to a “preload list” used by all major browsers to ensure the HSTS policy is in effect at all times.

Per the OMB memorandum, US federal agencies will need to make all their website and web services accessible through secure connections, specifically HTTPS with HSTS by December 31, 2016.

xAPI is positioned to emerge as a critical technology for data transport and use across systems. These federal guidelines present an opportunity for xAPI, just as it’s finding early majority adoption within enterprise, to continue to be future-forward in its approach towards data security. This is why xAPIsec is so important to address now.


We have identified three key items that should be established as best practices for secure xAPI usage with regards to transport-level security, i.e. the security of the external interface of an LRS.

  • First, we should establish a strong signing algorithm — particularly SHA-256 of the Secure Hash Algorithm set designed by the U.S. National Security Agency. This is a secure hash algorithm from the SHA-2 set which comprise cryptographic hash functions — this can help to determine data integrity.
  • Second, we should include a strong key exchange such as Elliptic-Curve Diffie-Hellman which is an anonymous key agreement protocol.
  • Third, we should absolutely leverage HSTS as mentioned above. This mitigates against attacks when properly coupled with long duration — including in the subdomains — and a preload directive concordant to the STS preload lists common in the leading commercial browsers.

These factors mitigate or prevent message interception, Man-in-the-Middle (MITM) attacks, and message or statement alteration between an Activity Provider (AP) and an LRS. These initial pieces are key to the security and OMB compliance of an LRS.

Furthermore, xAPI merits definition around infosec standards for Activity Providers considered in isolation from the LRS. This will have implications both for web and mobile services as well as Internet of Things (IoT), wearables, virtual reality (VR), and augmented reality (AR) technologies.

We have special concern for security mechanisms in the tracking of activity with regard to smart appliances; autonomous vehicles; intelligent buildings, infrastructure, and environments; and other non-traditional Internet connected devices and systems. Such things will be appearing more and more in the consumer-facing market and they will likely find use within work and school environments. We will no doubt find interesting ways to incorporate the data such devices and applications provide into fuller views of organizational culture and the impact of environments on human performance.

Throughout the spectrum of xAPI technologies — from APs to LRSs to bridges and libraries to analytical and visualization tools — we will want to discuss internals (meaning mechanisms for security conformance at the level of code, data, and semantics); information architecture; a secure network hierarchy for SaaS; and data persistence mechanism reliability (after all, as xAPI was designed for data immutability, the mechanics of the APs and LRSs should take immutability into consideration both for effective and confident data querying as well as security).

Additionally, in an ecosystem where much of the information collected will be of a sensitive nature — especially as regards HR, learning records, and work performance information — we will want to come to terms with full-stack implementation concerns (particularly around attack vectors present in existing data stores); best practices for intrusion detection systems; alarm response times; auditing; response to zero-day vulnerabilities; and Common Vulnerabilities and Exposures (CVE) response time standards.

The xAPIsec Effort

We are happy to lead the work on developing an industry security protocol, but to do this well and effectively, this effort requires input from all of the constituents relevant in this work. Consider this missive an invitation to contribute to the discussion.

Vendors will benefit from adhering to the OMB guidelines and should both contribute to the discussion and build their products and platforms to conform with xAPIsec guidelines.

Contributors to the spec should contribute to the effort by bringing their unique knowledge of xAPI to the broader issue of security in xAPI-enabled and connected environments. Indeed, one of the things we should consider is creating a tiered model for xAPIsec certification whereby government and commercial production applications adhere to a certain level of security represented by the highest tier and where experimental and R&D stage technologies may want to start out as represented by another tier. There are a number of spec contributors, especially in the experimental IoT and Simulations spaces, who will need to step up to see their positions recognized.

The stakeholders in the Department of Defense will find that in securing xAPI, they will be provided with an interoperable data transfer protocol which meets the extensibility demands of new processes, systems, programs, and technologies that increase the quality and value of data while significantly bringing down cost and reducing threats. Especially we look to the ADL, who as the current stewards of the specification clearly understand how a security protocol for xAPI will bear impact on all issues of data interoperability and integration. In the enablement of systems and applications across the Training and Learning Architecture, ADL can best assist the xAPI community in sharing the development and results of the industry-led security protocol with their constituents and community members throughout government as well as the global research community.

We have an opportunity here to define the terms of our future success in establishing xAPI as a secure and responsible piece of the data ecosystem.

See more on GitHub, and please contribute your issues and comments there.

Shelly Blake-Plock (CEO and Co-Founder, Yet Analytics)

shellyShelly Blake-Plock, CEO at Yet Analytics, Inc. Working at the intersection of advanced purpose-built database technologies and experiential data analysis, Shelly has provided a vision for information analysis to Fortune 500 companies and has worked within the xAPI community on issues ranging from data visualization to infosec.

Speak Your Mind

This site uses Akismet to reduce spam. Learn how your comment data is processed.