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

On Sun, Mar 20, 2022 at 12:59 PM Harrison <harrison@spokeo.com> wrote:

> Love this thread.  I am new to this space, so please feel free to clarify
> my potential misunderstanding.
>
> Centralization is defined as "the concentration of control of an activity
> under a single authority", and decentralization is where that control is
> not held by a single or few entities.  With this definition, the ultimate
> decentralization is when the control resides in each and every entity (e.g.
> tens of billions of users in this case).
>
> I think VC best advances decentralization because VC's trust model
> empowers users/holders to intermediate identity-related transactions.  In
> any multi-sided platform (e.g. identity), the middleman holds the power.
> In VC, user/holder is the middleman intermediating between verifiers and
> issuers, so each user/holder holds the power, and the decentralization of
> the identity platform could be achieved.
>
> In OIDC, the identity provider is the middleman between users and relying
> parties, so the identity provider holds the power.  While anyone can be the
> identity provider, I think there will be less identity providers than
> users, so OIDC is probably not going to be as decentralized as VC unless
> OIDC empowers users to be the middleman.
>

Yes, in what people think of as traditional OIDC the protocol decisions
were made to push as much business logic onto the identity provider side of
the interface, because from an implementation standpoint there are
radically fewer of them. If you are implementing OIDC in a hosted service,
you don't even have to check signatures on messages, you just need to
redirect, catch a redirect back, and make an API call.

Many companies deploy OIDC for their own services, acting as both a service
provider and identity provider. It's not uncommon to see hundreds of
internal services hidden behind such an interface, all decoupled from the
central operational business rules for identity.

And this is fine because it's all within a single organization operating
under a single set of rules. There are a lot of these (many also using SAML
instead, although integration with SAML is way harder, mostly due to
crypto).

When you are going across organizational policy boundaries (which arguably
is not most common, but is certainly most visible) you have a problem in
that everything behind that interface is atomic. Even for multiple
compliant OIDC providers, you can't be sure they actually meet your
service's business requirements. For instance, you may want a
verified-working email address - which means you need to basically treat
the OP as an issuer to decide whether their claim that an email address is
verified is trustworthy. It would be the social network, and not your
policy, that would determine if authentication is disabled.

OIDC has always had a SIOP model, where the OP was decentralized on the
end-user's device, and thus assumedly under the end-user's power and
control. However, the infrastructure didn't exist for this to not be
considered atomic - so in the verified email case above, you would only
have the end-user's self-asserted word.

The OIDC efforts have been to extend SIOP to support verifiable credentials
and presentations, so that the user could meet the needs of services and
could separate concerns. My choice of wallet could now not only present
verifiable information, but might even be able to present it from the real
authority rather than a version intermediated by an OP.


> Different technologies have different applications, and different problems
> require different solutions.  OIDC has been tremendously successful in
> authentication/authorization use cases, and I think OIDC's social login
> implementation could be one of the factors in multi-factor authentication
> (or at least a proxy to knowledge, possession, inherence, and location
> factors).  In identity verification use cases, I think VC is probably the
> way to go if we want to achieve self-sovereign and decentralized identity
> due to its decentralized trust model.
>

Agreed!

Although, I personally hope with the alternative of using VCs for account
creation and recovery, and with non-centralized authentication factors like
Web Authentication, social logins start to be a less attractive option for
both services and end-users.

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