<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 22/09/18 06:42, Takahiko Kawasaki via Openid-specs-fapi wrote:<br>
    <blockquote type="cite"
cite="mid:CAHdPCmN5sFF1ab0ry9ZTZhjNcD6nMf+Ht1KncrnHL27zPPLOMg@mail.gmail.com">
      <pre wrap="">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="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6749#section-4.1.2.1">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"
cite="mid:CAHdPCmN5sFF1ab0ry9ZTZhjNcD6nMf+Ht1KncrnHL27zPPLOMg@mail.gmail.com">
      <pre wrap="">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="moz-txt-link-rfc2396E" href="https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md"><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>
  </body>
</html>