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.
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.
Thanks Phillip. On your first question, I've represented writing to the VDR and an inbound (to the VDR) arrow and reading as an outbound arrow to represent data flow. So, I think it's OK, but I see where you're coming from. Certiphi *is* contacting the VDR.
Your second question is more nuanced. As I noted in footnote (2), this isn't a classic callback since the information about which credential is being presented isn't transmitted, just the information that a credential was presented. The X.509 cert could also be written to the VDR, which would solve this. Or the credential could be included with the DIDDoc.
Side note: the information leakage problem is different for different DID methods and trust ecosystems are likely to choose which DID methods they support based on this and other factors.
Appreciate the reply Phil. I tend to prefer the interpretation of the arrow from the representing the initiator of the actions orientation. But I fully understand there are different approaches and accept yours.
I did read the footnote and considered it before commenting. I like very much the idea that the information about issuers is consolidated in one place, the verified issuer/verifier registry (your VDR), which was what I would suggest. Other data such a registry should have includes the governance policies and requirements by which an issuer is included, along with what actions non-compliance with these policies on the part of an issuer will be levied. You probably saw or viewed Dmitri Zagidulin's initial presentation on using VCs to capture decisions and policies of such VDRs. If you're going to have a registry for who 'trusted issuers' are, the criteria for inclusion should be equally searchable and retrievable!.
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.
Thanks Phillip. On your first question, I've represented writing to the VDR and an inbound (to the VDR) arrow and reading as an outbound arrow to represent data flow. So, I think it's OK, but I see where you're coming from. Certiphi *is* contacting the VDR.
Your second question is more nuanced. As I noted in footnote (2), this isn't a classic callback since the information about which credential is being presented isn't transmitted, just the information that a credential was presented. The X.509 cert could also be written to the VDR, which would solve this. Or the credential could be included with the DIDDoc.
Side note: the information leakage problem is different for different DID methods and trust ecosystems are likely to choose which DID methods they support based on this and other factors.
Appreciate the reply Phil. I tend to prefer the interpretation of the arrow from the representing the initiator of the actions orientation. But I fully understand there are different approaches and accept yours.
I did read the footnote and considered it before commenting. I like very much the idea that the information about issuers is consolidated in one place, the verified issuer/verifier registry (your VDR), which was what I would suggest. Other data such a registry should have includes the governance policies and requirements by which an issuer is included, along with what actions non-compliance with these policies on the part of an issuer will be levied. You probably saw or viewed Dmitri Zagidulin's initial presentation on using VCs to capture decisions and policies of such VDRs. If you're going to have a registry for who 'trusted issuers' are, the criteria for inclusion should be equally searchable and retrievable!.