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

Having read (some) of this long thread, I mostly find myself in the 
"OIDC leads to centralization" camp... I agree with what Daniel writes, 
"the nature of the technical choices enshrines incentives".

There are some things in OpenID Connect (including in SIOP v1/v2) that 
are simply by design asymmetrical. Why does one side use a 
client_id+client_secret for authentication, and the other side uses an 
id_token with a "sub" field. Why don't both sides of an interaction use 
the same constructs?

While SIOP v2, OIDC4VP, OIDC4VCI look like very impressive work, and I 
am sure can be very helpful in adopting DIDs+VCs, to me they don't feel 
naturally aligned with decentralized identity principles.

Myself, I was already part of the community when the centralization of 
the original OpenID technology happened. An idealistic protocol for 
"user-centric identity" turned into an important pillar of surveillance 
capitalism. You know how at the IIW conference (the in-person one, not 
virtual) there's an opening circle where everybody introduces themselves 
very briefly, typically saying their name and affiliation? One of the 
OpenID community champions stood there and said "I am (name). OpenID. 
Facebook.". In that moment I felt that something was going very wrong. 
How can you possibly be affiliated with both OpenID and Facebook at the 
same time, I wondered? And well that's how it started.

Today, I find it strange that even now as OIDC SIOP v2 is still very 
new, its presenters are already very quick to point out /"yes, don't 
worry, it works with web wallets too!"/. I wonder, if you use a web 
wallet provided by some third party, then can you really still 
rightfully call the authentication response "self-issued"?

At a recent (in-person) conference, one of the OIDC SIOP v2 leaders 
explained to me that /"the meaning of SSI is evolving!"/. I wonder, 
evolving to what?

The OIDC SIOP v2 spec says the provider /"is within the End-User's local 
control"/. I wonder, how will the OIDC SIOP v2 community interpret 
"local control"?

The EUDI Wallet Architecture and Reference Framework also talks about 
/"the user’s sole control over sensitive cryptographic material"/, but 
at the same time it also says that the wallet can be either local or 
remote. They don't consider that a contradiction. In other words, they 
consider it possible that a remote wallet hosted by a third party is 
under "the user's sole control". This reminds me very strongly of the 
same kind of rhetoric we heard a long time ago when the original OpenID 
became centralized. The centralized OpenID providers also told everyone 
"come create an account at our IdP, we give you full control over your 
identity!".

So I personally believe that the OIDC SIOP v2 work is likely to lead to 
centralization again. The market interest and business incentives for 
that are very strong.

BUT: Maybe the results won't be as bad as before!

If we see a few centralized OIDC SIOP v2 wallets emerging, AND they are 
regulated by some strong EU data protection laws, AND they actually 
enable people to do some useful things with DIDs and VCs in ways that 
improve their lives, then there could also be something positive about 
it. But it will be only fake SSI.

Markus

