Re: Verifiable Requests?

Regarding "verifiable requests" (either that credentials be issued or that
they be shared in a presentation):

When you request something, two different types of verifiability may become
interesting.

1. Being able to verify that you (as opposed to someone else) made the
request.
2. Being able to verify that you have a *reasonable basis* to make such a
request.

Verifiability type 1 is a matter of committing in a non-repudiable way to
the request. It is making the request "on the record." This has very little
to do with credentials or the VC spec; it is essentially a question of
being authenticated (NOT authorized) in a way that third parties can check.
There are lots of ways to accomplish this authentication: website login,
SSH session, digital signatures, DID AuthN, etc, etc.

Verifiability type 2 is directly related to issues that the VC spec
surfaces. It's the question that people with a COVID-19 vaccination
credential should ask when they are challenged to prove part of their
health history: "Why should I tell you?" However, this question doesn't
need a new format/spec, because it is nothing more than inverting the
relationship between the requester and the requestee. A policeman knocks on
your door and says, "Are you John Q. Public?" And you say, "Who's asking?
Prove you're a policeman and I'll answer your question." He shows his
badge. Then you show him your driver's license. We don't need to understand
any part of this as a "verifiable request" happening; there are simply two
requests, one nested inside the other, with the roles reversed, and the
response to the first was made contingent on the response to the second.
The request isn't being verified; the bona fides of the requester is. The
data that gets shared to satisfy both requests is described by the VC spec
(a verifiable credential/presentation). The spec that DIF's been working on
covers how the request for this type of proof is made, but explicitly
excludes from its scope the question of which protocol is used to
communicate the request. (The request could flow over raw sockets, email,
DIDComm, CHAPI, or whatever.)

FWIW, here are the things that I think we need to standardize:

