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

The definition of “Self-Issued” in SIOP is OP’s ability to self-sign an ID Token using the keys controlled by the Holder and not a third Party Identity Provider.

In usual OIDC-Core, issuer=third party IdP (ie Microsoft, etc) attests to the Relying Party that sub=user’s identifier within that IdP belongs to that user. In SIOP issuer=User (can be local or cloud based) attests to the verifier that sub=User’s identifier belongs to that user. User can do so by using DIDs or JWK thumbprints as subject identifiers and by proving that the user controls that key by signing over the ID token. (For simplicity, user=holder in SIOP) Some call this DIDAuth. How those keys are controlled (HW-based, cloud-based, etc.) is out of scope of SIOP. Markus is right to point out that the current definition of SIOP says “in the local control” which does not reflect the evolution of SIOP v2 - alternative definition has been discussed in the WG.

Note that SIOP v2 might use DID as a BYOI (bring your own identifier) to the verifier, but to send a VP, user will use OIDC4VP to send a VP (or VPs) alongside ID Token. These VPs of course can use DIDs as user’s identifiers within the issuer.

In summary, together these specs enable a user to use her own identifier at the RP instead of the one provided by the third party IdP, and to present identity credentials without Verifier directly talking to the Issuer - this does sound like “SSI”, doesn’t it?

Best,
Kristina


________________________________
From: Markus Sabadello <markus@danubetech.com>
Sent: Saturday, March 26, 2022 4:38:09 PM
To: 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])


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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Famazon.com%2F&data=04%7C01%7Ckristina.yasuda%40microsoft.com%7C2e2c96e820b3418c807708da0f3f0b19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637839060723964478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5m5xPdRu%2Fo7CcKalGDJssTPjf%2F79FsW32uOkFH90HvA%3D&reserved=0>, but if I try to open a support ticket at support.amazon.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.amazon.com%2F&data=04%7C01%7Ckristina.yasuda%40microsoft.com%7C2e2c96e820b3418c807708da0f3f0b19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637839060723964478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TbwbbsWxFBn%2FtkWBBnggb3m0%2FC4t%2FDHgIDZktaNkYGA%3D&reserved=0>, or access my author dashboard at kdp.amazon.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkdp.amazon.com%2F&data=04%7C01%7Ckristina.yasuda%40microsoft.com%7C2e2c96e820b3418c807708da0f3f0b19%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637839060723964478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EFZFnxQfP4So81dIuS4CoeYImZns3QuywAUddJhsGB0%3D&reserved=0>, 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.