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

Vladimir Dzhuvinov vladimir at connect2id.com
Sat Sep 22 18:11:15 UTC 2018


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-4.1.2.1

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>"?
Yes, that's how I also read the spec. The JWS alg restriction should
then also apply to client registration.

Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180922/36913445/attachment-0001.html>


More information about the Openid-specs-fapi mailing list