<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">The way I interpret things is that 'authorization_signed_response_alg' indicates the JWS alg to use to sign the response only when the response_mode of the request is 'query.jwt', 'fragment.jwt', 'form_post.jwt', or 'jwt'. Otherwise 'authorization_signed_response_alg' has no effect. I suppose it'd be reasonable for an AS to reject a request without one of those response_mode values when the client has a 'authorization_signed_response_alg' value, as I think Vladimir suggested. But that's more of a policy choice for the respective AS. I do strongly agree that JARM should be turned on via the respective response_mode parameter values only and authorization_signed_response_alg should not have any impact on the response mode that's used. <br><br><i></i></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 25, 2018 at 11:37 AM Torsten Lodderstedt via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Takahiko,<br>
<br>
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.<br>
<br>
kinds regard,<br>
Torsten. <br>
<br>
> Am 23.09.2018 um 05:45 schrieb Takahiko Kawasaki via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>:<br>
> <br>
> Dear Vladimir,<br>
> <br>
> 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.<br>
> <br>
> If the specification explicitly said something like below, we would be able to expect higher interoperability.<br>
> <br>
> 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.<br>
> <br>
> Best Regards,<br>
> Takahiko Kawasaki<br>
> Authlete, Inc.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> 2018年9月23日(日) 3:11 Vladimir Dzhuvinov via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>>:<br>
> On 22/09/18 06:42, Takahiko Kawasaki via Openid-specs-fapi wrote:<br>
>> If an authorization request is made with response_type=code and without<br>
>> response_mode by a client whose authorization_signed_response_alg is not<br>
>> null (for example if it is RS256), should query.jwt be used as the default<br>
>> value? What I want to know is whether the value of<br>
>> authorization_signed_response_alg should affect the default value in the<br>
>> case of response_mode omission.<br>
>> <br>
> 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.<br>
> <br>
> <a href="https://tools.ietf.org/html/rfc6749#section-4.1.2.1" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc6749#section-4.1.2.1</a><br>
> <br>
> I see three issues with the AS trying to fill in the missing response_mode parameter using registered client metadata:<br>
>       • When we take the authZ request on its own, the default response_mode is actually determined by the response_type parameter.<br>
> <br>
>       • Implementing the logic to detect a mismatch with registered client metadata appears simpler to me than trying to get the request right.<br>
> <br>
>       • 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.<br>
> <br>
>> If an authorization request is made for FAPI READ+WRITE APIs and if the<br>
>> value of authorization_signed_response_alg of the client is neither PS256<br>
>> or ES256, should the request be rejected as required by "8.6 JWS algorithm<br>
>> considerations" of "FAPI Part 2<br>
>> <br>
>> <<a href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md" rel="noreferrer" target="_blank">https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md</a>><br>
>> "?<br>
>> <br>
> Yes, that's how I also read the spec. The JWS alg restriction should then also apply to client registration.<br>
> <br>
> Vladimir<br>
> _______________________________________________<br>
> Openid-specs-fapi mailing list<br>
> <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
> _______________________________________________<br>
> Openid-specs-fapi mailing list<br>
> <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
<br>
_______________________________________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br>
</blockquote></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.</font></span></i>