Client cannot know what client authentication method a server has registered it for

[jogu]

As discussed under #12 there is now a mechanism that allows clients to state what options they support.

However there is no way (when using automatic registration at the authorization endpoint) for the client+server to reach agreement on which method will actually be used.

e.g. if the client supports both private_key_jwt and mtls, and the server also supports both, as client that has done automatic registration at the authorization endpoint has no idea if it should send private_key_jwt or mtls to the token endpoint.

Removing automatic registration from the authorization endpoint and hence mandating the use of the PAR endpoint would solve this, as the client would be authenticating to the PAR endpoint and hence the server could register the client with the client authentication method it uses to authenticate at the PAR endpoint. There may be other solutions.

[selfissued]

e.g. if the client supports both private_key_jwt and mtls, and the server also supports both, as client that has done automatic registration at the authorization endpoint has no idea if it should send private_key_jwt or mtls to the token endpoint.

In this example, it seems like things will work fine no matter which choice the client makes. Do you have a different example, @jogu, where this isn't the case?

[jogu]

I don't understand why it would work.

The server will generally pick a client authentication method at registration time, and in my example the server might select private_key_jwt or mtls.

The client then needs to authenticate at the token endpoint, and doesn't know how to authenticate. It has to pick one of private_key_jwt or mtls to send, with a 50% chance it picks the wrong one and fails.

[selfissued]

Part of the point of Automatic Registration is that the server doesn't needn't have a registration record for the client. The requests (and the Entity Statements referenced from them) contain all the information the server needs to process the request.

In this case, the client is choosing a client authentication method supported by the server. All of them, in the end are backed by the Client's keys in its metadata, whether it uses private_key_jwt or self_signed_tls_client_auth, for instance. So as long as they're supported by the server, it doesn't matter which one the client picks.

[jogu]

That is not my experience of how implementations work. The majority of servers assign a token_endpoint_auth_method at client registration time and I believe we already noted that this kind of "client can be registered to use more than one auth method" behaviour wouldn't be supported with explicit registration. Even resolving this at the time of automatic registration is going to be hard for some of the implementations I've seen suggested.

I've read the current federation draft https://openid.github.io/federation/main.html#name-automatic-registration and I've not been able to find language that suggests servers need to behave like this, the focus seems very much to be on resolving client metadata at the time of automatic registration. If I overlooked something please let me know!

I don't think I'd be in favour of adding extra complexity to the specification and implementations here when there's a good solution (mandating use of PAR for automatic registration) that instead removes complexity from the specification and implementations.

[peppelinux]

In the context of automatic client registration, there is no preassigned authentication method. Entities must be capable of discovering trust with one another, inspecting metadata, and identifying supported configurations. If the configuration lacks details on supported methods, entities should default to the profiles they inherently support.

As we know, OpenID Connect, and OAuth 2.0 in general, do not mandate the use of Pushed Authorization Requests (PAR).
Another implementation experience involves using OpenID Federation and PAR with digital wallets. Here, the federation is utilized by the wallet unit to discover trust and metadata about the credential issuer, and by the credential issuer to establish trust with the wallet provider. This is because the wallet provides attestations issued by wallet providers. Notably, the wallet does not provide its metadata to the credential issuer, as is possible in OpenID for Verifiable Presentations (OpenID4VP) using the client_metadata with a request URI POST. In fact, OpenID for Verifiable Credential Issuance (OpenID4VCI) specifies:

"If the Credential Issuer is unable to perform discovery of the Wallet's Credential Offer Endpoint, the following custom URL scheme is used: openid-credential-offer://."

While I support enabling the wallet to provide its metadata to the VCI (though this is beyond the scope of this issue), I want to emphasize that using a common implementation profile is recommended for interoperability. Additionally, due to the transparency of OpenID Federation's automatic client registration, all clients should be able to inspect the Authorization Server's capabilities through metadata discovery.

Considering existing implementations, I would encourage implementers to use their solutions without mandating PAR.

