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

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/
>>
>>
>>