Re: Centralization dangers of applying OpenID Connect to wallets protocols (was: Re: 2022-2026 Verifiable Data Standards Roadmap [DRAFT])

IMO, OpenID Connect is not the reason why web applications do only offer a
limited set of sign-in options. It is also not the “Big Tech” companies
that force relying parties to reduce their sign-in options. They could
still offer more options. The reason why they don’t is simply they don’t
need to since most relying parties are just interested in a small set of
claims, most important is the verified email address and all providers can
address that need. There is no need for relying parties in investing in
more options since it is more complicated. Verifiable Credentials (VCs)
have a completely different promise, larger scope and scales in a very
different way (many many issuers and types of credentials). To lower the
costs for relying parties it would be actually good to use already existing
rails for VCs. That was the idea.

If people here are worried that “Big Tech” companies would enter the W3C VC
market, then they would enter the market not because we make it easy to
integrate with OpenID Connect, it is because the market is big and
attractive enough to invest in development. Was Google and Apple involved
in mobile driver’s licenses before ISO 18013-5? No, probably not. They
don’t even seem to be interested in the OpenID Connect profile of ISO
18013-5, they go a completely different route. If the market is big enough
those companies would invest and imo, they don’t care which protocol it is.
For that reason, I don’t think anyone can prevent “Big Tech” companies from
entering a lucrative market by inventing or betting on a new protocol (see
ISO 18013-5).

BTW. I still have no answers to my concerns on CHAPI raised in this email:
https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0200.html.


On Wed, 23 Mar 2022 at 16:50, Joe Andrieu <joe@legreq.com> wrote:

