Re: Verifiable Requests?

Lots of good discussion to respond to here, so in order:

Wayne:
I did not intend to cover the case of agreeing upon which did to use, or filling out a credential. It’s a legitimate problem, but may be off the mark for what I was thinking of.

Liam:

  *   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.
100% agree!

Kim:

  *   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?

I don’t think a gap implies consensus, it just implies there’s something asymmetrical about the spec (describing Verifiable Presentations, without defining why you would create one). I don’t think there is a well-known structure. There’s OIDC, DIDComm, and probably a few more protocols that enable what I’m thinking of as a Verifiable Request. On the flip side, when presenting credentials, I can use OIDC, DIDComm, and Verifiable Presentations alone.


  *   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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_vc-2Ddata-2Dmodel_-23lifecycle-2Ddetails&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=KljLoXEecHgPnlek4-t3ZT97PrCN8ulPcndHx4ilXq4&e=>), 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_vc-2Ddata-2Dmodel_-23presentations&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=aGIZIeb-kyrYg2gU4SX6JOcVC1rJ68tJYO8QMxuPgLU&e=> and understand the argument for a distinct notion of a VP. But yeah it certainly feels odd because of the way VPs are used.

I do not intend this to be a protocol. If there is a distinct notion of a VP, I propose there should be an equal notion of a VR. It should be as close to a VP as possible (metadata, the request, a proof).


  *   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?

Presentation Exchange is inherently agnostic to any transport/wrapper. This means a Presentation Definition is always wrapped inside something – OIDC, a DIDComm message, or … a Verifiable Request. A Presentation Definition is not an instance of a request, just a template from which instances of requests (from Verifiers to Holders) can be created.

On the flip side, a Presentation Submission can be wrapped inside any of the aforementioned in addition to a Verifiable Presentation, as exemplified in the specification -- https://identity.foundation/presentation-exchange/#presentation-submissions.


  *   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.

Ideally this would have a similar standing in the specification as Verifiable Presentations do today. If that path begins with a note, that sounds reasonable.

Daniel:


  *   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.

On the surface I agree with you. My stance then is either Verifiable Presentations should be removed from the VC spec, or Verifiable Requests be added. If you disagree, I’d like to know how you view Verifiable Presentations and Requests as asymmetric.


  *   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.")

We are in complete agreement here. Where do you think the best place to handle (2) is? 3, I believe can be handled in Presentation Exchange. I think your naming concern is worth discussing on the next call we have at DIF in the new year.

Gabe

From: Daniel Hardman <daniel.hardman@evernym.com>
Date: Friday, December 18, 2020 at 8:07 PM
To: Liam McCarty <liam@unumid.org>
Cc: Kim Hamilton <kimdhamilton@gmail.com>, Wayne Chang <wyc@fastmail.fm>, Gabe Cohen <gabe.cohen@workday.com>, W3C Credentials CG <public-credentials@w3.org>, Bjorn Hamel <bjorn.hamel@workday.com>, Keith Kowal <keith.kowal@workday.com>, Kamal Thandapani <kamal.thandapani@workday.com>
Subject: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_decentralized-2Didentity_presentation-2Dexchange_issues_166&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=87gQwT6l_VID00SpzHYLycuYkpIvkxx7xpORXPMt9lQ&e=>.


On Fri, Dec 18, 2020 at 7:25 PM Liam McCarty <liam@unumid.org<mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__didproject.azurewebsites.net_docs_verify-2Dcredential-2Din-2Dweb..html&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=_32O8fNzOyjnBFgQ9OVCAZwak26vhOtPsIUGga7VsfE&e=> endpoint and Evernym’s API docs have endpoints like PresentProofRequest<https://urldefense.proofpoint.com/v2/url?u=https-3A__app.swaggerhub.com_apis_evernym_verity-2Drest-2Dapi_1.0-3Futm-5Fmedium-3Demail-26-5Fhsmi-3D96927175-26-5Fhsenc-3Dp2ANqtz-2D9Nd8xV3pG79PJpQ68Tqw6kCjCdDpG5QL3u2IXzrbhwmrIs-5FpkRiZ7-5FGyWdHWzpsMvE4P2Yla9UAV-2DxPK7ksHbmkhsOxw-26utm-5Fcontent-3D96927175-26utm-5Fsource-3Dhs-5Fautomation-23_PresentProofRequest&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=a7wBJQ1nIlOJ1oK5C_AHbXDqhFwkPHayKvmFgruP66k&e=> and RequestCred<https://urldefense.proofpoint.com/v2/url?u=https-3A__app.swaggerhub.com_apis_evernym_verity-2Drest-2Dapi_1.0-3Futm-5Fmedium-3Demail-26-5Fhsmi-3D96927175-26-5Fhsenc-3Dp2ANqtz-2D9Nd8xV3pG79PJpQ68Tqw6kCjCdDpG5QL3u2IXzrbhwmrIs-5FpkRiZ7-5FGyWdHWzpsMvE4P2Yla9UAV-2DxPK7ksHbmkhsOxw-26utm-5Fcontent-3D96927175-26utm-5Fsource-3Dhs-5Fautomation-23_RequestCred&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=zO3-QfLrBtR8LDSX8wABIP77p4yB0Dj7BQ6B8nxg7LA&e=>.


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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.UnumID.org&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=6iqaI5EEACjutZ3VrPGPwtwDIBnzREO7xO3N-g9MBQc&e=>


On Dec 18, 2020, at 7:48 PM, Kim Hamilton <kimdhamilton@gmail.com<mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_vc-2Ddata-2Dmodel_-23lifecycle-2Ddetails&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=KljLoXEecHgPnlek4-t3ZT97PrCN8ulPcndHx4ilXq4&e=>), 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_vc-2Ddata-2Dmodel_-23presentations&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=aGIZIeb-kyrYg2gU4SX6JOcVC1rJ68tJYO8QMxuPgLU&e=> 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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unumid.org_&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=hvRDBONb-utJz5InWKCCMp6VWrbCbEbtuku3BhlMZvE&e=>


On Dec 18, 2020, at 6:23 PM, Wayne Chang <wyc@fastmail.fm<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unumid.org_&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=hvRDBONb-utJz5InWKCCMp6VWrbCbEbtuku3BhlMZvE&e=>

On Dec 18, 2020, at 6:08 PM, Gabe Cohen <gabe.cohen@workday.com<mailto:gabe.cohen@workday.com>> wrote:

Hi CCG folks,

We at Workday are working on wrapping Presentation Exchange<https://urldefense.proofpoint.com/v2/url?u=https-3A__identity.foundation_presentation-2Dexchange_&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=i_IkF1-lfvP_gXvRfi1y8LLP23HAIayCKx_H0xGx1sw&e=>  requests and notice there is a gap in the VC-Data-Model. There is a section on Verifiable Presentations<https://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_vc-2Ddata-2Dmodel_-23presentations&d=DwMFaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=puHIdUePXg5QXj1c0J-rZe-FK6CjOFQ3r-gukh5Ctx8&s=lYjeeEVkv2v7ldWhrjkVNJIdu-gG34WCJtbiDoOawYM&e=>, 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