Hello,
In the cert-verifier-js, the identity verification derived issuing address from did document and compare it. I don’t know the exactly function of the step. As the DID had been written in the VC which means the DID is authentic already. I found the introduce at Introduce DID verification
but I still don’t know the meaning of it.
How could it strengthen trust in the issuer’s identity and what does it mean if comparing addresses step succeed and fail?
thank you
Hi @linear,
you are touching a philosophical subject of DIDs that I never got a straight answer to even at the w3c working groups level.
To me, DIDs are a powerful technology, but they are only a vector to share keys, and you can’t assume ownership without verification (ie: a challenge endpoint on a domain, or in the case of did:web or hosted DIDs, trusting the domain belongs to the issuer, falling back to a CA, defeating the Decentralized in the DID).
But because anyone can create a DID, what stops someone from impersonating someone else, issuer or recipient?
You are still missing a trust link to prove the ownership of the DID, and while some decentralized solutions have been written in a white paper (I unfortunately cannot seem to find the link to one example document, it was about trust links between different actors vouching for each or other), at the time of implementation, no technical implementation was available.
So the decision we took was to make a DID document hold the public key that was used to generate the issuing address, and reference that key in the verificationMethod to 1) leverage that property 2) align with the SSI ecosystem expectations. As some issuers can have a registry of their issuing addresses (ie: Massachusetts Institute of Technology - Verification Portal), proving that they indeed hold both the key to the issuing address and the issuing address reinforces the trust you can have in the DID URI used as the issuer property in a cert.
I agree it is still half decentralized, but until a proper chain of trust can be established this is a solution that appeared to us as a viable approach.
Lastly, we have adapted the current (or legacy, depending on the point of view) issuer profiles so they can be a hybrid format between the V2 solution (just listing the issuing addresses in a hosted document) and the V3 DID support (they can have verificationMethod and assertionMethod properties as a direct copy of the DID properties, ie: https://www.blockcerts.org/samples/3.0/issuer-blockcerts.json).
Hope that clarifies the thought process that settled that extra verification step.
1 Like