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

> What is the security feature being sought here, and the attack model?

The basis of OAuth2 and the interaction mechanism via the "front channel" is based on redirects, simply put the reason the client specifies a redirect URI is so the provider can validate any request that comes in for a particular client against their registered redirect URI. This mitigates things like the ability for client impersonation. I believe VC API will run into this exact same requirement once it comes to better define the "interact" interface.

> You say "it is optional", but previously say "there is no point", which is a
contradiction. I'm going to assume you mean "its mandatory to ensure a good
UX". If so, yes, agreed some form of protocol negotiation is required at some
point.

My words are being taken out of context here, please re-read what I said. There is no point the provider generating a response that is un-processable by the client. The reason I said it was optional information during registration is that this particular piece of information can also be communicated in the request. Whats not optional though is for the provider to have no idea what the client supports in a response and just guess, which is exactly the issue CHAPI + VC API and VPR has right now, resulting in protocol failures I have already described.

> In CHAPI, this can be done via the wallet manifest.json file... just like it
can be done in OIDC via discover... however, I think doing both is a mistake.
We should probably make this a part of the protocol, and there are already
hooks in VPR to do this.

Can you please point to the hooks in the VPR spec that are available for this and how it is being used.

> What is the security feature being sought here, and the attack model?

There are numerous differences in the security characteristics of different client types (e.g web and native), for example the style of redirect URI they use, web clients most commonly us https:// based urls when native based clients might choose to use a deep link style URL. Therefore it can be useful for the provider to know the nature of the client to ensure it can safely interact with it in each request.

> Please do, :) exhaustive list please.

Rather than paraphrase every metadata element defined by the standard, please refer to the below, many of the descriptions quite clearly indicate the purpose of the different registration parameters in the protocol.

https://openid.net/specs/openid-connect-registration-1_0.html

Debating each one I dont think is a productive use of our time, the only reason I elaborated on a few was to make it clear that client registration serves a valuable purpose around negotiation in OpenID and its not just some dangerous centralizing force.

> Alright, Mr. "We've considered something you haven't"... :P

To be fair, I didn't invent OIDC or OAuth2 so these are not revelations in protocol design im claiming to have made. But they certainly highlight notable gaps in the current state of CHAPI + VPR + VC API. Providing a "heres how we may do it" response is not the same as having a rock solid standard that has been in production doing these things for over a decade, the devil is in the detail. So my original comment around "CHAPI + VC API flow hasn't got to tackling this particular problem yet" still stands, could "CHAPI + VC API" solve this, yeah probably, has it solved it yet? No.

The reason that distinction is important is because of some of the comments that have been made in this thread amounting to "OIDC client registration is nothing but a dangerous protocol wart, design to centralized the landscape" is invalid, because once CHAPI + VC API actually solves this problem we are likely to draw a straight line between many of these features and thus show their true purpose.


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 11:03
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/21/22 7:33 PM, Tobias Looker wrote:
> Essentially as Nikos pointed out the primary intent of client
> registration, whether it be accomplished dynamically or via other means is
> for the provider to understand certain things about it, that are core from
> a security and interoperability perspective.

We should be careful to separate client registration for the purposes of
identifying a vendor, and dynamic client registration (that allows the vendor
to be, ideally, anonymous).

> Suffice to say even in a model that uses CHAPI + VC API, most of the exact
> same information will have to be shared in order for exchange to be
> conducted securely,

The details matter here, so let's look at the specifics.

The objection here is to identify the wallet vendor and then base security
decisions off of that information. It's a variation of a confused deputy attack.

> - Redirect URIs, required so the provider knows where to send the
> authorization code in response, fundamentally if you want a protocol that
> involves the issuer interacting with the End-User, you will not be able to
> escape the usage of redirect and therefore the necessity of this parameter
> being featured somewhere in the protocol.

What is the security feature being sought here, and the attack model?

> - response types, what the wallet supports as a response type, required
> for interoperability, there is no point the provider producing a response
> the wallet is fundamentally un-able to receive, also note it is optional
> in registration.

You say "it is optional", but previously say "there is no point", which is a
contradiction. I'm going to assume you mean "its mandatory to ensure a good
UX". If so, yes, agreed some form of protocol negotiation is required at some
point.

In CHAPI, this can be done via the wallet manifest.json file... just like it
can be done in OIDC via discover... however, I think doing both is a mistake.
We should probably make this a part of the protocol, and there are already
hooks in VPR to do this.

My hope is that whatever we settle on works across all of the wallet protocols
(the description mechanism is the same). I'm already presuming that there will
be more than one wallet protocol; though, it would be a miracle if we could
get down to one.

> - grant types, again very much like the above but it is the client
> describing which possible grants it may request, also note it is optional
> in registration.

This is done via VPR. We've been passing ZCAP requests for years via VPR over
CHAPI. I expect we can easily do the same for other grant types. The key point
here is that we move this sort of stuff into the messages in the protocol and
don't have it as a one-off for OIDC/SIOP.

> - application_type, client describing its nature e.g is it web or native
> again important around how the provider might enforce certain policies
> associated to the redirect uri used which can be critical to the security
> of the flow.

What is the security feature being sought here, and the attack model?

> I can go on

Please do, :) exhaustive list please.

We need every "wallet option" written down, with an understanding of who needs
it and by when, if we're going to get anywhere.

> but the point is all of the information captured during registration has a
> purpose in the protocol either to mitigate certain security threats OR
> promote interoperability between the client and provider. Just because
> CHAPI + VC API flow hasn't got to tackling this particular problem yet,
> around how these two parties will communicate certain things about each
> other, does not mean the end-state solution will be any different.

Alright, Mr. "We've considered something you haven't"... :P

CHAPI has had protocol hinting and object matching for almost a decade now
(though, we've hesitated to use it to introspect deeply into a presentation
request because the wallet is usually better at letting the user know the
specifics of why it can't complete a VPR):

https://w3c-ccg.github.io/credential-handler-api/#credentialhint-dictionary

We also have stuff in VPR; we already know the verifier might want to signal
which issuer's it accepts (see `trustedIssuer`):

https://w3c-ccg.github.io/vp-request-spec/#query-by-example

... but it was, and probably still is a bit premature to create a long list of
things we think the ecosystem is going to want. We're letting it become
ecosystem driven... when we see preventable interop failures, we can implement
things in the appropriate place at that point, but no sooner.

We have also discussed that making the conveyance of this information protocol
specific sounds like a mistake. Having OIDC do it one way and VPR do it
another way and DIDCommv2 do it in yet another way sounds fairly terrible. So,
I'd hope we can come together and define something that works across all
protocols before giving up and hard coding feature negotiation into each
protocol separately.

> For example here is a concrete case with CHAPI + VC API flows today where
> this issue manifests clearly, say I'm on a relying parties website that
> support validating VP's signed with an ECDSA signature and only did:key as
> the did method. But when the End-User clicks "login" or "authenticate with
> VCs", the End-Users selects a wallet via CHAPI that only supports EdDSA and
> did:ion. What is going to happen is a VP is going to be generated and sent
> back to the relying party, which the relying party is going to have no
> ability to rely upon due to their in-ability to resolve the did method use
> OR validate the signature on the VP.

Yes, that certainly is a problem!

Now, let's solve that problem for as many protocols as possible instead of
doing this in a piece-meal fashion!

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