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

[Torsten Lodderstedt]

Hi Takahiko,

what you recommend was the default behavior before we introduced JARM and should stay the default behavior. JARM should be turned on via the respective response_mode parameter values only. I’m a bit reluctant to add an additional statement.

kinds regard,
Torsten. 

> Am 23.09.2018 um 05:45 schrieb Takahiko Kawasaki via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>:
> 
> 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 set.
> 
> 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-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
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3872 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180925/6c6b02c3/attachment.p7s>