<p dir="ltr">For a native app we still want to use PKCE so retuning AT directly would be a bad idea unless you are certain the app is using a view controller and a claimed URI (that is a separate discussion on how to do that safely)</p>
<p dir="ltr">For a server based app it would be fine.  </p>
<p dir="ltr">I need to think about how token binding or Pop would work in that case, but for bearrer it is OK with exact redirect URI matching. </p>
<p dir="ltr">John B.  </p>
<div class="gmail_quote">On Apr 12, 2016 3:58 PM, "Hans Zandbelt" <<a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">from an implementers/deployment standpoint I would argue that if the id_token is delivered in the front channel, I may just as well get the access token from there too rather than having to deal with the overhead of calling the token endpoint, esp. since at_hash is there to protect integrity<br>
<br>
so I'd favor response_mode=form_post, response_type="id_token token" over hybrid<br>
<br>
I realize that this doesn't leverage the possibility of using a client secret to get the access token but it doesn't really seem to matter security-wise at this point as the id_token was delivered without leveraging it as well<br>
<br>
anything wrong with that line of reasoning?<br>
<br>
Hans.<br>
<br>
On 4/12/16 9:23 PM, William Denniss wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Good point.<br>
<br>
Regarding the OP tests, the following are relevant to mitigate the<br>
cut-and-paste and mix-up attacks:<br>
<br>
 1. ID Token has nonce when requested for code flow [Basic] (OP-nonce-code)<br>
 2. Request with response_mode=form_post [Extra] (OP-Response-form_post)<br>
<br>
1) is important for preventing cut-and-paste (the id token needs to<br>
contain the 'nonce')<br>
2) is important for preventing mix-up as it means the redirect endpoint<br>
gets the id_token on the response at the server, as opposed to in the<br>
URI fragment.<br>
<br>
Unfortunately, form_post is optional for OPs, and sending the nonce on<br>
the code flow is optional for RPs (though fortunately to it is<br>
compulsory for OPs to support thanks to OP-nonce-code).<br>
<br>
We could add an hardened OP test for:<br>
– Forcing nonce to be present on the code flow<br>
<br>
We should definitely have RP tests for:<br>
– sending and validating nonce on the code flow<br>
– validating the c_hash, iss, aud on the hybrid flow<br>
<br>
How we would profile these tests I'm not sure; would they go in the<br>
Basic testing profile, or in a new Hardened one?  We could move<br>
OP-Response-form_post to the Basic profile if we wanted to be<br>
opinionated, or define a new profile.<br>
<br>
The good news is that supporting the features required to mitigate<br>
mix-up & cut-and-paste is not all that hard to do in Connect.<br>
<br>
<br>
On Tue, Apr 12, 2016 at 10:46 AM, Nick Roy <<a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a><br>
<mailto:<a href="mailto:nroy@internet2.edu">nroy@internet2.edu</a>>> wrote:<br>
<br>
    Would it be possible to check for the secure behavior in Roland's<br>
    test suite and either not certify non-mitigating implementations, or<br>
    offer a risk mitigation add-on cert for those that do the right thing?<br>
<br>
    Nick<br>
<br>
    From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a><br>
    <mailto:<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>>> on behalf of<br>
    William Denniss <<a href="mailto:wdenniss@google.com">wdenniss@google.com</a> <mailto:<a href="mailto:wdenniss@google.com">wdenniss@google.com</a>>><br>
    Date: Tuesday, April 12, 2016 at 11:01 AM<br>
    To: "<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
    <mailto:<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>"<br>
    <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
    <mailto:<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>>><br>
    Subject: [Openid-specs-ab] Defining a Hardened (Mix-up and<br>
    Cut-and-Paste Proof) OpenID Connect Profile<br>
<br>
    One item that came out of the discussions on the sidelines of IETF95<br>
    with folk from this WG (specifically Nat, Mike, John, Brian and<br>
    myself) was the need for the Connect community to respond to the<br>
    recently <<a href="http://arxiv.org/abs/1508.04324v2/">http://arxiv.org/abs/1508.04324v2/</a>> documented<br>
    <<a href="http://arxiv.org/abs/1601.01229v2/">http://arxiv.org/abs/1601.01229v2/</a>> security threats.<br>
<br>
    Connect is actually in a much stronger place for mitigating these<br>
    attacks (as noted in the papers themselves) than pure OAuth, with<br>
    the id_token offering a cryptographic binding of the code to the<br>
    issuer, audience and session identifier (nonce).<br>
<br>
    However, certain steps need to be followed, for example using<br>
    'nonce' with the code flow (which is optional to implement for<br>
    clients) to protect against cut-and-paste, and using the form-post<br>
    response type with the hybrid flow to verify that the code was<br>
    issued by the expected IdP, to ensure the code is exchanged at the<br>
    correct token endpoint (mitigating mix-up).<br>
<br>
    We discussed last week creating a profile of Connect that recommends<br>
    those practices to mitigate these classes of attack as a response to<br>
    the security researchers' findings. I wanted to share that<br>
    suggestion with the list, and continue the conversation.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</blockquote>
<br>
-- <br>
Hans Zandbelt              | Sr. Technical Architect<br>
<a href="mailto:hzandbelt@pingidentity.com">hzandbelt@pingidentity.com</a> | Ping Identity<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>