Re: Verifiable Requests?

Thank you Manu, this is super helpful.

For better and worse, I’m a relative newcomer (very much so compared to yourself!). For what it’s worth, let me just note a few things that confuse me as someone not as expert:


1. Request as a noun not a verb:

There are many ways of encoding data about a person/thing, and what’s best depends on the use case. But the point of the VC spec is to provide a standard of certain best practices that apply across all/most use cases (like cryptographic proof of provenance) and a common language to ensure they can all interoperate. Right? 

Couldn’t we say the exact same thing about requests? (Here I mean request as a noun not a verb.) “There are many ways of encoding requests for VCs/VPs, and what’s best depends on the use case. But we’d benefit from a spec that provide a standard of certain best practices (like cryptographic proof of provenance) and a common language to ensure they can all interoperate.” 

The discussions I’ve seen about interoperability have focused on making sure a wallet can store a VC no matter who/what created it. But it seems to me there’s another side of interoperability: making sure a wallet can receive requests for VCs/VPs no matter who/what is asking for them. What use is a common storage place if I can’t widely use what’s stored there?


2. The courtroom analogy:

Daniel, all respect to you, truly, but the analogy of courtroom testimony makes no sense to me. Like Gabe said, I wouldn't give testimony in a back alley if a random person asks me to. I'd do a visual “spot check” to make sure the courtroom and judge are legitimate, just as I’d ask a supposed FBI agent to see their badge. (And how much better I’d feel if I could cryptographically check they’re a real agent, rather than rely on my untrained eye!) 

Even more importantly, courtrooms in most modern societies — certainly the societies that would promote VCs! — are ultimately answerable to me, the voter. Their legitimacy stems from the citizens' acceptance. When the people at large lose faith in the courts, they don’t heed the courts' orders.


3. Phishing, supercharged.

A broader point: Today, it’s true that in almost every case, people do nothing more than a “spot check” to see if someone asking for information is legitimate. That’s already a huge problem: phishing is often listed as the #1 cause of data breaches, identity theft, etc. 

But in a future where I have tons of personal data stored in a digital wallet, phishing is going to be far more of a problem. Today, it’s difficult for me to share lots of data all at once. When it’s way easier to do so, I sure hope I have more than a gist of whether someone asking for the data is legitimate.


Hopefully I’m not just mixing up terms and concepts here. Again, this is a newbie’s perspective! I hope at least on that level it’s helpful.

All the best,

Liam

Liam McCarty
Co-Founder of Unum ID <http://www.unumid.org/>

> On Dec 21, 2020, at 2:44 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> 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://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
> 
>