- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 26 Mar 2022 16:32:26 -0400
- To: public-credentials@w3.org
On 3/20/22 8:56 PM, Tobias Looker wrote: > There was never any assertion made that this mechanism was suitable for > "same-device", hence why the description starts with the words > "cross-device". Yes, understood... but that's not the point I was making, which is below: > The list supplied was to describe the different ways a request can be > passed to a wallet using SIOP v2. What it does highlight is that SIOP v2 > supports more mediums to hand a request to a wallet than the CHAPI model > which shows in my mind why the protocol (OIDC/SIOP) should be separate from > the mediation layer that gets added on top when you are in an environment > like a browser that requires wallet chooser style mediation. Disagree on "more mediums" being a good thing. Here's the point: Generally speaking, cross-device wallet invocation is a solved problem -- just use a QR Code and /any/ of the presentation request mechanisms. Done. Everyone (W3C/CCG stack, OpenID/DIF stack, Aries stack) have already converged on that solution. That's not the point of contention, the point of contention is how OIDC/SIOP claims to solve same-device wallet invocation when every solution put forward has unworkable drawbacks with no suggestions about how to get around those drawbacks. Even worse, and when you put all of those SIOP solutions together -- no one is using them in a unified way and we're completely hand-waving over the centralization issues with mandatory OIDC registration for "high-value" use cases. I'm not talking about dynamic client registration, which might be ok, I'm talking about the Issuer going: "I need to know that this is an Apple Wallet I'm connecting to". <-- that will lead to market centralization. > Are we fundamentally comparing the wrongs things here? Should we instead > be comparing VPR + VC API to the OIDC protocols? Yes, probably... but we still need to know how OIDC is proposing to do same device wallet invocation without hand waving over it. In an attempt to try and narrow in on this, I've added two more columns to the W3C CCG Wallet Protocol Analysis document: "OS Protocol Handler" and "OS URL Handler", I suggest we move OIDC/SIOP to the Presentation Exchange section and focus purely on protocol... but am unsure if you want to extract just the wallet invocation bits of it before we do that? I leave moving that over to you... I think we're getting some really useful refinement on this point. For same-device wallet invocation, the apples-to-apples comparison is probably CHAPI vs. OS Protocol Handler vs. OS URL Handler. I'm not sure how the query parameter passing w/ OIDC is going to work on the presentation exchange page, but given that we already have OIDC4VC1 and OIDC4VP on there, it might work out. What do you think? >> The issue isn't cross-device... it's same device wallet invocation (which >> is a > very common use case). > > 100% agree that the NASCAR problem is mostly an issue for same-device > style interactions, but are you saying cross-device use-cases have no value > and we shouldn't design a protocol that works for that too? No, I'm saying that we should solve for all of these use cases that we know about because they're all important. We need to support: 1. Same-device web wallet. 2. Same-device native wallet. 3. Cross-device web wallet. 4. Cross-device native wallet. 1 and 2 are challenging, 3 and 4 are easy (just use a QR Code). If we do not have an open wallet ecosystem solution for all of those, we should expect a repeat of the centralization that OpenID Connect established in social login. -- 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:32:43 UTC