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

Please make sure you are talking about OIDC vs SIOP, as they are not the same with the flows.

 

From: Daniel Hardman <daniel.hardman@gmail.com> 
Sent: Thursday, March 24, 2022 2:13 AM
To: Tobias Looker <tobias.looker@mattr.global>
Cc: Joe Andrieu <joe@legreq.com>; Credentials Community Group <public-credentials@w3.org>
Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

 

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.