<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">They added the redirect_uri checking to the token endpoint to make it safe for code (I suspect that many sites won't do it because they don't understand why it is required),  but i don't know what if any use cases there are for having a dynamic path on the redirect_uri and how the client would keep track of it to be able to send exactly that URI as the parameter to the token endpoint.<div><br></div><div>Perhaps Chuck or Justin will remember.</div><div><br></div><div>John </div><div>On 2012-05-17, at 5:46 PM, Nat Sakimura wrote:<div><br class="Apple-interchange-newline"><blockquote type="cite">So, the real question is, what kind of use cases do we really throw away if we require the urls to be registered. If my assumption that OAuth WG decided that there are such use cases was bogus, then I am OK with MUST. <div>
<br></div><div><br><br><div class="gmail_quote">On Fri, May 18, 2012 at 6:39 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">You don't need to register the query parameters.  <div><br></div><div>I am OK with SHOULD for the code flow, however for 'code token' it allows a 3rd party to get an access token for someone else.   </div>
<div><br></div><div>The attacker would then replay it with the code at the real RP.   With the removal of checking nonce in the id_token you now have a great attack.</div><div><br></div><div>To safely use 'code id_token' you need to check nonce or you are screwed as they say if the redirect_uri is unregistered.</div>
<div><br></div><div>The way that the code flow on it's own gets around it is by the check of the redirect_uri in the authorization request with the one sent in the token request the server is responsible for the check in that case.</div>
<div><br></div><div>I suppose we could have the client retrieve token and reject the id_token if code is invalid.  that however is a touch complicated.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div>
<span class="HOEnZb"><font color="#888888">John</font></span><div><div class="h5"><br><div><div>On 2012-05-17, at 5:13 PM, Nat Sakimura wrote:</div><br><blockquote type="cite">My understanding was that OAuth 2.0 allowed it to be SHOULD to accommodate some use cases such as dynamic return_to urls, etc. <br>
<br><div class="gmail_quote">On Fri, May 18, 2012 at 5:46 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">We are requiring registration,  under what circumstances would a client not know it's return_to?<div>

<br></div><div>It might be a custom scheme, but that should be known in advance.</div><span><font color="#888888"><div><br></div><div>John</div></font></span><div><div><div><br><div><div>On 2012-05-17, at 4:03 PM, Nat Sakimura wrote:</div>

<br><blockquote type="cite"><div bgcolor="#FFFFFF"><div>I think we should keep SHOULD here. </div><div>There are use cases that a MUST cannot be fulfilled. <br><br>=nat via iPhone</div><div><br>On 2012/05/18, at 4:57, Chuck Mortimore <<a href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>> wrote:<br>


<br></div><div><span></span></div><blockquote type="cite"><div><div>Agreed.    </div><div><br></div><div>It was basically pointing out that we were over ridding the OAuth language and turning SHOULD to MUST.    As a platform, we're ok with it, as we're on the MUST side of things.</div>


<div><br></div><div>-cmort</div><div><br></div><br><div><div>On May 17, 2012, at 12:51 PM, John Bradley wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">
We may have been a bit overzealous with the MUST.   It should be a MUST for implicit and a SHOULD for code.<div><br></div><div>From 10.6 of OAuth</div><div><br></div><div><span style="font-size:16px;font-family:Times"><pre style="font-size:1em;margin-top:0px;margin-bottom:0px"> The authorization server
   MUST require public clients and SHOULD require confidential clients
   to register their redirection URIs.  If a redirection URI is provided
   in the request, the authorization server MUST validate it against the
   registered value.</pre></span><div><br></div><div><br></div><div>I don't the think we are actually precluded from making the SHOULD a must for Connect.</div><div><br></div><div>John</div><div><br></div><div><div>On 2012-05-17, at 2:49 PM, Mike Jones wrote:</div>


<br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div lang="EN-US" link="blue" vlink="purple">


<div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">Hi Chuck,</span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">I was going through some of my mail working on closing the remaining issues to finish the OAuth Bearer RFC and I ran across this message, which I realized that I never responded to.</span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">Could you expand on “This violates OAuth”?  Is there a change you’d recommend in the Connect specs as a result?</span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">(The second point is now moot, as we decided to remove the Check ID Endpoint at the last in-person working group meeting.)</span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">                                                                Thanks,</span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)">                                                                -- Mike</span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,32,96)"> </span></div>


<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span>Chuck Mortimore [mailto:<a href="mailto:cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>]<span> </span><br>


<b>Sent:</b><span> </span>Friday, March 02, 2012 11:13 AM<br><b>To:</b><span> </span>Mike Jones<br><b>Subject:</b><span> </span>Additional issues/questions with Basic</span></div>
<div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> </div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">


2.2.1  redirect_uri:  A redirection URI where the response will be sent. This MUST be pre-registered with the provider.</div></div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">


 </div></div><blockquote style="margin-left:30pt;margin-right:0in"><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">This Violates OAuth</div>


</div></blockquote><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> </div></div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">


 </div></div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">2.3.1 CheckID: access_token:  REQUIRED. The ID Token obtained from an OpenID Connect Authorization Request.</div>


</div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> </div></div><blockquote style="margin-left:30pt;margin-right:0in">


<div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">Why is this the ID Token, but called access_token?</div></div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">


 </div></div><div><div style="margin-top:0in;margin-right:0in;margin-left:0in;margin-bottom:0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">Why would we use POST if it's in an AuthZ header?</div>

</div>
</blockquote></div>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net" style="color:blue;text-decoration:underline" target="_blank">Openid-specs-ab@lists.openid.net</a><br>


<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:blue;text-decoration:underline" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br></div></span></blockquote></div>

<br></div></div>
</blockquote></div><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Openid-specs-ab mailing list</span><br><span><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a></span><br>


<span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br></div></blockquote></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>

@_nat_en</div><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div><br>
</div>
</blockquote></div><br></div></body></html>