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

Manu, all
I think that there is a misconception here (either by you or me 😊 ). 

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

Best,
Nikos

-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com> 
Sent: Monday, March 21, 2022 9:04 PM
To: public-credentials@w3.org
Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

On 3/20/22 8:02 PM, Tobias Looker wrote:
>> To be fair, I did that in the initial email in this thread :P
> 
> Ok, bear with me while I try to get some further detail 🙂

Detail is good :) -- specifically, I think you're on the right path wrt.
"identifying the appropriate comparisons" below...

> I'm going to take this particular issue to be about the fact that in 
> order for a wallet to request issuance from a provider in OIDC4VCI, 
> they must first register as a client with the provider? If so lets 
> un-pack because I think this comes from one of two possible perspectives:
> 
> 1. Either you are advocating for an exchange protocol where the wallet 
> provider remains entirely anonymous to the provider/issuer in a 
> credential issuance exchange.
> 
> 2. OR you are advocating for an exchange protocol where the wallet 
> provider has to fully re-identify/re-introduce itself to a provider 
> every time it interacts.

I'm advocating for neither, there is at least one other option:

Advocating for an exchange protocol where the wallet provider is never mandated to register itself with an issuer for credential issuance exchange.

Furthermore, advocating for an exchange protocol where the wallet provider can provide VCs, either issued by itself, an auditor, or a 3rd party, related to the features it provides.

For example: "The private key that is being used for this exchange is secured by a Hardware Security Module, and here is the digital proof provided by the HSM vendor hardware".

> OAuth2 which is where the concept of a client originates has this role 
> in the protocol for very good reason. That is, the party requesting 
> authorization to something (the wallet provider in the case of 
> credential
> issuance) should in some sense be identifiable to the provider.

Strongly disagree if you mean "the wallet provider's identity should be known". The issuer's identity should be known, the holder's identity might be know, but identifying the software vendor is a big red centralization warning flag.

We don't require that Google Chrome identify itself when you download your tax forms, access your corporate bank accounts, or manage your family photos. Some browsers, such as Brave, even go as far as lying about which browser they are (and that's a good thing).

Wallet vendor identification is an unnecessary path to centralization.

> Designing a protocol where this party gets to remain totally anonymous 
> becomes incredibly difficult from numerous perspectives, one for 
> instance is the provider being able to get appropriate End-User 
> consent. For example without the concept of the client in OAuth2, many 
> consent screens we come across in login transactions would change to
> 
> "Hey End-User do you want to allow access to ...errr ...hmmm well 
> actually we have no idea who is requesting it, how about you grant access anyway?"

If you frame the problem where this particular consent happens at the Issuer, then yes, you create this problem... but it's a completely manufactured and avoidable problem.

However, if you frame the problem where the consent should actually happen (at the wallet), then everything is fine. The wallet knows the party that is asking for access (you can't ask for access to the wallet w/o saying who you are).

If you need to ask for consent at the Issuer, the issuer can just say: "Is it ok for your wallet to access these things: A, B, and C?".

However, I'm not convinced we're not talking past each other on this point...
so, need to know (in detail) what threat model you're trying to defend against here.

> When it comes to registration, the main reason this exists is to make 
> identifying this party an efficient process. For instance, if instead 
> we designed a protocol where the wallet provider needs to re-introduce 
> itself to the provider every time, it just means large amounts of the 
> same information will be passed between the two parties (Wallet 
> provider to
> issuer) on every interaction, which is in-efficient and I really don't 
> see how having it "enables centralization".

This presumes that you need to convey the wallet provider identity. I continue to insist that doing that is dangerous from a centralization perspective.

You need to do wallet feature detection (send VCs from wallet to provide it has capabilities w/o requiring the wallet provider to identify itself).

> Also can you elaborate on how feature detection is a viable solution 
> here, are you saying a wallet would just anonymously state they 
> support say HSM backed keys during a credential issuance request and 
> issuers would just need to trust that?

No, definitely not saying that. There is the ideal, and then what we might be able to get away with for a couple of years (at the risk of centralizing the market?).

You will always know the issuer of a VC -- you must if you're to trust it.

It may start out with the wallet vendors asserting that their wallets are backed by HSMs... but that's really not ideal because 1) the wallet vendor identifies themselves and can thus be rejected by the issuer (because they're a competitor of the issuing software provider, for instance), or 2) you want a better assurance than just a wallet vendor claiming something (that might not be true).

Where we want to get to, however, is an assertion from the HSM itself that a private key 1) is contained in an HSM, and 2) is (optionally) not allowed to be exported.

This is the same argument for what we do /browser feature detection/ vs.
/browser engine detection/.

> The important context here though that I was trying to get across in 
> previous emails is that if the overall goal is establishing an "open 
> wallet ecosystem", then CHAPI alone does not solve this either, it may 
> facilitate this in same-device-web-based-channels but doesn't solve 
> for when the exchange occurs say across device?

Yes, correct, though the problem is far less severe in cross-device scenarios IF you don't mandate that the wallet vendor identify itself in the presentation exchange. IF you do this (which is what is currently being proposed for OIDC4VCI), then you re-introduce a strong centralization problem.

> I dont understand how this is a concern specific to OIDC protocols, 
> nor how it could be addressed with any protocol approach. I read this 
> concern as the only valid mitigation from your perspective would be 
> that all credential issuance journeys MUST start from the issuer 
> website and MUST invoke a mediation layer like CHAPI to satisfy your concern?

It's only a concern specific to OIDC protocols because it was suggested as a way to support an open wallet ecosystem in an OIDC ecosystem... "Start at the wallet (not the issuer)."

To put it another way, it /is/ a general concern for the entire ecosystem...
but it's especially troubling for the current proposed OIDC4VC flows.

One way to mitigate the concern is to ensure an open wallet ecosystem when starting at the issuer (something that OIDC isn't doing), so issuer's aren't forced to go to each wallet provider to ensure that they end up in each wallet's "credential search" listings.

Again, there are technical mitigations that help mitigate (but don't necessarily eliminate) the risk. The specific technical mitigation is enabling an open wallet ecosystem when starting the credential issuing process at the issuer, which CHAPI does.

-- 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/