1. A credential and a presentation (the VC spec)
2. How a credential is requested (what the new DIF spec calls a
"presentation definition", which is quite powerful and generally useful,
IMO)
3. How a response to a request explains the way that the response maps to
the request ("You asked me for either a driver's license or a passport,
plus proof of my current address. I chose to give you the passport, and to
prove my current address by showing you a utility bill.")

Item 3 is also covered by the new DIF spec, but the name for it in that
spec is really unfortunate, IMO. The spec calls it a "presentation
submission." I think that sounds like basically the same things as a
verifiable presentation, when in fact it's quite different. I'd prefer to
see it named "presentation explanation" or similar. See
https://github.com/decentralized-identity/presentation-exchange/issues/166.



On Fri, Dec 18, 2020 at 7:25 PM Liam McCarty <liam@unumid.org> wrote:

> My best attempt:
>
> 1. I’m not sure there’s any consensus, but it’s possible there’s a sort of
> hidden convergence that could later yield consensus. I’m hopeful this
> thread might pull to the surface other people/companies who’ve implemented
> similar things. If it’s true that many applications of the standards would
> involve some notion of a verifiable request, there may be enough similarity
> in what we’ve all been building to warrant trying to formalize it.
>
> We started thinking this might be true because other companies have
> released materials with similar language/concepts to what we’ve been using.
> For example, Microsoft’s API docs has a presentation-request
> <https://didproject.azurewebsites.net/docs/verify-credential-in-web..html> endpoint and
> Evernym’s API docs have endpoints like PresentProofRequest
> <https://app.swaggerhub.com/apis/evernym/verity-rest-api/1.0?utm_medium=email&_hsmi=96927175&_hsenc=p2ANqtz-9Nd8xV3pG79PJpQ68Tqw6kCjCdDpG5QL3u2IXzrbhwmrIs_pkRiZ7_GyWdHWzpsMvE4P2Yla9UAV-xPK7ksHbmkhsOxw&utm_content=96927175&utm_source=hs_automation#/PresentProofRequest>
>  and RequestCred
> <https://app.swaggerhub.com/apis/evernym/verity-rest-api/1.0?utm_medium=email&_hsmi=96927175&_hsenc=p2ANqtz-9Nd8xV3pG79PJpQ68Tqw6kCjCdDpG5QL3u2IXzrbhwmrIs_pkRiZ7_GyWdHWzpsMvE4P2Yla9UAV-xPK7ksHbmkhsOxw&utm_content=96927175&utm_source=hs_automation#/RequestCred>
> .
>
>
> 2. I think there’s a difference between transfer/exchange and knowing who
> you’re transferring to or exchanging with. From the VP definition, it seems
> the motivation is provenance not communication. It says the goal is to
> ensure “authorship of the data is verifiable". A similar motivation could
> apply to a verifiable request: to ensure authorship of the request is
> verifiable. To frame this in terms of practical needs, this basically
> amounts to phishing prevention, which is hugely valuable in at least the
> use cases we’re working on.
>
> I’ll admit things start to get rather confusing here. It’s tempting to try
> a different framing that remains within the “verifiable credential”
> conceptual sphere. Shouldn’t the verifier prove (to the subject) it says
> who it claims to be by presenting a credential that says as much? But then
> the verifier is acting as a subject, and the subject is acting as a
> verifier… And honestly that line of thinking becomes a completely
> discombobulated mess! I suspect this is part of the origin story of
> “verifiable presentation” — a way of avoiding the mess. I think a similar
> origin story might be appropriate for “verifiable request”.
>
>
> 3. Maybe? Honestly it’s super hard to keep track of all the different
> communities and specs. This is the blessing and the curse of having
> distance between those focused on writing the standards and those focused
> on building with them. I count myself more in the latter camp, so I’m
> really not sure.
>
>
> 4. Makes sense!
>
>
> Thanks for the great conversation everyone,
>
> Liam
>
> *Liam McCarty*
> Co-Founder of Unum ID <http://www.UnumID.org>
>
> On Dec 18, 2020, at 7:48 PM, Kim Hamilton <kimdhamilton@gmail.com> wrote:
>
> There are a lot of interesting things going on here, and I need help
> untangling it.
>
> 1. The idea that it’s a gap in the VC data model would imply there’s
> consensus on what a Verifiable Request is. Does this mean there is a
> common/well known structure, or that rather the concept of a "Verifiable
> Request" is missing?
>
> 2. I was especially surprised by the idea that it's a gap, because the VC
> data model explicitly does not define transfer/exchange protocols (see section
> 5.1 <https://www.w3.org/TR/vc-data-model/#lifecycle-details>), but I see
> your point. VPs are used within one side of the exchange protocol, so it
> does it feel asymmetric. I checked the definition of VP
> <https://www.w3.org/TR/vc-data-model/#presentations> and understand the
> argument for a distinct notion of a VP. But yeah it certainly feels odd
> because of the way VPs are used.
>
> 3. I thought Verifiable Requests were one of the points of the
> Presentation Exchange spec? Is this saying there is an element of the PE
> spec that is analogous to a VP that might make sense for inclusion in the
> VC data model?
>
> 4. Either way, I believe we can't approach this as a change to the
> existing VC v1 spec. But if it makes sense, it could be incubated, proposed
> as a note (I think that's the term) on the existing spec, and then finally
> a candidate for inclusion in a next rev of the spec.
>
> I’m very supportive of (what I think is) the goal, and I think it’s a good
> candidate for further refinement. I'm not very familiar with the PE spec,
> so maybe I'm just confused.
>
>
> On Fri, Dec 18, 2020 at 4:49 PM Liam McCarty <liam@unumid.org> wrote:
>
>> Interesting. In case it’s helpful, in our own implementation we’ve found
>> that “request” can become pretty overloaded but it’s still a very intuitive
>> term. So, we distinguish between “verifiable *presentation* requests”
>> and “verifiable *credential* requests”. The former is a verifier
>> requesting a presentation from a subject, and the latter is a subject
>> requesting a credential from an issuer. And to be honest, we ended up just
>> dropping “verifiable” from the names because it gets pretty clunky
>> otherwise.
>>
>> We haven’t needed to use credential requests much yet, but I think how
>> much they vs. presentation requests are needed probably depends a lot on
>> use case. The "credential offers" Wayne described seem like a good
>> complementary concept, where the issuer is offering (requesting?) something
>> from the subject.
>>
>> There’s a subtlety we’ve come across that I’ll also mention: It’s useful
>> to allow requests to be both general and specific. What I mean is, for
>> presentation requests, sometimes you want one that can be received by any
>> subject, and other times you want one that’s only for a specific subject.
>> Same with credential requests, where sometimes you want it to be for any
>> issuer and other times for a specific issuer. Again, I think which type is
>> more common depends hugely on use case.
>>
>> I’m a proponent of *not *trying to include every conceivable use case in
>> v1 of the standards. Much better to let practical implementation needs
>> guide the way. That said, I think these sorts of concepts would be really
>> helpful to include. And frankly, my guess is anyone who’s implementing the
>> current standards has invented things that are roughly equivalent… because
>> they’re simply necessary for real world applications. And because of that,
>> I’m sure much of this is old news to many!
>>
>> Liam
>>
>> *Liam McCarty*
>> Co-Founder of Unum ID <http://www.unumid.org/>
>>
>> On Dec 18, 2020, at 6:23 PM, Wayne Chang <wyc@fastmail.fm> wrote:
>>
>> Related to this, there is also the matter of Credential Offers--VC-like
>> objects that aren't fully populated or signed, but could be populated with
>> a wallet and signed by an issuer upon verification of the information. For
>> example, an issuer wants to know which one of your multiple valid DIDs/URIs
>> they should use as the credential subject.
>>
>> On Fri, Dec 18, 2020, at 7:16 PM, Liam McCarty wrote:
>>
>> Fully support this! We’ve been using our own version of verifiable
>> requests from the beginning because there’s really no choice for many use
>> cases. (Or rather, there’s no choice but to have some notion of requests —
>> and may as well make them verifiable.)
>>
>> Liam
>>
>> *Liam McCarty*
>> Co-Founder of Unum ID <http://www.unumid.org/>
>>
>> On Dec 18, 2020, at 6:08 PM, Gabe Cohen <gabe.cohen@workday.com> wrote:
>>
>> Hi CCG folks,
>>
>> We at Workday are working on wrapping Presentation Exchange
>> <https://identity.foundation/presentation-exchange/>  requests and
>> notice there is a gap in the VC-Data-Model. There is a section on Verifiable
>> Presentations <https://w3c.github.io/vc-data-model/#presentations>, but
>> not Verifiable Requests.
>> What about adding pretty much the same language as VPs, but for VRs —
>> wrapping a request for credentials with some metadata and a proof?
>>
>> Happy to collaborate on getting this added.
>>
>> Gabe
>>
>>
>>
>