While about the sentence I've read the current federation draft https://openid.github.io/federation/main.html#name-automatic-registration and I've not been able to find language that suggests servers need to behave like this, the focus seems very much to be on resolving client metadata at the time of automatic registration I would keep this as task for resolution in the next PRs

[vdzhuvinov]

In federations that allow multiple client auth methods the RP can fix its preferred method in a Entity Configuration and use the trust_chain authZ request parameter to push that EC to the OP. In regular as well as pusher requests.

This will also work with the recently proposed self_trust_chain + peer_trust_chain parameters (iss #100).

[jogu]

In federations that allow multiple client auth methods the RP can fix its preferred method in a Entity Configuration

I thought it couldn't, and that's why #12 added a way for the client to specify multiple options.

I'm confused as to whether we agree there's a problem yet.

To try and restate the problem again:

If the client supports both private_key_jwt and mtls (and lists both of these in it's Entity Configuration), and the server also supports both (and lists both in it's Entity Configuration), a client that has done automatic registration at the authorization endpoint will, by some servers, be assigned either private_key_jwt or mtls as it's client authentication method, and the client has no idea if it should send private_key_jwt or mtls to the token endpoint.

If we're going to update the specification to make it clear that in this situation the AS has to allow the client to authenticate with either private_key_jwt or mtls in this case, then that technically works as a solution for the specification, but in practice taking that approach is likely to make adoption of federation harder for many people, so I don't think that would be a good approach.

In addition, as mentioned, mandating PAR would massively simplify the federation specification and make interop considerably easier. I don't think this option has been given serious consideration. PAR is a very simple standard with security and privacy benefits. We should consider what is best for federation in the long term and try to make the 'final' version of federation the best it can be. (I acknowledge that doing so will make it slightly harder for some people that have already implemented federation, but improving the specification as a result of feedback is exactly why we do implementer's drafts.)

[selfissued]

If both the RP and OP support multiple client authentication methods, for instance private_key_jwt and self_signed_tls_client_auth, then PAR isn't any different than the authorization endpoint with respect to the OP knowing what client authentication method the RP will use next. Whether PAR is used or not, the RP could use private_key_jwt for one request and then self_signed_tls_client_auth for a subsequent request, or vice versa.

Whether the RP should be switching methods may be the real question. I understand @jogu's point that some OPs might be thrown off by the switch, even though both methods are ultimately rooted in a signature using a private key corresponding to one of the RP's public keys. In my mind, if we're going to add language about supporting multiple client authentication methods, we should suggest not to switch once the RP has used one at an OP (if the RP is willing to maintain the necessary state to know which was used the last time).

Note that this was discussed on the 12-Dec-24 working group call. @MichaelFraser1999 also plans to add his thoughts.

[MichaelFraser1999]

I think @jogu does reveal a valid concern here. In the scenario where a given R.P. lists both private_key_jwt and tls_client_auth in it's token_endpoint_auth_methods_supported parameter (but lists no token_endpoint_auth_method parameter), where both options are also supported by the target O.P. in it's token_endpoint_auth_methods_supported under the openid_provider metadata. I think there are two scenarios:

• in the scenario where the target O.P. doesn't support the OpenID Connect Relying Party Metadata Choices 1.0 specification, the O.P. will fall back on the default option as there is no token_endpoint_auth_method specified. The R.P. won't be aware of this result and wouldn't be aware how the A.S. expects the client to subsequently interact

• in the scenario where the O.P. does support the OpenID Connect Relying Party Metadata Choices 1.0 specification, there seems to be ambiguity as to what the correct behavior is for the O.P. Is it allowed to adjust the values received as with DCR in 7591? If so, we're left with the scenario where the R.P. no-longer is aware what token endpoint authentication mechanisms are allowed for use within the scope of their client's registration. I suspect the O.P. is not intended to be permitted to change the metadata from the final intersection between the R.P. and O.P. metadata documents?

[MichaelFraser1999]

