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

Takahiko Kawasaki taka at authlete.com
Fri Sep 28 03:43:57 UTC 2018


4.3.1. 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 &&
    // Change "query.jwt" to "fragment".
    mResponseMode = ResponseMode.FRAGMENT;
    // 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180928/d632a16f/attachment.html>

More information about the Openid-specs-fapi mailing list