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

On 3/21/22 5:50 PM, Nikos Fotiou wrote:
> I think that there is a misconception here (either by you or me 😊 ).

Let's find out who it is... :P

> Let's focus on issuance. When we are saying the wallet registers with the 
> issuer, this does not necessarily mean that apple will have to register 
> with an issuer in order for apple wallet to be used with that issuer.

That is exactly what is being proposed for high-value use cases using OpenID
Connect today. "DMV: If we don't know what digital wallet we're putting this
high value mobile driver's license into, we're not being a good custodian of
our customer's information!" This is the flawed thinking that many of the mDL
vendors have pushed on the US state DMVs. There are people in this community
that believe this, but it's a flawed mental model.

Yes, doing a special deal with a specific wallet vendor (Apple) that controls
the entire software, OS, and hardware stack all the way down to the Secure
Enclave and knowing for certain that you're dealing with that vendor's wallet
when you issue a mobile driver's license into that system is the safest thing
you can do.

It is also fantastically centralizing and anti-competitive... the issuer isn't
going to vet 50+ wallets from around the world... they're going to just do
deals w/ the big tech vendors and create a closed wallet ecosystem.

> This may as well mean that your particular instance of
> apple/google/whatever wallet registers with the issuer. The latter process
> does not have to be provider specific,  neither has to be done a priory:
> OAuth 2.0 and OIDC both support dynamic client registration ( 
> https://openid.net/specs/openid-connect-registration-1_0.html 
> https://datatracker.ietf.org/doc/html/rfc7591 ) that does not involve 
> nothing that resembles to a "wallet provider identity "(e.g., "Google 
> Chrome" or "Apple wallet").  Moreover, and more importantly, this process 
> is not used for ensuring that you are using the wallet of a particular 
> vendor, but it is done for establishing some necessary security
> parameters, including the client id and the redirection URI. These
> parameters are necessary in order to prevent various attacks.

Oh sure, that would be far better (though with its own pitfalls). Dynamic
client registration, however, is definitely not what's being proposed.

Strong wallet vendor detection using mandatory OAuth2 registration with issuer
approval is what's been proposed on this mailing list... not dynamic client
registration.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Saturday, 26 March 2022 20:49:32 UTC