CMI 5 Working Group Meeting Minutes – December 11th

cmi5 Working Group Meeting Minutes – December 11th

Attendees

• Bill McDonald (Working Group Leader)
• Andy Johnson (ADL)
• Florian Tolk (ADL)
• Mike Hernandez (Design Interactive)
• Dennis Hall (Learning Templates)
• Megan Bowe (Making Better)
• Allyssa Thompson (KeyBridge Technologies)
• Simon Hsu (KeyBridge Technologies)
• Yifei Dong (KeyBridge Technologies)
• Henry Ryng (InXSOL)
• Geir Fuhre Pettersen (Conexus)
• Christopher Thompson (Medcom, Inc.)

Notes

cmi5 narrative presentation(s)

The group revisited each of the cmi5 narrative presentations to add clarification on "authorization" (vs "authentication") due to recurring questions about the use of the Basic Auth token used for authorization in xAPI (HTTP) request headers for cmi5 statements.

The following changes were agreed to:

cmi5 Implementation Flow for an AU

The following document provides high-level description for implementing cmi5 in learning activities. For specific details see the cmi5 specification.

The chart below provides a high-level description of the execution flow for an implementing cmi5 in an AU (Assignable Unit) - i.e. learning content. Each of the shapes in the chart are further explained (below the chart). It is assumed that prior to the learner starting a learning activity:

1. The learner has authenticated by the LMS.
2. The LMS has authorized permissions for the learner for system access.
3. The LMS has authorized access to the learner for the learning activity (called a “Registration”)

Get Authorization Token

It is important to note that the AU does NOT authenticate to the LRS. Authentication is performed by the LMS and the LMS provide authorization to the AU with an LRS access authorization token. AU uses the fetch URL to get the LRS access authorization token. The fetch URL can only be used once. The retrieved token must be used for all subsequent xAPI calls in the AU launch session. See Sections:

• 8.2 Authorization Token Fetch URL

cmi5 Implementation Flow for an LMS

The following document provides high-level description for implementing cmi5 in learning activities. For specific details see the cmi5 specification.

The LRS described is a service that is either natively implemented in the LMS or an external service integrated with the LMS. Integration between an LMS and a 3rd party LRS is outside the scope cmi5 (or xAPI) specifications. The AU (learning activity) described is authorized to access the LRS through the LMS. Note that the AU does not authenticate to the LRS.

The chart below provides a high-level description of the execution flow for an implementing cmi5 in an LMS. Each of the shapes in the chart are further explained (below the chart).

Content Launch

LMS must have a service (Fetch URL) to provide an authorization token for access to the LRS. This token is used the by AU to provide an authorization header in messages to the LRS. See Section - 8.2 Authorization Token Fetch URL. LMS creates a URL launch line with LRS connect string parameters (including a reference to the Fetch URL). See Section - 8.1 Launch Method. The LMS launches the content using one of the following methods:

1. Redirects the Browser window to the launch URL
2. Redirect to an iFrame to the launch URL
3. Spawns a new window

See Section 13.1.4 AU Metadata - launchMethod

cmi5 FAQ page

The group also agreed to that the github site should have FAQ (Frequently Asked Question) page for recurring questions that the group has encountered whe explaining cmi5. Some example questions:

1. What does term "cmi5" mean? (It technically doesn't stand for anything - it is a name not an acronym)
2. Why are you using BASIC auth? (Not really for authentication)
3. Can there be more than one AU (content presentation) in a course ? (Yes)
4. Who created cmi5 ? (The AICC? The ADL?. Briefly explain the History)

---

All Previous cmi5 Meeting Minutes

https://github.com/AICC/CMI-5_Spec_Current/wiki

cmi5 on GitHub:

http://aicc.github.io/CMI-5_Spec_Current/