Open Badges 3.0 Certification Guide
Spec Version 3.0
Document Version: | 1.0 |
Date Issued: | May 27, 2024 |
Status: | This document is made available for adoption by the public community at large. |
This version: | https://www.imsglobal.org/spec/ob/v3p0/cert/ |
Latest version: | https://www.imsglobal.org/spec/ob/latest/cert/ |
Errata: | https://www.imsglobal.org/spec/ob/v3p0/errata/ |
IPR and Distribution Notice
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.
1EdTech takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on 1EdTech's procedures with respect to rights in 1EdTech specifications can be found at the 1EdTech Intellectual Property Rights webpage: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf .
The following participating organizations have made explicit license commitments to this specification:
Org name | Date election made | Necessary claims | Type |
---|---|---|---|
Concentric Sky | October 24, 2019 | No | RF RAND (Required & Optional Elements) |
Arizona State University | June 21, 2022 | No | RF RAND (Required & Optional Elements) |
Temple University | June 10, 2022 | No | RF RAND (Required & Optional Elements) |
Credly | October 3, 2019 | No | RF RAND (Required & Optional Elements) |
Workday, Inc. | June 10, 2022 | No | RF RAND (Required & Optional Elements) |
RANDA Solutions | June 9, 2022 | No | RF RAND (Required & Optional Elements) |
Anthology | April 16, 2024 | No | RF RAND (Required & Optional Elements) |
Unicon | April 22, 2024 | No | RF RAND (Required & Optional Elements) |
Bowdoin College | June 11, 2022 | No | RF RAND (Required & Optional Elements) |
American Association of Collegiate Registrars and Admissions Officers (AACARO) | April 15, 2024 | No | RF RAND (Required & Optional Elements) |
Desire to Learn (D2L) | April 16, 2024 | No | RF RAND (Required & Optional Elements) |
Digital Knowledge EdTech Lab Inc. | April 24, 2024 | No | RF RAND (Required & Optional Elements) |
IQC Italian Quality Company | April 19, 2024 | No | RF RAND (Required & Optional Elements) |
Skybridge Skills | April 16, 2024 | No | RF RAND (Required & Optional Elements) |
Navigatr | April 25, 2024 | No | RF RAND (Required & Optional Elements) |
T3 Innovation Network, US Chamber of Commerce Foundation | April 25, 2024 | No | RF RAND (Required & Optional Elements) |
Territorium | April 23, 2024 | No | RF RAND (Required & Optional Elements) |
Western Governors University (WGU) | June 11, 2022 | No | RF RAND (Required & Optional Elements) |
Use of this specification to develop products or services is governed by the license with 1EdTech found on the 1EdTech website: http://www.imsglobal.org/speclicense.html.
Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.
The limited permissions granted above are perpetual and will not be revoked by 1EdTech or its successors or assigns.
THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.
Public contributions, comments and questions can be posted here: http://www.imsglobal.org/forums/ims-glc-public-forums-and-resources .
© 2024 1EdTech™ Consortium, Inc. All Rights Reserved.
Trademark information: http://www.imsglobal.org/copyright.html
Abstract
Open Badges are visual symbols of accomplishments packed with verifiable metadata according to the Open Badges specification. The Open Badges 3.0 specification [OB-30] defines the properties necessary to define an achievement and award it to a recipient, as well as procedures for verifying badge authenticity and “baking” badge information into portable image files. It includes term definitions for representations of data in Open Badges and defines an API for exchanging badge information. These term definitions appear in the current Open Badges JSON-LD Context File.
This version of the specification aligns Open Badges with the conventions of the Verifiable Credentials Data Model v2.0 for the use cases of Defined Achievement Claim and a Skill Claim. The credentials that are produced are easily be bundled into Comprehensive Learner Records and Verifiable Presentations. Portability and learner data privacy are improved by expanding the usage of cryptographic proofs/signatures, because this format will be compatible with a growing array of proof schemas that are developed for the Verifiable Credentials Data Model.
1. Introduction
1.1 Conformance Statements
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [RFC2119].
An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.
1.2 Documents
The full set of documents is comprised of the following documents:
1.3 Terms
The following terms are used throughout this document.
Achievement: This is the content description of a credential that an assertion references. It contains metadata such as the name of the achievement, description, alignment of skills, etc. An Assertion asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.
Assertion: The core of both Open Badges and CLR is the assertion about achievement(s). Assertion properties are specific to one learner's achievement and specify metadata such as issuer, date of achievement, expiration data, as well as results and evidence that support the assertion. A Verifiable Credential more broadly asserts a claim about a Credential Subject which can be applied to education and occupational achievements.
Candidate platform: A platform implementing the Open Badges specification with the intent to obtain certification from 1EdTech. They may be in the process to obtain certification.
Comprehensive Learner Record (CLR): Set of assertions that can be packaged as a verifiable credential.
Defined Achievement Claim: An assertion that the learner achieved a specific achievement.
REST API: A style of web API (Application Programming Interface) loosely based on HTTP methods (DELETE, GET, POST, and PUT) to access resources (e.g. CLRs) via a URL.
Service Consumer: In a REST API, the Service Consumer is the actor that initiates the DELETE, GET, or POST request. Also called a Consumer in the IMS Global Security Framework v1.1.
Service Provider: In a REST API, the Service Provider is the actor that responds to a DELETE, GET, or POST request. Also called a Platform in the IMS Global Security Framework v1.1.
Skill: Measurable or observable knowledge, skill, or ability necessary to successful performance of a person.
Skill Claim: An assertion that the learner has the specified skill.
Verifiable Credential (VC): A tamper-evident credential whose issuer can be cryptographically verified. See [vc-data-model-2.0].
Verifiable Presentation (VP): A tamper-evident presentation of one or more Verifiable Credentials of which cryptographic verification can be used to determine the trustworthiness of the authorship of the data. [vc-data-model-2.0]
Verification: The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.
Verifier: The entity that receives a verifiable credential or verifiable presentation and verifies the credential or presentation has not been tampered with.
2. Conformance and Certification
This section is non-normative.
The goal of 1EdTech certification for Open Badges [OB-30] is to ensure interoperable implementations of badging systems that generate and issue digital badges as well as those that host and display badges.
1EdTech certification for Open Badges demands features and capabilities beyond those that are strictly required by the specification. These additional features are defined in this document. The specification is intentionally left very flexible to allow it to be used for many purposes. Gaining this certification is expected to be more difficult than simply meeting the minimum requirements for producing a valid Open Badge.
Certification may be achieved in one or more of the following services:
- Open Badges Issuer
- Open Badges Displayer
- Open Badges Host
The service types and associated certification tests are defined below.
2.1 API categorization
This specification defines a RESTful API protocol to be implemented by applications serving in the roles of Service Consumer and Service Provider. The API uses OAuth 2.0 for authentication and granular resource-based permission scopes.
All the endpoints defined in the Open Badges 3.0 API are grouped in four services for certification purposes. This grouping is based on the role of the candidate platform in the API architecture and the purpose of the operation. Thus, the resulting grouping is as follows:
Consumer (Initiates Requests) |
Provider (Responds to Requests) |
---|---|
Service Consumer (Read) | Service Provider (Read) |
Service Consumer (Write) | Service Provider (Write) |
These services contain a set of required endpoints a candidate platform must support for its further certification. Some services may contain a set of optional endpoints that, if supported by the candidate platform, it must support as well.
2.2 The Conformance Process
The process for conformance testing role implementations of Open Badges includes the following:
- First, launch the 1EdTech Conformance Test Suite for Open Badges 3.0 and follow the onscreen instructions to run the tests.
- Once the tests have been successfully run, submit your test results. A copy of your test results will be sent to your email address.
To pass certification, you must take the following steps:
- You must be an 1EdTech Digital Credentials and Badges Alliance Member, an 1EdTech Affiliate Member, or 1EdTech Contributing Member.
- You must pass all the tests associated with the features you are applying for using the certification suite hosted on the 1EdTech website.
- The tests must be completed by a designated representative of the 1EdTech member organization, and you must agree that there is no misrepresentation or manipulation of results in the submitted information.
After 1EdTech reviews your submitted information and notifies you that your application is approved, you can claim certification to Open Badges 3.0 and display the 1EdTech certified logo on your website and in your software. The 1EdTech Global Certified Products Directory will list your conformance details.
3. Open Badges 3.0 Issuer Service Conformance
This section is non-normative.
A Open Badges Issuer is an application that allows for the creation of OpenBadgeCredentials and the subsequent delivery of OpenBadgeCredentials to recipients that conform to the Open Badges Specification. The candidate platform must issue a valid baked badge and demonstrate how the badge is retrieved by the recipient. The candidate platform may also meet Service Consumer (Write) requirements and can send an AchievementCredential or a Profile to a product that conforms to Service Provider (Write) requirements.
3.1 Tests
Create a valid 3.0 badge and issue it to the recipient
conformance@imsglobal.org
and submit the issued badge to the conformance test system.Demonstrate through video the candidate platform's methodology for a recipient to retrieve their badge.
(Optional) Complete tests of, at least, required endpoints of § 3.2 Service Consumer (Write) Conformance.
3.2 Service Consumer (Write) Conformance
A product that conforms to Service Consumer (Write) requirements can send an OpenBadgeCredential or a Profile to a product that conforms to Service Provider (Write) requirements.
3.2.1 Required Service Consumer (Write) Endpoint Support
The service endpoints that MUST be supported for Service Consumer (Write) are listed in the table below:
Service Call | Endpoint | HTTP Verb | Mode | Authorization Required |
---|---|---|---|---|
getServiceDescription | /ims/ob/v3p0/discovery |
GET | Initiate | No |
OAuth 2.0 Registration | from Service Discovery Document (SDD) | GET | Initiate | No |
OAuth 2.0 Authorize | from SDD | GET | Initiate | No |
OAuth 2.0 Token | from SDD | POST | Initiate | No |
upsertCredential | /ims/ob/v3p0/credentials |
POST | Initiate | Yes |
3.2.2 Optional Service Consumer (Write) Endpoint Support
The service endpoints that MAY be supported for Service Consumer (Write) are listed in the table below:
Service Call | Endpoint | HTTP Verb | Mode | Authorization Required |
---|---|---|---|---|
putProfile | /ims/ob/v3p0/profile |
PUT | Initiate | Yes |
3.2.3 Tests
- Obtain an access token from the conformance test system using provided
getServiceDescription
endpoint and the following OAuth 2.0 authentication flow with the provided login credentials. Ensure that the right scopes are sent. - Create a valid AchivementCredential and issue it to the recipient
conformance@imsglobal.org
. Call the conformance test endpointupsertCredentials
, with the AchivementCredential. Submit the result of the call to the conformance test system. - (Optional) Create a new Profile for the id
"https://1edtech.org/issuers/cert"
and call the conformance test endpointputProfile
with the Profile. Submit the result of the call to the conformance test system.
4. Open Badges 3.0 Displayer Service Conformance
This section is non-normative.
An Open Badges Displayer is an application that displays and verifies badges for viewers. The candidate platform must support viewer-initiated verification of a badge.
4.1 Verification and status
The tests within this section refer to possible values of the status of a badge. The meaning of these values and how to determine them from a credential is defined in sections 9.1 and 9.2 of [OB-30]. As a quick summary:
- A Credential is revoked if the
credentialStatus
property is present, and thetype
of the CredentialStatus object is "1EdTechRevocationList". - A Credential is expired if the current date and time is after the
validUntil
.
4.2 Tests
The conformance test system will display the URL of three badges. One of them is neither expired nor revoked, other is expired but not revoked and the last one is not expired but revoked. The candidate platform must verify these badges and submit the status in the conformance test system. Demonstrate through separate videos that the platform allows viewers of badges to see the following data in all provided badges:
- image (if the badge provided is a baked badge)
- name
- description
- issuer name
- issuedOn Date
- status (expired and/or revoked)
Demonstrate through video that the platform allows viewers of badges to do the following:
- Trigger verification of the badge and retrieve results verifying that the badge credential is not expired, and not revoked
The conformance test system will display the URL of three badges created using Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) with the same characteristics as in Test 1. The candidate platform must verify these badges and submit the status in the conformance test system. Demonstrate through separate videos that the platform allows viewers of badges to see the following data in all provided badges:
- image (if the badge provided is a baked badge)
- name
- description
- issuer name
- issuedOn Date
- status (expired and/or revoked)
Demonstrate through video that the platform allows viewers of badges to do the following:
- Trigger verification of the badge and retrieve results verifying that the badge credential is not expired, and not revoked
5. Open Badges 3.0 Host Service Conformance
This section is non-normative.
An Open Badges Host is an application that can aggregate and publicly host OpenBadgeCredential for recipients. It also supports export of badges at user request. The candidate platform must be able to import all formats of Open Badges as well as prove that badge metadata is not lost upon export of the badge. The candidate platform must also meet § 5.4 Service Provider (Write) Conformance requirements and accept an AchievementCredential or a Profile from an Issuer application. And meet § 5.2 Service Consumer (Read) Conformance and § 5.3 Service Provider (Read) Conformance requirements for exchanging AchievementCredentials with other Host applications.
5.1 Tests
Import each of the provided artifacts (see table below), verify the badge, and submit the status to the conformance test system.
Required OpenBadgeCredential Format Use this resource for certification Baked OpenBadgeCredential (PNG) format https://someurl/OB30-conformance.png Baked OpenBadgeCredential (SVG) format https://someurl/OB30-conformance.svg OpenBadgeCredential JSON Resource URL https://someurl/OB30-conformance.jws Export the imported badge in the previous test and submit the exported badge to the conformance test system. The conformance test system will ensure that the exported badge is a valid badge and that no information is lost in the import/export operation.
Complete tests of § 5.2 Service Consumer (Read) Conformance.
Complete tests of § 5.3 Service Provider (Read) Conformance.
Complete tests of, at least, required endpoints of § 5.4 Service Provider (Write) Conformance.
5.2 Service Consumer (Read) Conformance
A product that conforms to Service Consumer (Read) requirements can request credentials and profiles from a product that conforms to Service Provider (Read) requirements.
5.2.1 Required Service Consumer (Read) Endpoint Support
The service endpoints that MUST be supported for Service Consumer (Read) are listed in the table below:
Service Call | Endpoint | HTTP Verb | Mode | Authorization Required |
---|---|---|---|---|
getServiceDescription | /ims/ob/v3p0/discovery |
GET | Initiate | No |
OAuth 2.0 Registration | from Service Discovery Document (SDD) | GET | Initiate | No |
OAuth 2.0 Authorize | from SDD | GET | Initiate | No |
OAuth 2.0 Token | from SDD | POST | Initiate | No |
getCredentials | /ims/ob/v3p0/credentials |
GET | Initiate | Yes |
getProfile | /ims/ob/v3p0/profile |
GET | Initiate | Yes |
5.2.2 Tests
- Obtain an access token from the conformance test system using provided
getServiceDescription
endpoint and the following OAuth 2.0 authentication flow with the provided login credentials. Ensure that the right scopes are sent. - Call the conformance test endpoint
getCredentials
. Submit the result of the call to the conformance test system and demonstrate through separate video that the platform displays the returned credentials. - (Optional) Call the conformance test endpoint
getCredentials
with query and pagination parameters. Submit the result of the call to the conformance test system and demonstrate through separate video that the platform displays the returned credentials. - Call the conformance test endpoint
getProfile
. Submit the result of the call to the conformance test system and demonstrate through separate video that the platform displays the returned profile.
5.3 Service Provider (Read) Conformance
A product that conforms to Service Provider (Read) requirements can provide badges to a product that conforms to Service Consumer (Read) requirements.
5.3.1 Required Service Provider (Read) Endpoint Support
The service endpoints that MUST be supported for Service Provider (Read) are listed in the table below:
Service Call | Endpoint | HTTP Verb | Mode | Authorization Required |
---|---|---|---|---|
getServiceDescription | /ims/ob/v3p0/discovery |
GET | Respond | No |
OAuth 2.0 Registration | from Service Discovery Document (SDD) | GET | Respond | No |
OAuth 2.0 Authorize | from SDD | GET | Respond | No |
OAuth 2.0 Token | from SDD | POST | Respond | No |
getCredentials | /ims/ob/v3p0/credentials |
GET | Respond | Yes |
getProfile | /ims/ob/v3p0/profile |
GET | Respond | Yes |
5.3.2 Service Provider (Read) Compliance
The functional capabilities of such systems are:
- They MUST support the required service endpoints
- They MUST require an access token with the appropriate scope for endpoints that require authorization
- They MUST return a valid entity in each endpoint. In
getCredentials
, each of the elements in the returned list MUST be verifiable. - They MUST support the endpoint payload pagination query parameters, and the corresponding response HTTP pagination headers MUST be supported
- They MAY support Token Refresh as defined in [RFC6749]. If so, a call to refresh token MUST return a new access token.
- They MAY support Token Revocation as defined in [RFC7709]. If so, a revocation MUST cause all of subsequent calls to return an error
5.3.3 Tests
- Authorize the conformance test system with the provided login credentials. Ensure that the right scopes are sent back to the conformance test system.
- Return valid AchivementCredentials when the API operation
getCredentials
is called. - Return valid AchivementCredentials when the API operation
getCredentials
is called with query and pagination parameters. - Return a Profile for the authorized user (with id
"https://1edtech.org/issuers/cert"
) when the API operationgetProfile
is called. - (Optional) Revoke the Token. Subsequents calls from the conformance test system must return an error.
If refresh token is supported, the conformance test system will perform a call for refreshing the token and repeat tests 2, 3 & 4 with the refreshed access token.
5.4 Service Provider (Write) Conformance
A product that conforms to Service Provider (Write) requirements can accept an OpenBadgeCredential or a Profile from a product that conforms to Service Consumer (Write) requirements.
5.4.1 Required Service Provider (Write) Endpoint Support
The service endpoints that MUST be supported for Service Provider (Write) are listed in the table below:
Service Call | Endpoint | HTTP Verb | Mode | Authorization Required |
---|---|---|---|---|
getServiceDescription | /ims/ob/v3p0/discovery |
GET | Respond | No |
OAuth 2.0 Registration | from Service Discovery Document (SDD) | GET | Respond | No |
OAuth 2.0 Authorize | from SDD | GET | Respond | No |
OAuth 2.0 Token | from SDD | POST | Respond | No |
upsertCredential | /ims/ob/v3p0/credentials |
POST | Respond | Yes |
5.4.2 Optional Service Provider (Write) Endpoint Support
The service endpoints that MAY be supported for Service Provider (Write) are listed in the table below:
Service Call | Endpoint | HTTP Verb | Mode | Authorization Required |
---|---|---|---|---|
putProfile | /ims/ob/v3p0/profile |
PUT | Respond | Yes |
5.4.3 Service Provider (Write) Compliance
The functional capabilities of such systems are:
- They MUST support the required endpoints.
- They MAY support the optional endpoints.
- They MUST require an access token with the appropriate scope for the endpoints that require authorization.
- They MUST preserve sent data. A subsequent call to
getCredentials
after aupsertCredential
with a given credential must return that same credential as result of the Credential equality and comparison algorithm defined in [OB-30]. - They MAY support Token Refresh as defined in [RFC6749]. If so, a call to refresh token MUST return a new access token.
- They MAY support Token Revocation as defined in [RFC7709]. If so, a revocation MUST cause all of subsequent calls to return an error.
5.4.4 Tests
- Authorize the conformance test system with the provided login credentials. Ensure that the right scopes are sent back to the conformance test system.
- Return valid AchivementCredentials when the API operation
upsertCredential
is called. - (Optional) Return the Profile for the authorized user when the API operation
updateProfile
is called. - (Optional) Revoke the Token. Subsequents calls from the conformance test system must return an error.
If refresh token is supported, the conformance test system will perform a call for refreshing the token and repeat tests 2 & 3 with the refreshed access token.
A. Revision History
This section is non-normative.
Version No. | Document Version | Release Date | Comments |
---|---|---|---|
Candidate Public Final | 1.0 | November 10, 2022 | Open Badges 3.0 first Candidate Public Final release |
Final | 1.0 | May 27, 2024 | Open Badges 3.0 Final Release |
B. References
B.1 Normative references
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
B.2 Informative references
- [OB-30]
- Open Badges Specification v3.0. 1EdTech. Candidate Final Public. URL: https://www.imsglobal.org/spec/ob/v3p0/
- [OB-CERT-30]
- Open Badges Specification Conformance and Certification Guide v3.0. 1EdTech. Candidate Final Public. URL: https://www.imsglobal.org/spec/ob/v3p0/cert/
- [RFC6749]
- The OAuth 2.0 Authorization Framework. D. Hardt, Ed.. IETF. October 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6749
- [RFC7709]
- Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs). A. Malis, Ed.; B. Wilson; G. Clapp; V. Shukla. IETF. November 2015. Informational. URL: https://www.rfc-editor.org/rfc/rfc7709
- [SEC-11]
- IMS Global Security Framework v1.1. C. Smythe; C. Vervoort; M. McKell. IMS Global Learning Consortium. July 19th, 2021. IMS Final Release. URL: https://www.imsglobal.org/spec/security/v1p1/
- [VC-DATA-MODEL]
- Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/
- [vc-data-model-2.0]
- Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 13 May 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
C. List of Contributors
The following individuals contributed to the development of this document:
Name | Organization | Role |
---|---|---|
Nate Otto | Concentric Sky, Skybridge Skills | Invited Expert |
Kerri Lemoie | Digital Credentials Consortium (MIT) | Editor |
Phillip Long | T3 Innovation Network | Invited Expert |
Marty Reed | RANDA Solutions | Co-chair, CLR |
Justin Pitcher | Anthology | Co-chair, OB |
Brent Capriotti | Western Governors University (WGU) | Co-chair, CLR |
Sherri Braxton | Bowdoin College | Co-chair, OB |
Jock Wright | VerifyEd | |
Jen Schreiber | Workday | |
Viktor Haag | D2L | |
Alex Hripak | Credly | |
David Ward | PCG | |
Laura Janusek | D2L | |
John Kuo | Arizona State University | |
Sara Arjona | Moodle HQ | |
Mark McConahay | AACRAO | |
Dmitri Zagidulin | DCC | Invited Expert |
Tracy Korsmo | North Dakota IT (NDIT) | |
Kate Giovacchini | Arizona State University | |
Andy Miller | 1Edtech | Editor |
Markus Gylling | 1Edtech | Editor |
Dan Blickensderfer | 1Edtech | Editor |
Xavi Aracil | 1Edtech | Editor |
Referenced in: