[Openid-specs-fapi] JARM: Questions about authorization_signed_response_alg

Takahiko Kawasaki taka at authlete.com
Sun Sep 23 03:45:56 UTC 2018

Dear Vladimir,

Thank you for your comment. Now I agree that query.jwt and fragment.jwt
should not be chosen as the default value in the case of response_mode
omission regardless of what value the 'authorization_signed_response_alg'
metadata of the client holds.

If the specification explicitly said something like below, we would be able
to expect higher interoperability.

*When the 'response_mode' request parameter is omitted, 'query' is the
default value in the cases of 'response_type=code' and
'response_type=none', and 'fragment' is the default value for other
response types such as 'code id_token token' that include at least either
'token' or 'id_token'. 'query.jwt', 'fragment.jwt' and other values should
not be chosen as the default value in the case of response_mode omission
even if the 'authorization_signed_response_alg' metadata of the client is

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

2018年9月23日(日) 3:11 Vladimir Dzhuvinov via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net>:

> On 22/09/18 06:42, Takahiko Kawasaki via Openid-specs-fapi wrote:
> If an authorization request is made with response_type=code and without
> response_mode by a client whose authorization_signed_response_alg is not
> null (for example if it is RS256), should query.jwt be used as the default
> value? What I want to know is whether the value of
> authorization_signed_response_alg should affect the default value in the
> case of response_mode omission.
> IMO the AS should return an invalid_request error, to signal the client
> (developer) that the submitted request doesn't match the contract
> established by the registered metadata for the client.
> https://tools.ietf.org/html/rfc6749#section-
> I see three issues with the AS trying to fill in the missing response_mode
> parameter using registered client metadata:
>    - When we take the authZ request on its own, the default response_mode
>    is actually determined by the response_type parameter.
>    - Implementing the logic to detect a mismatch with registered client
>    metadata appears simpler to me than trying to get the request right.
>    - If developers start relying on the AS to fill in the response_mode
>    for them this may lead to interop and security issues down the road.
> If an authorization request is made for FAPI READ+WRITE APIs and if the
> value of authorization_signed_response_alg of the client is neither PS256
> or ES256, should the request be rejected as required by "8.6 JWS algorithm
> considerations" of "FAPI Part 2<https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md> <https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md>"?
> Yes, that's how I also read the spec. The JWS alg restriction should then
> also apply to client registration.
> Vladimir
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180923/ac8baae8/attachment.html>

More information about the Openid-specs-fapi mailing list