- changed status to open
Guidance around algorithm migration
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?
Comments (4)
-
-
- marked as enhancement
- changed milestone to Ammendment
Adding multi-valued algorithm registrations would require an enhancement to the specifications.
-
The things that the OP signs that are sent to the client like
id_token_signed_response_alg
anduserinfo_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 aroundnone
).The things that the client signs and are sent to the OP like
request_object_signing_alg
andtoken_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 userequest_object_signing_alg
but rather just has a non-standard client setting to require signed request objects and will accept any alg (other thannone
). It also doesn't usetoken_endpoint_auth_signing_alg
but rather is configured off oftoken_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.
-
Per #2158, I am creating a new specification that will enable RPs to express sets of client registration metadata parameters that they support.
- Log in to comment
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.