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

> Disagree on "more mediums" being a good thing.

Can you elaborate? The only possible conclusions I can draw from this statement is that you are either advocating for entirely different protocols to solve these different mediums, which just seriously complicates the infrastructure requirements for all parties
in the ecosystem OR you are saying one of the mediums is invalid for some reason?

> Generally speaking, cross-device wallet invocation is a solved problem -- just
use a QR Code and /any/ of the presentation request mechanisms. Done. Everyone
(W3C/CCG stack, OpenID/DIF stack, Aries stack) have already converged on that
solution.

Sigh, if only :) please do point me to the canonical example of how this is done in a standard way across the ecosystem today? Im not aware of one, hence why we are trying to solve this with some of the OpenID work.

> Even worse, and when you put all of those SIOP solutions together
-- no one is using them in a unified way and we're completely hand-waving over
the centralization issues with mandatory OIDC registration for "high-value"
use cases. I'm not talking about dynamic client registration, which might be
ok, I'm talking about the Issuer going: "I need to know that this is an Apple
Wallet I'm connecting to". <-- that will lead to market centralization.

I mean are there un-solved issues around mediation for SIOP, yes, I've already said this repeatedly. But while we are talking about "hand-waving" can someone please produce, just one e2e sequence diagram for CHAPI + VPR + VC API and describe the security model here? To date I've not seen anything that shows how this would work? Including how you propose to solve client metadata negotiation without a mechanism like client registration AND how this would net anything meaningfully different around mitigating the vague centralizing forces that keep getting alluded to in this thread.

> Yes, probably... but we still need to know how OIDC is proposing to do same
device wallet invocation without hand waving over it. In an attempt to try and
narrow in on this, I've added two more columns to the W3C CCG Wallet Protocol
Analysis document: "OS Protocol Handler" and "OS URL Handler", I suggest we
move OIDC/SIOP to the Presentation Exchange section and focus purely on
protocol... but am unsure if you want to extract just the wallet invocation
bits of it before we do that? I leave moving that over to you... I think we're
getting some really useful refinement on this point.

Ok will review thanks.

> I'm not sure how the query parameter passing w/ OIDC is going to work on the
presentation exchange page, but given that we already have OIDC4VC1 and
OIDC4VP on there, it might work out. What do you think?

Same as the above I'll take a look at how it can be re-framed


> 1 and 2 are challenging, 3 and 4 are easy (just use a QR Code).


I mean yes the solution for 3 and 4 is likely to make use of a QR code, and it may be easier in some ways then the same device flows, but I wouldn't trivialize the work still required here, the security model and considerations can be complex to get right.


> If we do not have an open wallet ecosystem solution for all of those, we
should expect a repeat of the centralization that OpenID Connect established
in social login.


Im going to continue to be pedantic here, this sentence again puts the blame on OpenID Connect and as has been highlighted repeatedly on this thread much of that blame is miss placed and continuing with this framing will just continue to offend valuable people from OIDF that can help solve these problems.


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: 27 March 2022 09:32
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 8:56 PM, Tobias Looker wrote:
> There was never any assertion made that this mechanism was suitable for
> "same-device", hence why the description starts with the words
> "cross-device".

Yes, understood... but that's not the point I was making, which is below:

> The list supplied was to describe the different ways a request can be
> passed to a wallet using SIOP v2. What it does highlight is that SIOP v2
> supports more mediums to hand a request to a wallet than the CHAPI model
> which shows in my mind why the protocol (OIDC/SIOP) should be separate from
> the mediation layer that gets added on top when you are in an environment
> like a browser that requires wallet chooser style mediation.

Disagree on "more mediums" being a good thing.

Here's the point:

Generally speaking, cross-device wallet invocation is a solved problem -- just
use a QR Code and /any/ of the presentation request mechanisms. Done. Everyone
(W3C/CCG stack, OpenID/DIF stack, Aries stack) have already converged on that
solution.

That's not the point of contention, the point of contention is how OIDC/SIOP
claims to solve same-device wallet invocation when every solution put forward
has unworkable drawbacks with no suggestions about how to get around those
drawbacks. Even worse, and when you put all of those SIOP solutions together
-- no one is using them in a unified way and we're completely hand-waving over
the centralization issues with mandatory OIDC registration for "high-value"
use cases. I'm not talking about dynamic client registration, which might be
ok, I'm talking about the Issuer going: "I need to know that this is an Apple
Wallet I'm connecting to". <-- that will lead to market centralization.

> Are we fundamentally comparing the wrongs things here? Should we instead
> be comparing VPR + VC API to the OIDC protocols?

Yes, probably... but we still need to know how OIDC is proposing to do same
device wallet invocation without hand waving over it. In an attempt to try and
narrow in on this, I've added two more columns to the W3C CCG Wallet Protocol
Analysis document: "OS Protocol Handler" and "OS URL Handler", I suggest we
move OIDC/SIOP to the Presentation Exchange section and focus purely on
protocol... but am unsure if you want to extract just the wallet invocation
bits of it before we do that? I leave moving that over to you... I think we're
getting some really useful refinement on this point.

For same-device wallet invocation, the apples-to-apples comparison is probably
CHAPI vs. OS Protocol Handler vs. OS URL Handler.

I'm not sure how the query parameter passing w/ OIDC is going to work on the
presentation exchange page, but given that we already have OIDC4VC1 and
OIDC4VP on there, it might work out. What do you think?

>> The issue isn't cross-device... it's same device wallet invocation (which
>> is a
> very common use case).
>
> 100% agree that the NASCAR problem is mostly an issue for same-device
> style interactions, but are you saying cross-device use-cases have no value
> and we shouldn't design a protocol that works for that too?

No, I'm saying that we should solve for all of these use cases that we know
about because they're all important. We need to support:

1. Same-device web wallet.
2. Same-device native wallet.
3. Cross-device web wallet.
4. Cross-device native wallet.

1 and 2 are challenging, 3 and 4 are easy (just use a QR Code).

If we do not have an open wallet ecosystem solution for all of those, we
should expect a repeat of the centralization that OpenID Connect established
in social login.

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