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

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

I'll add a few clarifying points under the assumption that not everyone on
the list is intimately familiar with all aspects of OpenID Connect.

OpenID Connect was designed with features to allow people to bring their
own identities, with either self-selected/self-hosted providers or via a
locally run native app.

The user experience realities as well as market forces are what caused
these features to be largely unsupported.

The death of the prior version of the specification (OpenID 2) has several
articles out there I'm sure, but the top reasons that user-centric identity
failed were:
- lack of a higher level system providing state and integration to automate
the selection of an appropriate authentication process (including but not
limited to the NASCAR effect)
- the prior meant that each relying party needed to take a responsibility
for user education, in an environment where dropoff/abandonment is often a
critical metric
- lack of trust in the integrity and of the overall protocol correctness of
a user-selected provider
- desire to outsource more than a credential challenge - such as verifiable
attributes, abuse prevention and account recovery

OpenID Connect added the ability to run your own provider as a native app,
rather than hosted infrastructure. It also added the ability to aggregate
claimed attributes from other sources, so such a local agent could share
claims acquired from other parties at the end-user's leisure.

The goal of the current OpenID Connect efforts in this space (SIOPv2,
OpenID4VC, OpenID4VCI) are to adapt this existing system with changes and
new protocol additions toward supporting technologies created by the CCG -
allowing use of DIDs as subject identifiers as an option instead of public
keys under SIOP, and allowing verifiable presentations to be used in
addition to OpenID's own claim formats.

These efforts are consistent in that they are trying to increase the value
of independent providers by adding the ability to mediate access to
verifiable or anchored sources.

The hope here is that the initial adoption of self issuing OpenID
providers, and acceptance of user providers in general, failed to get
traction because it could only issue self-asserted claims information and
unanchored identity. The ability to pull externally issued credentials and
reference DIDs means that relying parties don't just also become verifiers,
but get more value from the underlying system. Indeed, my hope is they gain
more value than they have gotten so far from centralized providers.

Whether that goes to a a native app or a web-based wallet, and whether that
wallet is created and maintained by a small startup, non-profit, tech
conglomerate or the underlying platform is really going to be determined by
the market. I don't see this as being different from other protocol
proposals.

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

I assume your goal is not about logins, but about having such companies
involved in certain ways, most likely visibility into interactions.
However, all four of those companies mentioned are platform vendors, which
means at a certain point you are talking about regulatory protections and
not technology.

>
> I am "deathly afraid" of the work, because people are rushing into it
> without
> thinking deeply about the consequences. So, "Nope!":
>

If you wish to elaborate on a more technical concern, feel free to bring it
up. This seems a more emotional argument based on the parties who have
gotten the most benefit from the existing OpenID Connect deployments.

I refuse to just go with the herd and gleefully re-cement centralization in
> this new generation of identity technologies.



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

As mentioned above, OpenID Connect has never mandated centralization - that
has been driven by market forces. This is similar to how IPv4 and HTTP
weren't designed for ~40%
<https://truthonthemarket.com/2019/09/27/debunking-elizabeth-warrens-claim-that-more-than-70-of-all-internet-traffic-goes-through-google-or-facebook/>
of all internet traffic by volume ultimately being interactions with
services by five companies.

The lessons to learn are what is limiting the desired reality. For
instance, I have focused on ways to optimize the user (no software)
onboarding experience and ways we might eliminate the need for NASCAR-style
lists of providers (be them traditional hosted IDPs or vendor wallets).

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

Back to the initiating email chain topic, this is likely why there were
objections to the roadmap not being represented as e.g. CCGs roadmap for
standardization under W3C, but instead implying representation of some
broader effort.

The lack of cross-community communication and duplication of efforts will
carry the tribalism forward into deployment, which we have already seen
e.g. in the variety of COVID credentials.


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

SIOP v2 can be invoked three ways:
1. Local Invocation via URL schemes or platform-registered HTTPS URL (e.g.
universal links, app links)
2. Cross-device Invocation via QR code holding above initiation URL
3. Cross-device invocation via wallet QR code reader

The first two approaches gain power from, and limitations from, the
underlying platform support for apps registering URL schemes or app links.

The third approach is pretty common and does not use platform invocation.

If you were speaking of 'registration' in the sense of say a CHAPI style
registration of a credential handler with a centrally hosted party or web
extension, the SIOP approaches currently do not have such a mechanism.

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

SIOPv2 defines a base 'openid' URL scheme which will send you to a wallet,
but as a platform dispatch cannot filter based on wallet capabilities.

A group may declare their own URL scheme or app link based approach which
is expected to have more stringent requirements for capabilities in order
to improve the chance of user success. A single wallet can support multiple
such groups.

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

I'm not sure what this implies, or what you have seen.

I would say for most communities, the issuance specifications are least
mature. I might guess you saw a wallet which filled in the gap here by
providing the user instructions to get credentials that the wallet itself
kew how to acquire?

OpenID4VCI is meant to be a generalized issuance protocol, e.g. people
authorizing an issuer to release a credential to a wallet. Initiation is
via a URL (link or QR code presented e.g. by the issuer) which
would describe to a wallet how to start that process.

Rather than seeing solutions proposed to the problems above, the OpenID
> specifications seem to be doubling down on enabling the three items above.
>

See above.

Out of CHAPI, DIDCommv2, and OpenID... OpenID is the most centralizing,
> worst
> solution for Verifiable Credential Exchange on the table today.
>

See above.

That is not to say it can't be fixed, but I have yet to see a proposal that
> addresses all three items above.
>

I can't speak to the marketplace concept other than my above assumptions,
so I can't point to relevant specifications.

-DW

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._