From my testing it looks like the open badges specification doesn’t align with the V2 assertion because the badge ID is always set to urn:uuid:example. The open badge validator always rejects my assertions because it doesn’t recognize the badge id as a valid IRI?
Could you share your issuer profile?
https://openbadgespec.org/extensions/applyLinkExtension/context.json
I’m pretty sure the issuer is valid because my credentials have been verifying via the Blockcerts verifier.
Edit: Just noticed that the email on my hosted issuer profile is different than the one inside my BadgeClass, could that be causing the issue?
Getting closer, There are 4 native extensions used to create the certs which are recipientProfile, signature, signatureLines and verification. When I use an open source Open Badges validator they all return errors. I think they all need a @context included as well? Here is what the validator outputs, also it doesn’t seem to like the publicKey attribute of the issuer profile, specifically because the ecdsa-koblitz-pubkey isn’t a valid IRI.
"messages": [
{
"name": "VALIDATE_EXTENSION_NODE",
"messageLevel": "ERROR",
"result": "Could not determine extension type to test",
"success": false
}
Edit: Ok I’m starting to understand this a bit better. I see that the blockcerts context that is linked into credentials includes the obi validation for the native extensions. If I included additional global values and per recipient values then do I need to build obi validation via extensions?
More progress, any help is appreciated!
I have forked the openbadges validator to get down to the bottom if this issue.
one of the node_types that is being parsed through the blockcerts v2 context is “https://w3.org/blockcerts#RecipientProfile”
If I hardcode it to be RecipientProfile instead, I don’t receive any obi:extension errors. Due to this error the openbadges validator cannot determine what type to test for each of the Blockcerts extensions.
Thanks
It would be easy to debug if you could share the json certificate file and issuer. Also testnet public key is safe to share anyway.
Can’t upload JSON files to this forum but here’s the credential json as an image. The issuer json remains unchanged from the previous image.
Changed a couple domains to protect our dev servers.
can’t see much details on this picture. Make sure you hosted issuer json and revocation list with a valid URL and not from the example of blockcerts.
Ok. Any advice on linking my own contexts. Everytime I try to issue a credential with a linked context I get a cors error. The source of the context has cors enabled and access-control-allow-origin: * set.
You can verify the headers if CORS is enabled including Methods.
Chrome → inspect element → network → Response Headers
It should be like this
access-control-allow-methods: GET
access-control-allow-origin: *
Been trying to solve this and I made my way back to the cert-schema IMS Consortium repo that contains some blockcerts openbadges examples. From the v2 open badge compliant blockcerts examples provided by Kim Hamilton, I am still getting the same node extension errors. Does the blockcerts context need to be changed to properly validate credentials as an open badge?
Can anyone provide an example of a Blockcerts credential that is a valid v2 open badge.
Managed to get to the bottom of this open badge v2 validation issue. The Blockcerts verifier is looking for a string that contains the “escda-koblitz-pubkey:address” in the publicKey.id field, while the open badges verifier is just validating that the publicKey.id field is a valid IRI.
I set the value to an IRI and had no issue with open badge validation, but this causes the blockcerts-verifier to yield invalidIssuingAddressUnknown when trying to verify the certificate which I believe is caused by this file in cert-verifier-js.
I may try to work on a pr to implement the publicKey id’s to accept strings and urls that link to a escda-koblitz-pubkey address.
Hi @ampatt97, cert-verifier-js does not know explicitly about escda-koblitz-pubkey sort of keys. I believe your problem must be something different.
The file you are pointing to only confirms that the key used to sign the blockcerts is listed as valid by the issuer. Could you share the error you are getting?
Yeah, after a bit of work I found this file that was stripping the escda-koblitz prefix from the publicKeys to validate them with blockcypher. I added some code to check if it is a uri and pull the publicKey from there. Fixed the validation issues that I was having.
Good catch, I had forgotten about that step. Yet this should not fail if it’s not there?
The reason it was failing was that I was using a URI to host my publicKey and so I had to add a request to fetch that publicKey for validation. It works for me now.
Great questions in this thread. I wrote the OB validator as part of work for the 2.0 implementation with IMS Global. I don’t have a huge amount of time to throw at it, but I can sometimes help debug the error messages from the validator.
Open Badges 3.0 is coming soon. See the details of the proposed scope here: Open Badges 3.0 Proposal by kayaelle · Pull Request #303 · IMSGlobal/openbadges-specification · GitHub
- Verifiable Credentials Compatible. Essentially defines a schema for how a verifiable credential can claim that a credentialSubject has achieved a particular badgeclass definition
- It would not be hard to support blockcerts-specific proofs as supported verification type.
- The validator dot openbadges dot org and badgecheck dot io validators will be updated to support the 3.0 schema ~Q4/Q1 as it reaches a pretty stable state.
- The extensions in 2.0 are the most complicated fiddly little bit of verification. We’re going to propose a mechanism in coming weeks for simplification of the extensions mechanism, so that the type IRI is the URL at which extension validation information is available, rather than an extension-specific context. The issue here I think is that you haven’t linked an extension-specific context from which the validator grabs validation information. The new approach that I’m hoping to hit for OB 3.0 will avoid this problem.
1 Like