On 3/24/22 10:13, Daniel Hardman wrote:
> I would like to react to the subconversation between Joe and Tobias 
> (and others, but they've been the most vocal). The nub of the 
> disagreement there seems to me to be about whether we should analyze 
> the suitability of OIDC on the basis of technical protocol 
> characteristics only (Tobias's recommendation), or whether we should 
> consider OIDC from the perspective of history and incentive structures 
> (Joe's perspective). Have I been fair and reasonably accurate so far?
>
> I have a problem with OIDC on both of these dimensions, but in both 
> cases, my problem hasn't been articulated yet on the thread, so I'd 
> like to weigh in.
>
> On the technical side, OIDC enshrines the assumption that verification 
> is something DONE BY institutions, TO people; institutions and people 
> are not peers in OIDC, so authentication can never be reciprocal. It 
> may be theoretically possible for a person to challenge an institution 
> to prove something over OIDC, but in practice, this will never happen. 
> That's because the nature of web redirects, client-server, and 
> request-response virtually guarantees that the party challenging will 
> have a server, and the party proving won't. OIDC is also real-time 
> only; authenticating a week ago is never of interest because OIDC is 
> associated very strongly with synchronous web and (not by requirement, 
> but by practical realities) to assumptions about web sessions and cookies.
>
> David Chadwick said that certs (what an institution would use to 
> authenticate in an OIDC flow) are basically VCs. I agree that they 
> resemble them strongly in that they are signed attestations from an 
> issuer. But they don't resemble them in other ways (what protocols 
> invoke them; what identifiers they use, and how those identifiers are 
> managed; how revocation is managed; how signatures become "approved", 
> whether they can support ZKPs, etc), and it is these very dimensions 
> of difference that has created the phenomenon where certs are only 
> used in one direction on the web today. Those are the same reasons 
> that OIDC will only ever be used in one direction, too.
>
> So: is it a problem that OIDC is one-way only, and that it is 
> real-time only?
>
> In my mind, that depends on the point Joe has been arguing. 
> Undoubtedly, we *can* solve some SSI-style use cases with OIDC. But 
> when we do, it sucks all the air out of the room for other use cases 
> that are at the heart of SSI's value proposition. Alice wants to 
> authenticate Bob (another human). Alice wants to eliminate phishing 
> risks by authenticating a purported org that is doing something other 
> than offfering to let her browse their website (e.g., sending her an 
> SMS, sending her an email, calling her on the phone, asking her for 
> her consent or PII). Alice wants to authenticate an IoT drone that is 
> delivering her groceries. Alice wants to send an email that Bob reads 
> two weeks later, and Bob still wants to know that Alice sent it (not 
> authenticating her now, but authenticating her *then*). Alice wants to 
> digitally sign a mortgage and be authenticated five years in the 
> future, on the basis of her keys today. Etc. All of these use cases 
> have been neglected for years because they don't make the economic 
> engines of enterprise software or the surveillance economy any money.
>
> There's one other technical ramification to OIDC that I also consider 
> profound, that I don't hear anybody talking about, and that is channel 
> lock-in. Today, when you authenticate with OIDC, the authentication is 
> always based on the channel you're using (typically TLS-based HTTP/web 
> sockets). If the channel changes, then you have to re-authenticate. 
> This is why I can log in to amazon.com <http://amazon.com>, but if I 
> try to open a support ticket at support.amazon.com 
> <http://support.amazon.com>, or access my author dashboard at 
> kdp.amazon.com <http://kdp.amazon.com>, or listen to an audiobook from 
> audible (owned by Amazon), I probably have to authenticate all over 
> again. Enterprises play games with cookies and SSL sessions and SSO 
> technologies to fix this, and they are partly successful, but this 
> sort of problem is at the root of XSS attacks and lots of other 
> problems. But even if we can solve the channel lock-in problem for 
> enterprises, OIDC does ABSOLUTELY NOTHING to help with the channel 
> lock-in problem when the verifier isn't an enterprise. If Alice and 
> Bob want to start a chat on Signal, and then continue it on email (or 
> slack, or discord, or SMS), they must reauthenticate each other (and 
> probably, reauthenticate to the new platform), because their security 
> isn't portable. They don't actually "own" the security -- the channel 
> provider does. This one problem by itself is profoundly connected to 
> sovereignty. It locks Alice and Bob into the channel provider's 
> platform, which is unfortunate and unreasonable, given that secure 
> comm tech is cheap and easy to build. Secure comms should be tied to 
> the parties on either end of a pipe -- any pipe, we don't care what 
> kind -- not to the provider of a particular pipe. But OIDC reinforces 
> the view that it's tied to the provider of the channel.
>
> So that's my problem with the technical characteristics of OIDC: the 
> nature of the technical choices enshrines incentives in ways I don't 
> like. This is true whether "Big Tech" is the champion of it or it's 
> picked up by lots of other implementers, and it's true no matter how 
> many wallets implement it, or who builds those wallets. What I want is 
> a way to prove with credentials that is fundamentally, profoundly 
> peer-to-peer. I absolutely want it to work on the web, but I don't 
> want it to be tied to the web or to browsers; it should also work over 
> NFC (my current work on digital cash requires this), and over BLE, and 
> over LoRa, message queues, etc. And I want this way to be the first 
> one standardized, so it doesn't get undercut by a standard that solves 
> only the easy and lucrative-for-enterprises half of the use cases.
>
> I made parts of this argument to the "VC HTTP API" group (now renamed 
> VC API, but still overly HTTP-centric, IMO) a year ago, but my 
> argument mostly fell flat. So I'm not expecting it to win a lot of 
> points here. I'm just trying to go on record that there *are* 
> perspectives that conclude that the purely technical characteristics 
> of OIDC are problematic, quite independent of predictions about wallet 
> lockin. I mostly don't care about wallets, but I still resonate to Joe 
> and Manu's critiques for these other reasons.
>
> Now, turning my attention to the other dimension of my concern, I want 
> to talk about politics and markets for a minute.
>
> As a young engineer, I remember discovering to my chagrin with the 
> difference between SQL and the T-SQL and PL-SQL extensions that I had 
> been using. Both Microsoft and Oracle touted their standards 
> compliance ("get your SQL-89 here!"), but implemented extensions that 
> were only supported in their more specialized environments. I am not 
> impugning the motives of Microsoft or Oracle here; I think the 
> extensions they wrote were built with good intentions, and did a lot 
> of good in the world. Rather, I am pointing out that a "standard" can 
> be misunderstood by people. And I fear that this will happen with OIDC.
>
> We have already seen in this thread the need to distinguish carefully 
> between OpenID and OIDC and OAuth and OAuth2. Next-gen OIDC creates 
> another member of this family. People who are not highly sophisticated 
> about the distinctions will not understand that all of these related 
> standards have different adoption curves, different levels of 
> cross-vendor support, etc. All they will hear is that we have an OIDC 
> standard for VCs, and they will assume that anybody who supports OIDC 
> will support it.
>
> And this is *exactly* what the big players in OIDC want. Of course 
> they do; it's what I would want if I were them, and it's not a 
> dishonorable aspiration, per se. They want to claim that they are 
> doing SSI and that their customers don't have to do anything except 
> continue buying their products, and their world will transform into 
> one with all the SSI benefits.
>
> Where I have a problem is when the message becomes disingenuous. The 
> instant the ink dries on the new OIDC specs, who will actually have an 
> implementation? Not, "who CAN have an implementation", but "who DOES 
> have an implementation"? The answer will be: some subset of Big Tech 
> and big IAM providers. The end. But that won't be the messaging. The 
> messaging will be all about interoperability and level playing fields.
>
> Maybe a few startups will attempt support too -- but they will get 
> crushed by the dominant players because the only way to make money 
> from this standard will be to sell it to enterprises, and Big Tech 
> already has the relationships that enable such sales locked up. 
> Supplier relationship lock-in is basic MBA "Porters 5 Forces" 
> strategy. Since the standard takes away the ability for the startups 
> to offer a better "standard", they'll lose.
>
> Here's the ground truth, from a political/market perspective: 
> Fundamentally, SSI's value proposition is about changing power 
> dynamics. That's why "sovereignty" is part of its name. A standard 
> that doesn't disrupt power dynamics is not a way to achieve SSI; it's 
> a way to kill SSI by watering it down and trivializing it into oblivion.