<div dir="ltr">Dear Vladimir,<div><br></div><div>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.</div><div><br></div><div>If the specification explicitly said something like below, we would be able to expect higher interoperability.</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><i>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.</i></div></blockquote><div><br></div><div>Best Regards,</div><div>Takahiko Kawasaki</div><div>Authlete, Inc.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">2018年9月23日(日) 3:11 Vladimir Dzhuvinov via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net">openid-specs-fapi@lists.openid.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
On 22/09/18 06:42, Takahiko Kawasaki via Openid-specs-fapi wrote:<br>
<blockquote type="cite">
<pre>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.</pre>
</blockquote>
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 class="m_9219622310663909866moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6749#section-4.1.2.1" 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>
<ul>
<li>When we take the authZ request on its own, the default
response_mode is actually determined by the response_type
parameter.<br>
<br>
</li>
<li>Implementing the logic to detect a mismatch with registered
client metadata appears simpler to me than trying to get the
request right.<br>
<br>
</li>
<li>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>
</li>
</ul>
<p><br>
</p>
<blockquote type="cite">
<pre>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
<a class="m_9219622310663909866moz-txt-link-rfc2396E" href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md" target="_blank"><https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md></a>"?
</pre>
</blockquote>
Yes, that's how I also read the spec. The JWS alg restriction should
then also apply to client registration.<br>
<br>
Vladimir<br>
</div>
_______________________________________________<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>