[Openid-specs-ab] Updated Core

[Nat Sakimura]

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.  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 <<cmortimore at salesforce.com>
> cmortimore at salesforce.com> wrote:
>
>>
>>
>> On Sun, May 1, 2011 at 2:32 PM, Nat Sakimura < <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://www.sakimura.org/en/
>>> <http://twitter.com/_nat_en>http://twitter.com/_nat_en
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>>  <Openid-specs-ab at lists.openid.net>Openid-specs-ab at lists.openid.net
>>>  <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>
>
> --
> Nat Sakimura (=nat)
> <http://www.sakimura.org/en/>http://www.sakimura.org/en/
> <http://twitter.com/_nat_en>http://twitter.com/_nat_en
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>


-- 
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/20110502/c5d7c66e/attachment.html>