- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 21 Mar 2022 15:03:45 -0400
- To: "public-credentials@w3.org" <public-credentials@w3.org>
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/
Received on Monday, 21 March 2022 19:04:04 UTC