Re: Verifiable Requests?

I have trouble following this issue but I do have some experience with
requests vs. presentations (note the lower-case r and p) that might help
define their relationship to protocols.

A request has three orthogonal components:
- Requesting Party (RQ) identity claims
- (Scope of) resources or capabilities requested
- Purpose of the request
These three components are orthogonal because they are specified at
different times by different actors. The RQ claims have nothing to do with
the resources or the purpose. The purpose is another assertion by the RQ
but it is logically different and bound at a later time than the RQ
identity claims.

A presentation is more like the (Scope of) resources or capabilities. It
has been stripped of the other two components and maybe reduced in scope as
well.

From this perspective, both the request and the presentation can be
considered pure data models. Any relationship between them brings us into
protocol territory.

-Adrian



On Mon, Dec 21, 2020 at 4:45 PM Gabe Cohen <gabe.cohen@workday.com> wrote:

> I need some help understanding why Verifiable Presentations are not a
> protocol, and belong in the spec, and why Verifiable Requests are a
> protocol and do belong in the spec.
>
> To the point about DIF Presentation Exchange being one..not exactly. We
> intentionally did not define how it should be wrapped and signed. It can be
> packed into a JWT or other verifiable bodies.
>
> I could put a LD proof and some metadata around a Presentation Definition
> and call it a verifiable request, just like putting a proof and some
> metadata around credentials can be called a verifiable presentation.
>
> I’d still like to hear another viable place for the idea as I imagine a
> number of us will attempt to solve the same problem similarly, if there’s
> consensus the VC Data Model isn’t the right place.
>
> Gabe
>
> ------------------------------
> *From:* Manu Sporny <msporny@digitalbazaar.com>
> *Sent:* Monday, December 21, 2020 12:44:34 PM
> *To:* public-credentials@w3.org <public-credentials@w3.org>
> *Subject:* Re: Verifiable Requests?
>
> On 12/19/20 5:01 PM, Daniel Hardman wrote:
> > What I'm saying is that "Verifiable" Requests are not and need not be
> > a thing, because usually the burden of proof on the request doesn't
> > justify the "verifiable" label.
>
> As I read through this thread, I find myself nodding in agreement on a
> variety of the things that Daniel has said. The point above highlights
> why the Verifiable Credentials spec is the way it is (Gabe asked why the
> asymmetry, and Daniel hits the nail on the head above).
>
> For those in the discussion that are new, I'm the lead Editor for the
> W3C Verifiable Credentials specification -- and remember why we decided
> to NOT specify a Verifiable Request in the specification. It wasn't an
> oversight, it was very much by design.
>
> Once you start talking about request/response, you're talking about a
> protocol... and we wanted to stay very far away from specifying a
> protocol in the VC work because that would have taken us out of the data
> model aspects of VCs and put us squarely into protocol, which is a layer
> up from the data model. The VC specification does not, and should not
> specify protocol... ever. If it does so, it's an architectural layering
> violation. That is not to say that the VC layer can't have some things
> that are useful to protocols (like proofs, nonces, domains, etc... but
> protocol is out of scope for that specification).
>
> ... and it's for a simple reason:
>
> There may be many different protocols for requesting a VC. Some of the
> protocols are very simple, like the Query By Example mechanism that many
> companies used to achieve multi-way interop last spring via CHAPI.
> Others are more complex, like the DIF Presentation Request
> specification. The right answer depends on your use case. Yes, we don't
> want lots of choices for request protocols, but we are probably not
> going to have just one for at least the next 5 or so years. For this
> reason, the Credential Handler API was designed to run a variety of
> request/response protocols over the "dumb pipe" it sets up. Just like
> you can run Web Sockets, WebRTC, XMPP, or HTTP/3 over TCP/IP -- it's
> important to realize that there will likely not be one protocol for
> requesting VCs/VPs, but many.
>
> Some of those protocols will require the request to be digitally signed
> and contain human-readable explanations of the information being
> requested... other protocols won't require any of that.
>
> I urge folks to internalize that before rushing ahead and thinking that
> there is one answer to the "How do we request Verifiable
> Credentials/Presentations?" question.
>
> -- manu
>
> --
> Manu Sporny -
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_manusporny_&d=DwICaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=Gx2I-2NoiM2L6lYXe1AH00PHuqOmpYJw2gMhHDxh0gM&s=ANWM-pqCm24qli4_ANCFJRgAAL_AdOIejFrB81L3jWA&e=
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_veres-2Done-2Dlaunches&d=DwICaQ&c=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc&r=8q0wrOfH-XtkquJe3zZvbZIZ4Fdjh_ScTjE6H3xw59k&m=Gx2I-2NoiM2L6lYXe1AH00PHuqOmpYJw2gMhHDxh0gM&s=WPxNz5ThfJT4GkhFLW8pfB47dslJMWenQQFQ3Hg_Bh4&e=
>
>
>