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, but if I try to open a support ticket at
support.amazon.com, or access my author dashboard at 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.