DIDs as a way to properly identify issuers
did field that contains a DID for the assertion issuer in the
VerificationObject of the assertion.
I know Blockcerts does not take care about issuer identities as specified by the FAQ, but given the last discussions (https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/BlockcertsV3.md) about next Blockcerts version, I’d like to know if we could introduce a minor backwards compatible modification to the current standard version v2 so that we can start dealing with DIDs for a better assertions’ issuer identification.
Current issuer identification
We currently have two pieces of data to verify the issuer of an assertion:
The assertion’s badge’s issuer ID
In order to properly identify an issuer, now we place a dereferenceable IRI in the assertions’s
This will be used by the reference validator (cert-verifier-js) to fetch the issuer public keys so we know they were valid when the assertion was registered on the blockchain.
Therefore we know that who can control that IRI resource, can also publish the public keys that will be used for verification purposes in the
checkAuthentication step in cert-verifier-js.
Summarizing, we know that the controller of this IRI resource is who says whose keys of the issuer of the assertion are valid
Public key verification in
As we can see in the 2.1 spec, you can also include the public key of the issuer used to register the assertion in the blockchain in the
VerificationObject field, thanks to the
publicKey extension defined per Blockcerts:
This won’t be used for validation purposes, but the reference visual validator Web Component (blockcerts verifier) will use it to display the public key the issuer used to register the assertion on the blockchain.
This field comes from the blockcerts-verifier Web Component that picks the assertion’s
This field is not used in the validation steps of the reference implementation (cert-verifier-js) so maybe the address placed there is not the real one used for registration and the assertion keeps being valid (as per the current implementation).
Should this be fixed btw? This address is being shown on the blockcerts verifier as the issuer key but that key may not be the actual key used for the assertion’s registration on the blockchain
We rely on the issuer’s identity by the first piece of information, the issuer’s IRI (because of the reasons explained above).
We can implement a custom verifier that allows setting the trust on issuers IRIs so that we know if those issuers are trusted (like I think the
Blockcerts Wallet Android app by Learning Machine does).
That’s a poor solution as it would be ideal to not use DNS authorities to as a trusted third party.
With DIDs we can add more information to the issuer via the DID document and provide credentials that enforce its identity, therefore creating a solid identity, while keeping (depending on the DID method) a more decentralized registry to save those identity information verifiable credentials.
Place a field in the verification object (type
MerkleProofVerification2017) for the DID that will be used for the assertion registration in the
Then, a validator would have to resolve the DID and retrieve the DID authentication public keys and use those to validate the
MerkleProof2017 signature the same way is it done now.
If the forum is not the right place to discuss this, could you please refer me to where this discussions may take place?