Https client ids - security / scalability / interoperability

[jogu]

This is a description for an issue the Connect & DCP WG are liaising on and want to discuss at tomorrow's Connect WG call.

Background

OpenID Federation defines that Entity Identifiers are used as Client ID values when Automatic Registration is used. These are https URLs. There are other proposed specifications that also use https-based Client IDs. We need a way to clearly indicate which specification is in use.

OID4VP attempted to solve this (see openid/OpenID4VP#263) - it was hoped in a way that did not affect federation and would also be acceptable to OAuth WG.

Unfortunately the solution agreed there (of reserving https to always mean Federation) is not acceptable to the OAuth WG to go into an OAuth specification - it was unfortunately not known at the time that there are at least two specifications (Federation, W3C IndieAuth and/or OAuth Client ID Metadata Document) that use https client ids and define them in different ways with different security properties and both have significant production deployments. There is also currently nothing to stop further uses of https client ids being created - for example OID4VP at one point used https client ids to mean x509_san_uri, and I’m aware of at least one further proposal, and suspect there are more we’re unaware of.

Where we are now

Direction of movement at OAuth WG is that https:// client ids will not be reserved to mean only OpenID Federation as this would create a problem for the other ecosystems that also already use https client ids in production. A proposal for a way forward has been discussed at two IETF meetings: https://github.com/aaronpk/oauth-client-id-prefix - hope is that this draft can be updated to reflect a consensus of all 3 working groups (Connect, DCP, OAuth) on how to solve problem and will then be adopted by OAuth WG, potentially creating an IANA registry for Client ID prefixes that allows each specification (Federation, OID4VP, OAuth Client ID Metadata Document) to register an unambiguous prefix to indicate their trust establishment mechanism is in use - whilst also allowing a backwards compatibility option to use https to allow an easier path for existing production deployments.

The OAuth WG is (in my personal opinion) fairly likely to adopt & publish OAuth Client ID Metadata Document which would allow the use of https client ids for something other than Federation, due to the need to have a compatibility path for existing deployments.

A further change to OID4VP needs to be made before OID4VP goes to final imminently, but it is not yet agreed what that change would be. (The possible changes range from documenting the problems that arise from multiple specifications using unprefixed https client ids but stating it is for the OAuth WG to fully solve, through to fully solving it.)

Decision the Connect Working Group needs to make

Moving forward with https:// client ids being the only way to specify the use of federation causes two concrete issues:

1. There is no robust, simple way for ecosystems that use https urls to mean other trust mechanisms to later upgrade to Federation. (You could potentially design a bespoke solution for each situation, but doing so is likely to be less robust and potentially introduce new security issues / potential attacks, and some of the solutions would look exactly like the text in a revision OID4VP that was rejected for being overly fragile/complex or potentially resulting in authorization server’s become DoS attack amplifiers) This is more problematic in the situation in OID4VP where in most cases there is no metadata available to determine how the authorization server will interpret a request, as verifiers generally don’t know which wallet will respond to the request.

2. The ambiguity between the different mechanisms that use https is potentially a security issue in the Federation spec. For example, if a federation client receives an id_token with “aud”: “https://rp.example.com/” the client has no guarantee as to how the authorization server authenticated it. The authorization server could have used the lower security mechanism meaning the response is not to a request the client sent. (This doesn’t apply only to id tokens, many JWTs use only the client_id to indicate sender/receiver/intended subject. This wasn’t found by the formal security analysis of the Federation specification as the other specifications using https client ids were not in scope. [confirmed with the team at Stuttgart])

There seem to be solutions available that have simple low effort migration paths for existing ecosystems that have already deployed Federation, if/when those ecosystems want to move to align with federation ‘final’.

Does the Connect WG want to find a solution for this before OID4VP goes final? Or delay till before Federation goes Final? Or move to final despite these known issues and misalignment with OAuth WG? Do we want this problem to be solved consistently & interoperability or per specification / ecosystem?

[sakimura]

So, what was suggested in the call is to have the client prefix with openid_fedeation: to the entity identifier when it is using OpenID4VP. The receiver, knowing that it is interacting using OpenID4VP, also knows how to deal with the client_id with Client Identifier Prefix that is obtained from the VP request and the entity identifier/client_id obtained from the Federation spec.

That is like pushing the cognitive and implementation burden on the client and server implementer as @selfissued pointed out, but that could be a compromise point for the future implementations. The migration issues still need to be dealt with though.

Another point made that I remember now is:

• Dick expressed discomfort in sniffing what is supposed to be an opaque string to find the processing rule. That was my first reaction, too, and I am still a bit uncomfortable. However, that probably is a discussion to have at DCP WG and OAuth WG.

[jogu]

I should make clear that the observations on scalability and security I made above apply to the federation spec itself. Independently of what DCP decides to do with OID4VP, there is a need for the Connect WG to decide whether they will take any action about these issues.

Dick expressed discomfort in sniffing what is supposed to be an opaque string to find the processing rule. That was my first reaction, too, and I am still a bit uncomfortable. However, that probably is a discussion to have at DCP WG and OAuth WG.

Sniffing of the opaque string happens in federation already to roughly the same extent as far as I can see. It's not a problem that's new to DCP. And I personally believe it's fine because there's really no other viable option. (Adding extra parameters instead, as Dick suggested, "solves" it in the authorization request perhaps, but leaves problems as to what "aud" value you use in id_tokens, access tokens, etc, as you need to indicate the client type as well as the client id to have an unambiguous "aud". The cleanest way to do this is to prefix the client ids as that solves both issues without requiring anyone to start processing new jwt claims like perhaps "aud_client_id_type", or "aud_openid_federation".)

[peppelinux]

@jogu @sakimura I blieve that this issue should be moved to OpenID Federation Wallet Arch Draft, that is specifically born for wallet implementation using openid federation

[jogu]

I strongly disagree. I clearly framed this issue as a decision that the Connect WG needs to make about the federation specification. I did not mention wallets once above, and the references to OID4VP are only for context. Please move it back to the federation repository.

The questions I asked remain unanswered and are for the Connect WG to come to a decision on before federation goes final:

Does the Connect WG want to find a solution for this before OID4VP goes final? Or delay till before Federation goes Final? Or move to final despite these known issues and misalignment with OAuth WG? Do we want this problem to be solved consistently & interoperability or per specification / ecosystem?

[selfissued]

A lot has happened since this issue was filed, and much of it does not paint a pretty picture for interoperability across OAuth deployments. These things have happened:

• The DCP working group changed from the Client ID treatment in Change client_id_scheme to a prefix OpenID4VP#263, which was compatible with OpenID Federation, to that in make consistent the use of prefixes in the client_id prefixing OpenID4VP#401, which is incompatible. As I recorded at the time, to my knowledge, this is the first time that one OpenID working group knowingly introduced an incompatibility with a specification in another OpenID working group. And as I also put into the record at the time, I consider this a very unfortunate precedent, especially since the specifications are used together, but I realize that this is water under the bridge at this point.
• OpenID for Verifiable Presentations 1.0 became final with the incompatibility remaining in place.
• OAuth 2.0 Client ID Prefix proposed that OAuth use OpenID4VP-style Client ID prefixes.
• OAuth Client ID Metadata Document, by one of the same authors, proposed that OAuth not use OpenID4VP-style Client ID prefixes. This specification was adopted by the OAuth working group.
• OpenID Federation is about to be considered by the OpenID Connect working group for Final status.

Facts on the ground seem to indicate that there will be no common agreement between the OAuth working group and OpenID working groups on Client ID syntax. I also find this to be unfortunate, but it appears to be the case. Client ID syntax, in the general case, will be contextual for the foreseeable future.

On the bright side, OAuth Client ID Metadata Document's treatment of https Client IDs is not incompatible with OpenID Federation's use of them. They can both be used together by satisfying the requirements of both specifications, which do not appear to be in conflict.

The situation with OpenID4VP requires more work on the part of implementers and deployments, but is not insurmountable in practice. Deployments using OpenID Federation with OpenID4VP will have to add openid_federation: to the OpenID Federation Client IDs when talking to OpenID4VP services, to satisfy their requirements. This is doable.

The right place to fix the incompatibility with OpenID4VP is the OpenID Federation Wallet Architectures 1.0, which defines how to use OpenID Federation with wallet specifications, including OpenID4VP. The requirement to prefix the Client ID when interacting with OpenID4VP services can be normatively introduced there. This is by no means the only aspect of enabling interoperating between Federation and OpenID4VP defined in the Wallet specification, so it logically belongs there. (That's why I thought that @peppelinux's earlier decision to move this issue to https://github.com/openid/federation-wallet was the right one, but the same discussion can be had in either place.)

Finally, I'll state the obvious. Especially given that changing the Client ID syntax in OpenID Federation will not result in alignment with adopted OAuth specifications, no matter what we do, it would be irresponsible of us to change it at this late date. The Automatic Registration Client ID syntax has been stable since 2019. All the 14 implementations tested at the Federation Interop at SUNET use it, the OpenID Federation certification tests use it, as do many more implementations listed at https://openid.net/developers/openid-federation-implementations/. Breaking them all would not improve the world in any way.

I personally plan to create a PR at https://github.com/openid/federation-wallet describing how OpenID Federation deployments can work with OpenID4VP deployments. Once that is merged, I believe this issue should be closed, as I believe that's the best we can do under the circumstances.

[lj-raidiam]

The prefix was added to OpenID4VP as a compromise based on the fact that this was VP-protocol specific and didn't impact OAuth. I'm glad we achieved that compromise after these couple evening chats in April @jogu .

As you noted, @jogu , there are ecosystems that use HTTPS for client identification. Metadata resolution and trust establishment mechanisms are ecosystem-specific for this identifier scheme. The recent Client ID prefix draft proposes a way to make explicit what mechanism the client uses. It's valid to assume that going forward these ecosystems will keep using HTTPS, and that use of pure HTTPS scheme identifiers for client IDs will continue to be possible.

If we accept this reality, then IMO the question is how we address the issues you mentioned while also conveying information about supported and preferred mechanisms for pure HTTPS-scheme identifiers.

Including this information as a prefix in the Client ID is one option, but it comes with certain challenges. Fundamentally, an identifier is an identifier, and how you resolve metadata should not be part of the identifier itself. Even if we call it a "prefix," and it is not part of the true id, it's still inside the Client ID. Ideally, irrespective of how many resolution methods a client supports, it should remain a single client identified with a single id.

I'm not sure what a concrete change proposal would look like at the moment. Federation relies on URLs to identify entities of various types, and fundamentally this can't change so I am hoping that it is not it. Protocols that use Federation may assume this is one of the mechanisms, just as OpenID4VP did. Are you proposing changing a protocol part that is included in Federation to allow ecosystems to adjust the client registration process? Given the maturity stage of this specification, it's quite late for changes of this magnitude, and given that these are fairly early days still for client ID prefixes.

I also want to point out that this problem is not Client ID-specific. If you look at SD-JWT-VC, the same challenge exists for issuers. They are identified with pure HTTPS. Prefixes are not proposed there. HTTPS-scheme use is either defaulted to a mechanism defined inside the spec or, hopefully, allowed to be redefined by the ecosystem. I proposed to clarify further here: oauth-wg/oauth-sd-jwt-vc#377. I can imagine that a single issuer is going to support more than one mechanism and the verifier will have to know which one to use.

My proposal would be to accept existence of identification of both clients and issuers with pure HTTPS schemes and think about a universal discovery mechanism that would work for both issuer ids and client ids, allowing discovery of what mechanisms are supported. This would be in addition to addressing the challenges you mentioned, which are important for global interoperability and its security.

A potential harmonization of federation with client ID prefix may still happen when it is more mature, but given the above I would not see it to be part of the 1.0 federation release.