<div dir="ltr">Oh... Do you guys think that it is ready to be sent to the OAuth list? <div><br></div><div>Nat</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/29 Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.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">The sentiment of the group seems to be that we are concerned with preimage resistance here and not the collision resistance. <div>
Brian, Dirk, and me is supporting simple hash in this view, IMHO. John is supporting salted hash siting the collision resistance importance. </div>
<div><br></div><div>As an editor, for the time being, keeping 2^128 search space is more important than restricting the possibility of collision. </div><div>So I have reverted the salted hash to hash. I am happy to re-introduce salted hash if more convincing argument is put forward. </div>

<div>(That's the beauty of version control system :-)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Nat</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/7/29 Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.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">OK. I will keep it as transient client secret hash, tcsh. </div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/7/29 Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>don't use "request token", please! I expect this to totally confuse people. Probably request secret or similar.</p>
<p>Am 29.07.2013 14:27, schrieb Nat Sakimura:</p><div><div>
<blockquote type="cite" style="padding-left:5px;border-left:#1010ff 2px solid;margin-left:5px;width:100%">
<div dir="ltr">Good catch. 
<div> </div>
<div>I am also thinking of change the name for client secret hash to request token, and parameter name from 'tcsh' to 'rt'. </div>
<div>Also, I am thinking of reverting salted hash to just a hash per the discussion with Dirk. </div>
<div> </div>
<div>What do you think? </div>
</div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">2013/7/29 Brian Campbell <span><<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>In general, those changes look good to me. Though 2nd paragraph of section 1 still says "this extension utilizes OpenID Server Configuration Document" which should probably be removed now.<br><br></div>
I am also unsure about needing to salt the hash.<br>
<div><br><br><br><br></div>
</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Jul 29, 2013 at 12:26 PM, Nat Sakimura <span><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Updated the draft. 
<div> </div>
<div>Changes: </div>
<div> </div>
<div>* Removed the discovery, and made the method to find out the server capability out-of-scope. </div>
<div>* Salted the hash. <<< Still not sure but for the time being. </div>
<div>* Fixed the working group and area</div>
<div> </div>
</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">2013/7/29 Brian Campbell <span><<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>
<div>
<div>
<div>I'm just trying to be realistic.<br><br></div>
The client can send the values regardless of if the sever supports this or not.<br><br></div>
If a client really cares enough and will not use the AS if this isn't supported, it can find out out of band. Or it's easy enough to test it out. <br><br></div>
Most clients are written to a particular AS so they'll know already.  Libraries are more general and they need to support it first.<br><br></div>
Connect (and eventually general OAuth) can put this in dico. But the basic functionality doesn't need to address that.</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Jul 29, 2013 at 9:45 AM, Nat Sakimura <span><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hmmm. Then, the client has lost its capability to find out whether the server is secure or not dynamically. 
<div>Do you mean that the client should find it out out-of-band? </div>
<div>That's possible, and is more OAuthy. </div>
<div> </div>
<div>So, instead of current 3.2, it can just state : </div>
<div> </div>
<div>The client MUST find out if the server supports this mode before issuing the authorizaiton request. The exact method of how it can be done is out of scope. </div>
<div> </div>
<div>Is that what you mean? </div>
<div> </div>
<div>Nat</div>
</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">2013/7/29 Brian Campbell <span><<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">Pretty much just removing 3.1 and 3.2 and 2.2 from your draft.</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Jul 29, 2013 at 9:36 AM, Nat Sakimura <span><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Yup. It is too late. The client needs to know whether the server is secure or not to start with. 
<div>
<div> </div>
<div>> <span style="font-family:arial,sans-serif;font-size:18px">I still think that a base definition of this shouldn't try and address discovering or publishing support for the functionality.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:18px"> </span></div>
</div>
<div><span style="font-family:arial,sans-serif;font-size:18px">Could you kindly propose a concrete method? A concrete text would be even better. </span></div>
</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">2013/7/29 Brian Campbell <span><<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>As John pointed out, putting metainfo about support into the token response is too late in the flow.<br><br></div>
I still think that a base definition of this shouldn't try and address discovering or publishing support for the functionality.</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Jul 29, 2013 at 9:28 AM, Nat Sakimura <span><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">OK. Fair enough. 
<div> </div>
<div>I will change it to the invalid_grant. </div>
<div> </div>
<div>What do you think about the idea for "meta"? </div>
</div>
<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">2013/7/29 Brian Campbell <span><<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">It's really not client authentication. It's something that links the initial authorization request with the corresponding access token request, which enables detecting a particular problem/attack. Similar to a mismatch on the redirect URI value between the authorization request and the corresponding access token request, it's the grant (or transaction) that is invalid.<br>



<div>
<div class="gmail_extra"><br>
<pre><a href="http://tools.ietf.org/html/rfc6749#section-5.2" target="_blank">http://tools.ietf.org/html/rfc6749#section-5.2</a><br><br>           invalid_grant
               The provided authorization grant (e.g., authorization
               code, resource owner credentials) or refresh token is
               invalid, expired, revoked, does not match the redirection
               URI used in the authorization request, or was issued to
               another client. <br><br></pre>
Discovery is maybe useful but is definitely not necessary. What is necessary is to define the parameter(s) and their treatment on the authorization request and access token request so that clients and servers can interop.  </div>



<div>
<div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Jul 29, 2013 at 9:07 AM, Nat Sakimura <span><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb;padding-left:1ex">
<div dir="ltr">Hi Brian,
<div> </div>
<div>inline: <br>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>2013/7/29 Brian Campbell <span><<a href="mailto:bcampbell@pingidentity.com" target="_blank">bcampbell@pingidentity.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb;padding-left:1ex">
<div dir="ltr">
<div>IMHO, invalid_grant is the proper error response code, not invalid_client. </div>
</div>
</blockquote>
<div> </div>
</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>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb;padding-left:1ex">
<div dir="ltr">
<div><br>Along the same lines, I'd like to see it named something more like "message correlation id" rather than anything involving client secret.</div>
</div>
</blockquote>
<div> </div>
</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>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb;padding-left:1ex">
<div dir="ltr">
<div> </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.</div>
</blockquote>
<div> </div>
</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> </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> </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> </div>
<div>"meta": {</div>
<div>   "tcs_supported":true;</div>
<div>}</div>
<div> </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> </div>
<div>Thanks for pointing out. </div>
<div> </div>
<div>Best, </div>
<div> </div>
<div>Nat</div>
<div>
<div> </div>
<div> </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb;padding-left:1ex">
<div dir="ltr"> </div>
<div class="gmail_extra"><br><br>
<div class="gmail_quote">
<div>
<div>On Sun, Jul 28, 2013 at 9:39 PM, Nat Sakimura <span><<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>></span> wrote:</div>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb;padding-left:1ex">
<div>
<div>
<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> </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> </div>
<div>You can find it at: </div>
<div> </div>
<div><a href="https://bitbucket.org/Nat/drafts/src/" target="_blank">https://bitbucket.org/Nat/drafts/src/</a></div>
<div> </div>
<div>Comments are welcome. </div>
<div>
<div> </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>
</div>
<div>_______________________________________________<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>
</div>
</blockquote>
</div>
</div>
<div><br><br clear="all">
<div> </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>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all">
<div> </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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all">
<div> </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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all">
<div> </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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all">
<div> </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>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br><br clear="all">
<div> </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>
<br>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<div> </div>
</div></div></div>
<br>_______________________________________________<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></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></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></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>