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

Thu Oct 11 01:36:57 UTC 2018

Dear Filip, Brian,

Thank you for your comments. I now feel I should change my interpretation.
The error, "the query part must not be used", should be reported in the
query part. Likewise, the fallback corresponding to
"response_mode=query.jwt" should be "response_mode=query".

I did some experiments with a certain giant IdP to see how their
OpenID-certified implementation reports an error. The observed result is
that the IdP supports response_mode=form_post but ignores
response_mode=query. Their discovery JSON does not include
response_modes_supported. For every error case I tried except
"error=access_denied", the IdP returned "400 Bad Request + HTML" whenever
it detected an error condition (e.g. "Nonce required for response_type
id_token") even if valid redirect_uri, client_id, response_type and scope
were given. "error=access_denied" was reported in the fragment part even if
the authorization request included response_mode=query.

Best Regards,
Takahiko Kawasaki

2018-10-11 0:26 GMT+09:00 Filip Skokan <panva.ip at gmail.com>:

> Same as Brian said, I don't see an issue with returning errors about the
> response_mode being forbidden for a given response_type in the
> response_mode that's been requested (so long as it is a valid value), the
> client afterall expects the response that way.
>
> "query encoding MUST NOT be used" tells you to error the request, and
> "Both successful and error responses SHOULD be returned using the supplied
> Response Mode" tells you this error should be returned with the requested
> mode.
>
> Best,
> *Filip*
>
>
> On Wed, Oct 10, 2018 at 11:23 AM Takahiko Kawasaki via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
>> Dear Brian,
>>
>> It may sound reasonable, but, apart from JARM, the logic would require
>> authorization servers respond like '?error=invalid_request&error_
>> description=The+default+Response+Mode+for+this+
>> Response+Type+is+the+fragment+encoding+and+the+query+
>> encoding+MUST+NOT+be+used' when an authorization request includes
>> 'response_type=id_token&response_mode=query'. That is, the error message
>> saying "Don't use the query part" itself uses the query part. Is it a
>> consensus here?
>>
>> The answer would vary depending on how to interpret the description in OAuth
>> 2.0 Multiple Response Type Encoding Practices
>> <https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html>:
>>
>> 3. ID Token Response Type
>> <https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token>
>>
>>
>> id_token
>>
>> When supplied as the response_type parameter in an OAuth 2.0
>> Authorization Request, a successful response MUST include the parameter
>> id_token. The Authorization Server SHOULD NOT return an OAuth 2.0
>> Authorization Code, Access Token, or Access Token Type in a successful
>> response to the grant request. If a redirect_uri is supplied, the User
>> Agent SHOULD be redirected there after granting or denying access. The
>> request MAY include a state parameter, and if so, the Authorization Server
>> MUST echo its value as a response parameter when issuing either a
>> successful response or an error response. *The default Response Mode for
>> this Response Type is the fragment encoding and the query encoding MUST NOT
>> be used. Both successful and error responses SHOULD be returned using the
>> supplied Response Mode, or if none is supplied, using the default Response
>> Mode.*
>>
>>
>>
>> The spec says "the query encoding MUST NOT be used" for id_token. But
>> right after it, the spec says "Both successful and error responses SHOULD
>> be returned using the supplied Response Mode". If one believed "the
>> supplied Response Mode" can include "query" (although it must not be used),
>> the implementer would not hesitate to embed an error message in the query
>> part. On the other hand, if one believed "the supplied Response Mode" must
>> not include "query", the implementer would try to use the default response
>> mode.
>>
>> One may think like:
>>
>> The "Both" in *"Both successful and error responses"* implies the
>> "supplied Response Mode" is valid not only for error responses but also for
>> successful responses, so a response mode (here "query") which is not valid
>> for successful responses should not be used for error responses, either.
>>
>>
>> If asked to simplify the question, it would become like:
>>
>> *Should an error message saying "query is not allowed" be embedded in the
>> query part or in the default (fragment) part?*
>>
>>
>> If the query part is allowed for error reporting with the reason that the
>> error report will not include an ID token and an access token, why does
>> OAuth 2.0 Multiple Response Type Encoding Practices explicitly say "Both
>> successful and error responses"?
>>
>> I'd like to know whether there exists a consensus or it is up to each
>> implementation.
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>>
>> 2018-10-10 21:27 GMT+09:00 Brian Campbell <bcampbell at pingidentity.com>:
>>
>>> 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.*
>>
>>
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20181011/308c2987/attachment-0001.html>