Re: Verifiable Requests?

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