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

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/