<div dir="ltr"><div dir="ltr"><div dir="ltr">Dear Brian,<div><br></div><div>It may sound reasonable, but, apart from JARM, the logic would require authorization servers respond like <font face="monospace, monospace">'<font color="#ff0000">?</font>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'</font> when an authorization request includes <font face="monospace, monospace">'response_type=id_token&response_mode=query'</font>. That is, the error message saying "Don't use the query part" itself uses the query part. Is it a consensus here?<br></div><div><br></div><div>The answer would vary depending on how to interpret the description in <a href="https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html">OAuth 2.0 Multiple Response Type Encoding Practices</a>:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div><div><a href="https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token">3. ID Token Response Type</a></div></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><div>id_token</div></div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><div>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. <b>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.</b></div></div></div></div></blockquote></blockquote><div dir="ltr"><div dir="ltr"><div><br></div><div><br></div><div>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.</div><div><br></div><div>One may think like:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div>The "Both" in <i>"Both successful and error responses"</i> 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.</div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><br></div><div>If asked to simplify the question, it would become like:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div dir="ltr"><div><i>Should an error message saying "query is not allowed" be embedded in the query part or in the default (fragment) part?</i></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><br></div><div>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"?</div><div><br></div><div>I'd like to know whether there exists a consensus or it is up to each implementation.</div><div><br></div><div>Best Regards,</div><div>Takahiko Kawasaki</div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-10-10 21:27 GMT+09:00 Brian Campbell <span dir="ltr"><<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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. <br></div><div dir="ltr"><br></div><div dir="ltr"><br></div></div></div></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Thu, Sep 27, 2018 at 9:44 PM Takahiko Kawasaki via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.<wbr>openid.net</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div dir="ltr">Hello,<div><br></div><div><div><a href="https://openid.net/specs/openid-financial-api-jarm.html#response-mode-query.jwt" target="_blank">4.3.1. Response Mode "query.jwt"</a> says as follows:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div><div><i>Note: "query.jwt" MUST NOT be used in conjunction with response types that contain "token" or "id_token" <b>unless the response JWT is encrypted</b> to prevent token leakage in the URL.</i></div></div></div></blockquote><div dir="ltr"><div><br></div><div>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&<wbr>response_mode=query.jwt" and the "authorization_encrypted_<wbr>response_alg" metadata of the client is set.</div><div><br></div><div>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?</div><div><br></div><div>IMHO, in this case, "fragment" should be chosen as the fallback response mode. The following is a pseudocode.</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// Special case. If the response mode is "query.jwt" although the</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// default response mode of the response type is "fragment", it</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// means that "query.jwt" was allowed on the assumption that the</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// JWT would be encrypted. This happens when the response_mode</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// request parameter of the authorization request is "query.jwt"</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// and the 'authorization_encrypted_<wbr>response_alg' metadata of the</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// client is set.</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">//</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// Because an authorization response JWT failed to be created and</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// so the response parameters won't be encrypted, the query part</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// should not be used. Therefore, in this case, "query.jwt" is</font></div></div><div><div><font face="monospace, monospace" size="1" color="#6aa84f">// converted not to "query" but to "fragment".</font></div></div><div><div><font face="monospace, monospace" size="1">if (<font color="#0000ff">mResponseMode</font> == ResponseMode.<font color="#0000ff">QUERY_JWT</font> &&</font></div></div><div><div><font face="monospace, monospace" size="1">    <font color="#0000ff">mResponseType</font>.<wbr>requiresImplicitFlow())</font></div></div><div><div><font face="monospace, monospace" size="1">{</font></div></div><div><div><font face="monospace, monospace" size="1">    <font color="#6aa84f">// Change "query.jwt" to "fragment".</font></font></div></div><div><div><font face="monospace, monospace" size="1">    <font color="#0000ff">mResponseMode</font> = ResponseMode.<font color="#0000ff">FRAGMENT</font>;</font></div></div><div><div><font face="monospace, monospace" size="1">}</font></div></div><div><div><font face="monospace, monospace" size="1">else</font></div></div><div><div><font face="monospace, monospace" size="1">{</font></div></div><div><div><font face="monospace, monospace" size="1">    <font color="#6aa84f">// Change "{???}.jwt" to "{???}".</font></font></div></div><div><div><font face="monospace, monospace" size="1">    <font color="#0000ff">mResponseMode</font> = <font color="#0000ff">mResponseMode</font>.withoutJwt();</font></div></div><div><div><font face="monospace, monospace" size="1">}</font></div></div></blockquote><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>This complexity is introduced by the condition, <i>"unless the response JWT is encrypted"</i>. I think there are two options.</div><div><br></div><div><ol><li>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.<br></li><li>Keep the condition and describe in detail how the error case should be handled.<br></li></ol></div><div><br></div><div>Do you have any thought?</div><div><br></div><div><br></div><div>Best Regards,</div><div>Takahiko Kawasaki</div><div>Authlete, Inc.</div><div><br></div></div></div></div></div>
______________________________<wbr>_________________<br>
Openid-specs-fapi mailing list<br>
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank">Openid-specs-fapi@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>fapi</a><br>
</blockquote></div>

<br>
<i style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:rgb(255,255,255);font-family:proxima-nova-zendesk,system-ui,-apple-system,system-ui,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;color:rgb(85,85,85)"><span style="margin:0px;padding:0px;border:0px;outline:0px;vertical-align:baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"><font size="2">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.</font></span></i></blockquote></div><br></div>