- From: Tobias Looker <tobias.looker@mattr.global>
- Date: Tue, 22 Mar 2022 00:02:09 +0000
- To: Melvin Carvalho <melvincarvalho@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>
- CC: W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <SY4P282MB127461B92A54B90E7182D7C89D179@SY4P282MB1274.AUSP282.PROD.OUTLOOK.COM>
Manu, see below for some responses to your latest email. > Advocating for an exchange protocol where the wallet provider is never mandated to register itself with an issuer for credential issuance exchange. I continue to be confused with your framing of registration as the problem here, I think you mean a protocol where the wallet provider identifies itself, in the flow, is the actual issue? Registration is just a way to do the bulk of this once? I also dont see how this is materially different to the wallet feature VC approach either w.r.t centralizing forces that result. > 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. Its hard to really give feedback on this solution right now, as it feels very abstract, for instance: - Where is the list of 3rd parties of auditors that a issuer trusts assertions to come from? - How does a wallet know which 3rd parties or auditors the issuer trusts and therefore which to supply as a "wallet feature" VC's. - How does a provider request such VCs? - How does a wallet advertise which feature VCs it has to offer as features it supports? - Are complex things like a wallet provider passing something like a SOC2 audit even expressible in the form of a VC? Usually when a party is assessing another for compliance under a framework like SOC2 it requires them to actually read their auditors report, there is huge variability here around which controls/procedures a wallet provider may have been assess against also. > 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". In some cases this check may be sufficient, however in many others it may not. For example what happens if my wallet uses an HSM to store the keys but does absolutely no authentication on the party that is interacting with the wallet, hence anyone can generate a presentation for any VC it manages, what does an HSM backed key on its own offer in this instance? > 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). I don't agree with the comparison of wallets being akin to browsers and I think this is at the core of some of our disconnect. > 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). I think its a matter of opinion "where the consent should actually happen" and I'm personally not convinced this should be collected directly from the wallet. In general I think it can be dangerous to setup a consenting model, like you have suggested, where the party collecting the consent is the party that is granted the outcome produced by the consent being given. In this model malicious wallets have an incentive to just lie that they got consent from the End-User, so they can get the credential, issuers would be none the wiser. > 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. This is no more of an issue for an OIDC based flow, then it is for any other. Do we generally need to develop techniques that support a competitive issuer and wallet landscape for credentials, yes, does OIDC based protocols bias or limit these options in a negative way, IMO no. Therefore I don't feel this is a valid criticism w.r.t the original context in which this issue was raised, which is "Centralization dangers of applying OpenID Connect to wallets protocols". Thanks, [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> Tobias Looker MATTR CTO +64 (0) 27 378 0461 tobias.looker@mattr.global<mailto:tobias.looker@mattr.global> [Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> [Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> [Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> [Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. ________________________________ From: Melvin Carvalho <melvincarvalho@gmail.com> Sent: 22 March 2022 12:33 To: Manu Sporny <msporny@digitalbazaar.com> Cc: W3C Credentials Community Group <public-credentials@w3.org> Subject: Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT]) EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. On Fri, 18 Mar 2022 at 17:49, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote: I'm taking all of my hats off and saying the rest as a "concerned citizen and computer scientist". Take it as personal commentary, for whatever that is worth. I expect much of this to be controversial... and result in an unavoidable permathread. :) TL;DR: It is hopelessly naive to think that OpenID Connect, THE protocol that centralized social login to 3-4 major tech companies, only requires "small changes" for self-sovereign identity and is a "doorway" we should gleefully step through. On 3/17/22 5:45 PM, Kaliya Identity Woman wrote: > Yes - and I agree with the note following this one on the thread that they > are meeting different needs use-cases. It's all a matter of perspective, isn't it? :) When you get down into the details, sure you can argue that some protocols are addressing different needs/use-cases, but it is also undeniable that every single one of the protocols can move a Verifiable Credential from point A to point B. In that way, they're directly competitive with one another. That's not an interesting debate, though; it's at the wrong level -- too meta. What would be more beneficial is for someone to produce a pros/cons matrix like we did for "Protecting VCs using pure JSON JWTs vs. VC-JWTs vs. Linked Data Proofs": https://w3c.github.io/vc-imp-guide/#benefits-of-jwts https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs Until we get to that level of detail, I expect we'll not make much progress on the wallet protocols topic. > The fact is that there is a huge opportunity to really leverage the "OIDC" > "doorways" that exist all over the web (a protocol that is literally used > a billion times a day...you know some real adoption) to exchange VCs - with > some small changes. > > AND people in this group seem to be "deathly afraid" of that work because > it isn't home grown here alone in isolation and focused on web only. I... just... don't even know where to start. I disagree with every concept in the previous paragraph. :) I can't speak for anyone else in this group, so I'll just speak for myself: It is hopelessly naive to think that OpenID Connect, THE protocol that centralized social login to 3-4 major tech companies, only requires "small changes" for self-sovereign identity and is a "doorway" we should gleefully step through. Login with Google/Facebook/Apple/Microsoft, those "billions of times a day" usages... are all coerced logins. We have no choice but to use the big tech vendors. That is not a world I want to contribute to. We are not "focused on web only" here... though it is an effective "gotcha!" talking point that seems to not be questioned when uttered ("I mean... the word "WEB" is in World Wide Web Consortium! What else could they be up to over there!?"). The phrase is disingenuous, I really wish those uttering it would stop... but you can't blame them, it's an effective way to get people who don't know any better nodding in agreement with whatever "non-Web" thing you're going to say next. I am "deathly afraid" of the work, because people are rushing into it without thinking deeply about the consequences. So, "Nope!": I refuse to just go with the herd and gleefully re-cement centralization in this new generation of identity technologies. I refuse to trust that things will be different this time because the same people that created OpenID Connect have learned their lessons and are doing things differently now. ... and I refuse to accept your mischaracterization of this community, the good faith efforts that they've put forward to coordinate where they can, or why some of us remain sceptical of some of the other wallet protocol efforts going on right now. It is possible for all of us, across all communities, to act in good faith and still disagree on the path forward. I certainly don't think for a second that the vast majority of people involved in OpenID, DIF, CCG, IIW, or RWoT are acting in bad faith. Misguided, possibly (including myself!), but not this "Not Invented Here Tribalism" narrative that seems to be so popular. I see a bunch of people, across each "silo", doing their best to solve hard problems given all of the pressures of their work and home life. Full stop. Going back to OpenID being applied to Verifiable Credential Exchange. There are three fatal flaws that need to be overcome for it to be a good idea: 1. Eliminate registration -- if you require wallet registration, you enable centralization. 2. Eliminate NASCAR screens; don't allow verifiers to pick/choose which wallets they accept. If you allow either of these things to happen, you enable centralization. 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". Rather than seeing solutions proposed to the problems above, the OpenID specifications seem to be doubling down on enabling the three items above. Out of CHAPI, DIDCommv2, and OpenID... OpenID is the most centralizing, worst solution for Verifiable Credential Exchange on the table today. That is not to say it can't be fixed, but I have yet to see a proposal that addresses all three items above. > There is a lot of "othering" of work that isn't CCG. Because that work is > less "pure". No, there are concerns related to the technical underpinnings of OpenID that lead to centralization that have yet to be addressed by the current proposals. The only Othering I'm seeing going on here is what you're doing. Casting some vague subset of the CCG as this irrational, web-only, not invented here, tribal silo and going after community volunteers that are not doing what you want or meeting on your schedule. I've known you for many years, Kaliya -- you're better than this and are usually a bridge builder and tireless advocate for open lines of communication. I know you're frustrated, we all are, but I don't think the way in which you've chosen to engage is going to result in what you want. Again, just my $0.02 as a community member. +1 agree with everything Manu said As the old saying goes, "no matter how decentralized you make something, centralization creeps in through the back door". From my experience OIDC is a vector for that, perhaps the biggest vector I recall being on a call with Manu, 15 years ago, where we were advocating a web based single sign-on solution based on PKI that his team had put together and worked in the browser. We came quite close to getting that into Ubuntu, but it was felt that browser support wasnt quite there Over the course of the next decade, that solution, or something similar, became the basis of the Solid project. Single sign on via PKI was the the genesis and value proposition of what we created. It was innovative because users owned their own profiles, they could manage their own keys, and could log in without the need to rely on a trusted third party. One slight weakness was that it was domain based, and hard to move your identity. Content addressable identifiers such as DID provide an innovative (and complementary) alternative to that Much later OIDC was added to solid, and it was promised that it could live "side by side" with PKI. That was not the case, as soon as OICD was allowed in, the trusted third party system took over and owning your own keys got broken and never fixed. Tests were commented out etc. There was also no greater source of bugs in Solid than OIDC. They were never fixed. People came to the project and left, the earth being salted with the disappointment, as it appeared to be something that didnt work. In contrast, I used PKI on an hourly basis for 10 years (in browser, apps and server to server), and it never failed me. You may recall the original OpenID (nee. Yadis) from bradfitz was designed for sovereign identity. But increasingly it became used for just certain large providers, creating the NASCAR problem, and occasionally you would have "Log in with your OpenID". Which often didnt work. Then Yahoo came along and started white listing, and sovereign ID didnt get a look in. It's the same story again and again. We need to stand up for PKI solutions. Because trusted third party solutions will never be content to live side by side. They are a vector for the biggest companies to get bigger and leverage their overwhelming competitive advantages through standards It's a permathread because trusted third parties will never stop trying to get into standards and making themselves those trusted third parties. That's OK, we should accept that, but also create more choice for the user with modern cryptographic solutions -- 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 Tuesday, 22 March 2022 00:02:27 UTC