- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 20 Mar 2022 12:49:22 -0400
- To: public-credentials@w3.org
On 3/19/22 5:30 PM, Tobias Looker wrote: > Across all of these threads we appear to be wildly jumping from > considerations as they apply to credential issuance protocols and then as > they apply to credential presentation protocols. The reason that is the case is because CHAPI and DIDCommv2 cover the gamut of credential issuance and credential presentation, while the OpenID specs seem to (for some reason I have yet to understand) do different things depending on if you're issuing or presenting. I wouldn't say the conversation is "wildly jumping" -- we're having multiple conversations in parallel (and yes, it's a bit much). However, these are all considerations that need to go into a holistic solution. That said, I take your point about focusing on the technical primitives; it is part of the discussion that's currently a bit more chaotic than it needs to be. > SIOP currently supports multiple ways to invoke / send a request to a > wallet to ask for presentation of credentials, however when the relying > party is a website, without a consistent *browser style* mediation layer > that allows an End-User to register what wallets they use like in CHAPI, > it does not meet the "open wallet ecosystem" goal? Yes, correct, because it ducks the point of contention instead of addressing it directly: None of the current OpenID protocols work for people using their mobile phone to pick up a credential on the same device, nor do they work for people using their laptop/desktop to pick up a credential on the same device. CHAPI solves this particular problem, DIDCommv2 and OpenID do not. Remember where this conversation started... with Kaliya insisting that some in the community were being irrational in their "not invented here tribalism" by not adopting OpenID. The real reason is more nuanced -- it's that OpenID doesn't seek to solve the "open wallet ecosystem" goal. This thread is shedding light as to why -- OpenID isn't a solution to, arguably, the most important requirement that our community faces -- enabling an open wallet ecosystem with respect to the primary way people use their mobile devices when discovering something new today (open a browser, do something in-browser). I guess you could argue that DIDCommv2 only solves that goal if you have two devices with which to engage... except, we've seen examples of DIDCommv2 being bootstrapped over CHAPI (and that is a valid way, IMHO, of solving the open wallet ecosystem goal). We've gone so far as to try and establish how to do a protocol upgrade from CHAPI+VPR to DIDCommv2 here: https://w3c-ccg.github.io/vp-request-spec/#didcommv2-presentation OpenID does none of these things and instead demands that the user has to be engaging two devices at all times in order to scan a QR Code (same as DIDCommv2 w/o CHAPI) and then further hammers the centralization nail in by saying: "Oh, and wallets need to be registered with the issuer in some way during issuance... and probably for verification, too!" It's that last thing that makes OpenID the worst of all three options. > The reason I added the caveat "when the relying party is a website" here, > is how does CHAPI help achieve an "open wallet ecosystem" when you are > doing a cross device presentation (e.g in-person)? IMO it doesn't which > highlights the fact we perhaps need to be clearer about what user journeys > we are talking about when. Yes, point taken. CHAPI is NOT a solution to that problem... a QR Code with some sort of rendezvous payload is... but invoking a interaction in that way is largely a solved problem (for a use case that's important, but not the point of contention). Wouldn't it be nice if you didn't HAVE to have two devices to pick up a credential? > Also I think the importance of the existence of a mediation layer like > CHAPI is different in credential presentation flows vs issuance flows, for > example in issuance, a CHAPI mediation layer is only used if you start > from the issuers website AND your wallet is installed on the same device > and you need some way to invoke it. Yes, the use case otherwise known as "People using the Web on their mobile phone to get stuff done." or "People using the Web on their desktop/laptop to get stuff done." -- It's the primary interaction mechanism that many of us engage in every day. I don't know about ya'll, but I don't regularly jump from my desktop browser to my mobile device to accomplish a single task. The one exception is Multi-Factor Authentication -- and while it's necessary to have that happen on a different device... it's not necessary for me to pick up a credential using a different device. In fact, that's an annoying inconvenience that is being driven by self-imposed technical shortcomings in OpenID and non-CHAPI-DIDCommv2. Hope that helps shed more light on where all of this is coming from... will respond to your three technical points in the next email. -- 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 Sunday, 20 March 2022 16:49:39 UTC