Open Badges 3.0 Implementation Guide
Spec Version 3.0
Document Version: | 1.5 | |
Date Issued: | November 9, 2023 | |
Status: | This document is for review and adoption by the 1EdTech membership. | |
This version: | https://www.imsglobal.org/spec/ob/v3p0/impl/ | |
Issue Tracker |
|
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 | June 23, 2022 | No | RF RAND (Required & Optional Elements) |
Unicon | June 10, 202 | No | RF RAND (Required & Optional Elements) |
Bowdoin College | 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 .
© 2023 1EdTech™ Consortium, Inc. All Rights Reserved.
Trademark information: http://www.imsglobal.org/copyright.html
Abstract
Conformance Statements
This document is an informative resource in the Document Set of the Open Badges Specification specification [OB-30]. As such, it does not include any normative requirements. Occurrences in this document of terms such as MAY, MUST, MUST NOT, SHOULD or RECOMMENDED have no impact on the conformance criteria for implementors of this specification.1. Introduction
The 1EdTech digital credentials specifications, Open Badges and Comprehensive Learner Record (CLR) enable the recognition of learning achievements in many contexts that are cryptographically verifiable as the learners present them to unlock new opportunities across a lifetime of learning and employment. Key use cases include the recognition of skills and competencies, degrees, certificates and professional certifications, participation, and community engagement.
This implementation guide aims to inform product developers who are investigating or planning implementation of the Open Badges 3.0 and/or CLR 2.0 specifications about the available implementation options and how to situate a product within the ecosystem compatible with these specifications.
1.1 Overview
Each Open Badges OpenBadgeCredential
is digitally signed by its issuing
organization as Verifiable Credentials compatible with the Verifiable Credentials Data Model v1.1.
Issuers may bundle together multiple related achievement credentials into
transcripts and other longitudinal records for an individual learner in a CLR as
a ClrCredential
, which is also signed using the same technique as the
individual credentials. Additionally, credentials can be augmented with an
EndorsementCredential
from a third party to lend the support of another
individual or organization to the quality or relevance of an issuer or
credential data.
A RESTful API, with dynamic client registration, is available to transport data
in OpenBadgeCredential
and ClrCredential
format, under the control of the
learner, between systems where they are issued, hosted on behalf of the learner,
or verified by third parties in order to qualify the learner for job placement
or other opportunities. Implementing systems can participate in a variety of
roles
1.1.1 Spec documents (Normative References)
The full set of documents is comprised of the following documents:
1.1.2 Audiences
This implementation guide is intended for product developers across various implementation roles necessary for the operation of an ecosystem where digital credentials efficiently recognize achievements that matter and flow to the contexts where these achievements each need to be understood. Products may be situated to perform one or more roles within the ecosystem, such as issuing credentials, hosting credentials on behalf of learners, and verifying credentials.
1.2 OB Overview
An Open Badge (OpenBadgeCredential
) is a individual achievement recognized
about an individual learner. An Issuer makes a claim that a learner has met the
criteria of a particular defined Achievement
.
1.3 CLR Overview
A Comprehensive Learner Record allows many Open Badge achievement credentials to be bundled together, with some additional associations between them defined. This is like another onion layer wrapping the inner set of credentials that is also signed. Individual component credentials are verifiable, and the wrapping CLR is also verifiable. CLRs can contain achievements from multiple different issuers to show a learner's progression with multiple organizations or subdivisions of a large educational institution.
1.4 Use Cases
Use cases are outlined in each the Open Badges and Comprehensive Learner Record specifications. Use cases outline how each specification is intended to provide value to end users through interoperability between products.
Open Badges use cases include:
- Assertion Issuance to Wallet
- Assertion Issuance Without a Wallet
- Recipient Presentation of Assertion
- License Issuance
- Single Skill Assertion
- Mapping Skills
- Verifying Continuing Education
- Self-assertion
- Endorsement
- Re-issue an OB 2.0 Badge as an OB 3.0 Badge
- Authorization to Issue Given by Creator to Issuer
- Revocation of an Issued Credential
- Badge Class Status
Comprehensive Learner Record use cases (not yet published) include:
- Recent graduate wants to hold a copy of their own official transcript
- Job applicant provides proof of degree and transcript to potential employer
- Job applicant provides proof of degree and specific courses/engagements from the CLR
- Higher Ed Competency-Based Education
- Issuer Asserting All Student Achievements Comprehensively as a CLR
- Issuer Asserting Partial Transcript at Intermediate Points in Learning Journey
- Issuer Asserting Student Up to Date Partial Transcript of Achievements as CLR on Request
- Internal Organizational Staff Development and Promotion
- Upskilling with Higher Ed Professional/Continuing Education
- Teacher Placement with a District
- Professional Licensure Test Taker results
- Students in Tutoring Program
1.5 OB/CLR in the 1EdTech Ecosystem
The core of both Open Badges and Comprehensive Learner Record is an assertion about an achievement. As defined in Open Badges Specification v3.0 and Comprehensive Learner Record Standard v2.0, an assertion is specific to one learner. It contains a claim that the learner has made a particular achievement and metadata about the achievement, the issuer, and the learner, including possible evidence that provides support for the claim.
These concepts are also present in some way in other specifications within 1EdTech, enabling connections between specifications.
A clear connection to other specifications occurs through the alignment of
achievements. An alignment of an Achievement
to can refer to a IMS Competencies and Academic Standards Exchange (CASE) Service Version 1.0's
CFItem
for linking the achievement to a learning object in a CASE's Competency
Framework Package.
Another possible connection with other 1EdTech's specifications is the issuer of
the credential. Since it can be an organization or entity it can represent the
same entity described as an Org
in 1EdTech OneRoster® Specification v1.1 [OR-11] or Edu-API Specification Specification v1.0
[EDUAPI-10].
Moreover, the learner who the credential is issued to can have a relationship
with the User
entity in [OR-11] or the Person
entity in [EDUAPI-10], as
well.
Also, [OR-11] covers performance of the learner in a context such an
assignment vi the Result
entity. This can be related with the
Result Definition
of the issued Achievement
, and the Result
of an
AchievementSubject
.
Open Badges and Comprehensive Learner Record can be implemented by systems that use other specifications as well. For example, an Open Badges or CLR application be offered as a tool within an LMS using IMS Global Learning Tools Interoperability® Core Specification v1.3 to launching the OB or CLR-specific interfaces.
2. Getting Started (for Developers)
This section is non-normative.
It may seem like an overwhelming task to implement Open Badges 3.0 or CLR 2.0, but there are straightforward options that can take your product to a certified launch simply.
2.1 Relationship between VC and CLR/OB
New to this version of the specification, the data model of both CLR and OB adopts the convention of the [VC-DATA-MODEL].
Since Verifiable Credentials are extensible by design, CLR/OB defines a set of extensions (also called profile) for reflecting the domain both specifications cover: learning achievements, alignment with educational/workforce frameworks, etc. CLR/OB also defines the verification algorithm for these credentials, as well as a set of services for exchanging these credentials.
That means that ClrCredential
and AchievementCredential
are, in fact,
Verifiable Credentials, and can be used wherever a Verifiable Credential can be.
This assertion is not bidirectional, thus a Verifiable Credential might not be
an CLR/OB Credential. Only those credentials with the extension set defined by
the CLR/OB spec, and verifiable via CLR/Ob verification algorithm, can be
treated as CLR/OB Credentials.
2.2 Issuer quickstart
Here is a quickstart tutorial to build an MVP of an Open Badges product that issues Open Badges to learners. It aims to sketch out a simple path to a successful conformant implementation of Open Badges 3.0 issuance. From this base, optional components of the specifications can be layered on to implement relevant APIs, package records in CLR format, implementing revocation or refresh services, and more. Products that complete all the user stories in this quickstart will potentially be eligible for issuer-only certification.
We can track the workflows that must be built through a set of user stories.
Issuer Profile:
As an institutional administrative agent, I can define an Issuer Profile that represents my organization.
See details on the
selection of recipient and issuer identifiers,
but for the purposes of a quickstart, hosting an issuer profile on an HTTPS url
associated with a did:web
Decentralized Identifier is an easy choice for a web
application. See DID Web Method Specification For example, if the web application
under development is running on the domain example.com
, an issuer profile
identifier might be
did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774
, which would
resolve to a hosted resource available at
https://example.com/issuers/540e388e-2735-4c3e-9709-80142801c774
. But what is
served at this URL when a client requests it? The most effective answer is to
present a response that best matches what the client is requesting, as it
indicates with the Accept
HTTP header.
- When a client requests
Accept: application/json
orapplication/ld+json
or does not include anAccept
header, a JSON-LD that includes the OB 3.0 context should be returned. It should include its own primary id, all required properties from Profile, and a representation of the public key component of the keypair this issuer uses to sign credentials in selectedJWK
oreddsa-2022
format. See Dereferencing the Public Key - When a client requests
Accept: */*
orapplication/html
, an HTML representation of theAchievement
should be presented. This should express information about the issuer using Open Graph meta tags, including at least name, description, and image tags for easy rendering of preview cards when theAchievement
URL is shared to social media platforms, for instance.
In order to sign credentials, the issuer needs to have an associated key referenced from their profile, whether that profile is resolved via a DID or an HTTPS URL. Either a JWT stack using RSA 256 (or RSA with larger key sizes) or an EdDSA stack using a JSON-LD linked data signature must be used to achieve conformance certification as shown below. See Selecting proof methods and crypto algorithms for a detailed discussion on the management of keys and creation of signatures.
An example of a JSON-LD representation of an issuer profile follows, that uses the EdDSA Cryptosuite 2022 option for signing credentials:
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774",
"type": "Profile",
"name": "Example Institution",
"url": "https://example.com",
"description": "An example of an educational institution, such as a University",
"email": "info@example.com",
"verificationMethod": [{
"id": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774#key-0",
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-rdf-2022",
"controller": "https://example.com/issuer/123",
"publicKeyMultibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP"
}]
}
Achievement:
As an authorized institutional representative, I can define an
Achievement
on behalf of my organization, so that I can issue badges recognizing this achievement to learners.
Internally, an Achievement
is a database record or document within an issuer
system that can be presented using the required and optional properties of the
Open Badges Achievement
data model. For example, if your app uses a relational
database, Achievements would be stored in a database table that has columns for
each of the required fields and any supported optional fields. See
Achievement Data Model for
a listing of fields, noting those with [1]
or [1..*]
multiplicity are the
required ones.
Open Badges Achievements are often associated with images that provide a visual
representation of the achievement. Images are optional but are visually
prominent components of badges and are often included. OpenBadgeCredentials
are issued for many achievementTypes
(see
enumeration)
that may not traditionally include an image, but OB 3.0 now enables this an
image to be included for any type of achievement.
For an issuing system that operates a web application on a stable domain, an
easy path forward is to select an HTTPS URL as the identifier for each defined
Achievement
in its database. For example, if the web application under
development is running on the domain example.com
, an achievement identifier
might be
https://example.com/achievements/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6
. See
Publishing achievement definitions
for a discussion of options for Achievement
identifier. Again, is is best to
present a response to requests made to this URL that best matches what the
client is requesting, as it indicates with the Accept
HTTP header.
- When a client requests
Accept: application/json
orapplication/ld+json
or does not include anAccept
header, a JSON-LD that includes the OB 3.0 context should be returned. - When a client requests
Accept: */*
orapplication/html
, an HTML representation of theAchievement
should be presented. This should express information about the Open Graph meta tags including at least name, description, and image tags for easy rendering of preview cards when theAchievement
URL is shared to social media platforms, for instance.
An example of the JSON-LD document that might be fetched from this endpoint follows:
{
"@context": "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"id": "https://example.com/achievements/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6",
"type": "",
"name": "Advanced Shoe Tie",
"description": "Experts at shoe tying can securely fasten laces with a balanced knot.",
"achievementType": "Competency",
"creator": {
"id": "https://example.com/issuers/540e388e-2735-4c3e-9709-80142801c774",
"type": "Profile",
"name": "Example Institution",
"url": "https://example.com",
"description": "An example of an educational institution, such as a University",
"email": "info@example.com"
},
"criteria": {
"narrative": "# Requirements\nShoe tiers must complete..."
},
"image": {
"id": "https://example.com//achievements/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6/image",
"type": "Image"
},
"tag": [
"research",
"computer science"
]
}
Note that an image associated with the achievement is hosted at a related URL. This could be alternatively presented as a data URI within the Achievement.
Recipient Identifier:
As a learner, I am assigned a badge recipient identifier or can select one of my choosing.
See Selecting recipient and issuer identifiers for an in-depth discussion on how identifiers may be trusted within software to be associated with organizations or natural persons. A "Self-sovereign identity (SSI)" movement advocates for end user control over the identifiers that refer to users. OB and CLR are compatible with identifiers that support traditional or SSI approaches, including email addresses or student ID numbers on the traditional side and Decentralized Identifiers (DIDs) with varying SSI capabilities.
A workable approach that straddles the divide and can achieve good credential transferability to traditional and new verifiers (credential consumers, such as employers) is to deliver badges that target recipients by human-verifiable means at a minimum but then enable end users to present proof of control of a DID, at which point they may claim a version of the credential signed to that identifier instead.
Implementing this workflow varies for different organizations, depending on what identity management solutions they already use. For example, if an app that enables assessment and award of credentials connects to a Student Information System to gain access to course rosters and the student records in that system each include a student ID number and an email address, that application might choose the email address as the best recipient identifier to use in credentials, because it is easiest for target external consumers of those credentials to verify is associated with an individual. That learner might share their badge on a resume and the hiring manager they send it to can verify it matches them by sending them a six digit code and asking their job applicant to read it back to them.
Recommended options include:
- If the platform supports integration with a wallet or other system where a
learner can present and prove control of an identifier that is usable as a
VC or VP issuer identifier, and the user has gone through this process, use
their preferred identifier as
credentialSubject.id
. - If the badges will be delivered primarily for URL-based sharing or download,
and the user has not presented a DID, do not include a
credentialSubject.id
property, and instead include anidentifier
property referencing a known identifier that may be verified by humans or other non-VC, such as an email address.
As an educator, I can assess a learner and trigger the award of an
OpenBadgeCredential
recognizing that the student has met the criteria of the previously definedAchievement
.
Implementing this workflow may look like an educator accessing details about the credential, and then in an "award" section of those details, selecting a student from a roster list and confirming. The result of this action is typically to make a record in the product's database containing the metadata of the award, such as its creation time, the recipient and their identifier, and any other details such as what the educator may have entered in an evidence narrative text box. While it is possible to generate the signature on the credential in order to store it in the system as a signed document at this point, it is not necessary to sign the credential except when delivering it, via download, wallet integration, or OB/CLR REST API.
As a learner, I am notified that I have achieved the Achievement and that I can claim my badge.
Implementing this workflow may look like an email message sent to the recipient with a link into the issuing coordination system.
As a learner, I can access information about my badge in Open Badges 3.0
OpenBadgeCredential
format, complete with a reference to my recipient identifier and a cryptographic proof.
Within a notification email, a learner might see a link into the issuing
coordination system, where they are offered the chance to authenticate with
their organizational single-sign-on (SSO) provider. After successfully
authenticating, they can see options to access or share their badge. See
recommended practices about
sharing badges
via URL, but those capabilities might be available within an Open Badges Host
platform, not necessarily an issuer coordination app that produces signed
OpenBadgeCredentials
. Here, the recipient may see a download JSON option,
which upon activation yields a signed verifiable credential like the following.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "urn:uuid:a9fc82eb-416f-47c3-8786-de890331d4a5",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774",
"type": "Profile",
"name": "Example Institution",
"url": "https://example.com",
"description": "An example of an educational institution, such as a University",
"email": "info@example.com"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Advanced Shoe Tie",
"credentialSubject": {
"type": "AchievementSubject",
"identifier": {
"type": "IdentityObject",
"hashed": true,
"identityHash": "sha256$658625b25ab3d75d613ca97d9a5a77f70e2192feca5557f4ad09a4d4f121f5fc",
"identityType": "email",
"salt": "FleurDeSel"
},
"achievement": {
"id": "https://example.com/achievements/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6",
"type": "",
"name": "Advanced Shoe Tie",
"description": "Experts at shoe tying can securely fasten laces with a balanced knot.",
"achievementType": "Competency",
"creator": {
"id": "https://example.com/issuers/540e388e-2735-4c3e-9709-80142801c774",
"type": "Profile",
"name": "Example Institution",
"url": "https://example.com",
"description": "An example of an educational institution, such as a University",
"email": "info@example.com"
},
"criteria": {
"narrative": "# Requirements\nShoe tiers must complete..."
},
"image": {
"id": "https://example.com//achievements/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6/image",
"type": "Image"
},
"tag": [
"research",
"computer science"
]
}
},
"proof": [{
"type": "DataIntegrityProof",
"cryptosuite": "eddsa-rdf-2022",
"created": "2022-12-15T16:56:16Z",
"verificationMethod": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774#key-0",
"proofPurpose": "assertionMethod",
"proofValue": "z4o2Pva6ksbXtCCzHv4VM8Ss9WJg2tnxgDbVwfZr1dq3i2jjzNHWPPpHHRw8s1AknGzL4XjBZVyh3BzSo59qz8NBp"
}]
}
Several things to note about this credential.
- There is no primary credential subject ID in this example. The recipient has
not yet presented proof of control of a DID, so the credential identifies
them by their email address. The identityHash is the SHA-256 hash of the
concatenated student email address and credential salt
jjefferson18@example.comFleurDeSel
. This enables the student to present the credential and their institutional email address to a verifier who can check the hash to ensure the badge belongs to them. - The
verificationMethod.id
identifies the issuer's public signing key using a fragment identifier within the issuer's identifier. This is the same ID that appeared in the representation of the key in the issuer DID document itself. - This credential uses the id
urn:uuid:a9fc82eb-416f-47c3-8786-de890331d4a5
. Some implementers might choose an HTTPS URL on the same domain as the issuer DID Document and the Achievement, but is not assumed that the general public would be able to access data about this credential if they retrieved theid
of the document. Other issuers may allow learners to rely on badge backpacks or mobile wallets to provide sharing capabilities that match the use case. See discussion: Sharing badge links to social media.
Follow the steps in the Conformance Certification Guide for the issuer role to submit a downloaded signed credential like the above for conformance checks.
2.3 API quickstart
The API of Open Badges 3.0 and Comprehensive Learner Record 2.0 is divided into four groups, wether the OB / CLR tool is a consumer or a provider of the API and wether the operations it consumes / provides are read operations or write operations.
Depending of your certification goals it must be necessary to implement one or more of these groups of API. For instance, if you're seeking the certification as an Issuer (not Issuer only) you'll need to implement the service-consumer-write group.
2.3.1 Consumer basics
Consumers of the OB / CLR API must acquire an OAuth 2.0 access token from an authorization server for making API calls. The acquisition of the token implies a set of steps:
Call the ServiceDescription
endpoint. Once you know the base url of your
authorization server, make a GET call to the well-know getServiceDescription
endpoint. The response will contains all the endpoints needed for register your
client application (x-imssf-registrationUrl
) and acquiring and access token
(authorizationUrl
, tokenUrl
and refreshUrl
) with the desired scopes.
GET /ims/ob/v3p0/discovery HTTP/1.1
Host: example.edu
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
...
"components": {
"securitySchemes": {
"OAuth2ACG": {
"type": "oauth2",
"description": "OAuth 2.0 Authorization Code Grant authorization",
"x-imssf-name": "Example Provider",
"x-imssf-privacyPolicyUrl": "provider.example.com/privacy",
"x-imssf-registrationUrl": "provider.example.com/registration",
"x-imssf-termsOfServiceUrl": "provider.example.com/terms",
"flows": {
"authorizationCode": {
"tokenUrl": "provider.example.com/token",
"authorizationUrl": "provider.example.com/authorize",
"refreshUrl": "provider.example.com/token",
"scopes": {
"https://purl.imsglobal.org/spec/clr/v2p0/scope/delete" : "...",
"https://purl.imsglobal.org/spec/clr/v2p0/scope/readonly" : "...",
"https://purl.imsglobal.org/spec/clr/v2p0/scope/replace" : "..."
}
}
}
}
},
"schemas": {
...
}
}
...
Register your client using OAuth 2.0 Dynamic Client Registration Protocol
[RFC7591]. To do that, make a POST call to the endpoint defined in the
x-imssf-registrationUrl
field from the previous step.
POST /connect/register HTTP/1.1
Host: auth.1edtech.org
Accept: application/json
Content-Type: application/json; charset=utf-8
{
"client_name": "Example Client Application",
"client_uri": "https://client.1edtech.org/",
"logo_uri": "https://client.1edtech.org/logo.png",
"tos_uri": "https://client.1edtech.org/terms",
"policy_uri": "https://client.1edtech.org/privacy",
"software_id": "c88b6ed8-269e-448e-99be-7e2ff47167d1",
"software_version": "v4.0.30319",
"redirect_uris": [
"https://client.1edtech.org/Authorize"
],
"token_endpoint_auth_method": "client_secret_basic",
"grant_types": [
"authorization_code",
"refresh_token"
],
"response_types": [
"code"
],
"scope": "https://purl.imsglobal.org/spec/ob/v3p0/scope/delete https://purl.imsglobal.org/spec/ob/v3p0/scope/assertion.readonly https://purl.imsglobal.org/spec/ob/v3p0/scope/replace offline_access"
}
The response object will contain the details needed to perform the OAuth 2.0
Authorization Code Grant flow (client_id
, client_secret
, among others).
Acquire an access token following OAuth 2.0 Authorization Code Grant flow as
described in then IMS Security Framework [SEC-11]. Briefly, it consists in
building the authorizationUrl
from the url defined in the authorizationUrl
field gotten from step one with some query parameters. The use of Proof Key for
Code Exchange (PKCE) [RFC7636] is recommended.
Once built, redirect the user to this url in order to start the OAuth 2.0 Authorization Code Grant flow.
HTTP/1.1 302 Found
Location: https://auth.1edtech.org/authorize?
client_id=4ad36680810420ed
&response_type=code
&scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%ob%2Fv3p0%2Fscope%2Fassertion.readonly%20offline_access
&redirect_uri=https%3A%2F%client.1edtech.org%2FAuthorize
&state=26357667-94df-4a14-bcb1-f55449ddd98d
&code_challenge=XeDw66i9FLjn7XaecT_xaFyUWWfUub02Kw118n-jbEs
&code_challenge_method=S256
Once the authorization is made, the authorization server will redirect the
browser back to the specified redirect_uri
with the code
, scope
, and
state
query string parameters.
Then, you have to acquire an access token by making a POST request to the
tokenUrl
gotten from the Service Description endpoint. The HTTP POST request
MUST include a Basic authorization header with the client_id
and
client_secret
provided in the registration response. The body of the token
request MUST include the following form fields: grant_type
, code
,
redirect_uri
, scope
and code_verifier
.
POST /token HTTP/1.1
Host: auth.1edtech.org
Authorization: Basic NDE2ZjI1YjhjMWQ5OThlODoxNWQ5MDA4NTk2NDdkZDlm
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=7c7a73263ee14b2b48073d0615f286ec74f6636689046cb8dbede0b5e87a1338
&redirect_uri=https%3A%2F%client.1edtech.org%2FAuthorize
&scope=https%3A%2F%2Fpurl.imsglobal.org%2Fspec%2Fob%2Fv3p0%2Fscope%2Fassertion.readonly+offline_access
&code_verifier=mYUQfKNgI1lSbY8EqtvNHLPzu0x%2FcVKO3fpWnX4VE5I%3D
The response of this call will contain the access token to use in future calls to the API.
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, max-age=0
Pragma: no-cache
Content-Type: application/json; charset=UTF-8
{
"access_token": "863DF0B10F5D432EB2933C2A37CD3135A7BB7B07A68F65D92",
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"expires_in": 3600,
"token_type": "Bearer",
"scope": "https://purl.imsglobal.org/spec/ob/v3p0/scope/assertion.readonly offline_access"
}
2.3.2 User stories for an issuer (API consumer) and host (API provider)
Here are a selection of user stories covering how to add on support for the OB 3.0 API as an Issuer to a simple product after completing the issuer quickstart above. Completing the consumer-side portion of the will potentially qualify a product for conformance certification as an Open Badges Issuer (with API service-consumer-write support). This is a presentation of the experience of using the API from the user's perspective. Additional under-the-hood technical details for each procedure are described in the Specification section 6: Open Badges API.
As a badge holder, I can inform my issuer of my selected Open Badges host service.
Provide the base url or domain of the selected Open Badges host service to the issuer. This could utilize a text input where a user can paste a URL, or a consumer service could add known service providers to a list, presenting the manual input as an advanced option.
As an issuer service, I can discover information about an Open Badges host service.
The service consumer will call the getServiceDescription
endpoint from the
base url of the Open Badges service provider (host).
As an issuer service, I can register with a Open Badges host service provider.
By performing the OAuth 2.0 Client Dynamic Registration [RFC7591] to the
endpoint defined in the x-imssf-registrationUrl
field of the Open Badges Host
service description.
As a badge holder, I can request and approve a connection between my issuer and my host account.
By following the OAuth 2.0 Authorization Code Grant flow in their browser, following redirects between the issuer and the host service.
As a badge holder, I can select one, some or all
OpenBadgeCredentials
to transmit to my host account.
A basic service consumer (write) integration would typically push all awarded badges to the host, and a more advanced service consumer may enable users to select a specific scope of credentials for transmission.
As a badge holder, I can see that new badges I am awarded are automatically transmitted to my host, even when I am not interacting with either the issuer or host services directly, if I have configured my issuer to send badges automatically.
As a badge holder, I can deauthorize my issuer from connection to my Open Badges host, so my issuer can't retrieve badges from my Open Badges host no more.
By revoking the access token granted to the issuer from within the Open Badges (service provider) interface.
As a user who has revoked consumer access to my host, I should see the broken connection within the consumer app and be able to initiate reauthorization.
While authenticated with a host service, one action users may take is to view the connected issuer(s) or displayer(s) they have authorized and to revoke some of those approvals. When a user takes this action, it invalidates any access tokens or refresh tokens the connected services, so that those services may no longer access API endpoints on the user's behalf. This should be handled in the issuer or displayer service as a potential expected outcome, after which the service may display an inactive status on the connection and/or prompt the user to reauthorize if they desire to continue sending badges to that host once again.
Your issuer service may discover that your access credentials no longer work as expected when you receive a 401 or 403 status response from the host when attempting to access a protected endpoint and then subsequently receive an error response when attempting token refresh.
2.3.3 Provider basics
The above description of a consumer implementation shows the requests that are made of a provider. This guide does not go into depth about how to accomplish the provider side of these interactions, but the API roughly follows common OAuth patterns for (a) dynamic client registration, authorization code access token grants, and protected resource endpoint access.
- Provide the
ServiceDescription
endpoint with the right values for theOAuth2ACG
's securitySchema. The urls there must point to your OAuth related endpoints. - Allow Registration of clients using
Dynamic Registration
. - Implement OAuth 2.0 Authorization Code Grant flow for granting tokens.
- Enable access to protected resources to requests authenticated with an appropriately scoped access token.
- Enable deauthorization of access tokens via user interface. Show a list of authorized applications and their associated access details and enable users to revoke authorizations from the service provider (host).
2.4 Supporting Technical Resources
3. Recommended Practices
This section is non-normative.
Conformance certification ensures consistency across an important but focused scope of requirements. A healthy ecosystem will necessarily develop out the collective experience and collaboration of implementers. Implementers are encouraged to join the 1EdTech community to provide feedback and discuss how we can collectively improve our implementations and guidance.
Below are a variety of recommended practices and considertions for the implementation of the Open Badges and CLR specification.
3.1 Issuer
3.1.1 Selecting recipient and issuer identifiers, such as DID methods
Both issuers and recipients (credential subjects) of Open Badges and CLR credentials may be identified with a range of identifiers.
Issuers may be identified with an HTTP URL that resolves to an issuer profile that expresses profile and key information in JSON-LD. Or, they might be identified by a Decentralized Identifier (DID) that resolves to a document with some information about the issuer and/or its signing key(s).
DID methods most commonly used in interoperability testing by community members, both for issuer identifiers and recipient identifiers:
- The did:key method resolves identifiers to a DID document that contains a public key representation without accessing any remote resources by embedding a representation of the key itself in the DID path.
- The did:jwk method
is similar to
did:key
, except the value encoded in the DID path is abase64url
-encoded representation of a key in JWK (JSON Web Key) format. - The
did:web
method is a quick way to use HTTP URLs with DIDs, because the value in the path of the DID decodes to a URL which is then fetched, resulting in a DID document. It relies on the DNS registration of a domain holder, but many DIDs may be associated with any one domain or subdomain.
Technically, this set of DID methods whose use is commonly observed among early implementers is a narrow range of the DID methods proposed, and each of them lacks some capabilities promoted as possibilities with certain DID methods, such as the ability to rotate keys periodically, recover control after losing relevant keys, or avoidance of the use of DNS. The DID Method Rubric provides a number of relevant comparison factors. Usage of other DID methods may significantly change in the coming years as the consumer technology landscape and open source libraries develop.
The OB 3.0 and CLR 2.0 specifications make no normative requirements strictly limiting which DID methods may be used. Implementers have an incentive to create interoperable experiences with one another through implementing common DID methods and testing interoperability paths for users. In practice, the DID method(s) a credential's Issuer supports being the same as the DID methods Hosts and Displayers (or other wallets and verifiers) support is what governs interoperability.
The Open Badges, CLR and broader Verifiable Credentials ecosystems will take time to converge on reliable interoperability pathways. Specific implementations working together through cooperation and communication will create the opportunities for others to make compatible implementation choices as well as inform future normative specification versions.
3.1.2 Selecting proof methods and crypto algorithms
The OB and CLR specifications define some requirements around the signing or proving of credentials (see Proofs). Two formats of proof method are introduced, JWTs and Linked Data Proofs. Within each format, there are still a range of options that issuers may select for cryptographically signing the credentials. Notably, signing algorithm selection and its closely related concept of key material expression format must be considered. The best choices within these options sometimes depend on other parts of the issuer's tech stack and which options are supported among wallets and verifiers with whom badge recipients want to share their badges.
The OB specification identifies some specific options, which are used by the conformance test suite to check product implementations. These identified algorithms will likely see the broadest early implementation within Open Badges.
- Linked Data Proofs using the Data Integrity EdDSA Cryptosuites v1.0. Issuers produce an
DataIntegrityProof
proof referencing a key URL of a public key expressed ineddsa-rdf-2022
format as its verificationMethod. - JWTs with
RSA256
algorithm, with key material published as JSON Web Key (JWK).
A step-by-step guide to signing an OB or CLR is provided in the OB specification section on Proofs. In order to achieve certification, implementers must be able to pass conformance testing with one of the listed methods, but it is expected that the ecosystem will grow as issuers, verifiers, and other services explore new approaches.
It is important to not only prevent unauthorized access to keys and application processes that can trigger signing. At least as important to keeping the signing keys themselves safe is being confident in knowing if keys may have been accessed or compromised with a high degree of confidence. Considerations include:
- Issuers may wish to make use of Hardware Security Modules (HSMs) whenever possible that prevent keys from leaving the device where authorized signing occurs.
- Cloud platform Key Management Services are largely not yet compatible with
Ed25519 keys and may not be able to generate the signatures within linked
data proofs.
- HashiCorp Vault (open source or in HashiCorp cloud) offers a Ed25519-compatible sign API via its "Transit" API.
- Google Cloud Platform supports RSA and ECDSA on the non-NIST secp256k1 curve but not Ed25519.
- JWT signing with RSA family keys may have broader support in systems like this across all major cloud vendors offering a KMS.
3.1.3 Publishing Achievement
definitions and selecting Achievement
identifiers
Arguably the most important field for an Achievement
is the id
, the
creator's primary identifier for that achievement. It is expressed as a URI. Two
approaches for identifier expression are common, with differing capabilities and
slightly different instructions for interpretation:
- Use an HTTPS URL as the identifier: Issuer systems and other achievement
publishing systems can publish achievements at the identifier URLs. Clients
can use the URL to request the metadata directly from its creator when a
client wants an authoritative representation of the issuer's current
understanding of the metadata associated with the
Achievement
. When twoOpenBadgeCredentials
are issued at different points in time but reference the sameAchievement.id
, they may contain slightly different representations of theAchievement
metadata itself. Relying parties are encouraged to understand the embedded signed data as the representation that the issuer had for the credential at the time it was issued, and they may encounter a different representation embedded in a different credential, which they should understand as a different version of the same achievement. The issuer may use the optionalversion
property to express a label for each of these versions for presentation where relevant. At any point in time, a relying party may request an updated copy of theAchievement
from itsid
URL. If the response returnsAchievement
data successfully, the client should understand the retrieved metadata to represent the issuer's current understanding of theAchievement
. When relying parties encounter the same HTTPS-type achievement ID in AchievmentCredentials across multiple issuers, they can assume that the issuers did intend to recognize the same achievement, as it is defined by its publisher, but they cannot make an assumption that each of the issuers were duly authorized to recognize this achievement by its creator or even that theAchievement
honestly represents the identity of its creator, unless the relying party verifies anOpenBadgeCredential
referencing thisAchievement
issued by the creator referenced in the copy of theAchievement
retrieved from its ID URL. Future versions of Open Badges may address use cases and normative requirements serving use cases around verifiable authorship of anAchievement
or delegation of capabilities related to anAchievement
by theAchievement
's creator. - Use a UUID: Issuers sometimes assign an identifier that is assumed to be
locally unique to that issuer but cannot be dereferenced. Nevertheless,
relying parties may encounter multiple
OpenBadgeCredentials
that reference an achievement with this ID over time. ForOpenBadgeCredentials
from the same issuer that reference anAchievement
with the same ID, relying parties should interpret these as different versions of the sameAchievement
. When the same UUID-typeAchievement.id
is referenced by different issuers across multipleOpenBadgeCredentials
, relying parties cannot authoritatively determine that the intent was to recognize the same semantic achievement.
A common use case among Open Badges implementers is for a verifier to expect a
particular Achievement
claim in an OpenBadgeCredential
from a specific
issuer. With Open Badges 2.0, it was presumed that verification that an
achievement (BadgeClass
) was associated with a credential (Assertion
) issuer
as part of verification, by determining that hosted Achievement
IDs were on
the same domain as hosted Assertion IDs and/or hosted Issuer IDs. With OB 3.0,
some of this capability can no longer be assumed to remain. This is partly
because there is no longer a requirement for issuer profiles to use HTTP IDs,
but also because integrity verification is assumed to occur at the Verifiable
Credentials Data Model level only, because wallets and credentials verifiers
will primarily focus on verifying the integrity of the proof on each credential
without assumed capacity to verify other relationships represented deeply within
these credentials even if OB 3.0 had included such a mechanism in its scope.
3.1.4 Managing credential status and revocation
The ability to mark a credential as revoked is an important capability for many organizations that make use of Open Badges and CLR. The Verifiable Credentials Data Model v1.1 offers an extensible mechanism by which a credential status resource may be exposed within a credential. Various use cases and solutions have been developed to enable credential status checking with a range of capabilities and implications. OB and CLR reference optional 1EdTech extensions supporting verifiers in obtaining updated representations of credentials and checking for revocation. Issuers and verifiers need to support a common mechanism in order for status checking to work, and yet issuers often need to produce the credential without knowing which other parties might someday rely on it or what methods those verifiers may support. Here are some mechanisms identified by the implementing community for status and revocation management.
- The 1EdTech Revocation List Status Method accompanies the OB and CLR specifications. This enables verifiers to query for status results without revealing to the issuer which specific credential's status is being checked. It does reveal to the requester a list of credential IDs claimed by the issuer to be associated with it, though it is not assumed to be exhaustive or accurate except to indicate the status of the credential known to the requester, because issuers may use multiple lists concurrently, packaged with different sets of credentials and red herrings may appear in some lists. The 1EdTech certification process and validator software will support this status checking method. A reason for revocation may be available for a revoked credential.
- The 1EdTech Credential Refresh Service also accompanies the OB and CLR specifications and enables fetching of an updated version of a credential under inspection by a verifier. The 1EdTech verifier tools will request updated version if such an endpoint is indicated in the badge. There is no approach to authentication or variable authorization defined in this specification, so if an issuer uses it, it is presumed that any client could request the latest version of the credential from this endpoint if they knew the correct URL. Future versions of this specification may serve use cases that require more in-depth protection of refresh endpoints.
- Another option in the space is the Credential Status List 2021 specification, which was adopted as a standards-track specification by the VCWG on December 14th 2022. This protocol enables an issuer to publish a compactly encoded list of status indicator bits covering many credentials at once in an unnamed order. Within each issued credential, the issuer includes a pointer to a specific bit within the bulk status list. This enables verifiers to efficiently query for status results without revealing which specific credential's status is being checked. It does not feature the ability to retrieve a revocation reason for a revoked credential, nor does it provide a refreshed version of the credential consistent with the issuer's latest status data, features that are sometimes bundled with revocation.
3.1.5 Alignment with CASE items
IMS Competencies and Academic Standards Exchange (CASE) Service Version 1.0 [CASE-10] specification defines how systems exchange and manage information about learning standards and/or competencies in a consistent and referenceable way.
[CASE-10] defines an information model consisting in, briefly, a container
(CFDoc
) of a set of academic standard/competency document definitions
(CFItem
). These CFItem
can have associations with others CFItem
of another
containers, allowing several types of relationships between learning
objectives/competences from one institution and another.
In Open Badges and Comprehensive Learner Record, the recording of related
skills, competencies, standards, and other associations are enabled by the
alignment
of an Achievement
. This field defines the fields for univocally
establish a connection between the Achievement
and a node in an educational
framework, i.e CFItem
.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json"
],
"id": "http://example.edu/credentials/3732",
"type": ["VerifiableCredential", "OpenBadgeCredential"],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Example University Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "https://1edtech.edu/achievements/1",
"type": "Achievement",
"criteria": {
"narrative": "Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the text, including determining where the text leaves matters uncertain"
},
"description": "Analyze a sample text",
"name": "Text analysis",
"alignment": [{
"type": "Alignment",
"targetCode": "74f5bb7d-d7cc-11e8-824f-0242ac160002",
"targetFramework": "Alabama Course of Study: English Language Arts",
"targetName": "Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the text, including determining where the text leaves matters uncertain",
"targetType": "CFItem",
"targetUrl": "https://caseregistry.imsglobal.org/uri/74f5bb7d-d7cc-11e8-824f-0242ac160002"
}]
}
}
}
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json", "https://w3id.org/security/data-integrity/v1" ], "id": "http://example.edu/credentials/3732", "type": [ "VerifiableCredential", "OpenBadgeCredential" ], "issuer": { "id": "https://example.edu/issuers/565049", "type": "Profile", "name": "Example University" }, "issuanceDate": "2010-01-01T00:00:00Z", "name": "Example University Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "AchievementSubject", "achievement": { "id": "https://1edtech.edu/achievements/1", "type": "Achievement", "criteria": { "narrative": "Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the text, including determining where the text leaves matters uncertain" }, "description": "Analyze a sample text", "name": "Text analysis", "alignment": [ { "type": "Alignment", "targetCode": "74f5bb7d-d7cc-11e8-824f-0242ac160002", "targetFramework": "Alabama Course of Study: English Language Arts", "targetName": "Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the text, including determining where the text leaves matters uncertain", "targetType": "CFItem", "targetUrl": "https://caseregistry.imsglobal.org/uri/74f5bb7d-d7cc-11e8-824f-0242ac160002" } ] } }, "proof": [ { "type": "DataIntegrityProof", "created": "2023-11-09T13:59:58Z", "verificationMethod": "https://example.edu/issuers/565049#z6MkjTUMoMcbxeFGZ7c89JKKJ2SsVqNbuxA9ZDZPLWvqSLzh", "cryptosuite": "eddsa-rdfc-2022", "proofPurpose": "assertionMethod", "proofValue": "zheGx34BASzaK73MWY2rVJyjAuLjVqcedgniXnenhvcPcFkiD1FXFzeF6pZ61wqXPRBeMyoU1yB6efeERKAgn4zL" } ] }
---------------- JWT header --------------- { "alg": "RS256", "typ": "JWT", "jwk": { "e": "AQAB", "kty": "RSA", "n": "0viIUTX2WQs2bINUjWAmgXNoI6376zo2aRpvsERkI-NKzFBvCek0fF90WmUgMKLYZKawpz aWNYZTk6ioObfJRyV2TiSAqZWHznovv-_eJ1LRTMn-jYkH6oSLgQgJ2wnxwCdNq32jXw4S5Y-7yv7lU7 0wOg8U1a_jLETnXSMmL4hkCuTP2DMQmGNzCzGaWzYayxJhc11Vqss8dTehzKHplvZT--nQ2uudjBGFEB C3vJV4rWmprO6VIL5kcwAueUbwH5udN01faYsHaLgvrbl5JTFj3ugLij3Ouq4KK1XD-6TQwsay5VRlVg WSe-m_VUX1vbgJeMfgisULXW0B3orcPQ" } } --------------- JWT payload --------------- // NOTE: The example below uses a valid VC-JWT serialization // that duplicates the iss, nbf, jti, and sub fields in the // Verifiable Credential (vc) field. { "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json" ], "id": "http://example.edu/credentials/3732", "type": [ "VerifiableCredential", "OpenBadgeCredential" ], "issuer": { "id": "https://example.edu/issuers/565049", "type": "Profile", "name": "Example University" }, "issuanceDate": "2010-01-01T00:00:00Z", "name": "Example University Degree", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "AchievementSubject", "achievement": { "id": "https://1edtech.edu/achievements/1", "type": "Achievement", "criteria": { "narrative": "Cite strong and thorough textual evidence to support ana lysis of what the text says explicitly as well as inferences drawn from the text , including determining where the text leaves matters uncertain" }, "description": "Analyze a sample text", "name": "Text analysis", "alignment": [ { "type": "Alignment", "targetCode": "74f5bb7d-d7cc-11e8-824f-0242ac160002", "targetFramework": "Alabama Course of Study: English Language Arts", "targetName": "Cite strong and thorough textual evidence to support analysis of what the text says explicitly as well as inferences drawn from the t ext, including determining where the text leaves matters uncertain", "targetType": "CFItem", "targetUrl": "https://caseregistry.imsglobal.org/uri/74f5bb7d-d7cc-1 1e8-824f-0242ac160002" } ] } } }, "iss": "https://example.edu/issuers/565049", "nbf": 1262304000, "jti": "http://example.edu/credentials/3732", "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21" } --------------- JWT --------------- eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i OiIwdmlJVVRYMldRczJiSU5ValdBbWdYTm9JNjM3NnpvMmFScHZzRVJrSS1OS3pGQnZDZWswZkY5MFdt VWdNS0xZWkthd3B6YVdOWVpUazZpb09iZkpSeVYyVGlTQXFaV0h6bm92di1fZUoxTFJUTW4tallrSDZv U0xnUWdKMndueHdDZE5xMzJqWHc0UzVZLTd5djdsVTcwd09nOFUxYV9qTEVUblhTTW1MNGhrQ3VUUDJE TVFtR056Q3pHYVd6WWF5eEpoYzExVnFzczhkVGVoektIcGx2WlQtLW5RMnV1ZGpCR0ZFQkMzdkpWNHJX bXByTzZWSUw1a2N3QXVlVWJ3SDV1ZE4wMWZhWXNIYUxndnJibDVKVEZqM3VnTGlqM091cTRLSzFYRC02 VFF3c2F5NVZSbFZnV1NlLW1fVlVYMXZiZ0plTWZnaXNVTFhXMEIzb3JjUFEifX0.eyJ2YyI6eyJAY29u dGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vcHVy bC5pbXNnbG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0LTMuMC4yLmpzb24iXSwiaWQiOiJodHRw Oi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsInR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRp YWwiLCJPcGVuQmFkZ2VDcmVkZW50aWFsIl0sImlzc3VlciI6eyJpZCI6Imh0dHBzOi8vZXhhbXBsZS5l ZHUvaXNzdWVycy81NjUwNDkiLCJ0eXBlIjoiUHJvZmlsZSIsIm5hbWUiOiJFeGFtcGxlIFVuaXZlcnNp dHkifSwiaXNzdWFuY2VEYXRlIjoiMjAxMC0wMS0wMVQwMDowMDowMFoiLCJuYW1lIjoiRXhhbXBsZSBV bml2ZXJzaXR5IERlZ3JlZSIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1wbGU6ZWJm ZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwidHlwZSI6IkFjaGlldmVtZW50U3ViamVjdCIsImFjaGll dmVtZW50Ijp7ImlkIjoiaHR0cHM6Ly8xZWR0ZWNoLmVkdS9hY2hpZXZlbWVudHMvMSIsInR5cGUiOiJB Y2hpZXZlbWVudCIsImNyaXRlcmlhIjp7Im5hcnJhdGl2ZSI6IkNpdGUgc3Ryb25nIGFuZCB0aG9yb3Vn aCB0ZXh0dWFsIGV2aWRlbmNlIHRvIHN1cHBvcnQgYW5hbHlzaXMgb2Ygd2hhdCB0aGUgdGV4dCBzYXlz IGV4cGxpY2l0bHkgYXMgd2VsbCBhcyBpbmZlcmVuY2VzIGRyYXduIGZyb20gdGhlIHRleHQsIGluY2x1 ZGluZyBkZXRlcm1pbmluZyB3aGVyZSB0aGUgdGV4dCBsZWF2ZXMgbWF0dGVycyB1bmNlcnRhaW4ifSwi ZGVzY3JpcHRpb24iOiJBbmFseXplIGEgc2FtcGxlIHRleHQiLCJuYW1lIjoiVGV4dCBhbmFseXNpcyIs ImFsaWdubWVudCI6W3sidHlwZSI6IkFsaWdubWVudCIsInRhcmdldENvZGUiOiI3NGY1YmI3ZC1kN2Nj LTExZTgtODI0Zi0wMjQyYWMxNjAwMDIiLCJ0YXJnZXRGcmFtZXdvcmsiOiJBbGFiYW1hIENvdXJzZSBv ZiBTdHVkeTogRW5nbGlzaCBMYW5ndWFnZSBBcnRzIiwidGFyZ2V0TmFtZSI6IkNpdGUgc3Ryb25nIGFu ZCB0aG9yb3VnaCB0ZXh0dWFsIGV2aWRlbmNlIHRvIHN1cHBvcnQgYW5hbHlzaXMgb2Ygd2hhdCB0aGUg dGV4dCBzYXlzIGV4cGxpY2l0bHkgYXMgd2VsbCBhcyBpbmZlcmVuY2VzIGRyYXduIGZyb20gdGhlIHRl eHQsIGluY2x1ZGluZyBkZXRlcm1pbmluZyB3aGVyZSB0aGUgdGV4dCBsZWF2ZXMgbWF0dGVycyB1bmNl cnRhaW4iLCJ0YXJnZXRUeXBlIjoiQ0ZJdGVtIiwidGFyZ2V0VXJsIjoiaHR0cHM6Ly9jYXNlcmVnaXN0 cnkuaW1zZ2xvYmFsLm9yZy91cmkvNzRmNWJiN2QtZDdjYy0xMWU4LTgyNGYtMDI0MmFjMTYwMDAyIn1d fX19LCJpc3MiOiJodHRwczovL2V4YW1wbGUuZWR1L2lzc3VlcnMvNTY1MDQ5IiwibmJmIjoxMjYyMzA0 MDAwLCJqdGkiOiJodHRwOi8vZXhhbXBsZS5lZHUvY3JlZGVudGlhbHMvMzczMiIsInN1YiI6ImRpZDpl eGFtcGxlOmViZmViMWY3MTJlYmM2ZjFjMjc2ZTEyZWMyMSJ9.w3O7KAlre4CdX7g_TKhD69H7Yq5DlCe ZuDUV9SZGPzzTmb9pHaTzc-e8CuebNDV_qSXTpcSyQJ_FkTewCl6kuWY9LNFDbtX9e0pxpztF61YCb91 6is0767eeqkSk7ojpeBQv8NIK_ne2uhFVlDpaFB84bgPZJKzBL6ggzxw2KLDdbh7CojYt5Xk4juf0KDq 0Z72nLARUemEyPXeYnn-FIhwEQCZAXhv9kYUPQQc2nTQEIPQM1RAH0vmEhRGQmgQO46B_cJ37jKteLkc k571aHGwiMJlHUzoPJ2TZy6vQkSbtl9t8mK7yRLmhjlMwGvHi0AsjoLJHBxdXP3v23JQ1SA
3.1.6 Skills
A Skill Assertion credential is just like a basic OpenBadgeCredential
in how
an Achievement
is included, except that it makes a claim referencing an
Achievement
that is generic to allow for use by many possible issuers. The
Achievement
may describe alignment to external competency or skill
definitions, such as a CFItem
, but the most important aspect of the skill
assertion pattern is the shared use of a common achievement that represents a
skill or competency across multiple OpenBadgeCredential
issuers.
This usage of shared achievements enables consumers to describe specific achievements that they would like learners to hold without being particular about where the learner obtains a credential certifying that achievement. This recognizes the many pathways that lifelong learners find to attain comparable skills.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json"
],
"id": "http://1edtech.edu/credentials/3732",
"type": ["VerifiableCredential", "OpenBadgeCredential"],
"name": "Solve and graph linear equations and inequalities",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "https://example.com/achievements/math/linear-1",
"type": "Achievement",
"achievementType": "Competency",
"creator": {
"id": "https://example.com/issuers/123767",
"type": "Profile",
"name": "Example Industry Group",
"url": "https://example.com",
"description": "Example Industry Group is a consortium of luminaries who publish skills data for common usage.",
"email": "info@exammple.com"
},
"criteria": {
"narrative": "Learners must demonstrate understanding of linear algebra and graphic representation of linear equations."
},
"description": "This achievement represents developing capability to solve and graph linear equations and inequalities",
"image": {
"id": "https://example.com/achievements/math/linear-1/image",
"type": "Image",
"caption": "A line, sloping upward optimistically"
},
"name": "Linear equations and inequalities"
}
},
"issuer": {
"id": "https://1edtech.edu/issuers/565049",
"type": "Profile",
"name": "1EdTech University",
"url": "https://1edtech.edu",
"phone": "1-222-333-4444",
"description": "1EdTech University provides online degree programs.",
"image": {
"id": "https://1edtech.edu/logo.png",
"type": "Image",
"caption": "1EdTech University logo"
},
"email": "registrar@1edtech.edu"
},
"issuanceDate": "2022-07-01T00:00:00Z",
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
]
}
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json", "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json", "https://w3id.org/security/data-integrity/v1" ], "id": "http://1edtech.edu/credentials/3732", "type": [ "VerifiableCredential", "OpenBadgeCredential" ], "name": "Solve and graph linear equations and inequalities", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "AchievementSubject", "achievement": { "id": "https://example.com/achievements/math/linear-1", "type": "Achievement", "achievementType": "Competency", "creator": { "id": "https://example.com/issuers/123767", "type": "Profile", "name": "Example Industry Group", "url": "https://example.com", "description": "Example Industry Group is a consortium of luminaries who publish skills data for common usage.", "email": "info@exammple.com" }, "criteria": { "narrative": "Learners must demonstrate understanding of linear algebra and graphic representation of linear equations." }, "description": "This achievement represents developing capability to solve and graph linear equations and inequalities", "image": { "id": "https://example.com/achievements/math/linear-1/image", "type": "Image", "caption": "A line, sloping upward optimistically" }, "name": "Linear equations and inequalities" } }, "issuer": { "id": "https://1edtech.edu/issuers/565049", "type": "Profile", "name": "1EdTech University", "url": "https://1edtech.edu", "phone": "1-222-333-4444", "description": "1EdTech University provides online degree programs.", "image": { "id": "https://1edtech.edu/logo.png", "type": "Image", "caption": "1EdTech University logo" }, "email": "registrar@1edtech.edu" }, "issuanceDate": "2022-07-01T00:00:00Z", "credentialSchema": [ { "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json", "type": "1EdTechJsonSchemaValidator2019" } ], "proof": [ { "type": "DataIntegrityProof", "created": "2023-11-09T13:59:58Z", "verificationMethod": "https://1edtech.edu/issuers/565049#z6Mkhp7dmNhneHpRXFwnMoro63Nt6pnGXh9kyTeT5Q79CRq4", "cryptosuite": "eddsa-rdfc-2022", "proofPurpose": "assertionMethod", "proofValue": "z2TfHNHpuNyb5M9K8tkQxhB8jggo3g34WX9k93heGeCDz2CrUGZDsZfBTtJnvXhummVTcWxHA2gB1LS98dxFTUFMm" } ] }
---------------- JWT header --------------- { "alg": "RS256", "typ": "JWT", "jwk": { "e": "AQAB", "kty": "RSA", "n": "jMJUqfOo9i4srfwSj-eWMKJ_4yEt3dvJ2GEXJ1Cc-OMxCozBHuxNJcjJyQor5IovRiO97q e6FHPfd3OwQiodzUmGRHHttmkubJDbKysSc3aaxJHwhrqjM5eC0pYXtCkgsGMHFRifQkzE9bzPeJoHtb yRxSMvdkERn8fJqlcr7MtOCvvKIEsp7XzeyovmrmcM-pxvUr0WtOnp8L8eLZoXxPbK8iBv1hI0d1aHO3 Zn2GJU_yEdM8OXTQUD54rpy3b1GPeMXcly24e9spEZT6z68PUSG0XJ7H1CtdRcSVpWfVaDlms26rqT0j 0iA00cgE17e1S76F6Bfbv0LUJUEiPVIQ" } } --------------- JWT payload --------------- // NOTE: The example below uses a valid VC-JWT serialization // that duplicates the iss, nbf, jti, and sub fields in the // Verifiable Credential (vc) field. { "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json", "https://purl.imsglobal.org/spec/ob/v3p0/extensions.json" ], "id": "http://1edtech.edu/credentials/3732", "type": [ "VerifiableCredential", "OpenBadgeCredential" ], "name": "Solve and graph linear equations and inequalities", "credentialSubject": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "type": "AchievementSubject", "achievement": { "id": "https://example.com/achievements/math/linear-1", "type": "Achievement", "achievementType": "Competency", "creator": { "id": "https://example.com/issuers/123767", "type": "Profile", "name": "Example Industry Group", "url": "https://example.com", "description": "Example Industry Group is a consortium of luminaries w ho publish skills data for common usage.", "email": "info@exammple.com" }, "criteria": { "narrative": "Learners must demonstrate understanding of linear algebr a and graphic representation of linear equations." }, "description": "This achievement represents developing capability to sol ve and graph linear equations and inequalities", "image": { "id": "https://example.com/achievements/math/linear-1/image", "type": "Image", "caption": "A line, sloping upward optimistically" }, "name": "Linear equations and inequalities" } }, "issuer": { "id": "https://1edtech.edu/issuers/565049", "type": "Profile", "name": "1EdTech University", "url": "https://1edtech.edu", "phone": "1-222-333-4444", "description": "1EdTech University provides online degree programs.", "image": { "id": "https://1edtech.edu/logo.png", "type": "Image", "caption": "1EdTech University logo" }, "email": "registrar@1edtech.edu" }, "issuanceDate": "2022-07-01T00:00:00Z", "credentialSchema": [ { "id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achie vementcredential_schema.json", "type": "1EdTechJsonSchemaValidator2019" } ] }, "iss": "https://1edtech.edu/issuers/565049", "nbf": 1656633600, "jti": "http://1edtech.edu/credentials/3732", "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21" } --------------- JWT --------------- eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4i OiJqTUpVcWZPbzlpNHNyZndTai1lV01LSl80eUV0M2R2SjJHRVhKMUNjLU9NeENvekJIdXhOSmNqSnlR b3I1SW92UmlPOTdxZTZGSFBmZDNPd1Fpb2R6VW1HUkhIdHRta3ViSkRiS3lzU2MzYWF4Skh3aHJxak01 ZUMwcFlYdENrZ3NHTUhGUmlmUWt6RTlielBlSm9IdGJ5UnhTTXZka0VSbjhmSnFsY3I3TXRPQ3Z2S0lF c3A3WHpleW92bXJtY00tcHh2VXIwV3RPbnA4TDhlTFpvWHhQYks4aUJ2MWhJMGQxYUhPM1puMkdKVV95 RWRNOE9YVFFVRDU0cnB5M2IxR1BlTVhjbHkyNGU5c3BFWlQ2ejY4UFVTRzBYSjdIMUN0ZFJjU1ZwV2ZW YURsbXMyNnJxVDBqMGlBMDBjZ0UxN2UxUzc2RjZCZmJ2MExVSlVFaVBWSVEifX0.eyJ2YyI6eyJAY29u dGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSIsImh0dHBzOi8vcHVy bC5pbXNnbG9iYWwub3JnL3NwZWMvb2IvdjNwMC9jb250ZXh0LTMuMC4yLmpzb24iLCJodHRwczovL3B1 cmwuaW1zZ2xvYmFsLm9yZy9zcGVjL29iL3YzcDAvZXh0ZW5zaW9ucy5qc29uIl0sImlkIjoiaHR0cDov LzFlZHRlY2guZWR1L2NyZWRlbnRpYWxzLzM3MzIiLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFs IiwiT3BlbkJhZGdlQ3JlZGVudGlhbCJdLCJuYW1lIjoiU29sdmUgYW5kIGdyYXBoIGxpbmVhciBlcXVh dGlvbnMgYW5kIGluZXF1YWxpdGllcyIsImNyZWRlbnRpYWxTdWJqZWN0Ijp7ImlkIjoiZGlkOmV4YW1w bGU6ZWJmZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIiwidHlwZSI6IkFjaGlldmVtZW50U3ViamVjdCIs ImFjaGlldmVtZW50Ijp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9hY2hpZXZlbWVudHMvbWF0aC9s aW5lYXItMSIsInR5cGUiOiJBY2hpZXZlbWVudCIsImFjaGlldmVtZW50VHlwZSI6IkNvbXBldGVuY3ki LCJjcmVhdG9yIjp7ImlkIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXJzLzEyMzc2NyIsInR5cGUi OiJQcm9maWxlIiwibmFtZSI6IkV4YW1wbGUgSW5kdXN0cnkgR3JvdXAiLCJ1cmwiOiJodHRwczovL2V4 YW1wbGUuY29tIiwiZGVzY3JpcHRpb24iOiJFeGFtcGxlIEluZHVzdHJ5IEdyb3VwIGlzIGEgY29uc29y dGl1bSBvZiBsdW1pbmFyaWVzIHdobyBwdWJsaXNoIHNraWxscyBkYXRhIGZvciBjb21tb24gdXNhZ2Uu IiwiZW1haWwiOiJpbmZvQGV4YW1tcGxlLmNvbSJ9LCJjcml0ZXJpYSI6eyJuYXJyYXRpdmUiOiJMZWFy bmVycyBtdXN0IGRlbW9uc3RyYXRlIHVuZGVyc3RhbmRpbmcgb2YgbGluZWFyIGFsZ2VicmEgYW5kIGdy YXBoaWMgcmVwcmVzZW50YXRpb24gb2YgbGluZWFyIGVxdWF0aW9ucy4ifSwiZGVzY3JpcHRpb24iOiJU aGlzIGFjaGlldmVtZW50IHJlcHJlc2VudHMgZGV2ZWxvcGluZyBjYXBhYmlsaXR5IHRvIHNvbHZlIGFu ZCBncmFwaCBsaW5lYXIgZXF1YXRpb25zIGFuZCBpbmVxdWFsaXRpZXMiLCJpbWFnZSI6eyJpZCI6Imh0 dHBzOi8vZXhhbXBsZS5jb20vYWNoaWV2ZW1lbnRzL21hdGgvbGluZWFyLTEvaW1hZ2UiLCJ0eXBlIjoi SW1hZ2UiLCJjYXB0aW9uIjoiQSBsaW5lLCBzbG9waW5nIHVwd2FyZCBvcHRpbWlzdGljYWxseSJ9LCJu YW1lIjoiTGluZWFyIGVxdWF0aW9ucyBhbmQgaW5lcXVhbGl0aWVzIn19LCJpc3N1ZXIiOnsiaWQiOiJo dHRwczovLzFlZHRlY2guZWR1L2lzc3VlcnMvNTY1MDQ5IiwidHlwZSI6IlByb2ZpbGUiLCJuYW1lIjoi MUVkVGVjaCBVbml2ZXJzaXR5IiwidXJsIjoiaHR0cHM6Ly8xZWR0ZWNoLmVkdSIsInBob25lIjoiMS0y MjItMzMzLTQ0NDQiLCJkZXNjcmlwdGlvbiI6IjFFZFRlY2ggVW5pdmVyc2l0eSBwcm92aWRlcyBvbmxp bmUgZGVncmVlIHByb2dyYW1zLiIsImltYWdlIjp7ImlkIjoiaHR0cHM6Ly8xZWR0ZWNoLmVkdS9sb2dv LnBuZyIsInR5cGUiOiJJbWFnZSIsImNhcHRpb24iOiIxRWRUZWNoIFVuaXZlcnNpdHkgbG9nbyJ9LCJl bWFpbCI6InJlZ2lzdHJhckAxZWR0ZWNoLmVkdSJ9LCJpc3N1YW5jZURhdGUiOiIyMDIyLTA3LTAxVDAw OjAwOjAwWiIsImNyZWRlbnRpYWxTY2hlbWEiOlt7ImlkIjoiaHR0cHM6Ly9wdXJsLmltc2dsb2JhbC5v cmcvc3BlYy9vYi92M3AwL3NjaGVtYS9qc29uL29iX3YzcDBfYWNoaWV2ZW1lbnRjcmVkZW50aWFsX3Nj aGVtYS5qc29uIiwidHlwZSI6IjFFZFRlY2hKc29uU2NoZW1hVmFsaWRhdG9yMjAxOSJ9XX0sImlzcyI6 Imh0dHBzOi8vMWVkdGVjaC5lZHUvaXNzdWVycy81NjUwNDkiLCJuYmYiOjE2NTY2MzM2MDAsImp0aSI6 Imh0dHA6Ly8xZWR0ZWNoLmVkdS9jcmVkZW50aWFscy8zNzMyIiwic3ViIjoiZGlkOmV4YW1wbGU6ZWJm ZWIxZjcxMmViYzZmMWMyNzZlMTJlYzIxIn0.IBaiwn2tj7pi6A3ctVSTdaaXmz6RvOdsnPCAa_eBcjXT PFrreFG15F1Xd-Mp3OpQwsCeKyFOkhY8vlgqChUr0xu4stYU41OkMJxZAj7UlV1a2vgW6WIuvvgBa8Eg IZYGheqIitg5usf0_o6T_a6e6Fr38h7f7v8KBkZZXI-jnKdAyukTRNNw1IYmRnjIENXjYtDHC8eL7iAq zTjWtZAF2E0fJLawlxN3eFbjJuynR5Rz-h8K2MCM2oZ5aH5Nq1VX4V1aQGIC_Ctv6uHiM0FgInjJapli Kf_XRZrgORWizhvmUxC-p106Nl9KEUQpCDwMgRrKcq3W7D2cSIK5M6Hjpg
3.1.7 Including additional recipient profile information
Sometimes issuers want credentials to be shareable to audiences who are not
capable of authenticating subjects via an identifier such as a DID. Many of
these use cases may be served by including one or more email identifiers. (Only
partial data is shown for clarity, for example omitting the achievement
claim
within credentialSubject
.)
{
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"identifier": [
{
"type": "IdentityObject",
"hashed": false,
"identityHash": "a.exampleton@example.edu",
"identityType": "emailAddress"
}
]
}
}
If the known email address for the user is expected to no longer be a useful source of authentication, such as if the user loses access to a work or university email after leaving that organization (perhaps 6 months after graduation), an issuer may wish to provide additional identifying information, such as a name.
{
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"identifier": [
{
"type": "IdentityObject",
"hashed": false,
"identityHash": "Albert Exampleton",
"identityType": "ext:name"
}
]
}
}
Inclusion of additional personally identifiable information about the subject,
especially with "hashed": false
, reduces the potential anonymity of the
subject. Those with whom the credential is shared may share it to others, who
would be able to view this identifying information. While sharing typically
passes through control of the subject/holder, different issuers may weigh the
potential benefits of including this information against the risks of
unauthorized disclosure.
If issuers desire to include much more information about the subject in the
credential, they may add the Profile
type and include additional properties
from Profile. The above approach using IdentityObject is expected to be more
broadly usable, because displayers of OpenBadgeCredentials
will expect this
type of data. Additional data from Profile
is not expected directly within
credentialSubject
, so it is less likely that displayers would build custom
handling for these unexpected properties. An "advanced" view where users may
review the JSON data directly may be included in some displayer products, in
which case viewers would be able to review this information more directly.
{
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": ["AchievementSubject", "Profile"],
"givenName": "Albert",
"familyName": "Exampleton"
}
}
3.1.8 Embedding Evidences
Issuers can add a description of the work that the recipient did to earn the
achievement via the evidence
attribute of AchievementCredential
. This
description can be a page that links out to other pages if linking directly
to the work is infeasible.
The id
property also can be the evidence encoded as a Data URI. However,
embedding the evidence as Data URI as the id of the evidence has some caveats:
- Due to the JSON-LD canonicalization process for signing, there's a row for each field of the evidence with the id inside. If the id is the evidence itself as Data URI, the size of the payload to process grows significantly, moreover when evidence has 5 fields and is extensible.
- Some libraries fails when processing this.
Also attempting to embed large data in a credential JSON is not recommended. You should expect uneven interop performance if you do that.
Instead, the recommendation for embedding the evidence is:
- use a
urn:
URI for the id. - have a separate property (data or whatever works) that contains the text-encoded data.
3.1.9 Key provenance
Keys used in proof generation must belong to the issuer. However, there isn't a existing way in current standards to completely assure this provenance.
The following best practices establish a verification mechanism to assure that the issuer is the owner of the key used in a credential.
3.1.9.1 Linked Data proof
Linked Data Proofs defines a method to get the public key (via verificationMethod
)
which, as defined by [VC-DATA-INTEGRITY], implies the dereference of a controller
document.
Section 2.6 of [VC-DATA-INTEGRITY] describes a way to verify the association of the verification method with an issuer:
One way to check for such an association is to ensure that the value of the controller property of a proof's verification method matches the URL value used to identify the issuer or holder, respectively. This particular association indicates that the issuer or holder, respectively, is the controller of the verification method used to verify the proof.
We recommend following this practice. As an issuer, then, you must set the
value of the controller as the id
of the issuer.
3.1.9.2 External proof
When using an external proof, an issuer must set either the kid
or jwt
fields of the JOSE header of the JWS. kid
is an URI that can be dereferenced
to an object of type JWK representing the public key, wether jwt
is the
representation of the public key.
In order to assure key provenance, we recommend the use of a JWK Set (JKWS) [RFC7517]. This set, following this recommmendation, should be publicly accessible via the well-known url:
https://{domain}/.well-known/jwks.json
The reponse of a request to this url is a JSON-serialized representation
of the JKWS with the media type application/jwk-set+json
.
Section 6 of [SEC-11] contains recommendations for key management.
When using the kid
attribute, an issuer must set it to an existing key in
its set. On the other hand, when using the jwt
attribute, the key set in this
field must be one of the keys in the set.
3.1.9.2.1 Issuing platforms with multiple issuers
[RFC7517] allows adding additional members to the JWK format:
Additional members can be present in the JWK; if not understood by implementations encountering them, they MUST be ignored. Member names used for representing key parameters for different keys types need not be distinct. Any new member name should either be registered in the IANA "JSON Web Key Parameters" registry established by Section 8.1 or be a value that contains a Collision-Resistant Name.
We propose leverage this to add a new member iss
in the JWK for the issuer's id
.
3.1.9.3 JWK Set endpoint
Following this recommendation ultimatelly means that, for an issuer to be trusted, the endpoint for the issuer's Json Web Key Set should be publicly available at any time a credential is verified, which can happen long after the issuing of the credential. If don't, there's a potential issue of a valid credential not accepted because the endpoint is no longer available.
Following this recommendation, thus, implies a commitment for the issuer to maintain its JWK Set and publicly expose it throught the endpoint.
3.2 Displayer
3.2.1 Cryptosuites in Linked Data Proofs
Linked data proofs imply the use of a cryptosuite for its generation and further verification. The Open Badges 3.0 and Comprehensive Learner Record 2.0 specifications define the cryptosuite to use.
The change of the cryptosuite has impact in newly issued credentials. But there are already issued credentials with a proof generated using a now old cryptosuite. Verifiers should support prior cryptosuites, specially when the credential doesn't define the refresh service. In that case, is argually that the issuer will provide a refreshed version of the credential with a proof computed with the current designed cryptosuite.
Prior designed cryptosuites in both OB 3.0 and CLR 2.0 were:
eddsa-2022
Ed25519Signature2020
3.2.2 Key provenance
Keys used in proof generation must belong to the issuer. However, there isn't a existing way in current standards to completely assure this provenance.
The following best practices establish a verification mechanism to assure that the issuer is the owner of the key used in a credential.
3.2.2.1 Linked Data proof
Linked Data Proofs defines a method to get the public key (via verificationMethod
) which, as defined by [VC-DATA-INTEGRITY], implies the
dereference of a controller document.
Section 2.6 of [VC-DATA-INTEGRITY] describes a way to verify the association of the verification method with an issuer:
One way to check for such an association is to ensure that the value of the controller property of a proof's verification method matches the URL value used to identify the issuer or holder, respectively. This particular association indicates that the issuer or holder, respectively, is the controller of the verification method used to verify the proof.
We recommend following this practice. As an verifier, then, you must check that
the value of the controller is the id
of the issuer.
3.2.2.2 External proof
When using an external proof, an issuer must set either the kid
or jwt
fields of the JOSE header of the JWS. kid
is an URI that can be dereferenced
to an object of type JWK representing the public key, wether jwt
is the
representation of the public key.
Section 6.3.1 of [VC-DATA-MODEL] extends the definition of kid
as
kid
MAY be used if there are multiple keys associated with the issuer of the JWT. The key discovery is out of the scope of this specification. For example, thekid
can refer to a key in a DID document, or can be the identifier of a key inside a JWKS.
With these two premises, the recommendation for verifing key provenance is using JWK Set. A verifier must, then, get the public JKWS of the issuer for further check of the provided key.
In order to get the issuer's JKWS, a verifier must build a well-known url with
the authority
part of the issuer's id
([RFC3986]):
https://{authority}/.well-known/jwks.json
A verifier must make a HTTP request to this endpoint with an accept header of
application/jwk-set+json
. The response of this call must a JWKS.
After the request, a verifier must check that the provided key in in the
returned set. If the key in the JOSE Header in referenced by the kid
field, this kid
must be in the set. On the other hand, if the key is
represented by the jwk
field, this jwk
must be in the set with
any specified kid
.
If the found JWT in the set contains the member iss
, this must be equal
to issuer's id
.
3.3 Host
3.3.1 Open Badges 3.0 API recommendations
Consider the following example two products using the OB 3.0 API to interact:
Example: Sending an Open Badge to a credential backpack via API
Luis is in college pursuing a technical degree. He completes an assessment in class and receives a grade. He is notified by email that he has earned a badge and clicks through, where he is authenticated to the college's student Open Badges portal using his college single sign on. He sees that he has actually earned two badges, each representing competencies, that were assessed by his instructor. The website says the CLR is ready to save, so Luis selects that option. The application shows him a list of two credential backpack providers he can use to save. There is an advanced toggle that reveals an additional option to enter a service provider URL, but Luis closes that and picks one of the known options that looks good and has a good privacy policy. He selects that option and is directed to the backpack site where he signs up for an account. After he completes registration, he is prompted that he may return to the Open Badges portal to complete receiving his credential. He confirms and appears back in the Open Badges portal, where a confirmation message greets him saying all credentials were successfully transferred. He then confirms to return once more to the backpack site, where sees the two Open Badges representing his competencies.
Luis looks at a page detailing the metadata of the first achievement, including the achievement type of Competency and a description of what he had been working to learn. He thinks that being able to look back at these and see the description will help him prepare for job interviews in the future.
Luis sees an option to share his competency badge to a social media site. He proceeds and is prompted to customize sharing settings, including whether anyone with the link is able to view full verifiable details or if viewers need to request access. He selects full details and shares the generated URL to a professional social network site, where a preview card appears including relevant keywords for the competency. His post receives a like from one of Luis's friends immediately.
This is a long user workflow. What makes this interaction successful?
- These products each have a clear sense of their scope of responsibility. One is the "Issuer" of the Open Badges, the other is the "Backpack". They can each implement the necessary parts of the experience that fits their role and not invest deeply in other parts. For example, the issuer platform doesn't need to offer a system of sharing URLs and online access control management, all it does is sign the credential and implement the Client side of the Open Badges API. The Backpack handles the sharing, including giving Luis significant control over URL-based access. This takes product focus.
- Known-successful integrations are highlighted in the experience. This takes cooperation between implementation partners, but the benefit is clear: Luis doesn't need to know what an Open Badge is or how to find a compatible backpack on the TrustEd Apps Directory in order to take advantage of his credential. Tested compatibility paths and instructions on how to take the next step are provided as the primary choice for non-advanced users.
- The backpack platform implemented the Open Graph Protocol for the sharing URL, better supporting the social network site's generation of a preview card that included the badge image and a relevant title and content snippet.
Other recommendations related to implementing the API include:
- Service provider (host) platforms represent the learner (resource owner) in interactions that allow that learner to share their credentials with relying parties. In order to give the learner adequate control over sharing, hosts should recognize that learners may want to use their system for multiple different partially overlapping uses. For example, a learner might hold formal professional credentials and informal social badges in the same account. Hosts should give the learner the ability to attenuate access grants to read their badges so that certain service consumers (read) can only access badges that the user has designated for that purpose. The mechanism to do this may vary across different systems. For example, a host might enable a learner to gather badges into collections and may make it possible to select one or more collections when making an access grant. The consumer application they grant access to will be able to read any badges added to the collection at the time of the request, even if the badge is added to the collection after the original access grant was approved.
- Products should take into account many factors and opportunities for user failure including high conceptual complexity or use of jargon, forgotten passwords or no-longer working email addresses, and potential incompatibilities due to differing choices of DID methods, key formats/signature suites, or credential exchange protocol choices across different certifiable products.
The OB API enables key use cases for interoperability between web services that manage Open Badges on holders' behalf. This is centered on an ecosystem of backpacks and clients. "Backpack" and "web wallet" are commonly used terms to refer to a web service that holds Open Badges and/or CLR credentials for learners, enabling them to manage and share them. Clients each often primarily act to issue credentials or to verify credentials to display or convert into local understanding of someone's capabilities and accomplishments. Typically learners authorize issuers to send their credentials to backpacks and then from those backpacks, authorize verifier clients to access them.
This is an ambitious ecosystem to propose, even though users are familiar with the underlying OAuth and OpenID Connect experiences that tie together dozens of their online accounts. There is the addition of dynamic client registration and the wide variety of optional components these specifications feature. Implementers should prioritize high success-rate user experiences in credential acceptance.
Products that best aim to teach users a controlled number of concepts and provide interfaces offering easy successful options for the most common actions have a better chance of ensuring learners can take advantage of their digital credentials. No learner should be disadvantaged by poor interoperability experiences and dead ends.
3.3.2 CLR 2.0 API recommendations
As ClrCredential
s bundle a number of individual OpenBadgeCredentials
together, they sometimes offer additional information about the relationships
between elements. Implementations of the CLR API should be done for use cases
where the signed bundles (signed by the original issuers) or the inclusion of
associations provides benefit to users.
Example: Sending a CLR to a credential backpack (host) via API
Luis achieved his Associate Degree and is looking for jobs. He is notified by email that his CLR is ready and clicks through, where he is authenticated to the college's student CLR portal using his college single sign on. He sees the CLRCredential. This is his first CLR, and he wants to see how to use it to help his job search.
The website says the CLR is ready to save, so Luis selects that option. The application shows him a list of two credential backpack providers he can use to save. There is an advanced toggle that reveals an additional option to enter a service provider URL, but Luis closes that and picks one of the known options that looks good and has a good privacy policy. He selects that option and is directed to the backpack site where he signs up for an account. After he completes registration, he is prompted that he may return to the CLR portal to complete receiving his credential. He confirms and appears back in the CLR portal, where a confirmation message greets him saying all credentials were successfully transferred. He then confirms to return once more to the backpack site, where sees the CLR Credential and all the individual Achievement Credentials within it representing the degree, the courses he took, and the competencies he mastered.
3.3.3 Protocols for connection to Verifiable Credentials Wallets
While the OB 3.0 and CLR 2.0 APIs serve use cases for web services to verifiably exchange credentials on behalf of holders, the Verifiable Credentials community is exploring how more portable wallets, often operating on mobile devices which cannot serve HTTP requests can serve additional use cases. All Verifiable Credentials, including Open Badges and CLRs can and will be communicated over a range of protocols. This is a space that is seeing significant experimentation pre-standardization.
Implementers are encouraged to cooperate through communities like 1EdTech to ensure high-quality user experience in the exchange of credentials between their products, both via OB and CLR APIs and emerging protocols to carry these credentials into next-generation use cases. When new user experience patterns are presented that aim to become universal, take care to help the user through the workflow, and give them fallback solutions whenever possible.
Protocols under development to transport Verifiable Credentials including Open Badges and CLR include Credential Handler API (CHAPI), DIDComm, and OID4VC.
Example: The experience of a learner who receives their CLR
Luis now is viewing his CLR in his backpack, a web service that holds Open Badges & CLR Verifiable Credentials on his behalf:
Luis is looking at his college's CLR portal. He sees these credentials are set to be issued to his college email address, but he just graduated and will lose access to that email address in 6 months. There is an option to prove control of a personal address and have the credentials issued to that address, but Luis also sees another option to connect a wallet on his mobile device, where he can use a securely generated passkey to create a cryptographically verifiable Decentralized Identifier (DID) to use. Links appear to mobile app stores for several mobile wallet options.
Luis puts it off until Saturday but then reads a little about Verifiable Credentials and is interested to try out replacing his soon-to-expire email address with a DID. He chooses one of the wallet options that works on his device and sets it up. Back at the CLR portal on his desktop computer, he selects to proceed to connect to a mobile wallet. He chooses the CLR Credential and several of the competency achievements to send to the wallet initially. He is directed to an experience where through scanning a QR code displayed on screen and confirming some details on his phone, he is shown that there is a successful connection, and that credentials have been downloaded to the wallet. He sees them on his phone, which says he'll be able to use them in the future on websites that use Verifiable Credentials.
Here, Luis walks through the experience of downloading a mobile app to use as a
wallet for credentials including his CLRCredential
and several
OpenBadgeCredential
s. This issuer app seems to be compatible with a wide
variety of web wallets, perhaps even through implementing multiple protocols
used by these wallets with a variety of options. Some issuer services may be
operating with connections to fewer or different wallet applications.
Some recommendations for pre-standardization implementation of service connection protocols include:
- Test integrations and communicate with your implementation partners for the benefit of users' experience.
- Share pain points (without exposing personal information) and learn about possible solutions from others.
- Accurately inform users of the experimental status of features and integrations as necessary. Giving users an accurate sense of whether they are traveling a smooth and well-trodden path or a new route that may have pitfalls or dead ends goes a long way to gaining user trust.
- Prioritize tested high-success pathways to product integration.
- Provide some opportunities for users who desire it to learn about the work your product is doing under the hood to take care of their important data and empower them as participants in non-monopolistic ecosystems using open standards.
- Give users fallback options that are likely to succeed if the first path they try fails. For example, offer the chance to choose any wallet that uses a certain supported protocol, but suggest one particular integration as an easy choice, so users don't get stuck if the wallet they previously used for a different issuer doesn't work with the protocol used on your site. If all else fails, maybe a signed credential in a JSON download is an adequate compromise.
- Present benefits and risks to user to help them understand their choices. This example emphasized the user-owned nature of DIDs enabled by wallet connection in the face of the potential loss of control of an institutional or organizational email identifier. Products should make users aware of risks, such as any loss of data or verifiability that might be caused by losing a physical device.
4. Using Reference Implementations
This section is non-normative.
The Reference Implementation is an 1EdTech implementation of Open Badges 3.0 and Comprehensive Learner Record 2.0 which contains a Issuer, a Displayer and a Host. The reference implementation is written in Java. We provide source code and a hosted version of the tool. Our reference implementation has passed Conformance Certification and is complete with 100% automated tests. Developers can run it locally and develop against this tool. We are working to have this available in multiple languages and common functionality eventually available as libraries. From OB 3.0 and CLR 2.0 on, 1EdTech, with the support of the working group, will be keeping this implementation up-to-date, to have all versions supported.
- Source Code is a member-only resource.
- Hosted version will be available to the public, with services being a member-only resource.
5. Conformance and Certification
This section is non-normative.
The [OB-CERT-30] covers the specific requirements that implementers must cover in order to achieve certification for a successful implementation of Open Badges 3.0. An accompanying CLR 2.0 guide is forthcoming. Here is a quick summary of the types of services that can be certified.
5.1 Certified Roles in Open Badges
Services implementing Open Badges fall into one or more ecosystem roles, depending on their relationship to issued credentials. These roles are named "Issuer", "Host", and "Displayer". Issuer services may also add on API support as an additional optional certification level, whereas API support is required for the other two roles. This recognizes that some issuers deliver signed credentials directly to holders via file downloads or potential integrations with wallet
- Issuer: A product that issues Open Badges and transmits them to learners.
Certification as an issuer covers whether a well-formed signed
OpenBadgeCredential
is produced by the tested product.- Optional API support: Issuers can achieve an additional level of certification for Issuer API support if they can demonstrate successful registration with the reference Host system, authorization code grant flow execution for a test user, and transmission of signed Open Badge(s) to the reference Host system by posting them to the Host API.
- Host: A product implementing the server side of the Open Badges API that holds badges on behalf of data subjects or holders and controls API access to them. The Resource Server responds to automatic registration requests, authorization grant flow initiations, and authenticated resource requests via the API endpoints.
- Displayer: A product that implements the client side of the Open Badges API. Certification is granted that the product can demonstrate successful registration with the reference Host system, authorization code grant flow execution for a test user, and transmission of signed Open Badge(s) from the reference Host system by making a request for credentials held by a user who completed the authorization flow.
5.2 Certified Roles in CLR
Certified CLR 2.0 services require use of the API in the same roles as Open
Badges, except that the credentials transmitted over the API must be
ClrCredential
s meeting the requirements displayed by the test system.
Issuer-only certification without API support is not listed as an option for
CLR.
5.3 Conformance Testing Process
Follow the conformance and certification guide listed in the specification for detailed instructions on conformance. A 1EdTech member organization wishing to submit their product for conformance certification will undergo a semi-automated process, following onscreen instructions to run the tests. Then they submit their test results for review by 1EdTech, and if they successfully meet the requirements, the product will appear in the TrustEd Apps Directory, where consumers may find it under filters for each of the implementation roles they are looking for a product to serve.
6. Migrating from OB 2.0, OB 2.1, and CLR 1.0
This section is non-normative.
Open Badges 3.0 and Comprehensive Learner Record 2.0 are major releases, and objects published under these versions are not backwards-compatible
Issuers who use Open Badges 2.0 typically make available standard-compliant
endpoints for each Issuer Profile, BadgeClass, and Assertion. In addition to
enabling verification of their badge awards, these endpoints often also serve to
present human-readable information to clients in HTML when HTML is requested by
browsers. Social media networks to which badge awards are shared gather
information to display awards from these endpoints as
Open Graph Protocol metadata. Exceptions to the pattern of
one endpoint per Assertion or BadgeClass occur for implementers who have chosen
to use
OB 2.0 signed verification
for assertions or
ephemeral BadgeClass IDs
in the urn:uuid
namespace.
For any system already using hosted endpoints for these objects, use cases
remain within the 3.0 ecosystem to continue that support in addition to
delivering these objects compliant with 3.0. In OB 3.0 and CLR 2.0, assertions
become OpenBadgeCredentials
or AchievementCredentials
(an alias), and
BadgeClasses
become Achievements
, which may be more likely to use urn:uuid
identifiers. As the ecosystem transitions to support OB 3.0 serialization of
these objects, some products will continue to support OB 2.0 representations, so
an efficient transition for issuer services likely involves a window of
continued support for 2.0 with no breaking changes for clients who rely on it
today.
The new OB 3.0 and CLR 2.0 specifications each define APIs over which credentials can be exchanged, from issuers, to holders and then to displayers, but as these standards implement Verifiable Credentials
As portable signed credentials, Open Badges and CLR will take advantage of newly expanded options for both the potential of these credentials to contribute to understanding of skills, qualifications and experience, but also expanded privacy options for learners to control how their data is used and shared. The OB 3.0 and CLR 2.0 releases represent a beginning, but these capabilities will take time and require the launch of new features and new products to deliver on their potential impact. A transition to this generation of specification should be non-destructive but should also move quickly to take advantage of new capabilities.
The recommendations in this guide are intended to identify opportunities for interoperable implementation of of the Open Badges and Comprehensive Learner Record specifications. This serves goals of enabling (a) immediate improvement of last-gen credentials due to next-gen thinking, and (b) gradual technology change.
6.1 How to support both OB 2.0 and OB 3.0 as an Issuer
The quickstart in this implementation guide provides an example implementation
using a did:web
issuer identifier, HTTPS Achievement identifier, and a
urn:uuid
in the OpenBadgeCredential
. Meanwhile, an issuer may wish to avoid
breaking support for OB 2.0 to ensure learners can still use their badges in
tools that do not yet support the new version. This is possible and can work
elegantly to express the relationships between related objects if a few steps
are followed. The same achievement data may be exposed in OB 2.0 and OB
3.0/CLR 2.0 formats. It is not advisable to attempt to publish a combined
expression of an entity that is compatible with OB 3.0/CLR 2.0 and the previous
version formats, but it is possible to express the relationship between related
objects using different IDs for the new versions of these specifications.
For example, a related
association may be made within an Achievement
and the
OB 2.0 equivalent BadgeClass
that represents the same achievement. The issuer
service does not store the data in two separate formats, but it is capable of
serializing the data into the relevant formats when requested at different
endpoints. It is a helpful hint to include the IRI of the legacy BadgeClass type
(but because the term BadgeClass
doesn't appear in the OB 3.0 context and the
two contexts are not compatible with one another to be applied to the same
document, the full IRI https://w3id.org/openbadges#BadgeClass
is used here).
- There is an existing OB 2.0 endpoint for a BadgeClass at HTTPS id
https://example.com/badgeclasses/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6
- Implement the OB 3.0 serialization at an endpoint
https://example.com/achievements/c3c1ea5b-9d6b-416d-ab7f-76da1df3e8d6
- This example also shows another entry in the related array, to describe a
Spanish translation of the achievement, serialized in OB 3.0
Achievement
format.
An OB 2.0 related property could be implemented to make the reverse connection from the OB 2.0 BadgeClass:
- Again, the type IRI is spelled out in full, because
Achievement
is not defined in the OB 2.0 context.
The issuer profile shown in the quickstart uses a did:web
identifier, and the
issuer must use an HTTPS identifier for the OB 2.0 hosted profile. Within the
3.0 Profile
as embedded in a credential, an otherIdentifier
property is
described that may be used to link to the 2.0 representation.
Additionally, within the DID Document context, an alsoKnownAs
property is
available, that may express the HTTPS id of the OB 2.0 representation of the
profile.
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774",
"alsoKnownAs": "https://example.com/issuers/v2p0/540e388e-2735-4c3e-9709-80142801c774",
"otherIdentifier": [{
"type": ["IdentifierEntry"],
"identifier": "https://example.com/issuers/v2p0/540e388e-2735-4c3e-9709-80142801c774",
"identifierType": "identifier"
}]
"name": "Example Institution",
"url": "https://example.edu",
"email": "info@example.edu",
}
Within the OB 2.0 representation of the issuer, a reverse link may be made with
related
, as was done with the BadgeClass
{
"@context": "https://w3id.org/openbadges/v2",
"id": "https://example.com/issuers/v2p0/540e388e-2735-4c3e-9709-80142801c774",
"type": "Profile",
"name": "Example Institution",
"url": "https://example.com",
"email": "info@example.com",
"related": [{
"type": [
"https://purl.imsglobal.org/spec/vc/ob/vocab.html#Profile"
],
"id": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774",
"version": "Open Badges v3p0"
}]
}
And finally, at the level of the OpenBadgeCredential
, an association to the
original OB 2.0 Assertion may be made using "evidence". The use of "evidence"
instead of a more complicated construction with related
enables human-readable
display of a useful link to the original document in as many cases as possible,
by any displayer that supports the concept of evidence.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json"
],
"id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130004",
"type": ["VerifiableCredential", "OpenBadgeCredential"],
"issuer": {
"id": "did:web:example.com:issuers:540e388e-2735-4c3e-9709-80142801c774",
"alsoKnownAs": "https://example.com/issuers/v2p0/540e388e-2735-4c3e-9709-80142801c774",
"otherIdentifier": [{
"type": ["IdentifierEntry"],
"identifier": "https://example.com/issuers/v2p0/540e388e-2735-4c3e-9709-80142801c774",
"identifierType": "identifier"
}],
"name": "Example Institution",
"url": "https://example.edu",
"email": "info@example.edu",
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Example Competency Badge Issued under OB 2.0",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Example Competency Badge Issued under OB 2.0",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "This example badge was issued originally as an Open Badges 2.0 assertion",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
},
"evidence": [
{
"type": ["Evidence", "https://w3id.org/openbadges#Assertion"],
"id": "https://example.org/ob2/assertions/10481810-e094-4ffe-806f-25de49c87933",
"name": "Original Open Badges 2.0 assertion for this credential",
"description": "This credential was originally issued as an Open Badges 2.0 assertion. It has been updated to the latest version for delivery to Verifiable Credentials wallets and verifiers or inclusion within a Comprehensive Learner Record (CLR 2.0)."
}
]
}
Notes about this example:
- A new ID is assigned for the upgraded assertion, in this case an
urn:uuid
identifier - The original badge data, which was expressed as a "hosted" OB 2.0 assertion is linked via the OB 3.0 Evidence.
- A strong hint that the evidence item is an OB 2.0 Assertion is the use of
the full IRI
https://w3id.org/openbadges#Assertion
as an additional type for theEvidence
item. Consumers should understand that if they desire, they may verify the original using OB 2.0 protocols. - For additional context and human readability of the evidence link, a
name
anddescription
appear in the Evidence record describing the upgrade process. - As the issuer in this example is the same entity offering credentials in either OB 2.0 or OB 3.0 format, there is a proof expected to be included in this credential.
6.2 How to migrate from CLR 1.0 to CLR 2.0
There is less of an ecosystem of consumption for CLR 1.0 than for OB 2.0, and
the increased complexity of a CLR makes support for multiple versions more
expensive than for Open Badges, so it is not likely to be worth the investment
to maintain simultaneous serialization of both formats of packaged records. A
CLR 2.0 platform that also serves as the issuer for the OpenBadgeCredentials
packaged within the ClrCredential
may choose to implement the above
backwards-compatibility steps for increased visibility and shareability of the
individual achievements. At the level of the CLR, it is likely that new
consumption products coming on the scene will implement the capability to
process CLR in the new 2.0 format rather than the legacy version.
Migrating to CLR 2.0 involves a replacement of endpoints where CLR 1.0 documents were available with the implementation of the CLR 2.0 API. If there are existing clients or relying parties on the CLR 1.0 representations, the best path is to work with those clients to upgrade to 2.0 representations and transfer via API and then remove the 1.0 endpoints once a 2.0 channel has been established.
6.3 Including older Open Badges in CLR 2.0
When Comprehensive Learner Record (CLR) issuers want to include Open Badges
issued over time, these credentials must match the expected schema of an OB 3.0
OpenBadgeCredential
. But the CLR issuer might have collected them in an older
format, such as OB 2.0, which largely expressed the same achievement
information, except in a different schema. To ensure that consumers are able to
process data included in a CLR efficiently, the CLR issuer may use the
technique above to
represent the OB 2.0 data in OB 3.0 format with a reference to the original as
"evidence".
If the issuer of the CLR is the same as the issuer of the embedded upgraded
credentials, they may sign each with their own key, presumably the same used to
sign the outer CLR itself. If the original issuer of an embedded credential is
another entity, the embedded OpenBadgeCredential
may be included without
signature. In either case, the related
reference back to the original enables
consumers or viewers to trace the verification back to the original. The
inclusion of the unsigned third party credential implies the CLR issuer's
verification or trust of the original. Consumers may perform their own
verification of the referenced original OB 2.0 assertion using the OB 2.0
verification protocols.
This approach enables the CLR to meet the schema requirements for CLR 2.0 without leaving behind the millions of achievement assertions issued using previous versions of the Open Badges Specification.
Implementation notes:
- If the issuer is the same entity between the OB 2.0 and OB 3.0 versions, the CLR issuer should include a proof for the upgraded credential, but if the issuer is different, the CLR issuer should not include a proof and should expect that interested verifiers could perform OB 2.0 verification based on the assertion linked in Evidence.
- An approach for OB 2.0 signed assertions is not included, as these represent less than 1% of all OB 2.0 assertions in existence, but this approach could be modified to work with a signed assertion, perhaps using a data URI to embed the original OB 2.0 compact JWS string.
7. Getting Help
This section is non-normative.
If you have questions or need help with implementing Open Badges 3.0 or Comprehensive Learning Record 2.0, or achieving conformance certification, here are some available resources:
- Public Forum for all members of the 1EdTech community.
- Affiliate Forum for Learning Tools and Content Alliance, Affiliate, and Contributing Members.
- 1EdTech Contributing Members have access to private GitHub repositories and a Slack channel for Digital Credentials Project Group discussions and collaborations. Contact an 1EdTech staff member to gain access.
- Digital Credentials and Open Badges FAQs If you have a question, an answer may already be waiting. If not, please contact us.
8. Linked Data Proof Test Vector for Open Badges 3.0
This section is non-normative.
This chapter is an example of the signing process of a given credential with an Linked Data Proof producing aDataIntegrityProof
of a public
key expressed in eddsa-rdf-2022
format.
8.1 Key pair & Multikey
For this example we are using the following keypair:-
Public key (hex):
4bdeafde2ea8beefadd8c699b5c7e0704cf51154d52e17b20b71337ca04cc5a5
-
Private key (hex):
6241a409e6707bb640a0140a8a32bc3d193c33a661747284d6adfa4ed4180be44bdeafde2ea8beefadd8c699b5c7e0704cf51154d52e17b20b71337ca04cc5a5
MultiKey
used in this example is as follows:
{
id: 'https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi',
controller: 'https://example.edu/issuers/565049',
publicKey: Uint8Array(32) [
75, 222, 175, 222, 46, 168, 190,
239, 173, 216, 198, 153, 181, 199,
224, 112, 76, 245, 17, 84, 213,
46, 23, 178, 11, 113, 51, 124,
160, 76, 197, 165
],
secretKey: Uint8Array(64) [
98, 65, 164, 9, 230, 112, 123, 182, 64, 160, 20,
10, 138, 50, 188, 61, 25, 60, 51, 166, 97, 116,
114, 132, 214, 173, 250, 78, 212, 24, 11, 228, 75,
222, 175, 222, 46, 168, 190, 239, 173, 216, 198, 153,
181, 199, 224, 112, 76, 245, 17, 84, 213, 46, 23,
178, 11, 113, 51, 124, 160, 76, 197, 165
],
publicKeyMultibase: 'z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi',
secretKeyMultibase: 'zrv2bqTbNwCTsRrHFcJCPjVAduh4Ezcnoq1A3ZxH1GWTNkxipLVuaAoMFmze2gFN9oNXfJjufxSHWVZzsJiUsMHFMcx',
revoked: undefined,
export: [AsyncFunction: export],
signer: [Function: signer],
verifier: [Function: verifier]
}
8.2 Test data
The credential used in the example is:{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context/ob_v3p0.jsonld"
],
"id": "http://example.com/credentials/3527",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": [
"Profile"
],
"url": "https://www.imsglobal.org",
"name": "Example Corp"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Teamwork Badge",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": [
"AchievementSubject"
],
"achievement": {
"id": "https://example.com/achievements/21st-century-skills/teamwork",
"type": [
"Achievement"
],
"criteria": {
"narrative": "Team members are nominated for this badge by their peers and recognized upon review by Example Corp management."
},
"description": "This badge recognizes the development of the capacity to collaborate within a group environment.",
"name": "Teamwork"
}
}
}
8.3 Document with cryptosuite context
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context/ob_v3p0.jsonld",
"https://w3id.org/security/data-integrity/v1"
],
"id": "http://example.com/credentials/3527",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": [
"Profile"
],
"url": "https://www.imsglobal.org",
"name": "Example Corp"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Teamwork Badge",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": [
"AchievementSubject"
],
"achievement": {
"id": "https://example.com/achievements/21st-century-skills/teamwork",
"type": [
"Achievement"
],
"criteria": {
"narrative": "Team members are nominated for this badge by their peers and recognized upon review by Example Corp management."
},
"description": "This badge recognizes the development of the capacity to collaborate within a group environment.",
"name": "Teamwork"
}
}
}
8.4 Proof before signing
{
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod"
}
8.5 Proof normalized
_:c14n0 <http://purl.org/dc/terms/created> "2010-01-01T19:23:24Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> . _:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> . _:c14n0 <https://w3id.org/security#cryptosuite> "eddsa-rdfc-2022" . _:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> . _:c14n0 <https://w3id.org/security#verificationMethod> <https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi> .
8.6 Document normalized
<did:example:ebfeb1f712ebc6f1c276e12ec21> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#AchievementSubject> . <did:example:ebfeb1f712ebc6f1c276e12ec21> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Achievement> <https://example.com/achievements/21st-century-skills/teamwork> . <http://example.com/credentials/3527> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential> . <http://example.com/credentials/3527> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> . <http://example.com/credentials/3527> <https://schema.org/name> "Teamwork Badge"^^<https://www.w3.org/2001/XMLSchema#string> . <http://example.com/credentials/3527> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:ebfeb1f712ebc6f1c276e12ec21> . <http://example.com/credentials/3527> <https://www.w3.org/2018/credentials#issuanceDate> "2010-01-01T00:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> . <http://example.com/credentials/3527> <https://www.w3.org/2018/credentials#issuer> <https://example.edu/issuers/565049> . <https://example.com/achievements/21st-century-skills/teamwork> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Achievement> . <https://example.com/achievements/21st-century-skills/teamwork> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Criteria> _:c14n0 . <https://example.com/achievements/21st-century-skills/teamwork> <https://schema.org/description> "This badge recognizes the development of the capacity to collaborate within a group environment."^^<https://www.w3.org/2001/XMLSchema#string> . <https://example.com/achievements/21st-century-skills/teamwork> <https://schema.org/name> "Teamwork"^^<https://www.w3.org/2001/XMLSchema#string> . <https://example.edu/issuers/565049> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Profile> . <https://example.edu/issuers/565049> <https://schema.org/name> "Example Corp"^^<https://www.w3.org/2001/XMLSchema#string> . <https://example.edu/issuers/565049> <https://schema.org/url> "https://www.imsglobal.org"^^<https://www.w3.org/2001/XMLSchema#anyURI> . _:c14n0 <https://purl.imsglobal.org/spec/vc/ob/vocab.html#narrative> "Team members are nominated for this badge by their peers and recognized upon review by Example Corp management."^^<https://www.w3.org/2001/XMLSchema#string> .
8.7 Document hash (hex)
d994aebd5e53f4af4495dbe9e1155410bae683811107c26acf83671075c163b3
8.8 Proof hash (hex)
3cf3c265b6c8ebb29b4d5ea310b87d2f31c79b633eff8af561d2e8c97a85c8cb
8.9 Data to sign (hex)
3cf3c265b6c8ebb29b4d5ea310b87d2f31c79b633eff8af561d2e8c97a85c8cbd994aebd5e53f4af4495dbe9e1155410bae683811107c26acf83671075c163b3
8.10 Signature (hex)
17a898a91832fa58bd66433e18dc8256522bcf84382994c395c23c26cba71ff8060a2587390e5ed20c4decec45c0c0c9eec1f7d2d1ce91e1ffc992983a74a300
8.11 Proof value (hex)
zUSD5bjo6mYV1n9i9E6ZwUiHuj4JyZDjCDfDqoJcPi9XJrc9LYstik9mdBvutdwBdquWXjWrwJDVGJrAarvRs8uD
8.12 Proof
{
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "zUSD5bjo6mYV1n9i9E6ZwUiHuj4JyZDjCDfDqoJcPi9XJrc9LYstik9mdBvutdwBdquWXjWrwJDVGJrAarvRs8uD"
}
8.13 Signed credential
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context/ob_v3p0.jsonld",
"https://w3id.org/security/data-integrity/v1"
],
"id": "http://example.com/credentials/3527",
"type": [
"VerifiableCredential",
"OpenBadgeCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": [
"Profile"
],
"url": "https://www.imsglobal.org",
"name": "Example Corp"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Teamwork Badge",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": [
"AchievementSubject"
],
"achievement": {
"id": "https://example.com/achievements/21st-century-skills/teamwork",
"type": [
"Achievement"
],
"criteria": {
"narrative": "Team members are nominated for this badge by their peers and recognized upon review by Example Corp management."
},
"description": "This badge recognizes the development of the capacity to collaborate within a group environment.",
"name": "Teamwork"
}
},
"proof": {
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "zUSD5bjo6mYV1n9i9E6ZwUiHuj4JyZDjCDfDqoJcPi9XJrc9LYstik9mdBvutdwBdquWXjWrwJDVGJrAarvRs8uD"
}
}
9. Linked Data Proof Test Vector for Comprehensive Learner Record 2.0
This section is non-normative.
ClrCredential
instead of an AchievementCredential
as the input data
DataIntegrityProof
of a public key
expressed in eddsa-rdf-2022
format.
9.1 Key pair & Multikey
For this example we are using the following keypair:- Public key (hex):
4bdeafde2ea8beefadd8c699b5c7e0704cf51154d52e17b20b71337ca04cc5a5
- Private key (hex):
6241a409e6707bb640a0140a8a32bc3d193c33a661747284d6adfa4ed4180be44bdeafde2ea8beefadd8c699b5c7e0704cf51154d52e17b20b71337ca04cc5a5
MultiKey
used in this example is as follows:
{
id: 'https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi',
controller: 'https://example.edu/issuers/565049',
publicKey: Uint8Array(32) [
75, 222, 175, 222, 46, 168, 190,
239, 173, 216, 198, 153, 181, 199,
224, 112, 76, 245, 17, 84, 213,
46, 23, 178, 11, 113, 51, 124,
160, 76, 197, 165
],
secretKey: Uint8Array(64) [
98, 65, 164, 9, 230, 112, 123, 182, 64, 160, 20,
10, 138, 50, 188, 61, 25, 60, 51, 166, 97, 116,
114, 132, 214, 173, 250, 78, 212, 24, 11, 228, 75,
222, 175, 222, 46, 168, 190, 239, 173, 216, 198, 153,
181, 199, 224, 112, 76, 245, 17, 84, 213, 46, 23,
178, 11, 113, 51, 124, 160, 76, 197, 165
],
publicKeyMultibase: 'z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi',
secretKeyMultibase: 'zrv2bqTbNwCTsRrHFcJCPjVAduh4Ezcnoq1A3ZxH1GWTNkxipLVuaAoMFmze2gFN9oNXfJjufxSHWVZzsJiUsMHFMcx',
revoked: undefined,
export: [AsyncFunction: export],
signer: [Function: signer],
verifier: [Function: verifier]
}
9.2 Test data
The credential used in the example is:{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/clr/v2p0/context.json",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "http://example.edu/credentials/3732",
"type": [
"VerifiableCredential",
"ClrCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Sample Transcript",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "ClrSubject",
"verifiableCredential": [
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
"type": [
"VerifiableCredential",
"AchievementCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Example University Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 1",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 1",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
},
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
],
"proof": {
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "z2CGNmCgEmN68CWch6Kgg4vnjRDE896jnUqfQtJoG11qxC8ntxUPCQaGckoHG7BXW7KWZyUiSs5EkKX3gEiGYKrz"
}
}
],
"achievement": [
{
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 1",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 1",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
},
{
"id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 2",
"criteria": {
"id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 2",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
],
"association": [
{
"type": "Association",
"associationType": "isParentOf",
"sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
}
]
},
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
]
}
9.3 Document with cryptosuite context
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/clr/v2p0/context.json",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "http://example.edu/credentials/3732",
"type": [
"VerifiableCredential",
"ClrCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Sample Transcript",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "ClrSubject",
"verifiableCredential": [
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
"type": [
"VerifiableCredential",
"AchievementCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Example University Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 1",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 1",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
},
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
],
"proof": {
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "z2CGNmCgEmN68CWch6Kgg4vnjRDE896jnUqfQtJoG11qxC8ntxUPCQaGckoHG7BXW7KWZyUiSs5EkKX3gEiGYKrz"
}
}
],
"achievement": [
{
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 1",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 1",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
},
{
"id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 2",
"criteria": {
"id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 2",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
],
"association": [
{
"type": "Association",
"associationType": "isParentOf",
"sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
}
]
},
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
]
}
9.4 Proof before signing
{
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod"
}
9.5 Proof normalized
_:c14n0 <http://purl.org/dc/terms/created> "2010-01-01T19:23:24Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> . _:c14n0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> . _:c14n0 <https://w3id.org/security#cryptosuite> "eddsa-rdfc-2022" . _:c14n0 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> . _:c14n0 <https://w3id.org/security#verificationMethod> <https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi> .
9.6 Document normalized
<did:example:ebfeb1f712ebc6f1c276e12ec21> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#ClrSubject> . <did:example:ebfeb1f712ebc6f1c276e12ec21> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#AchievementSubject> . <did:example:ebfeb1f712ebc6f1c276e12ec21> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#achievement> <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> . <did:example:ebfeb1f712ebc6f1c276e12ec21> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#achievement> <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> . <did:example:ebfeb1f712ebc6f1c276e12ec21> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#association> _:c14n2 . <did:example:ebfeb1f712ebc6f1c276e12ec21> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#verifiableCredential> <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> . <did:example:ebfeb1f712ebc6f1c276e12ec21> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#achievement-0> <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> . <http://example.edu/credentials/3732> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#ClrCredential> . <http://example.edu/credentials/3732> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> . <http://example.edu/credentials/3732> <https://schema.org/name> "Sample Transcript" . <http://example.edu/credentials/3732> <https://www.w3.org/2018/credentials#credentialSchema> <https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json> . <http://example.edu/credentials/3732> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:ebfeb1f712ebc6f1c276e12ec21> . <http://example.edu/credentials/3732> <https://www.w3.org/2018/credentials#issuanceDate> "2010-01-01T00:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> . <http://example.edu/credentials/3732> <https://www.w3.org/2018/credentials#issuer> <https://example.edu/issuers/565049> . <https://example.edu/achievements/sample.png> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image> . <https://example.edu/issuers/565049> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Profile> . <https://example.edu/issuers/565049> <https://schema.org/name> "Example University" . <https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vccs/v1p0/context.json#1EdTechJsonSchemaValidator2019> . <https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vccs/v1p0/context.json#1EdTechJsonSchemaValidator2019> . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential> . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <https://schema.org/name> "Example University Degree" . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <https://w3id.org/security#proof> _:c14n0 . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <https://www.w3.org/2018/credentials#credentialSchema> <https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json> . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <https://www.w3.org/2018/credentials#credentialSubject> <did:example:ebfeb1f712ebc6f1c276e12ec21> . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <https://www.w3.org/2018/credentials#issuanceDate> "2010-01-01T00:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> . <urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002> <https://www.w3.org/2018/credentials#issuer> <https://example.edu/issuers/565049> . <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Achievement> . <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Criteria> <https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria> . <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image> <https://example.edu/achievements/sample.png> . <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#creator> <https://example.edu/issuers/565049> . <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> <https://schema.org/description> "Achievement 1" . <urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002> <https://schema.org/name> "Achievement 1" . <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Achievement> . <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Criteria> <https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria> . <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image> <https://example.edu/achievements/sample.png> . <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> <https://purl.imsglobal.org/spec/vc/ob/vocab.html#creator> <https://example.edu/issuers/565049> . <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> <https://schema.org/description> "Achievement 2" . <urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002> <https://schema.org/name> "Achievement 2" . _:c14n1 <http://purl.org/dc/terms/created> "2010-01-01T19:23:24Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> _:c14n0 . _:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://w3id.org/security#DataIntegrityProof> _:c14n0 . _:c14n1 <https://w3id.org/security#cryptosuite> "eddsa-rdfc-2022" _:c14n0 . _:c14n1 <https://w3id.org/security#proofPurpose> <https://w3id.org/security#assertionMethod> _:c14n0 . _:c14n1 <https://w3id.org/security#proofValue> "z2CGNmCgEmN68CWch6Kgg4vnjRDE896jnUqfQtJoG11qxC8ntxUPCQaGckoHG7BXW7KWZyUiSs5EkKX3gEiGYKrz"^^<https://w3id.org/security#multibase> _:c14n0 . _:c14n1 <https://w3id.org/security#verificationMethod> <https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi> _:c14n0 . _:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.imsglobal.org/spec/vc/clr/vocab.html#Association> . _:c14n2 <https://purl.imsglobal.org/spec/vc/clr/vocab.html#AssociationType> "isParentOf" . _:c14n2 <https://purl.imsglobal.org/spec/vc/clr/vocab.html#sourceId> "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002"^^<xsd:anyURI> . _:c14n2 <https://purl.imsglobal.org/spec/vc/clr/vocab.html#targetId> "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"^^<xsd:anyURI> .
9.7 Document hash (hex)
fd987e45f5ee69ee7bc36a4111d9012c727fb80d79f867b344bf3fa67e8c4e83
9.8 Proof hash (hex)
3cf3c265b6c8ebb29b4d5ea310b87d2f31c79b633eff8af561d2e8c97a85c8cb
9.9 Data to sign (hex)
3cf3c265b6c8ebb29b4d5ea310b87d2f31c79b633eff8af561d2e8c97a85c8cbfd987e45f5ee69ee7bc36a4111d9012c727fb80d79f867b344bf3fa67e8c4e83
9.10 Signature (hex)
50857f041f543633b12e02ff1173f8271f0edfd7d92fcfe07b0b25d11b3d240e37070c15667a5c9346625afbf671abf065b5a37b1cfa3ba5ad22b77c9a9eec05
9.10.1 Proof value (hex)
z2cNeK7UjuvWoNUHa8D7bbZuhryrgG3LjXmJSnY3R69mVJTAdX5yP1RCo9SH1aZwmyA76snohTwACQRFyrwGihsfr
9.10.2 Proof
{
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "z2cNeK7UjuvWoNUHa8D7bbZuhryrgG3LjXmJSnY3R69mVJTAdX5yP1RCo9SH1aZwmyA76snohTwACQRFyrwGihsfr"
}
9.10.3 Signed credential
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/clr/v2p0/context.json",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "http://example.edu/credentials/3732",
"type": [
"VerifiableCredential",
"ClrCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Sample Transcript",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "ClrSubject",
"verifiableCredential": [
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json",
"https://purl.imsglobal.org/spec/ob/v3p0/extensions.json",
"https://w3id.org/security/data-integrity/v1"
],
"id": "urn:uuid:91537dba-56cb-11ec-bf63-0242ac130002",
"type": [
"VerifiableCredential",
"AchievementCredential"
],
"issuer": {
"id": "https://example.edu/issuers/565049",
"type": "Profile",
"name": "Example University"
},
"issuanceDate": "2010-01-01T00:00:00Z",
"name": "Example University Degree",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"type": "AchievementSubject",
"achievement": {
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 1",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 1",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
},
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/ob/v3p0/schema/json/ob_v3p0_achievementcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
],
"proof": {
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "z2CGNmCgEmN68CWch6Kgg4vnjRDE896jnUqfQtJoG11qxC8ntxUPCQaGckoHG7BXW7KWZyUiSs5EkKX3gEiGYKrz"
}
}
],
"achievement": [
{
"id": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 1",
"criteria": {
"id": "https://example.edu/achievements/a7467ef6-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 1",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
},
{
"id": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002",
"type": "Achievement",
"creator": {
"id": "https://example.edu/issuers/565049",
"type": "Profile"
},
"name": "Achievement 2",
"criteria": {
"id": "https://example.edu/achievements/dd887f0a-56cb-11ec-bf63-0242ac130002/criteria"
},
"description": "Achievement 2",
"image": {
"id": "https://example.edu/achievements/sample.png",
"type": "Image"
}
}
],
"association": [
{
"type": "Association",
"associationType": "isParentOf",
"sourceId": "urn:uuid:a7467ef6-56cb-11ec-bf63-0242ac130002",
"targetId": "urn:uuid:dd887f0a-56cb-11ec-bf63-0242ac130002"
}
]
},
"credentialSchema": [
{
"id": "https://purl.imsglobal.org/spec/clr/v2p0/schema/json/clr_v2p0_clrcredential_schema.json",
"type": "1EdTechJsonSchemaValidator2019"
}
],
"proof": {
"type": "DataIntegrityProof",
"created": "2010-01-01T19:23:24Z",
"verificationMethod": "https://example.edu/issuers/565049#z6MkjZRZv3aez3r18pB1RBFJR1kwUVJ5jHt92JmQwXbd5hwi",
"cryptosuite": "eddsa-rdfc-2022",
"proofPurpose": "assertionMethod",
"proofValue": "z2cNeK7UjuvWoNUHa8D7bbZuhryrgG3LjXmJSnY3R69mVJTAdX5yP1RCo9SH1aZwmyA76snohTwACQRFyrwGihsfr"
}
}
A. Revision History
This section is non-normative.
Version No. | Document Version | Release Date | Comments |
---|---|---|---|
Version 3.0 IMS Candidate Final | 1.0 | November 10, 2022 | Covers Issuer, Displayer, and Host conformance and certification. |
Version 3.0 IMS Candidate Final | 1.1 | June 20, 2023 | Updated Linked Data Proof to the new EdDSA Cryptosuite v2022 [VC-DI-EDDSA]. |
Version 3.0 IMS Candidate Final | 1.2 | July 14, 2023 |
New version of the context.json (context-3.0.2.json ) file. See Open Badges Specification v3.0: Errata for detailed changes
|
Version 3.0 IMS Candidate Final | 1.3 | September 8, 2023 |
|
Version 3.0 IMS Candidate Final | 1.4 | September 22, 2023 |
|
Version 3.0 IMS Candidate Final | 1.5 | November 9, 2023 |
|
B. References
B.1 Normative references
- [CASE-10]
- IMS Competencies and Academic Standards Exchange (CASE) Service Version 1.0. IMS Global Learning Consortium. July 7, 2017. IMS Final Release. URL: https://www.imsglobal.org/sites/default/files/CASE/casev1p0/information_model/caseservicev1p0_infomodelv1p0.html
- [CLR-20]
- Comprehensive Learner Record Standard v2.0. 1EdTech. IMS Base Document. URL: https://www.imsglobal.org/spec/clr/v2p0/
- [CLR-CERT-20]
- Comprehensive Learner Record Conformance and Certification Guide v2.0. 1EdTech. IMS Base Document. URL: https://www.imsglobal.org/spec/clr/v2p0/cert/
- [EDUAPI-10]
- Edu-API Specification Specification v1.0. 1EdTech. IMS Candidate Final. URL: https://imsglobal.org/spec/eduapi/v1p0/
- [LTI-13]
- IMS Global Learning Tools Interoperability® Core Specification v1.3. C. Vervoort; N. Mills. IMS Global Learning Consortium. April 2019. IMS Final Release. URL: https://www.imsglobal.org/spec/lti/v1p3/
- [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/
- [OR-11]
- 1EdTech OneRoster® Specification v1.1. 1EdTech. 1EdTech Final Release. URL: https://www.imsglobal.org/oneroster-v11-final-specification
- [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
- [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/
B.2 Informative references
- [OB-ERRATA-30]
- Open Badges Specification v3.0: Errata. URL: https://www.imsglobal.org/spec/ob/v3p0/errata/
- [RFC3986]
- Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
- [RFC7517]
- JSON Web Key (JWK). M. Jones. IETF. May 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7517
- [RFC7591]
- OAuth 2.0 Dynamic Client Registration Protocol. J. Richer, Ed.; M. Jones; J. Bradley; M. Machulak; P. Hunt. IETF. July 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7591
- [RFC7636]
- Proof Key for Code Exchange by OAuth Public Clients. N. Sakimura, Ed.; J. Bradley; N. Agarwal. IETF. September 2015. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7636
- [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-INTEGRITY]
- Verifiable Credential Data Integrity 1.0. Manu Sporny; Dave Longley; Greg Bernstein; Dmitri Zagidulin; Sebastian Crane. W3C. 21 October 2023. W3C Working Draft. URL: https://www.w3.org/TR/vc-data-integrity/
- [VC-DI-EDDSA]
- Data Integrity EdDSA Cryptosuites v1.0. Manu Sporny; Dmitri Zagidulin; Greg Bernstein; Sebastian Crane. W3C. 1 November 2023. W3C Working Draft. URL: https://www.w3.org/TR/vc-di-eddsa/
- [VC-DID-WEB-METHOD]
- DID Web Method Specification. Credentials Community Group. CG-DRAFT. URL: https://w3c-ccg.github.io/did-method-web/
- [VC-STATUS-2021]
- Credential Status List 2021. W3C Credentials Community Group. W3C Editor's Draft. URL: https://w3c.github.io/vc-status-list-2021/
- [VCCR-10]
- 1EdTech Credential Refresh Service. 1EdTech. Candidate Final Public. URL: https://imsglobal.org/spec/vccr/v1p0/
- [VCRL-10]
- 1EdTech Revocation List Status Method. 1EdTech. Candidate Final Public. URL: https://imsglobal.org/spec/vcrl/v1p0/
C. List of Contributors
The following individuals contributed to the development of this document:
Name | Organization | Role |
---|---|---|
Nate Otto | Skybridge Skills | Invited Expert |
Justin Pitcher | Anthology | Co-chair, OB |
Xavi Aracil | 1Edtech | Editor |
Rob Coyle | 1Edtech | Editor |