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

Hi all,

Just adding my $0.02 NZD into the mix 🙂

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

To the contrary I think its completely counter-productive to view "social login" as the only application upon which OpenID Connects suitability as a protocol for self-sovereign identity should be evaluated. Furthermore attempting to
lay all the blame around how the social login market has played out on top of it as a protocol also means we loose focus on what factors a technical protocol can actually be responsible for. OpenID and the underlying protocol of OAuth2 is used in so many more ways than just "social login" each of which illustrates why the current landscape around "social login" is not just an OpenID problem, but a market forces issue, one that I agree can be further influenced through new components in the ecosystem, but does not require us to throw everything out to accomplish.

> ... which is why solving this problem is mandatory:

Agree we need to solve this problem, but I've never seen any evidence to suggest that OpenID needs to be thrown out to do so, instead just remarks that amount to "the current state of social login on the web is bad so we should purge ourselves of anything to do with that landscape".

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

I for one believe many in the OpenID community have learnt lessons that this community hasn't yet and therefore welcome the experience and perspective.

> 1. Eliminate registration -- if you require wallet
   registration, you enable centralization.

Having already spoken about this topic on another thread, I'm going to take this particular issue to be about the fact that in order for a wallet to request issuance from a provider in OIDC4VCI, they must first register as a client with the provider? If so lets un-pack because I think this comes from one of two possible perspectives:

1. Either you are advocating for an exchange protocol where the wallet provider remains entirely anonymous to the provider/issuer in a credential issuance exchange.
2. OR you are advocating for an exchange protocol where the wallet provider has to fully re-identify/re-introduce itself to a provider every time it interacts.

OAuth2 which is where the concept of a client originates has this role in the protocol for very good reason. That is, the party requesting authorization to something (the wallet provider in the case of credential issuance) should in some sense be identifiable to the provider. Designing a protocol where this party gets to remain totally anonymous becomes incredibly difficult from numerous perspectives, one for instance is the provider being able to get appropriate End-User consent. For example without the concept of the client in OAuth2, many consent screens we come across in login transactions would change to

"Hey End-User do you want to allow access to ...errr ...hmmm well actually we have no idea who is requesting it, how about you grant access anyway?"

When it comes to registration, the main reason this exists is to make identifying this party an efficient process. For instance, if instead we designed a protocol where the wallet provider needs to re-introduce itself to the provider every time, it just means large amounts of the same information will be passed between the two parties (Wallet provider to issuer) on every interaction, which is in-efficient and I really don't see how removing it "enables centralization".

> 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 needs to be clarified, what I think we are trying to solve for here is changing the interaction model between the three parties involved (Relying party, End-User, Provider). Currently in "social login" as we see it on the web today, the relying party has the ultimate say around which providers they choose to support because there is no efficient way for them to get input from the End-User. This in turn causes relying parties to pick the smallest number of providers (to keep the UX as simple as possible) that results in usable login options for their user-base. A mediation layer like an account chooser or wallet chooser where the End-User can influence this list of options that gets rendered during login would change this for the better, however it does not require you to throw out OpenID to accomplish it.

> 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 have no idea how any of the current OIDC specs is having or can have any more control over this then any other protocol options being discussed.


Thanks,

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>



Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

[Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>

[Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>

[Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

________________________________
From: David Waite <dwaite@pingidentity.com>
Sent: 19 March 2022 08:41
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: public-credentials@w3.org <public-credentials@w3.org>
Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

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.