[Openid-specs-fapi] JARM: "query.jwt" for response types whose default response mode is "fragment"

Brian Campbell bcampbell at pingidentity.com
Wed Oct 10 12:27:45 UTC 2018


The intent behind the text "Note: "jwt.query" MUST NOT be used in
conjunction with response types that contain "token" or "id_token" unless
the response JWT is encrypted to prevent token leakage in the URL"  is to
avoid leaking an access or ID token in the query string of the redirect
URI.  So, based on that intent, returning an error response unencrypted
with "jwt.query" would be okay. And a client that asked for "jwt.query"
will be expecting the response to come back as a query parameter. So I'd
say that If an error occurred during building the JWT in the case  in
question, the error should be returned in the query part.



On Thu, Sep 27, 2018 at 9:44 PM Takahiko Kawasaki via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> Hello,
>
> 4.3.1. Response Mode "query.jwt"
> <https://openid.net/specs/openid-financial-api-jarm.html#response-mode-query.jwt>
> says as follows:
>
> *Note: "query.jwt" MUST NOT be used in conjunction with response types
> that contain "token" or "id_token" unless the response JWT is encrypted to
> prevent token leakage in the URL.*
>
>
> This implies that, if the JWT is encrypted, "query.jwt" can be used even
> if the default response mode of the response type is "fragment". This can
> happen, for example, when an authorization request includes
> "response_type=id_token&response_mode=query.jwt" and the
> "authorization_encrypted_response_alg" metadata of the client is set.
>
> If an error occurred during building the JWT in the case above, how should
> the error be reported? Should the response parameters ("error",
> "error_description", "error_uri", "state") be embedded in the query part or
> in the fragment part?
>
> IMHO, in this case, "fragment" should be chosen as the fallback response
> mode. The following is a pseudocode.
>
> // Special case. If the response mode is "query.jwt" although the
> // default response mode of the response type is "fragment", it
> // means that "query.jwt" was allowed on the assumption that the
> // JWT would be encrypted. This happens when the response_mode
> // request parameter of the authorization request is "query.jwt"
> // and the 'authorization_encrypted_response_alg' metadata of the
> // client is set.
> //
> // Because an authorization response JWT failed to be created and
> // so the response parameters won't be encrypted, the query part
> // should not be used. Therefore, in this case, "query.jwt" is
> // converted not to "query" but to "fragment".
> if (mResponseMode == ResponseMode.QUERY_JWT &&
>     mResponseType.requiresImplicitFlow())
> {
>     // Change "query.jwt" to "fragment".
>     mResponseMode = ResponseMode.FRAGMENT;
> }
> else
> {
>     // Change "{???}.jwt" to "{???}".
>     mResponseMode = mResponseMode.withoutJwt();
> }
>
>
> This is implementable (and actually I have implemented the logic), but I'm
> not sure all implementers will reach the same conclusion and I'm afraid
> this will harm interoperability.
>
> This complexity is introduced by the condition, *"unless the response JWT
> is encrypted"*. I think there are two options.
>
>
>    1. Remove the condition and state that "query.jwt" should not be used
>    when the default response mode of the response type is not "query" even if
>    the JWT is encrypted.
>    2. Keep the condition and describe in detail how the error case should
>    be handled.
>
>
> Do you have any thought?
>
>
> Best Regards,
> Takahiko Kawasaki
> Authlete, Inc.
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>

-- 
_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._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20181010/28a30db3/attachment.html>


More information about the Openid-specs-fapi mailing list