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