- From: Oliver Terbu <o.terbu@gmail.com>
- Date: Sun, 20 Mar 2022 14:52:59 +0100
- To: public-credentials@w3.org
- Message-ID: <CAJdc_G=vTefgxtD0_BgXy_n5VuE48o8fdp1QEreY57M=x0BFNA@mail.gmail.com>
My apologies, in my previous diagram, the arrows between the web application and the W3C CCG Credential Handler need to be reversed obviously. [image: image.png] Thanks, Oliver On Sun, 20 Mar 2022 at 14:37, Oliver Terbu <o.terbu@gmail.com> wrote: > Writing this from my personal email account since I want to comment on a > few things. > Also want to point out that any opinion shared here is my personal > opinion, potentially > controversial. > > > What would be more beneficial is for someone to produce a pros/cons > matrix > > like we did for "Protecting VCs using pure JSON JWTs vs. VC-JWTs vs. > Linked > > Data Proofs": > > https://w3c.github.io/vc-imp-guide/#benefits-of-jwts > > https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs > > I don't think having a comparison table like this is useful or can be done > in a meaningful way. > Since I believe that any of the credentials exchange protocols can be > implemented in > a more or less centralized way. This includes OIDC, CHAPI and the Aries > protocols. > IMO, the degree of centralization is a design decision and none of the > protocols can exclude > this design on a pure technical level. Those design decisions are driven > by business, regulatory, > technical and UX requirements. > > Why it is so hard to come up with a comparison table that puts those > protocols on a > spectrum shows the following diagrams (based on CHAPI, using different > approaches for > managing access to data and keys). There are certainly many other ways > this can be done. > Note, that centralization is not inherent to CHAPI, in that case it was > merely a design decision. > Similar diagrams can be created for system architectures that use OIDC or > Aries. > > [image: image.png] > > I also want to point out that SIOPv2 does not require a centralized > component, in the same way > as CHAPI and Aries don't require centralized components. If we want to > talk about "centralization > dangers", then we should not look at one specific protocol. > > I also want to comment on the points below. > > > 1. Eliminate registration -- if you require wallet > > registration, you enable centralization. > > SIOPv2 does not require wallet registration as other people have also > pointed out. > > > 2. Eliminate NASCAR screens; don't allow verifiers to > > pick/choose which wallets they accept. If you allow > > either of these things to happen, you enable > > centralization. > > This is a complicated topic. IMO, solving NASCAR always requires support > from > platform/OS and/or browser vendors if you don't want to provide unfamiliar > UX for end > users. > One of the problems is the platform-specific handling of custom URL > schemes. On iOS > this simply doesn't work well if multiple apps registered the same URL > scheme handler. > There is one approach that seems promising which includes handling > mime-types for > presentation requests on mobile platforms but I don't know if anyone has > implemented it > in a production environment. The idea is to assign a mime-type for > presentation requests. > IMO, it is also not great for end users if they wipe their browser cache > and none of the > Credential Handler is installed. AFAIK, this would then require > re-installation of the > Credential Handler which is hard to explain to end users. Because of that, > CHAPI seems > to be also an incomplete solution to NASCAR (similar to openid:// on iOS). > If browsers > would allow permanent storage, this would be certainly solved but again it > requires their > support. This is not required by the SIOPv2 spec, but one can implement > SIOPv2 in a > similar way since the discovery process can have any form. IMO, there is > room for > convergence between CHAPI and SIOPv2. SIOPv2 doesn't necessarily preclude > a solution > that is similar to CHAPI. > > > 3. Eliminate the concept of "App Store"-like in-wallet > > "Marketplaces". If you do this, you put issuers at a > > natural disadvantage -- pay to play to get listed > > in a wallet's "Marketplace". > > If some of the wallets decide to do that, then it is their design > decision. There is no requirement > in any of the OIDC4SSI specs. However, any wallet can choose to implement > such features > but there is nothing in CHAPI, Aries that would prevent anyone from doing > that in the same way > you may have observed. > > If you read this far, then the main point I want to get across is that we > should avoid denouncing > certain protocols as bad or evil. If a technology is used in a good or bad > way depends on design decisions > made by technology providers. > > Thanks, > Oliver > > >> ---------- Forwarded message --------- >> From: Manu Sporny <msporny@digitalbazaar.com> >> Date: Fri, Mar 18, 2022 at 5:49 PM >> Subject: Centralization dangers of applying OpenID Connect to wallets >> protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT]) >> To: <public-credentials@w3.org> >> >> >> I'm taking all of my hats off and saying the rest as a "concerned citizen >> and >> computer scientist". Take it as personal commentary, for whatever that is >> worth. >> >> I expect much of this to be controversial... and result in an unavoidable >> permathread. :) >> >> TL;DR: It is hopelessly naive to think that OpenID Connect, THE protocol >> that >> centralized social login to 3-4 major tech companies, only requires "small >> changes" for self-sovereign identity and is a "doorway" we should >> gleefully >> step through. >> >> On 3/17/22 5:45 PM, Kaliya Identity Woman wrote: >> > Yes - and I agree with the note following this one on the thread that >> they >> > are meeting different needs use-cases. >> >> It's all a matter of perspective, isn't it? :) >> >> When you get down into the details, sure you can argue that some >> protocols are >> addressing different needs/use-cases, but it is also undeniable that every >> single one of the protocols can move a Verifiable Credential from point A >> to >> point B. In that way, they're directly competitive with one another. >> That's >> not an interesting debate, though; it's at the wrong level -- too meta. >> >> What would be more beneficial is for someone to produce a pros/cons matrix >> like we did for "Protecting VCs using pure JSON JWTs vs. VC-JWTs vs. >> Linked >> Data Proofs": >> >> https://w3c.github.io/vc-imp-guide/#benefits-of-jwts >> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs >> >> Until we get to that level of detail, I expect we'll not make much >> progress on >> the wallet protocols topic. >> >> > The fact is that there is a huge opportunity to really leverage the >> "OIDC" >> > "doorways" that exist all over the web (a protocol that is literally >> used >> > a billion times a day...you know some real adoption) to exchange VCs - >> with >> > some small changes. >> > >> > AND people in this group seem to be "deathly afraid" of that work >> because >> > it isn't home grown here alone in isolation and focused on web only. >> >> I... just... don't even know where to start. I disagree with every >> concept in >> the previous paragraph. :) >> >> I can't speak for anyone else in this group, so I'll just speak for >> myself: >> >> It is hopelessly naive to think that OpenID Connect, THE protocol that >> centralized social login to 3-4 major tech companies, only requires "small >> changes" for self-sovereign identity and is a "doorway" we should >> gleefully >> step through. >> >> Login with Google/Facebook/Apple/Microsoft, those "billions of times a >> day" >> usages... are all coerced logins. We have no choice but to use the big >> tech >> vendors. That is not a world I want to contribute to. >> >> We are not "focused on web only" here... though it is an effective >> "gotcha!" >> talking point that seems to not be questioned when uttered ("I mean... the >> word "WEB" is in World Wide Web Consortium! What else could they be up to >> over >> there!?"). The phrase is disingenuous, I really wish those uttering it >> would >> stop... but you can't blame them, it's an effective way to get people who >> don't know any better nodding in agreement with whatever "non-Web" thing >> you're going to say next. >> >> I am "deathly afraid" of the work, because people are rushing into it >> without >> thinking deeply about the consequences. So, "Nope!": >> >> I refuse to just go with the herd and gleefully re-cement centralization >> in >> this new generation of identity technologies. >> >> I refuse to trust that things will be different this time because the same >> people that created OpenID Connect have learned their lessons and are >> doing >> things differently now. >> >> ... and I refuse to accept your mischaracterization of this community, the >> good faith efforts that they've put forward to coordinate where they can, >> or >> why some of us remain sceptical of some of the other wallet protocol >> efforts >> going on right now. >> >> It is possible for all of us, across all communities, to act in good >> faith and >> still disagree on the path forward. >> >> I certainly don't think for a second that the vast majority of people >> involved >> in OpenID, DIF, CCG, IIW, or RWoT are acting in bad faith. Misguided, >> possibly >> (including myself!), but not this "Not Invented Here Tribalism" narrative >> that >> seems to be so popular. I see a bunch of people, across each "silo", doing >> their best to solve hard problems given all of the pressures of their >> work and >> home life. Full stop. >> >> Going back to OpenID being applied to Verifiable Credential Exchange. >> There >> are three fatal flaws that need to be overcome for it to be a good idea: >> >> 1. Eliminate registration -- if you require wallet >> registration, you enable centralization. >> >> 2. Eliminate NASCAR screens; don't allow verifiers to >> pick/choose which wallets they accept. If you allow >> either of these things to happen, you enable >> centralization. >> >> 3. Eliminate the concept of "App Store"-like in-wallet >> "Marketplaces". If you do this, you put issuers at a >> natural disadvantage -- pay to play to get listed >> in a wallet's "Marketplace". >> >> Rather than seeing solutions proposed to the problems above, the OpenID >> specifications seem to be doubling down on enabling the three items above. >> >> Out of CHAPI, DIDCommv2, and OpenID... OpenID is the most centralizing, >> worst >> solution for Verifiable Credential Exchange on the table today. >> >> That is not to say it can't be fixed, but I have yet to see a proposal >> that >> addresses all three items above. >> >> > There is a lot of "othering" of work that isn't CCG. Because that work >> is >> > less "pure". >> >> No, there are concerns related to the technical underpinnings of OpenID >> that >> lead to centralization that have yet to be addressed by the current >> proposals. >> >> The only Othering I'm seeing going on here is what you're doing. Casting >> some >> vague subset of the CCG as this irrational, web-only, not invented here, >> tribal silo and going after community volunteers that are not doing what >> you >> want or meeting on your schedule. >> >> I've known you for many years, Kaliya -- you're better than this and are >> usually a bridge builder and tireless advocate for open lines of >> communication. I know you're frustrated, we all are, but I don't think >> the way >> in which you've chosen to engage is going to result in what you want. >> >> Again, just my $0.02 as a community member. >> >> -- 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/ >> >> >>
Attachments
- image/png attachment: image.png
- image/png attachment: 02-image.png
Received on Tuesday, 22 March 2022 08:27:01 UTC