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

Writing this from my personal email account since I want to comment on a
few things. Also want to point out that any opinion shared here is my
personal opinion, potentially
controversial.

I think my previous email didn’t go through, so please apologize if this
may have been received twice (didn’t find my previous email in the archive,
so sending again).

> 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

I don't think having a comparison table like this is useful or can be done
in a meaningful way. Since I believe that any of the credentials exchange
protocols can be implemented in
a more or less centralized way. This includes OIDC, CHAPI and the Aries
protocols. IMO, the degree of centralization is a design decision and none
of the protocols can exclude this design on a pure technical level. Those
design decisions are driven by business, regulatory, technical, UX and
other requirements. BTW, I’m not advocating for centralized models.

Why it is so hard to come up with a comparison table that puts those
protocols on a spectrum shows the following diagrams (based on CHAPI, using
different approaches for managing access to data and keys). There are
certainly many other ways this can be done. Note, that I don't want to
suggest centralization is inherent to CHAPI, in that case it was merely a
design decision. Similar diagrams can be created for system architectures
that use OIDC or Aries protocols.

Diagram here:
https://raw.githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg

I also want to point out that SIOPv2 does not require a centralized
component, in the same way as CHAPI and Aries don't require centralized
components. If we want to talk about "centralization dangers", then we
should not look at one specific protocol.

I also want to comment on the points below.

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

SIOPv2 does not require wallet registration as other people have also
pointed out.

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

IMO, solving NASCAR in a satisfying manner always requires support from
platform/OS and/or browser vendors if you don't want to provide unfamiliar
or broken UX for end users. Some of the problems are platform-specific
handling of custom URL schemes and short-lived browser storage.
Technically, SIOPv2 can solve NASCAR by using openid:// but we know that
won’t work well on iOS. Other SIOPv2 discovery options exist and the spec
allows room for innovation. Even a convergence with the CHAPI model may be
possible, e.g., get SIOPv2 OPs config via CHAPI.

There might be promising other approaches such as handling mime-types for
presentation requests on mobile platforms but I don't know if anyone has
implemented it in a production environment. The idea is to assign a
mime-type for presentation requests.

I believe CHAPI can be great but this is why I believe CHAPI doesn’t solve
NASCAR either yet (at least not in a satisfying manner):

1. (ASSUMPTION) CHAPI currently relies on a mediator which is a hosted
polyfill under authn.io. This polyfill is permissive (in terms of wallets)
but governed by a private company. I do believe that the current
implementation is fine regarding privacy, so no tracking and will stay
permissive. But websites could decide to host their own less permissive
polyfill which can limit mediation to certain credential handlers (i.e.
wallets). This is possible as long as the polyfill doesn’t get implemented
as a native browser feature which requires browser vendors support. Correct
me if I’m wrong here.

2. Registered credential handlers live in the browser storage and if that
gets wiped, users need to re-register their credential handlers which
involves going back to wallet vendors’ web pages.

I’d like to understand how and when the CHAPI community wants to solve 1.
and 2. Then, CHAPI will definitely be a good option to solve NASCAR.

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

If some of the wallets decide to do that, then it is their design decision.
There is no requirement in any of the OIDC4SSI specs. However, any wallet
can choose to implement such features but there is nothing in CHAPI, Aries
that would prevent anyone from doing that in the same way you may have
observed.

If you read this far, then the main point I want to get across is that we
should avoid denouncing certain protocols as bad or evil and stop using
polemic arguments. If a technology is used in a good or bad way depends on
design decisions made by technology providers. For example, governments can
act as a forcing function to provide requirements in the form of
regulations that are more permissive (my hope for eIDAS 2.0).

Thanks,
Oliver

On Sun, 20 Mar 2022 at 21:24, Oliver Terbu <o.terbu@gmail.com> wrote:

