[Openid-specs-ab] Updated Core

[Nat Sakimura]

OK. I thought I read somebody saying in the OAuth list that apps are using
"code" flow, but I might have mixed it up with something else.

Why did you chose implicit grant for the native app, by the way?

=nat

On Mon, May 2, 2011 at 11:54 PM, Chuck Mortimore
<cmortimore at salesforce.com>wrote:

>
>
>
> On 5/1/11 6:49 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:
>
> Right, introducing 'code' makes the flow not "implicit". I am kind of
> bothered by the implicit flow because it makes the spec dirty. It causes
> several 'If, When', in the core.As I understand, the standard "code" flow
> can also be used by Javascript client. Most "thick" active clients seem to
> use the standard flow.
>
> Almost all of our native clients use the implicit flow.   We’ve shipped 6
> different ones ourselves, plus a number of ISVs are using it.
>
> -cmort
>
>
>  So, I am trying to understand the real reason that this is a valuable
> flow. It is probably best to bring this "merit" out in the user-agent
> binding.
>
> When I said that not much difference in security characteristics, I meant
> that introducing 'code' portion into the flow does not lower the security
> characteristics of implicit flow.
>
> =nat
>
> On Mon, May 2, 2011 at 10:27 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>
> Nat,
>
> Not quite sure what you are getting at.
>
> The two flows have quite different security.
>
> 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.
>
> 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.
>
> 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.
>
> 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)
>
> 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.
>
> 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.
>
> John B.
>
>
> On 2011-05-01, at 6:11 PM, Chuck Mortimore wrote:
>
>
> On May 1, 2011, at 5:24 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:
>
> Thanks Chuck for quick response.
>
> Implicit Grant can be drawn as:  <http://bit.ly/l5M90v>
> http://bit.ly/l5M90v
>
> Making the use of Code would be:  <http://bit.ly/j8NmXs>
> http://bit.ly/j8NmXs
>
>
> This wouldn't be allowed in oauth2 as it stands currently.  Exchange of a
> authorization code grant happens backchannel over POST
>
> -cmort
>
> The security characteristics is not so much different, I think, and we have
> a unified flow.
>
> =nat
>
> On Mon, May 2, 2011 at 8:23 AM, Chuck Mortimore < <
> mailto:cmortimore at salesforce.com <cmortimore at salesforce.com>>
> cmortimore at salesforce.com> wrote:
>
>
>
> On Sun, May 1, 2011 at 2:32 PM, Nat Sakimura < <mailto:sakimura at gmail.com<sakimura at gmail.com>>
> sakimura at gmail.com> wrote:
>
> Hi.
>
> I have just updated the core.
>
> HTML:  <http://openid4.us/specs/ab/openid-connect-core-1_0.html>
> http://openid4.us/specs/ab/openid-connect-core-1_0.html
>
>
> Main diff is that I have moved the "openid" structure from the access token
> response to UserInfo response.
> The id_token response is still treated as extension. It should probably be
> incorporated in the core in the next rev.
>
> 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?
>
> One question: maybe better to send this to OAuth list but... why does not
> the user-agent flow use "code"?
> If it does, the entire spec will be even more simple.
> 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.
>
>
> It's for clients that can't secure secrets, and/or have difficulty making
> cross domain calls, such as javascript based clients.
>
> -cmort
>
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110503/524d1803/attachment.html>