Guidance around algorithm migration

[Dave Tonge]

We discussed this briefly on the FAPI call yesterday. Currently the UK OpenBanking ecosystem is going through a migration from RS256 to PS256 algorithms for both the signing of ID Tokens and of Request Objects.

The current OpenID Connect Dynamic Client Registration spec defines the following Client metadata parameters:

• id_token_signed_response_alg
• request_object_signing_alg
• token_endpoint_auth_signing_alg
• userinfo_signed_response_alg

as single values. This is problematic when it comes to a smooth migration as it implies that an OP should only ever sign ID Tokens with a single algorithm for a particular Client and that the Client should only sign request objects with a single algorithm.

To enable smoother migration it would be better for OPs to be able to signal to Clients that there are two algorithms they may use to sign ID Tokens and the Client should be prepared to accept either signing algorithm. Likewise the Client should be able to signal to the OP that there are two signing algorithms that it may use to sign request objects and the OP should accept either. This would prevent a hard switchover which would be likely to result in some maintenance downtime.

Is it possible to add some guidance around this?

[Nat Sakimura]

So, OpenID Connect Core does not restrict it. For algorithm agility, a client should have not registered this optional parameter.

Perhaps we can add this in an errata, saying

This optional parameter is not recommended when algorithm agility is sought.

Note: Server metadata publishes an array for acceptable algorithms.

[Michael Jones]

Adding multi-valued algorithm registrations would require an enhancement to the specifications.

[Brian Campbell]

The things that the OP signs that are sent to the client like id_token_signed_response_alg and userinfo_signed_response_alg are indicative of a configuation setting for the given client at the OP (the setting could be dynareg or UI config or whatever but the metadata kinda implies that some such setting exists for a client at an OP). And the setting dictates what algorithm to use to sign the given thing for the given client. There's nothing that says that the client can only accept the indicated algorithm. And it's probably advisable for a client to accept more than one signing algorithm to facilitate seamless transitions in situations like this so an OP can start using a different algorithm for a client without an interruption in service or need to coordinate the timing of a config or code change. I guess that's easy to say in retrospect and in light of this issue but, FWIW, most of the software my employer produces works that way in accepting all the JWS algorithms (with exceptions around none).

The things that the client signs and are sent to the OP like request_object_signing_alg and token_endpoint_auth_signing_alg are trickier because they have language like "Request Objects from this from this Client MUST be rejected, if not signed with this algorithm." That makes changing algorithms more problematic without specific coordination and timing. For that reason (and others) our AS/OP software doesn't use request_object_signing_alg but rather just has a non-standard client setting to require signed request objects and will accept any alg (other than none). It also doesn't use token_endpoint_auth_signing_alg but rather is configured off of token_endpoint_auth_method and will take any alg.

Not sure how helpful that is or if any of that counts as "guidance". But I mentioned it on the Connect WG call this morning and was asked to comment here.