> Writing this from my personal email account since I want to comment on a
> few things. Also want to point out that any opinion shared here is my
> personal opinion, potentially
> controversial.
>
> I think my previous email didn’t go through, so please apologize if this
> may have been received twice (didn’t find my previous email in the archive,
> so sending again).
>
> > 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
>
> I don't think having a comparison table like this is useful or can be done
> in a meaningful way. Since I believe that any of the credentials exchange
> protocols can be implemented in
> a more or less centralized way. This includes OIDC, CHAPI and the Aries
> protocols. IMO, the degree of centralization is a design decision and none
> of the protocols can exclude this design on a pure technical level. Those
> design decisions are driven by business, regulatory, technical, UX and
> other requirements. BTW, I’m not advocating for centralized models.
>
> Why it is so hard to come up with a comparison table that puts those
> protocols on a spectrum shows the following diagrams (based on CHAPI, using
> different approaches for managing access to data and keys). There are
> certainly many other ways this can be done. Note, that I don't want to
> suggest centralization is inherent to CHAPI, in that case it was merely a
> design decision. Similar diagrams can be created for system architectures
> that use OIDC or Aries protocols.
>
> Diagram here:
> https://raw.githubusercontent.com/awoie/chapi-notes/main/chapi-modes.jpg
>
> I also want to point out that SIOPv2 does not require a centralized
> component, in the same way as CHAPI and Aries don't require centralized
> components. If we want to talk about "centralization dangers", then we
> should not look at one specific protocol.
>
> I also want to comment on the points below.
>
> > 1. Eliminate registration -- if you require wallet
> >    registration, you enable centralization.
>
> SIOPv2 does not require wallet registration as other people have also
> pointed out.
>
> > 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.
>
> IMO, solving NASCAR in a satisfying manner always requires support from
> platform/OS and/or browser vendors if you don't want to provide unfamiliar
> or broken UX for end users. Some of the problems are platform-specific
> handling of custom URL schemes and short-lived browser storage.
> Technically, SIOPv2 can solve NASCAR by using openid:// but we know that
> won’t work well on iOS. Other SIOPv2 discovery options exist and the spec
> allows room for innovation. Even a convergence with the CHAPI model may be
> possible, e.g., get SIOPv2 OPs config via CHAPI.
>
> There might be promising other approaches such as handling mime-types for
> presentation requests on mobile platforms but I don't know if anyone has
> implemented it in a production environment. The idea is to assign a
> mime-type for presentation requests.
>
> I believe CHAPI can be great but this is why I believe CHAPI doesn’t solve
> NASCAR either yet (at least not in a satisfying manner):
>
> 1. (ASSUMPTION) CHAPI currently relies on a mediator which is a hosted
> polyfill under authn.io. This polyfill is permissive (in terms of
> wallets) but governed by a private company. I do believe that the current
> implementation is fine regarding privacy, so no tracking and will stay
> permissive. But websites could decide to host their own less permissive
> polyfill which can limit mediation to certain credential handlers (i.e.
> wallets). This is possible as long as the polyfill doesn’t get implemented
> as a native browser feature which requires browser vendors support. Correct
> me if I’m wrong here.
>
> 2. Registered credential handlers live in the browser storage and if that
> gets wiped, users need to re-register their credential handlers which
> involves going back to wallet vendors’ web pages.
>
> I’d like to understand how and when the CHAPI community wants to solve 1.
> and 2. Then, CHAPI will definitely be a good option to solve NASCAR.
>
> > 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".
>
> If some of the wallets decide to do that, then it is their design
> decision. There is no requirement in any of the OIDC4SSI specs. However,
> any wallet can choose to implement such features but there is nothing in
> CHAPI, Aries that would prevent anyone from doing that in the same way you
> may have observed.
>
> If you read this far, then the main point I want to get across is that we
> should avoid denouncing certain protocols as bad or evil and stop using
> polemic arguments. If a technology is used in a good or bad way depends on
> design decisions made by technology providers. For example, governments can
> act as a forcing function to provide requirements in the form of
> regulations that are more permissive (my hope for eIDAS 2.0).
>
> Thanks,
> Oliver
>
> On Sun, 20 Mar 2022 at 21:24, Tobias Looker <tobias.looker@mattr.global>
> wrote:
>
>> > Given that Tobias is leading OpenID working on this stuff, my hope is
>> that he
>> takes our concerns into that work... that is, if we can convince him of
>> the
>> dangers. :)
>>
>> I'm more than happy to take concerns from members of this community back
>> to the working group, working on these specs, however so far I've not been
>> able to gather what the issues actually are. This thread jumps from issuer
>> to verification protocols, web to native, with some claiming that OpenID
>> efforts have several fatal flaws and CHAPI and DIDCommv2 answer it all (or
>> more of it at least). Are we able to please list these issues / criticisms
>> in a more structured manner so we can analyse and respond to each.
>> 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.
>>
>> 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?
>>
>> 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?
>>
>> Anymore?
>>
>> 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:* Manu Sporny <msporny@digitalbazaar.com>
>> *Sent:* 21 March 2022 06:12
>> *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 12:21 PM, Daniel Hardman wrote:
>> > If we standardize and promote OIDC+SIOP+VCs as the standard way for
>> > institutions to authN/Z users in web contexts, and only for that, then I
>> > think we suck all the wind out of the sails of a standard that would
>> > actually correct this imbalance. Not because there's some fatal flaw in
>> the
>> > API, but because it's teaching the world, yet again, to treat users and
>> > institutions unequally.
>>
>> Yes! Thank you, Daniel! This! +1000
>>
>> Now, we should not be under the impression that people won't try and build
>> this flawed model anyway -- there are strong economic incentives to do so
>> --
>> "The infrastructure is already there! It's doing billions of interactions
>> a
>> day! Let's build on top of it!"
>>
>> I don't think there is any way that the OpenID Foundation DOES NOT go
>> ahead
>> with their VCs over OpenID protocol plans.
>>
>> Given that Tobias is leading OpenID working on this stuff, my hope is
>> that he
>> takes our concerns into that work... that is, if we can convince him of
>> the
>> dangers. :)
>>
>> My hope is that we all, across the various communities, also start
>> collectively pointing toward why OpenID + VCs (as is currently designed)
>> is
>> dangerous to the ecosystem... but we find a way to express these as not
>> pointing the finger at the OpenID protocol, but at design patterns that
>> lead
>> to power inequalities and centralization as Daniel so eloquently stated
>> in his
>> email.
>>
>> Or... the folks working on the OpenID + VCs convince some of us hold outs
>> that
>> what they're doing does support open wallet ecosystems... :)
>>
>> Finally, there are no easy answers here.
>>
>> CHAPI and DIDCommv2 aren't magical in their ability to combat
>> centralization.
>> If Issuers start demanding that wallet vendors identify themselves in
>> transactions (another bad idea), we fall into the same trap, which is why
>> being LOUD about what a dysfunctional centralized ecosystem looks like is
>> crucial.
>>
>> This is why I'd like us to mine this thread and have a "VC Market
>> Competition
>> Considerations" section somewhere... it's clear that some individuals were
>> unaware of the problem and that means we're not doing a good job in
>> educating
>> folks as they enter the industry.
>>
>> -- 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/
>>
>>
>>