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

Permalink to diagram file here:
https://github.com/awoie/chapi-notes/blob/f02c2442bd68f1fa8cdb3076d910596b733e9bf3/chapi-modes.jpg

On Tue, Mar 22, 2022 at 11:14 AM Oliver Terbu <o.terbu@gmail.com> wrote:

> BTW, something odd happened to the mailing list ordering, so sending this
> again. This was also flagged as containing inappropriate content by the
> mailing list operator which I don't feel that it does.
>
> 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.
>
> I think my previous email didn’t go through, so please apologize if this
> may have been received twice (didn’t find my previous email in the archive,
> so sending again).
>
> > 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, UX and
> other requirements. BTW, I’m not advocating for centralized models.
>
> 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 I don't want to
> suggest centralization is 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 protocols.
>
> Diagram here:
> https://raw.githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg
> <https://raw..githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg>
>
> 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.
>
> IMO, solving NASCAR in a satisfying manner always requires support from
> platform/OS and/or browser vendors if you don't want to provide unfamiliar
> or broken UX for end users. Some of the problems are platform-specific
> handling of custom URL schemes and short-lived browser storage.
> Technically, SIOPv2 can solve NASCAR by using openid:// but we know that
> won’t work well on iOS. Other SIOPv2 discovery options exist and the spec
> allows room for innovation. Even a convergence with the CHAPI model may be
> possible, e.g., get SIOPv2 OPs config via CHAPI.
>
> There might be promising other approaches such as 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.
>
> I believe CHAPI can be great but this is why I believe CHAPI doesn’t solve
> NASCAR either yet (at least not in a satisfying manner):
>
> 1. (ASSUMPTION) CHAPI currently relies on a mediator which is a hosted
> polyfill under authn.io. This polyfill is permissive (in terms of
> wallets) but governed by a private company. I do believe that the current
> implementation is fine regarding privacy, so no tracking and will stay
> permissive. But websites could decide to host their own less permissive
> polyfill which can limit mediation to certain credential handlers (i.e.
> wallets). This is possible as long as the polyfill doesn’t get implemented
> as a native browser feature which requires browser vendors support.  If it
> is implemented by browser vendors, wouldn't this mean they are in control
> again and can decide who they would let in? Correct me if I’m wrong here.
>
> 2. Registered credential handlers live in the browser storage and if that
> gets wiped, users need to re-register their credential handlers which
> involves going back to wallet vendors’ web pages.
>
> I’d like to understand how and when the CHAPI community wants to solve 1.
> and 2. Then, CHAPI will definitely be a good option to solve NASCAR.
>
> > 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 and stop using
> polemic arguments. If a technology is used in a good or bad way depends on
> design decisions made by technology providers. For example, governments can
> act as a forcing function to provide requirements in the form of
> regulations that are more permissive (my hope for eIDAS 2..0).
>
> 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/
>>>>
>>>>
>>>>