JARM: Default JWS alg for authorization_signed_response_alg needs reconsidering

[Vladimir Dzhuvinov]

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.

[Filip Skokan]

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.

[Vladimir Dzhuvinov]

@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.

[Vladimir Dzhuvinov]

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

[Filip Skokan]

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.

[Vladimir Dzhuvinov]

Can you point to text in the spec that explicitly forbids that?

According to my reading of the spec we can do that ;)

[Filip Skokan]

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.

[Vladimir Dzhuvinov]

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.

[Filip Skokan]

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.

[Brian Campbell]

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 no authorization_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 for authorization_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 to response_types from RFC 7591) indicates what response modes the client can use.

[Vladimir Dzhuvinov]

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.

[Brian Campbell]

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.

[Brian Campbell]

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 algorithm none is not allowed. The default, if omitted, is RS256.

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 is RS256. The algorithm none is not allowed.

?

[Vladimir Dzhuvinov]

Could not be worded better! Thanks Brian!

[Brian Campbell]

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.

[Dave Tonge]

resolves Issue #192 by 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>>

[Dave Tonge]

Merged in b_c/forking-fapi/i192 (pull request #85)

resolves Issue #192 by 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 regist

Approved-by: Brian Campbell [e-mail] Approved-by: Dave Tonge [e-mail]

→ <<cset 9cb172bb29df>>