Re: Verifiable Requests?

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=