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

The generalizazion proposed by Michael is quite natural in X.509 perspective, since it corresponds to the distinction between pub-key certificates vs. attribute certificates –
[cid:image001.jpg@01D56F9E.F61BF180]

Best,
--luca


Da: Daniel Hardman <daniel.hardman@evernym.com>
Inviato: giovedì 19 settembre 2019 20:12
A: Michael Herman (Parallelspace) <mwherman@parallelspace.net>
Cc: public-credentials@w3.org
Oggetto: Re: Verified Credentials: where are the protocols described for retrieving a VC?

You're generalizing in a way I had not thought of before (the mental model that a DID Doc is more or less a credential). I'll have to chew on that a bit...

In the meantime, here are some partial answers to your question:

One defined protocol for retrieving a credential from an issuer for the first time (a "credential issuance" protocol) is Aries RFC 0036<https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential>, which describes how issuance works for any credential type (JWT, LD-Sig, or CL-Sig based). Others on this thread may know of similar efforts.

One protocol for retrieving a credential from local storage is Wallet Query Language<https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0050-wallets/README.md#wallet-query-language>. Another might be built from DIF Identity Hubs Collections interface<https://github.com/decentralized-identity/identity-hub/blob/master/explainer.md#collections>, but I don't know whether any work has been done specifically on how creds should be indexed to make them conveniently queryable.

Retrieving a credential in the sense of preparing a presentation for a verifier is the subject of several protocol efforts. I believe Digital Bazaar is working on a web polyfill that addresses this sort of retrieval in web browsers; perhaps Manu or Dave can provide a link to that effort. Aries RFC 0037<https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof> describes how a presentation request can be made, and then satisfied with any credential type, using DID-based communication. And Workday has been doing work inside DIF, which is (I believe) an evolution of this paper from the recent RWOT conference<https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/PresentationRequest.md>, and which AFAIK answers this question for JWT creds specifically.

On Thu, Sep 19, 2019 at 11:42 AM 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:image003.jpg@01D56F9D.85DCDB10]

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]