<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Nat,<div><br></div><div>Not quite sure what you are getting at. </div><div><br></div><div>The two flows have quite different security. </div><div><br></div><div>In the code flow the RP knows that the access token is coming from the IdP, In the implicit flow it is taking the chance that the user is not cutting and pasting a different token.</div><div><br></div><div>In my opinion the implicit flow is good for when the Requester is the Java client itself, so the user has no reason to fake it.</div><div><br></div><div>If the Requester is the Web service then it should use the code flow to be certain there is no cutting and pasting going on.</div><div><br></div><div>The other issue is that in the implicit flow you are counting on JS security in the browser to keep the access token safe. (good luck with that)</div><div><br></div><div>The problem comes when Facebook and others want to simplify the client. They can more easily give a RP a JS to past in than get them to install a library. That is why implicit gets used where it probably shouldn't.</div><div><br></div><div>On the other hand leaving aside JS security it is probably no worse than the current openID 2.0 flow at LoA 1, at-least with an audience restricted ID_token and nonce to prevent replay.</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><div><div>On 2011-05-01, at 6:11 PM, Chuck Mortimore wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div><br></div><div>On May 1, 2011, at 5:24 PM, "Nat Sakimura" <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div>Thanks Chuck for quick response. </div><div><br></div>Implicit Grant can be drawn as: <a href="http://bit.ly/l5M90v"></a><a href="http://bit.ly/l5M90v">http://bit.ly/l5M90v</a><div><div><br></div><div>Making the use of Code would be: <a href="http://bit.ly/j8NmXs"></a><a href="http://bit.ly/j8NmXs">http://bit.ly/j8NmXs</a></div>
<div><br></div></div></div></blockquote><div><br></div><div>This wouldn't be allowed in oauth2 as it stands currently. Exchange of a authorization code grant happens backchannel over POST</div><div><br></div><div>-cmort</div><br><blockquote type="cite"><div><div><div>The security characteristics is not so much different, I think, and we have a unified flow. </div><div><br></div><div>=nat<br><br><div class="gmail_quote">On Mon, May 2, 2011 at 8:23 AM, Chuck Mortimore <span dir="ltr"><<a href="mailto:cmortimore@salesforce.com"></a><a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><br><div class="gmail_quote"><div><div></div><div class="h5">On Sun, May 1, 2011 at 2:32 PM, Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com" target="_blank"></a><a href="mailto:sakimura@gmail.com">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">
Hi. <div><br></div><div>I have just updated the core. </div><div><br></div><div>HTML: <a href="http://openid4.us/specs/ab/openid-connect-core-1_0.html" target="_blank"></a><a href="http://openid4.us/specs/ab/openid-connect-core-1_0.html">http://openid4.us/specs/ab/openid-connect-core-1_0.html</a></div>
<div>
<br></div><div>Main diff is that I have moved the "openid" structure from the access token response to UserInfo response. </div><div>The id_token response is still treated as extension. It should probably be incorporated in the core in the next rev. </div>
<div><br></div><div>One discussion point. When we are using JWS, "signed" actually contains everything in the original response. Is it not redundant to return both? Just returning "signed" as "access_token" should suffice?</div>
<div><br></div><div>One question: maybe better to send this to OAuth list but... why does not the user-agent flow use "code"? </div><div>If it does, the entire spec will be even more simple. </div><div>User-agent getting "access_token" directly instead of "code" and using that "access_token" repeatedly on the resource seem to be a small amount of optimization (one round-trip) with a lot of spec complication. </div>
</blockquote><div><br></div></div></div><div>It's for clients that can't secure secrets, and/or have difficulty making cross domain calls, such as javascript based clients.</div><div><br></div><div>-cmort</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 class="im">
<div><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank"></a><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank"></a><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>
<br></div>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"></a><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" target="_blank"></a><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/"></a><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en"></a><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div></div>
</div></blockquote></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>