Re: Verifiable Requests?

This is an interesting discussion and Gabe'a summary is very helpful.

I tend to agree with making VCs separate from VPs and VRs. If the goal is
to issue a VC once and to VP it many times, then protocol issues will
inevitably creep in. After all, there will be more VPs than VRs and more
VRs than VCs. Also, there are competing privacy interests for both parties
at each intersection and these will require a practical accountability
model to handle.

My suggestion to solving this riddle is to keep VCs and DIDs as simple data
models as possible - VCs separate from VR and VP - DIDs with only a minimum
of essential service endpoints - and then focus on _the roles_ in the GNAP
Grant Negotiationand Authorization Protocol next because GNAP understands
'requests' in a clearer and more generative way than other protocols I've
worked on.

Adrian



On Sat, Dec 19, 2020 at 2:05 AM Gabe Cohen <gabe.cohen@workday.com> wrote:

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