RE: Verified Credentials: where are the protocols described for retrieving a VC?

The Early, Early Market

For context, first, we’re in the very early market phases wrt the adoption of blockchain (and more specifically, digital identity) concepts and capabilities as a foundational technologies for the Internet.  Checkout Phases of Foundational Technology Adoption (https://www.linkedin.com/pulse/blockchain-foundational-technology-michael-herman/).

As such (and as Daniel’s reply indicates), there are way too many protocols for doing what is essentially the same thing N different ways: creating, storing, finding, fetching, and transmitting a Credential (which, for me, includes DID Documents and Schemas – i.e. any set of Claims). This is perfectly OK and expected …we’re in the early, early market. There should be a lot of different approaches to be considered before settling in on a small subset of specifications that become industry standards …perhaps there’s also a bit of NIH going on …a bit of first mover advantage / “no mystery, no margin” thinking going on too.   Whatever the motivations are, at this point, every idea is a good idea but only that.

We’re still “in the box” …the curve today may look asymptotic but it’s not.  Here’s my version of the Digital Identity Hype Cycle… (my apologies in advance to Gartner).

[cid:image005.jpg@01D56FA3.496AB520]

Interop

Snorre, you mention “the reason for why the interop project efforts are so important”.  As I suggested above, I believe this is an early market phenomena because there are too many options to choose from.  I think this problem, the need for an interop solution, will either go away or be greatly diminished “in the fullness of time”.

Everyday Credential Protocols

One protocol that is missing from Daniel’s list below is DNS’s plain old binary protocol.  It’s been around for awhile (decades) and has proven itself to be perfectly adequate for storing, managing, finding, and retrieving, what in effect are, Internet credentials (sets of claims) …it’s been doing this for several decades …since the ‘60s?  DNS Servers are lightweight in terms of the amount of code and the resources needed to execute a DNS Server on a scaled basis.

I’ve written about DNS Extensibility (and credentials) in a small section I’ve added to the article DNS (Domain Name Service): A Detailed, High-level Overview (https://hyperonomy.com/2019/01/02/dns-domain-name-service-a-detailed-high-level-overview/).  Check it out.  When I first wrote the article at the beginning of 2019, I had no idea I would be basing the Trusted Digital Web on DNS-enabled UDIDServer technology.

Similarly, every agent, every wallet, every resolver, every TDW app, etc. etc. can simply/potentially run on top of it’s own DNS-enabled credentials engine/service …using the exact same everyday DNS protocols for creating, managing, finding, and retrieving DID Documents, Credentials (of any type), Schemas, etc. etc.  Here’s an example…

[cid:image008.jpg@01D56FA3.496AB520]

Encrypted Data Vaults

I believe this type of thinking (e.g. DIDs can only be associated with credentials backed by a blockchain) is inherently problematic …too narrowly focused; hence, Universal DIDs ...a DID for Every Little Thing (ELT) in the universe (https://hyperonomy.com/2018/01/24/tokenization-of-every-little-thing-elt/).  We need to have DIDs, DID Documents, Credentials, Schema, etc. that can live anywhere …not just on a blockchain …as well as the same “in motion” which clearly don’t live on a blockchain while being moved/communicated.

IMHO, we don’t need specific, additional/new protocols for Encrypted Data Vaults.  EDVs just become another data source for credentials sitting under an extensible DNS framework/platform/engine/service/server.

[cid:image001.jpg@01D56F8F.23B09840]

Best regards,
Michael Herman
Self-Sovereign Blockchain Architect
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[Trusted Digital Web Certificate 0.1]



From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Sent: September 20, 2019 3:49 AM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net>
Cc: daniel.hardman@evernym.com; public-credentials@w3.org
Subject: Re: Verified Credentials: where are the protocols described for retrieving a VC?

I think the questions you are raising are important, and the reason for why the interop project efforts are so important.[https://app.prosperworks.com/tp/t/NzMzNDc5fHx8fHwyNTU0NTJ8fHx8fDE1Njg5NzI0ODU3MTY=/space.gif?creator=snorre@diwala.io]
There were some papers at RWoT 9 that was raising the same concern and trying to raise the need for some agreement on what to put the efforts into. And some specifying more clearly how a general API can look towards the storage part. The were called encrypted data vaults.

But since these questions come up time after time, and everything we are able to answer with is an example of a query language that I dont know if everybody is working around. Then we need to put more effort into the case of interop, and be able to bridge the different efforts.
This is one effort going on: https://github.com/decentralized-identity/interop-project

And I believe Aries is doing some good work, someone here can fill in more on that than me.



On Thu, Sep 19, 2019 at 7:44 PM Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
Good analysis (as usual 😊) Daniel,

First, one potential point of confusion is that I’m thinking of a Credential in broad terms:

  *   A set of Claims (name-value pairs) associated with a Credential ID as well as the ID of the Subject of the Credential
  *   In this sense, I’m not distinguishing between a Credential and a DID Document …neither physically or from a high-level schema perspective, they essentially look the same:
a set of Claims (name-value pairs)
  *   A Credential is an actual thing (aka application object) …i.e. an instance of a data structure filled with data values

Let’s look at your use cases:

  1.  the holder receiving the credential for the first time from the issuer

     *   It’s a fair assumption that the Issuer (before transmission) and the Holder (upon receipt) will need to store the Credential somewhere (e.g. local wallet, private database, etc.).
What are the keys for retrieving/working with these Credentials?
     *   The Credential will also need to be persisted for transmission and might live in an indexed, intermediate store that is part of the communication protocol.
What are the keys for retrieving/working/inspecting with these Credentials?

  1.  the holder sharing the credential with a verifier later

     *   Ditto for the Holder and Verifier (interchanging Verifier for Holder and Holder for Issuer)

  1.  the holder looking up the credential in their private database, for their own use?

     *   Ditto for the Holder (essentially the same as use case #1 and #2)

In all 3 use cases, an Agent, or another piece of software, might also need to “inspect” a Credential to determine who the Subject is as well as the scope/subject matter of the Credential (Credential ID, schema identifier, etc.).

So my evolved questions are:

  1.  How are Credentials uniquely “named” or identified?   Subject ID only, Credential ID only, or should it be both?
  2.  Are there any evolving (generic) APIs/protocols for retrieving a Credential (set of Claims) from a store (e.g. a wallet, private database, distributed transaction store, relational database, etc. etc.)

[cid:image001.jpg@01D56F8F.23B09840]

Best regards,
Michael Herman
Self-Sovereign Blockchain Architect
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[Trusted Digital Web Certificate 0.1]



From: Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>>
Sent: September 18, 2019 9:46 PM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Cc: public-credentials@w3.org<mailto:public-credentials@w3.org>
Subject: Re: Verified Credentials: where are the protocols described for retrieving a VC?

When you say "retrieving" a verified credential, are you talking about the holder receiving the credential for the first time from the issuer--or about the holder sharing the credential with a verifier later--or about the holder looking up the credential in their private database, for their own use?

On Wed, Sep 18, 2019 at 8:21 PM Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>> wrote:
Where are the protocols described for retrieving a Verified Credential?  For example, at the Technology level, is a VC just the same as a conventional DID Document?

Also, do you only need to know the DID for the VC to be able to retrieve it? …or do you need to know both the DID for the VC as well as the DID for the Subject of the VC?

Best regards,
Michael Herman
Self-Sovereign Blockchain Architect
Hyperonomy Digital Identity Lab
Parallelspace Corporation

[Trusted Digital Web Certificate 0.1]




--
[https://drive.google.com/uc?id=1rrnSCfL0eQbwK0dS3CE6XFtdHO8NDHMq&export=download]
Snorre Lothar von Gohren Edwin
Co-Founder & CTO, Diwala
+47 411 611 <tel:+47%20404%2061%20926> 94
www.diwala.io<http://www.diwala.io/>