[Openid-specs-ab] Updated Core

[Chuck Mortimore]

On May 1, 2011, at 5:24 PM, "Nat Sakimura" <sakimura at gmail.com<mailto: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<mailto: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<mailto: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
<mailto:Openid-specs-ab at lists.openid.net>Openid-specs-ab at lists.openid.net<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110501/1b8628ef/attachment.html>