Using X.509 Certs for DID Provenance
Summary: The abundance of X.509 certificate authorities who already perform identity proofing for businesses provides a rich resouce that can be leveraged to boot the verifiable data ecosystem. Here’s how it could work.
When you used a verifiable credential to prove something about yourself, the verifier can know cryptographically: (1) the identifiers for the issuer, (2) the credential hasn't been tampered with, (3) the credential was issued to you, and (4) the credential hasn't been revoked. These four checks are important because their establish the fidelity of the data being transferred. They don't, however, tell them whether they can trust the issuer. For that, they need to take the issuer's decentralized identifier (DID) that they got from credential presentation and determine who it belongs to.
At Internet Identity Workshop last week, Drummond Reed gave a session on how X.509 certificates could help with this. The first step, like always, is to resolve the DID and retrieve the DIDDoc that associates keys and endpoints with the DID. The endpoint can be an HTTP server and, of course, should have an X.509 certificate providing TLS security. That certificate, at the very least, has a a domain name to bind that to the certificate's public key. It can, if you pay for the feature, also include information about the entity that applied for the certificate. The certificate authority proofs that information and is vouching for it when they sign the certificate.
The key to making the X.509 certificate useful for checking the provenance of a DID lies in one key change. X.509 certificates can contain and extended field called a Subject Alternative Name. This following figure shows how it can help.
The issuer (Attestor) creates the DID they will use to issue the certificate along with its associated DIDDoc, including an HTTP endpoint for DID verification.
Attestor applies for a X.509 certificate for that endpoint, including in the application the DID they created in (1).
The certificate authority does it's usual proofing of the application and issues a certificate that includes the DID in the Subject Alternative Name field.
The issuer creates a credential definition in the usual way that includes their DID and writes it to whatever Verifiable Data Registry their DID method dictates.
Attestor issues a credential to a holder (Alice) using that credential definition.
At some later time, Alice presents the credential to the verifier (Certiphi).
Certiphi resolves the DID to get the DIDDoc and retrieves the verfication endpoint from the DIDDoc
Certiphi retrieves the certificate for that endpoint1.
Certiphi verifies the certificate by checking it's signature and ensures that the DID in the DIDDoc for the credential matches the one in certificate.2
The issuer's DID has now been tied in a verifiable way to whatever information is in the certificate. Provided the certificate includes information about the entity beyond the domain name, the verifier can use that information to determine whether or not the credential is authentic (i.e., issued by who the credential definition purports issued it). That might be all the evidence they need to determine whether to trust the entity. Certificate authorities could also issue verifiable credentials to the customer attesting the same verified claims—after all, it's one more product they can offer.
The benefit of doing issuer validation using X.509 certificates is that there are already many trusted X.509 certificate authorities in business who already do proofing of attributes about businesses. That's a huge chunk of the verifiable data ecosystem that doesn't need to be built because it can be leveraged. To make this work, digital certificate authorities would need to start offering to validate DIDs and include them in a certificate as a Subject Alternative Name. I don't discount that this will take some bureaucratic maneuvering. Certificate authorities will need to see a business opportunity. I'd love to see Digitcert or someone do a pilot on this.
Notes
Note that this step might be combined with the previous step if the Verifiable Data Registry is the same server as the endpoint, but that's not necessarily going to be the case for a number of reasons.
Note that this does not create a call back wherein Attestor can determine which credential was used, preserving the privacy of the presentation. Attestor does know one of its credentials has been presented to Certiphi.
Of course, this workflow would also benefit from more secure comms/protocols such as DIDComm or ToIPs proposed Trust Spanning Protocol
Phil - it's presentations like the one you've just summarized from Drummond's talk at the latest IIW that drive home how important this gathering of people is to the SSI/VC community.
I have two questions, both possibly representing miss-interpretations of what's being said. The first is shouldn't the direction of the arrow in the graphic "Using X.509 Certificates to establish the owner of a DID" listed as #7 Reads be from the Credential Verifier to the Verifiable Data Registry? The Credential Verifier is reading the vetting information provided by the link in the credential to the DIDdoc where that information is stored in the Verifiable Credential Registry.
Second Step 8. Retrieves Certificate seems to be a call back to the issuer (your Attestor Org). Isn't that one of the fundamental design principles the decentralized architecture of VCs intentionally eliminates the necessity for? If that's a necessary step, a core value proposition, namely the ability to still verify an issuer who has 'gone away' (business folded, college closed, etc.) should still be possible as long as the public key of that now defunct issuer has been preserved and past on to some public third-party (such as a verifiable issuer registry or other persistent publicly accessible endpoint.
Cheers.