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

> To be fair, I did that in the initial email in this thread :P

Ok, bear with me while I try to get some further detail 🙂

> 1. Eliminate registration -- if you require wallet registration, you
> enable centralization.

> #1 is about mandatory wallet registration and wallet vendor detection being a
> bad idea. There are certain technical solutions (feature detection) that help
> here.

Could you respond to my queries, I sent in response to this? Re-stated for clarity below


I'm going to take this particular issue to be about the fact that in order for a wallet to request issuance from a provider in OIDC4VCI, they must first register as a client with the provider? If so lets un-pack because I think this comes from one of two possible perspectives:



1. Either you are advocating for an exchange protocol where the wallet provider remains entirely anonymous to the provider/issuer in a credential issuance exchange.

2. OR you are advocating for an exchange protocol where the wallet provider has to fully re-identify/re-introduce itself to a provider every time it interacts.



OAuth2 which is where the concept of a client originates has this role in the protocol for very good reason. That is, the party requesting authorization to something (the wallet provider in the case of credential issuance) should in some sense be identifiable to the provider. Designing a protocol where this party gets to remain totally anonymous becomes incredibly difficult from numerous perspectives, one for instance is the provider being able to get appropriate End-User consent. For example without the concept of the client in OAuth2, many consent screens we come across in login transactions would change to



"Hey End-User do you want to allow access to ...errr ...hmmm well actually we have no idea who is requesting it, how about you grant access anyway?"



When it comes to registration, the main reason this exists is to make identifying this party an efficient process. For instance, if instead we designed a protocol where the wallet provider needs to re-introduce itself to the provider every time, it just means large amounts of the same information will be passed between the two parties (Wallet provider to issuer) on every interaction, which is in-efficient and I really don't see how having it "enables centralization".

Also can you elaborate on how feature detection is a viable solution here, are you saying a wallet would just anonymously state they support say HSM backed keys during a credential issuance request and issuers would just need to trust that?

> 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.

> #2 is about OpenID not having any CHAPI-like equivalent, which creates a
> natural centralization pressure. There are certain technical solutions
> (CHAPI-like mediators) that help here.

I think I understand this one now, and I think my re-stating in the context of the affected OIDC protocol draft makes this clearer? E.g

OIDC4VP (the verifiable credentials presentation protocol) features no
adequate mediation layer (wallet chooser component) that allows a web based
relying party or verifier to invoke during a presentation request that
allows an End-User to select which wallet they would like to respond to a
request with?

The important context here though that I was trying to get across in previous emails is that if the overall goal is establishing an "open wallet ecosystem", then CHAPI alone does not solve this either, it may facilitate this in same-device-web-based-channels but doesn't solve for when the exchange occurs say across device?


> The third issue (issue #3 in the original email that started this thread) is
the "Credential Marketplace" problem, which creates a centralization concern
with dominant Wallet vendors. There might be technical solutions to this
problem, but I doubt we'll be able to do much here other than best practices
and perhaps some finger wagging spec language about centralization dangers
related to tight binding between wallet->issuer w/o also ensuring CHAPI-like
wallet invocation. I can elaborate further on this if anyone is interested,
but for now, the real centralization dangers seem to be the two items you
mentioned.

I dont understand how this is a concern specific to OIDC protocols, nor how it could be addressed with any protocol approach. I read this concern as the only valid mitigation from your perspective would be that all credential issuance journeys MUST start from the issuer website and MUST invoke a mediation layer like CHAPI to satisfy your concern?


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: Manu Sporny <msporny@digitalbazaar.com>
Sent: 21 March 2022 10:50
To: public-credentials@w3.org <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 3/20/22 4:21 PM, Tobias Looker wrote:
> Are we able to please list these issues / criticisms in a more structured
> manner so we can analyse and respond to each.

To be fair, I did that in the initial email in this thread :P

https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0101.html


To quote directly from that email:

> 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".

#1 is about mandatory wallet registration and wallet vendor detection being a
bad idea. There are certain technical solutions (feature detection) that help
here.

#2 is about OpenID not having any CHAPI-like equivalent, which creates a
natural centralization pressure. There are certain technical solutions
(CHAPI-like mediators) that help here.

#3 is about challenging the notion that putting the wallet at the centre via
"Credential Marketplaces" is without great centralization risk. There are best
practices and market competition warnings that could help here.

> Personally I dont think, statements like "openid does not support an open
> wallet ecosystem" suffices as an issue, we need to push past this into
> why, how and where, it is only then we will be able to work on addressing
> it.

Sure, but as I point out above... I'm not intentionally trying to be vague and
there have been multiple people providing specific technical examples of where
things fall a part.

> So in the spirit of trying to get to this view, do the following issues
> summarise your concerns @Manu
>
> OIDC4VP (the verifiable credentials presentation protocol) features no
> adequate mediation layer (wallet chooser component) that allows a web based
> relying party or verifier to invoke during a presentation request that
> allows an End-User to select which wallet they would like to respond to a
> request with?

Yes, that is one of the issues (issue #2 I raised in the original email).

> OIDC4VCI (the verifiable credential issuance protocol) requires the wallet
> to be a valid "client" with the provider (issuer) in order to request
> credential issuance. This constraint encourages some form of
> centralization or anti-competitive market force that is un-tenable?

Yes, that is another one of the issues (issue #1 I raised in the original email).

The third issue (issue #3 in the original email that started this thread) is
the "Credential Marketplace" problem, which creates a centralization concern
with dominant Wallet vendors. There might be technical solutions to this
problem, but I doubt we'll be able to do much here other than best practices
and perhaps some finger wagging spec language about centralization dangers
related to tight binding between wallet->issuer w/o also ensuring CHAPI-like
wallet invocation. I can elaborate further on this if anyone is interested,
but for now, the real centralization dangers seem to be the two items you
mentioned.

-- 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/