W3C home > Mailing lists > Public > public-credentials@w3.org > March 2022

Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 27 Mar 2022 16:28:52 -0400
To: public-credentials@w3.org
Message-ID: <e832802b-d172-e84a-2c8b-5a3aba226e4e@digitalbazaar.com>
On 3/24/22 5:13 AM, Daniel Hardman wrote:
> So that's my problem with the technical characteristics of OIDC: the nature
> of the technical choices enshrines incentives in ways I don't like. This is
> true whether "Big Tech" is the champion of it or it's picked up by lots of
> other implementers, and it's true no matter how many wallets implement it,
> or who builds those wallets. What I want is a way to prove with credentials
> that is fundamentally, profoundly peer-to-peer. I absolutely want it to
> work on the web, but I don't want it to be tied to the web or to browsers;
> it should also work over NFC (my current work on digital cash requires
> this), and over BLE, and over LoRa, message queues, etc. And I want this
> way to be the first one standardized, so it doesn't get undercut by a
> standard that solves only the easy and lucrative-for-enterprises half of
> the use cases.
> 
> I made parts of this argument to the "VC HTTP API" group (now renamed VC
> API, but still overly HTTP-centric, IMO) a year ago, but my argument mostly
> fell flat.

You argument didn't fall flat... at least, I heard you loud and clear and
accepted large parts of the argument you were making. I mean, that's not a new
argument from you and I agreed with you the first time you uttered it years ago.

My hope is that many of us acknowledge that these "exchanges" can't just move
over HTTP (or presume HTTP is available).

CHAPI is not HTTP (even though people erroneously mistake it for HTTP -- which
you can't blame them, how browsers work is a mystery to most)... CHAPI uses a
variety of non-HTTP protocols (postMessage and Web Share to be specific). We
have moved VPR and DIDCommv2 over CHAPI.

We also move VPR over VC API... VPR has to be able to do peer-to-peer or we've
failed, which I think is the same mode that you operate in wrt. DIDCommv2.

You probably haven't looked at the Verifiable Presentation Request work in a
while, but we are attempting to support a "protocol upgrade" feature there,
which attempts to support VC API, OIDC, and DIDCommv2.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/
Received on Sunday, 27 March 2022 20:29:08 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 27 March 2022 20:29:09 UTC