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

On 3/20/22 4:24 PM, Oliver Terbu wrote:
> I don't think having a comparison table like this is useful or can be done
>  in a meaningful way.

So far, the comparison table (snapshot attached) is being edited by multiple
people in the community (with conflicting viewpoints) and seems to be
generating useful and productive dialogue:

https://docs.google.com/spreadsheets/d/1Gp5V5lTO3pyQ94hS-UR_WTWg0DkBMv0ubXYaKjIPqnU/edit#gid=0

> I believe that any of the credentials exchange protocols can be implemented
> in a more or less centralized way.

That's not a point of contention... the point of contention is that some
protocols, by their very nature, are more centralized/decentralized than
others. For example, OIDC requires client registration, VPR + VC-API and WACI
+ DIDCommv2 do not. It's true that you can do dynamic client registration and
allow anything (which is good and fine), but some on here are arguing that we
need to strongly identify the wallet vendor as well (which creates
centralization pressures in the market). That is not to say that other
centralization pressures don't exist, but we need to get rid of as many of
them as we can, for as many use cases as we can, if we are to have a
competitive open wallet ecosystem in the end.

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

I don't think anyone is arguing that we can avoid centralization for wallet
invocation and presentation exchange on a PURELY technical basis. What is
being argued is that certain protocols nudge the market towards centralization
more than other protocols, and we have very strong evidence that OpenID has
historically strongly nudged the market towards centralization by not
providing an IdP mediation layer like CHAPI does. David Waite listed a number
of reasons this happened, though, some of these reasons no longer hold because
new technologies exist today that didn't exist a decade ago (or even five
years ago)... yet, the OpenID "industry" has not fielded something like
CHAPI... why is that?

> Diagram here: 
> https://raw.githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg

All those diagrams do is put the word "Centralized" on things that have open
standard interfaces on them. This whole ecosystem we're building here allows for:

1. Multiple Agents, per SOME of the open protocols.

2. Multiple EDV providers, per the open EDV protocol.

3. Multiple WebKMS providers, per the open (and horribly
   undocumented) WebKMS protocol.

4. Multiple Credential Handler (aka wallet) providers, per
   the open specification.

It is true that authn.io (the website domain, which serves the polyfill until
it's implemented natively in browsers) is centralized. We do need to fix that
via an open governance model (more on that below). It is also true that there
are SOME really terrible design patterns we should avoid in ALL protocols to
avoid some common centralization pitfalls that OpenID has kept falling into
over the past decade.

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

Yes, perhaps that's the right thing to focus on now that we have established
an example of a centralization danger in one of the protocols. Namely,
requiring OpenID client registration and binding that to a "wallet vendor
identity". ANY protocol that requires client registration and the
identification or fingerprinting of a "wallet vendor identity" is a
centralization danger. That applies to OpenID*, CHAPI, VPR + VC-API, WACI +
DIDCommv2, etc.

>> 1. Eliminate registration -- if you require wallet registration, you 
>> enable centralization.
> 
> SIOPv2 does not require wallet registration as other people have also 
> pointed out.

While it doesn't require it, it is being suggested (by MATTR) that certain use
cases require it and the strong identification of the wallet provider... which
leads to centralization dangers.

Alternatively, a guiding principle should be to NEVER do wallet provider
detection, but rather, feature detection (as browsers do). We don't want RPs
hard coding themselves to wallet providers.

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

No, false. Counter-point: CHAPI

Again, that's not to say that CHAPI doesn't have some issues in corner case
browsers (such as Brave... <1% market share) or Safari on iOS ("Are you sure
you want to allow authn.io to track you?") or 3rd party storage -- HOWEVER,
there are fixes to those that we have proposed and are awaiting community
feedback before implementing them.

One of the nice things about the CHAPI polyfill is that we can respond very
quickly to UX challenges and browser changes... as we have been doing with
CHAPI for the past 10 years.

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

All of the options that have been put forward so far have been shot down due
to UX challenges. We can't call things "solutions" when they don't actually
address the point of contention. I expect we'll keep going around in circles
about this for another couple of weeks, but it'll be a useful exercise because
/eventually/, most of us will understand the points that everyone else is
making (or understand that our mental model was flawed).

> Even a convergence with the CHAPI model may be possible, e.g., get SIOPv2 
> OPs config via CHAPI.

Now, there's a really interesting idea... perhaps CHAPI and SIOPv2 are solving
different problems! (They are, the CHAPI folks have claimed this for years --
and that OIDC could use CHAPI to solve the mediation problem it has... but I'm
not sure all of the OIDC/SIOPv2 people are aware of that fact yet since the
statements that some are making seem to indicate a misunderstanding of 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.

That's how CHAPI Native works... and yes, we've implemented it and yes we're
supporting it in production (unless something better comes along).

I will note that Chrome allow-lists only certain types of media types (it's
very limited), but one of those media types works well for CHAPI -- text/html
with an embedded VPR media type.

> 1. (ASSUMPTION) CHAPI currently relies on a mediator which is a hosted 
> polyfill under authn.io <http://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. Correct me if I’m wrong here.

The operation and governance of CHAPI (and authn.io) will not be private-run
when we go to production (later this year). We will be handing the site over
to a dedicated global operations team, and code review/release will be gated
among the companies using CHAPI in production.

Yes, someone can always build /their/ version of CHAPI, but we will have a
production software license that provides a license to anyone to freely use
and distribute CHAPI as long as they promise to only use it on authn.io.

There is legal and community pressure that we can assert on anyone that
chooses to try and break the unified ecosystem by running CHAPI on a
non-authn.io site in production. We do know of multiple people that run it in
their dev environment, and that's fine. We'd love to hear of alternate ways we
can ensure a unified mediator environment; this is the best one that's
surfaced in the past decade or so.

I believe that mitigates both of your concerns -- do you agree?

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

I think the answer is "this year" -- in fact, we're preparing to deploy CHAPI
into fully supported production as we speak.

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

Yes, that's correct. It is, however, a market centralization pressure we want
to make sure everyone knows about. The way to combat this particular pressure
is to ensure that we have open wallet choice (no NASCAR screens, no RP
hand-picking wallets) and

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

Agree on the use of "evil" (though, I don't recall someone using that word in
this thread? "Polemic" feels a bit hyperbolic, but understand how some of the
arguments could come across as that...

Noting "centralization dangers" and applying that language to certain
protocols, like OpenID and CHAPI and DIDCommv2 needs to be done. We have to be
able to talk about these things and debate them. At present, as the Chairs
have noted, I'm seeing a mostly professional sort of engagement on the topic.
These discussions are needed to educate the broader community, of which there
are over 450+ people now, of the pitfalls and dangers posed by certain
protocol designs.

> If a technology is used in a good or bad way depends on design decisions 
> made by technology providers.

A car without seatbelts leads to different outcomes than a car with seatbelts.
That is a technical solution. You can't always stop people from making
mistakes, but you can put in things to mitigate certain dangers when mistakes
do happen. There are technical design considerations that affect
centralization outcomes -- they are not purely regulatory in nature either.

> 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).

Regulation is one tool that can be used (a very big hammer that's slow to
swing)... better to avoid as many issues if there are some technical
mitigations than to leave everything to regulation. How we go about this might
be a difference in culture... though, I'll note that big tech seems to be
running largely unchecked in Europe as it does in most of the rest of the
world. In the same vein, GDPR has helped immensely in shaping the way the US
is approaching privacy regulation.

The solution is a mixture of technology, culture, and regulation and we should
endeavour to maximize the effect of each of those dimensions.

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