Having read PAR again much more closely, I also agree with @jogu 's suggestion to mandate PAR. This way, even if an RP and an OP both support multiple authentication options, the one actually used during the PAR flow would lock in which one the RP is going to use for the lifetime of the registration. This allows an RP to support both in an ecosystem with OPs may support one or more authentication mechanisms while still knowing for certain which one to use with a given OP

[vdzhuvinov]

Federations that have this concern can define a require_pushed_authorization_requests=true metadata policy.

Not all federations are going to face this issue. A hard PAR requirement will make it more difficult for existing OIDC deployments to support OpenID Federation 1.0.

[jogu]

Federations that have this concern can define a require_pushed_authorization_requests=true metadata policy.

We'd still need to add text to the specification to make it clear how ASes need to behave when PAR isn't used. It's a non-trivial amount of text but is very definitely necessary to do for interoperability purposes if we continue to allow non-PAR.

A hard PAR requirement will make it more difficult for existing OIDC deployments to support OpenID Federation 1.0.

I agree this is a consideration, but the specification is at implementors draft status - we can, and should, make hard decisions about simplifying the specification and the complexity of implementing the specification even if that makes a little bit more work for existing deployments to move over to 'final' (which they may or may not decide to do - ecosystems would be free to use the existing implementors draft, they don't have to move to final).

Mandating PAR removes a page or two from the specification, and avoids the need to add new complex text to talk about this issue, and solves some privacy issues. It's also a very straightforward specification to implement. That's a significant win in my opinion.

[vdzhuvinov]

@jogu On the 11th of December I had a long conversation with @Razumain who is implementing Federation for Sweden, for its next national trust infrastructure. I became sympathetic (and have been thinking recently a lot) about Stefan's strategy to roll out a national federation gradually, first as a directory service for easy metadata discovery, then with addition of TM and other services, and federated auto RP / OP transactions coming in at a later stage. Can existing IdPs continue using core OIDC with Federation - Stefan posed this question, in view of the extra request object in "auto" registration (designed to prove possession of the federation keys at auto registration time).

I believe we should make it possible and relatively easy for people to stick to Core OIDC in a federation (I don't want to think of the editorial issues for now :) ). Just like with explicit registration, which can be handled by a proxy / separate service on top of the std OIDC DCR endpoint - this requires only a stock OP implementation, I believe a similar proxy could be devised to handle auto registration (which would again rely on OIDC DCR, but with the ability to set the client_id instead of the OP assigning it).

Suppose we mandate PAR in the spec. We will solve this particular case, but it will put a barrier of sorts for people to adopt Federation. If I operate an OIDC IdP, ideally I would just need to install & configure an extra service / proxy and leave the existing OP as it is. I found that I haven't considered this aspect of adoption / transition enough, paths to retrofit Federation to existing OIDC and yes, even SAML deployments :)

This is the background behind my stand against mandating PAR.

[selfissued]

In my view, if we're going to simplify the spec by removing functionality, we should remove PAR and not the other way around. OpenID Connect Core uses the Authorization Endpoint but not PAR, and so support for the Authorization Endpoint can be expected in OpenID Connect implementations.

Also in my view, the premise of this issue, that there is a "registration" created for the RP at the OP cuts against the purpose of Automatic Registration as designed by @andreassolberg - that OPs can be stateless with respect to their RPs - not keeping any client state. This is possible because each time the RP uses the OP, its Entity Configuration retrieved via its client_id value freshly provides all the information the OP needs to interact with the RP. As originally envisioned, there is no client registration state with Automatic Registration.

Finally, I'll observe that a problem with PAR is that it is inherently stateful. The PAR response contains a URI to be used as a request_uri value, meaning that that URI must be maintained by the server until the URI is used. (Unless, perhaps, the URI is a data URI containing all the data needed inline, I suppose.)

That said, as you all know, I'm a practical person. If people believe it would address Joseph's concern, I'm fine adding a sentence along these lines, even though I'm not thrilled with the architectural assumptions behind it:

It is RECOMMENDED that RPs using Automatic Registration use the same method of authenticating the RP each time, so as to enable working with OPs that assume a single authentication method will be used by an RP during its interactions with the OP.