JARM: Default JWS alg for authorization_signed_response_alg needs reconsidering
It's nice to have a sensible default JWS alg (RS256) for JARM, however in the absence of another parameter to signal a client's intent to register for JARM, clients that don't want it will also end up getting registered for JARM.
My suggestion to register the client for regular authZ responses when the parameter is omitted.
Comments (16)
-
-
reporter @panva
Hi Filip,
Thanks for the clarification.
This behaviour - setting
"authorization_signed_response_alg":"RS256"
in the metadata when the client didn't register for the JARM extension, creates a precedent that may confuse developers. When we've had OAuth extensions in the past that introduce new client parameters, the default values are assumed to be not registered / value omitted. For instance, with mTLS:tls_client_certificate_bound_access_tokens OPTIONAL. Boolean value used to indicate the client's intention to use mutual TLS client certificate bound access tokens. If omitted, the default value is "false".
My thinking is that the returned metadata should include the minimal number of parameters to convey what's happening, and only set those extension parameters where the client explicitly signed up for. We have quite a number of reg parameters already.
This will also make it possible for an AS to enforce JARM on clients (if the AS chooses), but still require clients to set
response_mode
to get a JARM back. -
reporter To sum up, with a default value of not registered instead of
RS256
:- We stick with the existing convention
- Someone inspecting the client metadata can easily determine whether the client is indeed registered for JARM or not
- Allows an AS to potentially enforce JARM on registered clients
-
Allows an AS to potentially enforce JARM on registered clients
Having the property does not mean a client must start sending the response_mode. I wish this was possible but it's not with the existing language.
-
reporter Can you point to text in the spec that explicitly forbids that?
According to my reading of the spec we can do that ;)
-
I'm not big on making up AS policies that the client has no way of detecting based on simply following the specification. An as-is, a presence of jarm properties in the registration response does not indicate a client must be using jarm.
-
reporter Detection becomes possible if we drop the RS256 default for
authorization_signed_response_alg
and the default setting instead becomes no JARM.If the client registration response is an error or has metadata where
authorization_signed_response_alg
is set to RS256 or some other value, the client will know that the AS requires JARM.An as-is, a presence of jarm properties in the registration response does not indicate a client must be using jarm.
I'd like to expand on my second point, why this can be a problem. Client apps often get developed in a team, developers come and go, so someone new coming just by looking at the client reg metadata wouldn't immediately know if the client was indeed registered with the intent to receive JARM or not. Ideally, the entire client configuration will reside in the client metadata, and no other extra configuration will have to be kept. AS personnel looking at the metadata for a client also wouldn't be able to tell whether that client is signed up for JARM or not.
-
Yup, detection would become possible, but not implied enforcement for the client to understand it must only use jarm from that point on. That part would not be required given the existing language unless it changes. That's my whole point.
-
IMHO a default like that only means that
RS256
will be used in applying the signature when the requested response mode dictates it be signed and noauthorization_signed_response_alg
is explicitly provided/persisted for the given client. It does not mean setting"authorization_signed_response_alg":"RS256"
in the metadata when the client didn't register for it or omitted it. So one could potentially do some policy at the AS based on the presence of a value forauthorization_signed_response_alg
.If a metadata layer way to indicate that JARM has to be used is needed/desired, I think maybe something more general might be appropriate. Like a
response_modes
that (kinda similar toresponse_types
from RFC 7591) indicates what response modes the client can use. -
reporter Thanks for the clarification Brian. Is there a way to reword the metadata section along these lines?
The
reponse_modes
seems like a nice thing to enforce / lock down the response modes for the client, however, I think we'd better leave this. There may not much real need for that, and I'm also afraid it might cause break existing client reg specs / implementations. -
I think that if
response_modes
were introduced as an optional parameter with a default behavior for it when absent that matches current behavior, i.e. no response_mode restrictions applied to the client, it wouldn't break anything. But there maybe isn't real need for it. -
The current text in §5 is:
authorization_signed_response_alg
JWS RFC7515 alg algorithm JWA RFC7518 REQUIRED for signing authorization responses. If this is specified, the response will be signed using JWS and the configured algorithm. The algorithmnone
is not allowed. The default, if omitted, isRS256
.What about changing it to:
authorization_signed_response_alg
JWS RFC7515 alg algorithm JWA RFC7518 REQUIRED for signing authorization responses. If this is specified, the response will be signed using JWS and the configured algorithm. If unspecified, the default algorithm to use for signing authorization responses isRS256
. The algorithmnone
is not allowed.?
-
reporter Could not be worded better! Thanks Brian!
-
Well, I suspect that it probably could still be worded better. But thanks :) I'll call it okay enough. Pull request #85 has the proposed change.
-
- changed status to resolved
resolves Issue
#192by rewording authorization_signed_response_alg client metadata parameter to more clearly suggest that the default is applied when doing the signing and not that the default needs to be applied and persisted with client config or registration→ <<cset db541536df72>>
-
Merged in b_c/forking-fapi/i192 (pull request #85)
resolves Issue
#192by rewording authorization_signed_response_alg client metadata parameter to more clearly suggest that the default is applied when doing the signing and not that the default needs to be applied and persisted with client config or registApproved-by: Brian Campbell bcampbell@pingidentity.com Approved-by: Dave Tonge dave.tonge@bluespeckfinancial.co.uk
→ <<cset 9cb172bb29df>>
- Log in to comment
Hi Vladimir, a signed response is only sent in response to
response_mode
parameter being present, therefore having the default does not "register" a client to get JARM responses.