<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Inline<div><br><div><div>On 2013-07-29, at 9:07 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Brian,<div><br></div><div>inline: <br><div class="gmail_extra"><br><div class="gmail_quote">2013/7/29 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">IMHO, invalid_grant is the proper error response code, not invalid_client. <br></div></blockquote>
<div><br></div><div>I have thought a bit about that when I was writing it down. </div><div>invalid_grant is concerned about the token which has been previously issued. </div><div>invalid_client is concerned about the client authentication. </div>
<div>In the initial path, I had it as invalid_grant, then, I thought - well, it is the client </div><div>authentication that is failing when the client has provided invalid tcs. </div><div>The code is correct. It is the client authentication which is going wrong, is it not?</div>
<div> </div></div></div></div></div></blockquote><div>I think Brian wants it to be about token verification and not client authentication,   We don't want to conflate the two because they happen at points in the server process.</div><div>Client authentication happens at the start and that is keyed only to the client_id it may be done by a separate http basic module in the server.  </div><div>Code proof of possession is keyed to the code and the verification happens in the OAuth code where the client_id and redirect_uri etc are validated.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div dir="ltr"><br>Along the same lines, I'd like to see it named something more like "message correlation id" rather than anything involving client secret.<br>
</div></blockquote><div><br></div><div>The name "message correlation identifier" does not convey the nature of the parameter, which is the high entropy credential for the client. Just for the sake of the correlation, it does not have to have a high entropy. Thus, I have chosen the name. </div>
<div> </div></div></div></div></div></blockquote><div>It is a symmetric proof of possession key for the code.</div><br><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>

<br></div>This is a general OAuth problem and I believe the solution should be general too. Thus, at least the base definition of the parameter(s) should not require discovery or rely on any of the Connect documents.<br>
</div></blockquote><div><br></div><div>OAuth generally does not need discovery. However, this spec really needs it, at least in one form or another. </div><div>I have thought of making a new file but then that would amount to having the client hit those discovery endpoints twice. </div>
<div>I did not want the duplicate situation that resulted in the dynamic client registration. That's why I am referring OpenID Connect. </div><div>OpenID Connect originated the Discovery and Registration. On the hind site, even registration should have been referring OpenID Connect documents instead of duplicating. At least, that's how academic papers work :-)</div>
<div><br></div><div>Another idea is to have the metadata come back in the token response. </div><div>I actually prefer this. It increases the server traffic a bit, though. </div><div><br></div><div>The way it works is this. </div>
<div>Instead of doing the discovery and caching it at the client, the client finds the server capability from the token endpoint reference. For this, the server includes something like: </div><div><br></div><div>"meta": {</div>
<div>   "tcs_supported":true;</div><div>}</div><div><br></div><div>You guys know that I like this idea because then I would have a stub to put link relationship there as well. </div><div>Do you like the idea? If so, I can update the draft in this manner. </div>
<div>Well, perhaps I should anyways. </div><div><br></div><div>Thanks for pointing out. </div></div></div></div></div></blockquote><div><br></div>Telling the client that the server supports it in the response from the token endpoint is nice but the real client may never see this as a tab client may intercept it.</div><div>At that point if it is not supported then the token is stolen.</div><div><br></div><div>It is better if the client knows if the server supports it before it sends the request, so it can choose not to use insecure authorization servers.</div><div><br></div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Best, </div><div><br></div><div>Nat</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
</div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Sun, Jul 28, 2013 at 9:39 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>

</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">As some of you knows, passing the code securely to a native app on iOS platform is next to impossible. Malicious application may register the same custom scheme as the victim application and hope to obtain the code, whose success rate is rather high. <div>



<br></div><div>We have discussed about it during the OpenID Conenct Meeting at IETF 87 today, and I have captured the discussion in the form of I-D. It is pretty short and hopefully easy to read. </div><div><br></div><div>



You can find it at: </div><div><br></div><div><a href="https://bitbucket.org/Nat/drafts/src/" target="_blank">https://bitbucket.org/Nat/drafts/src/</a></div><div><br></div><div>Comments are welcome. </div><span><font color="#888888">


<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>
</font></span></div>
<br></div></div><div class="im">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></div></blockquote></div><br></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>
</div></div></div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>