Note Credentials created following Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL]) have different names for attributes used in this process. Concretely, they have issuanceDate and expirationDate instead of validFrom and validUntil, respectively
This is very confusing for implementers. Wasn't it decided that aliases would be used?
alignment
Consider re-naming or adding an alias or adding a new property to specifically reference skills/comptencies.
1EdTechJsonSchemaValidator2019
What is this?
image Image An image representing this user's achievement. If present, this must be a PNG or SVG image, and should be prepared via the 'baking' instructions. An 'unbaked' image for the achievement is defined in the Achievement class and should not be duplicated here. [0..1]
Is this needed if there is an Achievement image?
id URI An identifier for the Credential Subject. Either id or at least one identifier MUST be supplied.
Would be helpful to explain that decentralize identifiers could be a value and what that means.
refreshService RefreshService The information in RefreshService is used to refresh the verifiable credential. [0..1]
Should reference or model: https://www.w3.org/TR/vc-data-model-2.0/#refreshing
credentialStatus CredentialStatus The information in CredentialStatus is used to discover information about the current status of a verifiable credential, such as whether it is suspended or revoked. [0..1]
Should model W3C VCDM 2.0 and reference BitString Status List
Timestamp of when the credential was awarded. validFrom is used to determine the most recent version of a Credential in conjunction with issuer and id. Consequently, the only way to update a Credental is to update the validFrom, losing the date when the Credential was originally awarded. awardedDate is meant to keep this original date.
Not sure what this means. What about the created date in the proof? Some clarity needed in communicating what each date is intended for.
name String The name of the credential for display purposes in wallets. For example, in a list of credentials and in detail views. [0..1] description String The short description of the credential for display purposes in wallets. [0..1] image Image The image representing the credential for display purposes in wallets. [0..1]
These properties are confusing at this level. Name and description are required properties of the Achievement. Are they needed here?
Image isn't needed (and baking should be removed from the spec).
id URI Unambiguous reference to the credential. [1]
This property should be optional and not recommended.
Verifiable Credentials & Open Badges 3.0 are intended to be shared without any access to the issuer. A URL for an achievementCredential would be unique to the credential and if accessed by a verifier, could violate the privacy of the credential holder.
DCC will ignore this property when verifying and displaying. Currently using UUID.
related
re: language - OBv3 should considered aligning with how VCDM 2.0 handles multi-language credentials so that they are the same.
tag
Should this be an array?
fieldOfStudy
Revisit how this field is used and how it can accommodate credentials that are recognizing multiple fields, multiple majors, minors, concentrations, etc.
criteria
Criteria is required but neither the id or the narrative are required?
achievementType
Why isn't this required? What should be the default if systems consume an open badge without an achievement type?
id
Revisit if this should be required.
Many assertions may be created corresponding to one Achievement.
Achievements may also be unique to assertions.
Open Badges Verifiers must support the following supported proof mechanisms for Linked Data Proof format:
One or both? How about JWT?
Data Integrity ECDSA Cryptosuites v1.0 suite with the ecdsa-sd-2023 algorithm. The resulting credential MUST contain all required fields for the credential.
DCC could add
5. Open Badges 3.0 Host Service ConformanceThis section is non-normative.An Open Badges Host is an application that can aggregate and publicly host OpenBadgeCredential for recipients. It also supports export of badges at user request. The candidate platform must be able to import all formats of Open Badges as well as prove that badge metadata is not lost upon export of the badge. The candidate platform must also meet § 5.4 Service Provider (Write) Conformance requirements and accept an AchievementCredential or a Profile from an Issuer application. And meet § 5.2 Service Consumer (Read) Conformance and § 5.3 Service Provider (Read) Conformance requirements for exchanging AchievementCredentials with other Host applications.
Hosting is not part of the Open Badges 3.0 specification. Hosting verification is part of <=2.1 versions.
4.2.1 Supported Proof Mechanisms
See note for section 3.1.1
Demonstrate through video that the platform allows viewers of badges to do the following: Trigger verification of the badge and retrieve results verifying that the badge credential is not expired, and not revoked
This may not be necessary if testing system can use a digital wallet to interact with issuing platform and/or test uploaded .json files.
image (if the badge provided is a baked badge) name description issuer name issuedOn Date status (expired and/or revoked)
Reference and link to specific properties in the specification.
The conformance test system will display the URL of three badges.
Consider updating the conformance test system to accept .json files versus URLs. This is more inline with how Open Badges 3.0 are generated and used.
Verifiable Credentials Data Model v1.1 ([VC-DATA-MODEL])
Update t0 VCDM 2.0
"1EdTechRevocationList".
Will be updated with BitStringStatusList
The candidate platform must support viewer-initiated verification of a badge.
What does this mean?
3.2 Service Consumer (Write) ConformanceA product that conforms to Service Consumer (Write) requirements can send an OpenBadgeCredential or a Profile to a product that conforms to Service Provider (Write) requirements. Note In the scope of the conformance test system, the test system acts as the Service Provider, so a [Candidate Platform] MUST send credentials and profiles from the given conformance test system. 3.2.1 Required Service Consumer (Write) Endpoint Support The service endpoints that MUST be supported for Service Consumer (Write) are listed in the table below: Service Call Endpoint HTTP Verb Mode AuthorizationRequired getServiceDescription /ims/ob/v3p0/discovery GET Initiate No OAuth 2.0 Registration from Service Discovery Document (SDD) GET Initiate No OAuth 2.0 Authorize from SDD GET Initiate No OAuth 2.0 Token from SDD POST Initiate No upsertCredential /ims/ob/v3p0/credentials POST Initiate Yes 3.2.2 Optional Service Consumer (Write) Endpoint Support The service endpoints that MAY be supported for Service Consumer (Write) are listed in the table below: Service Call Endpoint HTTP Verb Mode AuthorizationRequired putProfile /ims/ob/v3p0/profile PUT Initiate Yes 3.2.3 Tests Obtain an access token from the conformance test system using provided getServiceDescription endpoint and the following OAuth 2.0 authentication flow with the provided login credentials. Ensure that the right scopes are sent. Create a valid AchivementCredential and issue it to the recipient conformance@imsglobal.org. Call the conformance test endpoint upsertCredentials, with the AchivementCredential. Submit the result of the call to the conformance test system. (Optional) Create a new Profile for the id "https://1edtech.org/issuers/cert" and call the conformance test endpoint putProfile with the Profile. Submit the result of the call to the conformance test system.
Unclear why this is needed for 3.0
3.1.1 Supported Proof Mechanisms Open Badges Issuers opting for a Linked Data Proof format as the signature of the badge must use one of the following supported proof mechanisms: Data Integrity EdDSA Cryptosuites v1.0 suite with the eddsa-rdfc-2022 algorithm. Data Integrity ECDSA Cryptosuites v1.0 suite with the ecdsa-sd-2023 algorithm. The resulting credential MUST contain all required fields for the credential.
The spec does not mention specific proof mechanisms. The spec mentions JWT but that is not mentioned as being supported here.
(Optional) Complete tests of, at least, required endpoints of § 3.2 Service Consumer (Write) Conformance.
Unclear why this is needed for conformance.
host
Hosting should be discussed. This breaks alignment with W3C Verifiable Credentials because it puts privacy at risk. Also, hosting is not part of the 3.0 specifictaion.
To discuss: if platforms want o host open badges, they should use 2.0 not 3.0.
Open Badges Host
See above note. Should be discussed that hosting be removed from 3.0 certification. Hosting is not part of the specification. Open Badges 2.0 has a hosting verification method but 3.0 does not.
issue it to the recipient conformance@imsglobal.org
Open Badges 3.0 are not issued to email addresses. Email addresses can be included but adding them to credentials is an unnecessary step.
Testing conformance should be done using a digital wallet application that mimics how a credential holder would be issued an open badge 3.0 directly.
Or the .json file of the tester's badge should be uploaded to a verifier app -- idelaly one that also does schema validation.
2.1 API categorization
To increase interoperability, 1EdTech should not provide an API for 3.0, only 2.0. 3.0 badges should follow VC-API and/or OpenID4VC.
Verification: The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds.
Updated definition needed to indicate differences between verifying signature, data tampering, and schema validation.
Verifiable Credential (VC): A tamper-evident credential whose issuer can be cryptographically verified. See [vc-data-model-2.0].
Updated definition needed to explain that the signature can be cryptographically verified, not the issuer. Could also explain that Open Badges 3.0 and W3C VC 2.0 are intended to be aligned.
Skill: Measurable or observable knowledge, skill, or ability necessary to successful performance of a person. Skill Claim: An assertion that the learner has the specified skill.
Seems irrelevant in the context of conformance. Re: skill claim (see above annotation about achievement claim.
Defined Achievement Claim: An assertion that the learner achieved a specific achievement.
Unclear what this and skill claim refer to. They are both defined in the spec but not referred to anywhere else.
Comprehensive Learner Record (CLR): Set of assertions that can be packaged as a verifiable credential.
Not relevant to this document
CLR
This conformance guide should focus on Open Badges
A Verifiable Credential more broadly asserts a claim about a Credential Subject which can be applied to education and occupational achievements.
Not relevant to this term
An Assertion asserts a single achievement. A CLR asserts a collection of assertions, each of which asserts a single achievement.
Not relevant to this definition
and “baking” badge information into portable image files
Consider removing "Baked Badges" from the spec. Images are no longer required. Badge baking is no longer necessary with Open Badges 3.0 since files are portable by default.
This version of the specification aligns Open Badges with the conventions of the Verifiable Credentials Data Model v2.0 for the use cases of Defined Achievement Claim and a Skill Claim. The credentials that are produced are easily be bundled into Comprehensive Learner Records and Verifiable Presentations. Portability and learner data privacy are improved by expanding the usage of cryptographic proofs/signatures, because this format will be compatible with a growing array of proof schemas that are developed for the Verifiable Credentials Data Model.
This paragraph could be re-written to explain the purpose of this document which is to explain the 1EdTech Open Badges 3.0 conformance process.