DIDs as a way to properly identify issuers

Standards
1

DIDs as a way to properly identify issuers

TL;DR:

Add a did field that contains a DID for the assertion issuer in the VerificationObject of the assertion.

Prolog

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 .badge.issuer.id.

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 VerificationObject

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 verification.publicKey field.

https://github.com/blockchain-certificates/blockcerts-verifier/blob/master/src/selectors/certificate.js#L228

Unvalidated field

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

The problem

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.

The solution

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.

The proposal

Place a field in the verification object (type MerkleProofVerification2017) for the DID that will be used for the assertion registration in the MerkleProof2017 signature.

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.

Epilog

If the forum is not the right place to discuss this, could you please refer me to where this discussions may take place?

Thanks everybody!

2 Likes
2

PD: I think @kim could help with this!

3

Thanks a lot @davidlj_btca for the write up! I wanted to get a couple more things written up in that V3 draft before engaging the broader community but I think this is a good thing we can go ahead and talk about, and I’m glad you’re already looking at it!

I actually had no idea, I had assumed we were. I do agree, maybe we should fix that.

So I guess right now, there’s several locations where public key is located. In the VerificationObject, in the transaction’s public key that made the transaction, and part of the issuer profile. Seems like then we are only comparing transaction public key with the issuer profile public key.

I’d almost question whether or not we really need VerificationObject at all if we can always derive the public key based on the transaction information, and compare that with issuer keys. I guess at this point it’s just to comply with Open Badges.

If we’re keeping it, I’m wondering if we can get away with not placing an additional field at all. Given that we already use prefix’s for publicKey, we should be able to use a did reference pointing to a key (ie, did:method:123#key0). Looks like Kim also had that consideration when writing this: https://github.com/IMSGlobal/cert-schema/blob/master/docs/open_badge_v2_extensions.md#considerations-for-adopting-as-official-open-badge-extensions

It would be up to verifiers to understand the URI if they support did’s / specific did methods, and resolve them to a public key.

Though, in the case of V3, we’d now have 4 places where public key is referenced. Transaction, VerificationObject, DID key, and (as part of VC spec) - proof.verificationMethod.

Would that be overkill? Is that simply the price we pay to be VC compliant AND considerate to OB?

I think the forums are still a good place! I check them daily, just had to sit on your thoughts for a few days :slight_smile:

1 Like
4

Hi @aronning,

Thanks for your elaborated response!

About the displayed issuer’s public key field that is not getting validated, I’ve placed an issue in the blockcerts-verifier repository:

Yeah! We could use the DID reference to the public key in those field so no new field would be necessary.

Looking forward for Blockcerts v3 specs and features btw!

5

We could also use DIDs in IssuerProfiles public keys, despite it would be better using them in VerificationObject so this way if we resolve the DID properly there, we don’t need to fetch the IssuerProfile any more if the revocationList is placed in the assertion.

I’ve made a pull request in cert-schema repo for this little step towards adopting DIDs

6

I am not sure it’s a good thing to put in the v2.1 spec. We’d need a lot of code changes in place with the verifiers & displayers to support such a thing.

I’ll spin up a bunch of v3 branches across the repos once we outline the v3 draft a bit more and start engaging everyone on it, but I appreciate the initiative!

1 Like
7

Agree. I’ll contribute when those new branches appear then.

Thanks @aronning