Re: Verifiable Requests?

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