Re: Verifiable Requests?

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 <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 <http://www.unumid.org/>
> 
>> 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 <http://www.unumid.org/>
>>> 
>>>> 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://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
>