- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 19 Mar 2022 12:20:41 -0400
- To: public-credentials@w3.org
On 3/18/22 1:43 PM, Brian Richter wrote: > here is my first impressions of the answers to those questions with no > advocacy implied as I am just learning what this looks like myself. Brian, thank you for engaging in the discussion. Dmitri has already done an excellent job of pointing out where some of your thinking might not align with the reality of the specifications. Some higher-level responses to your questions below. > Is this going to be used by RPs to only allow pre-registered wallets to > authenticate? I don't think so I say this with respect -- on this particular point, you are being naive. :) I can tell you that "only allowing approved wallets via OpenID" is currently being proposed by some vendors in the SSI ecosystem to their customers. I do think it's being done in good faith -- "You don't want to just allow /any/ wallet to hold a credential, do you!?" -- the answer to that question should be "In general, yes, that's exactly what you want -- given the wallet has the features you need to ensure the safety of your credential -- such as being able to prove that it's using a Hardware Security Module and appropriate authentication to do key management." To put this in perspective... remember how horrible browser vendor detection was in the late 90s and early 00s, and how it contributed to one of the biggest anti-trust cases[1] in history against Microsoft? ... not to mention countless broken websites? We all learned from that... do browser /feature/ detection, don't do browser /vendor/ detection. The lesson here is: Do /wallet feature/ detection, don't do /wallet vendor/ detection. > I believe on a long enough time scale this is largely solved by SIOP as it > becomes the only OIDC provider worth a damn. No, don't delay solving the problem, solve the problem NOW. I've heard that "just wait, OpenID will eventually solve the NASCAR problem" so many times... and the technology continues to fail to deliver on that promise. The current iteration is no different. CHAPI addresses the NASCAR problem *today* AND you can bootstrap into other protocols such as OIDC, DIDCommv2, VC-API, and VPR from it. > 3. Eliminate the concept of "App Store"-like in-wallet "Marketplaces". If > you do this, you put issuers at a natural disadvantage -- pay to play to > get listed in a wallet's "Marketplace". > > I don't think I understand this grievance :) It's still up to the RP to > choose what credentials they will trust. That's not the problem... the problem is from the opposite side. To state it another way: If you convince wallets vendors that the solution to the NASCAR problem is to just list every credential that is of interest to a holder /in the wallet UI/, then you put issuers at a disadvantage. How do people discover the issuer? If it's only through the wallet interface, then all of a sudden all of the issuers need to lobby wallet providers to get their credentials issued. If you give the wallet vendors that sort of power, market consolidation will result in issuers doing pay-to-play (like the music/streaming industry)... you get issuers paying wallet providers to include them in their searches and for search placement. Sounds like a pretty great business model -- I wonder if there's ever been a company to capitalize on that in an anti-competitive fashion. :P All this to say, we've provided strong guidance around security and privacy in both the Verifiable Credentials specification and the Decentralized Identifiers specification. We should think about providing some level of Market Competition Guidance since some of us seem to be marching into anti-competitive outcomes without much of a debate. Again, almost everyone is being well intentioned... but you know what they say about the road to hell. :P -- manu [1]https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp. -- 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, 19 March 2022 16:20:59 UTC