> On Tue, Mar 22, 2022, at 9:02 PM, Tobias Looker wrote:
>
>
> > Those of us in the user-centric identity space saw this play out with
> OpenID 1.0. While initially created for self-sovereign style user control,
> it was immediately co-opted by major players who decided to be OpenID
> providers without being OpenID relying parties. We all watched as, before
> our very eyes, the democratizing tech we had helped birth became merely
> another surveillance tool for BigTech. Trying to protect people from the
> big players, in fact, gave the largest players even more reach into the
> every day web activities of just about everyone on the Internet. Login with
> Facebook isn't just a button. It's a beacon that tracks you on every
> website that offers it.
>
> I for one will admit I was not around participating in this space during
> these days, so I'm not going to pretend I
> understand all the relevant history. But I would like to encourage others
> who are on this mailing list, who did participate in this work to please
> help in understanding it more.
> ...
> The overall point I'm trying to make is that the perception that "BigTech"
> had this highly organized effort to rally around a protocol, make it
> anti-competitive to their own gain is not supported by the evidence I've
> seen and even so there are literally thousands of OpenID providers beyond
> just big tech who collectively support hundreds of thousands of relying
> parties a day, this landscape is incredibly distributed to say the very
> least, so again, the blame here is being put in the wrong place.
>
>
> OpenID began as a way for anyone to use their own website to log in to
> OpenID compliant websites. The vision was for widespread consumption and
> production of OpenID as a login.
>
> For clarity, I'm talking about OpenID. OpenID begat OAuth, which lead to
> OIDC. These aren't peers, but that is the order of market development.
>
> Instead, after a brief honeymoon, NONE of the major players allow login
> anyone else's OpenID or OAuth. Can you log in to Apple with your Google
> account or vice-versa?
>
> No.
>
> Even the sources you reference in support for OIDC, talk about BigTech
> using OIDC to extend the impact of their market position rather than
> allowing third-party login to their services.
>
> As for what is BigTech, it's the largest players in tech by market cap:
> Apple, Microsoft, Google, and Amazon. Facebook is trailing #7 after Tesla
> and NVIDIA. FWIW, Facebook uses OAuth2.0, but not OIDC, but architecturally
> it's all the same problem.
>
> What we had was an identity platform that allowed anyone to use any site
> to login to any other site.
>
> What we got was not the democratization of authentication, but the
> extension of existing power dynamics to even greater footprint across the
> web. What we got was less democratization and more power centralization.
>
> I don't find it credible to believe the companies behind OIDC aren't going
> to play by the same playbook.
>
> But that's speculation.
>
> What I can say without attempting to predict the future is that we've seen
> the OpenID / OAuth / OIDC playbook. We helped create OpenID. We've used it.
> We've seen it completely co-opted by BigTech.
>
> This is a nightmare and I'd rather not see it happen to DIDs and VCs.
>
> Is nightmare too strong?
>
> I don't think it is strong enough.
>
> ID.me recently had a moment where they were announced as the heir apparent
> to ALL authentication into the IRS. *ALL* online services for a fundamental
> services of the US Government were going to be forced to go through a
> single provider.
>
> There is no way that is appropriate in a free society.
>
> Fortunately, after an outcry, they've restored some sanity to the
> situation.
>
> https://federalnewsnetwork.com/agency-oversight/2022/02/irs-plans-pivot-to-login-gov-lets-users-create-online-accounts-without-facial-recognition/
>
> *THIS* is what we are fighting.
>
> Not because BigTech is evil. Heck, they are a huge force for modernization
> and making the world a better place. Even as they make policy choices I
> disagree with, I find most of their services are a net benefit.
>
> We fight because private interests have no moral authority to interject
> themselves into interactions between a free population and their
> government. In fact, they have no moral authority to force themselves into
> any interaction. OAuth and associated systems of real-time deference are an
> abdication of authority. That's something to be avoided, not embraced.
> Cryptographic tools now give us entirely new ways to authenticate reliably,
> without phoning home, without deference.
>
> That's what we are fighting for.
>
> The freedom to use our own identifiers and our own crypto to manage our
> affairs wherever we may find ourselves. Once BigTech took over OpenID,
> OpenID and its descendants, it stopped being an example of how to
> democratize anything.
>
> -j
>
>
> Are we missing a mediation layer that allows the End-User to participate
> more in the choices they see when they go to login on the web? Yes - But
> this is not clear cut, there are a tonne of issues to work through in order
> to get this right, at web scale. Does it require throwing out OIDC, no in
> my opinion it does not, the mediation layer can be added, in fact it has
> been done before [4].
>
> [1]
> https://openid.net/2019/09/30/apple-successfully-implements-openid-connect-with-sign-in-with-apple/
>
>
> [2] https://twitter.com/TwitterDev/status/1436020870875656196
>
> [3]
> https://thenextweb.com/news/facebook-connect-oauth-and-openid-the-differences-and-the-future
>
>
> [4] https://github.com/openid/accountchooser.com
>
>
> Thanks,
>
> [image: 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
>
> [image: 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>
>
> [image: 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>
>
> [image: 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>
>
> [image: 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:* Joe Andrieu <joe@legreq.com>
> *Sent:* 22 March 2022 18:53
> *To:* 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 Mon, Mar 21, 2022, at 5:02 PM, Tobias Looker wrote:
>
> 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.
>
>
> I'm also confused, but mostly because I think I'm with Manu here, but the
> way Tobias is engaging makes me wonder if we're talking about the same
> thing. Folks seem to be talking past each other.
>
> There are two angles I'm seeing here where registration does and doesn't
> make sense.
>
> Where it doesn't make sense is attempting to verify a particular software
> implementation of a client. There's a reason the web doesn't do this. There
> are even better reasons why cryptocurrencies don't.
>
> The fact is, you can't trust the client to be honest about itself. Ever.
> You have to assume that whatever magic sauce you might bake into the client
> will be reverse-engineered and reused by apps by distilling the "secret"
> and applying it themselves. Once you put the secret in your binary, you may
> as well just publish it because you do publish the binary.
>
> In all cases, you should assume the client is hostile and act accordingly.
> Cryptocurrencies push the authenticity question to the key store. You don't
> have to trust the client software that communicates your signed
> transaction, you just have to trust the hardware device that actually does
> the signing (however your setup works).
>
> To the extent that the advocacy is to enable  some sort of allow-list for
> wallet implementations, that's a huge security hole and should be avoided.
> It will only ever give you a false sense of security. Instead, check the
> math on the proof, is the proof valid? Then who cares what software
> delivered it? You certainly aren't going to allow-list all of the hops on
> the network, so why would an allow-list for the client software make any
> sense? I believe this is the point Manu is attempting to make and I agree
> with this point.
>
> All these allow-lists ever do is create a barrier to entry so that the
> existing players can minimize the impact of newer players.
>
> The way that registration makes sense is for DID Auth prior to issuing a
> VC, but I'm not seeing much in Tobias's comments to suggest that is the
> step he means.
>
> > 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?
>
>
> What auditors are you talking about? Why would an issuer trust anyone?
>
> Each issuer is on the hook for doing their own onboarding and establishing
> the identity assurance necessary for their function. That's their own
> business logic and they are free to use whatever means they find
> appropriate. They will trust who they decide to trust and no outside entity
> should be necessary to tell them otherwise.
>
> - How does a wallet know which 3rd parties or auditors the issuer trusts
> and therefore which to supply as a
> "wallet feature" VC's.
>
>
> Why does a wallet need to know any of this? All input and output to a
> wallet should be moderating by a human being. Potentially through
> established policies for automation, but deferring to a 3rd party is
> precisely the kind of centralization Manu is arguing against.
>
> - How does a provider request such VCs?
>
>
> What provider? A verifier asks for VCs using any of the many VC/VP Request
> protocols by talking with software that eventually reaches the Holder.
> Nobody else gets to ask for VCs. In fact, IMO, all VC/VP protocols SHOULD
> be user-initiated so that even verifiers only ever ask in response to a
> request from the Holder. Holders, IMO, should never expose a public
> endpoint for arbitrary VC requests.
>
> If you're saying the issuer wants to also be a verifier, that's fine. But
> lets not conflate the two. Acting as an issuer has a different set of
> responsibilities than acting as a verifier.
>
> - How does a wallet advertise which feature VCs it has to offer as
> features it supports?
>
>
> It doesn't. That's a privacy problem. Verifiers ask for the type of VC
> they want. If the holder doesn't have it, an error message should propagate
> to the verifier so they can provide alternative options. For the holder to
> advertise its capabilities is asking for an increased attack surface. The
> Verifier should say what they need and the Holder should be free to satisfy
> those requirements using any system or software they decide. Just like
> websites and web browsers.
>
> And what is a feature VC?
>
> Wallets should work with any VC and DIDs whose crypto it can understand.
> If a wallet supports a given Verification Method, it should be able to
> support any VC using that method and any DID using that method. In
> practice, the number of methods are likely to follow the Rule of 3 and 4,
> within coherent market segments.
> https://www.bcg.com/publications/1976/business-unit-strategy-growth-rule-three-four
>
> FWIW, I think digital identity is going to look more like the
> transportation industry than soft drinks, which means there will be 3/4
> dynamics in particular segments like SUVs, sports cars, family cars,
> commuter cars, electric cars, etc.
>
> So, yes, there will be allow-lists on differing methods, but to apply
> allow-lists to specific implementations of any particular component in any
> particular DID method is, IMO, not just a waste of time, it creates a false
> sense of security.
>
> - 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.
>
>
> I can't comment on SOC2, but auditing holder software is a selection
> pressure for the holder, not the verifier or the issuer. As mentioned
> before, any such audits can be spoofed or hacked when checked interactively
> over the network. Such audits are great for individuals or enterprises when
> they select the software they want to use, but it is essentially
> meaningless for verifiers or issuers attempting to enforce the software
> they accept interactions with.
>
> Also, anyone can say anything in a VC, so yeah, you could express the
> output of an SOC2 audit as a VC. Not sure what good it does you if you
> aren't the holder, because you can't guarantee that the software currently
> interacting is the subject of that VC. All you can do is prove that some
> software, somewhere, perhaps with a given binary (as could be verified by
> the holder) has been audited (and the audit results). That has nothing to
> do with whether or not the current system is running that binary.
>
> > 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?
>
>
> If your wallet uses an HSM with crappy security, that's on you. You should
> have picked a more secure wallet. You can also leave your ignition keys in
> your car or even hardwire it so a key isn't necessary. I don't recommend
> it. Security assertions are for the "buyer" of that software. Not for third
> parties.
>
> > 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.
>
>
> It may be, but its extremely apt. You can't trust any client software to
> be what you imagine it could be. If you could solve this problem, you would
> solve DRM. The best you can do is create a horrible customer experience
> that at the end of the day will be trivially hackable by any script kiddie.
> The client can always be spoofed.
>
>
> > 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.
>
>
> IMO, the hardware wallet is THE place you need to be able to trust. That's
> it. Everything else is just a conduit for the math done on your HSM--even
> if that HSM is just software somewhere.
>
>
> 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.
>
>
> Hmmm...
>
> How is my wallet incentivized to falsify my consent?
>
> That's seems like worrying about revolvers that are incentivized to
> misfire. Once it becomes known that a particular revolver has poor
> performance characteristics, people will stop buying it. Problem solved.
> Companies are always going to have varying quality in their products.
> Choose wisely.
>
> If a wallet is compromised, you're screwed. Period. Trusting your wallet
> is fundamental to being able to trust anything in the system.
>
> See Ben Laurie's article on this:
> https://authors.library.caltech.edu/72223/
>
> We cannot remove trust completely, but we can abstract it away into just
> the one magic device that does the math with access to our secrets. Protect
> that. Secure that. Back that up. That's how you secure your crypto. If you
> don't care to be that secure, trust a service provider. That's also an
> option. But that service provider gets to be trusted on your behalf because
> they can do the math, not for any other reason. Coinbase isn't "allowed" to
> buy bitcoin for me because they have an approved software implementation.
> Thy are allowed to do it because I gave them money to buy bitcoin and put
> it into a transaction address that they control. They could take my BTC at
> any point, leaving me with only the courts to seek redress. It's an
> acceptable trade-off for many.
>
> The way to support the Coinbases of the world is not by establishing
> wallet registration, it is by ensuring that it's the math that matters.
> That focus not only allows individuals and enterprises to set their own
> wallet custody policies if they choose to self-host that capability, it
> also ensures that this capability can be outsourced. This substitutability
> is how we get open systems through open standards. That is how email works.
> It is how the web works. It's how crypto works.
>
>
> > 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".
>
>
> I think Manu's point is spot on.
>
> Those of us in the user-centric identity space saw this play out with
> OpenID 1.0. While initially created for self-sovereign style user control,
> it was immediately co-opted by major players who decided to be OpenID
> providers without being OpenID relying parties. We all watched as, before
> our very eyes, the democratizing tech we had helped birth became merely
> another surveillance tool for BigTech. Trying to protect people from the
> big players, in fact, gave the largest players even more reach into the
> every day web activities of just about everyone on the Internet. Login with
> Facebook isn't just a button. It's a beacon that tracks you on every
> website that offers it.
>
> I can't speak to the specific features of OpenID that may or may not
> currently compromise the vision of VCs and DIDs, but I see, just in this
> thread, enough misunderstanding of what is actually technically possible to
> see exactly how "wallet registration" is a false hope that will engender
> centralized systems--those for which individual choice requires "jail
> breaking".
>
> Let's not advocate for systems where user choice requires jail-breaking.
> Instead, let the math do the talking.
>
> If the latest from OpenID suggests or requires wallet registration, then,
> yeah, we should avoid aligning ourselves with that part of OpenID.
>
>
>
> Thanks,
>
> [image: 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
>
> [image: 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>
>
> [image: 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>
>
> [image: 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>
>
> [image: 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>
> 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/
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>