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> 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?
>
>       2. the holder sharing the credential with a verifier later
>       - Ditto for the Holder and Verifier (interchanging Verifier for
>       Holder and Holder for Issuer)
>
>       3. 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.)
>
>
>
>
>
> Best regards,
>
> Michael Herman
>
> Self-Sovereign Blockchain Architect
>
> Hyperonomy Digital Identity Lab
>
> Parallelspace Corporation
>
>
>
> [image: Trusted Digital Web Certificate 0.1]
>
>
>
>
>
>
>
> *From:* Daniel Hardman <daniel.hardman@evernym.com>
> *Sent:* September 18, 2019 9:46 PM
> *To:* Michael Herman (Parallelspace) <mwherman@parallelspace.net>
> *Cc:* 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> 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
>
>
>
> [image: Trusted Digital Web Certificate 0.1]
>
>
>
>
>
>