On May 26, 2010, at 7:44 AM, John Bradley wrote: > Hi Luke, > > The mandate for AB was to maintain compatibility with openID 2.0.
Understood ... although I see this as less important. By breaking compatibility we can gain greater simplification and thus adoption. > Allowing the existing openID libraries to avoid using POST redirects in > requests and responses to better support mobile devices. I agree that POST redirects are really annoying. OAuth 2.0 has eliminated them - it's up to the Authorization server to keep their responses under 2k. The place where URLs start getting really long is when you include other URLs inside them - as in many OpenID responses. With OpenID Connect the auth server could return just the name and profile pic if it wanted to, and provide a lot of utility without a ton of baggage in the URL. > The place where AB is diverging from the oAuth 2.0 flow is passing parameters > to the OP directly, or by reference rather than as scope elements, to remain > consistent with the existing openID 2.0 logic, and keep the redirect through > the browser small. > > The redirect response is also kept small with only a access token for the > protected resource that contains the openID response that would normally be > passed in a POST. This is possible/suggested in OpenID Connect as well. > The approaches are likely both oAuth 2.0 flows but with some small yet > significant differences, including consumer secrets, discovery and signing > once you start comparing AB with connect. However they are more similar > than different. > > John B. > > On 2010-05-26, at 10:17 AM, Luke Shepard wrote: > >> >> On May 25, 2010, at 7:45 PM, Nat Sakimura wrote: >> >>> Hi Allen, >>> >>> Thanks for your response. >>> >>> That is right, and as I have indicated in the OAuth list, >>> I was wishing the artifact flow to be included in the >>> OAuth 2.0 as well, as it improves the mobile support as well >>> as the security. >>> >>> For those of you who are not closely following as Allen, >>> the difference is that in Artifact Binding, instead of sending >>> all the parameters in the browser redirect, it only sends a URL >>> from which the OAuth Authorization server can obtain >>> all the parameters, including OpenID extension parameters. >>> >>> (David and Dick, can you just push this through? Or is there >>> something that I have to do?) >>> >> >> The great thing about OAuth 2.0 is that it allows for different Flows to >> obtain an access token. Why don't you write a flow in the OAuth 2.0 style >> for Artifact Binding? >> >>> Otherwise, it is almost the same: Another design decision I had to >>> do was whether I should put all the assertion into the OAuth access token, >>> or I should return the OpenID parameters along with OAuth access token. >>> "Connect" opted for the former, while "AB" opted for the later. >> >> What do you mean by this? OpenID Connect returns attribute parameters (like >> name, pic, etc) as extra parameters, not encapsulated within the opaque >> access token. >> >>> The reason for doing later from the AB stand point was that >>> the response could get pretty big because it has to return all the response >>> from various extensions and you probably would not like to >>> use such big string as an access token. >>> >>> I wanted to standardize on the standard attributes, but that was not the >>> scope of the Artifact Binding WG. Instead, it is the scope of AX1.1 WG. >>> >>> So, in essence, >>> >>> Connect = AB1.0+AX1.1 - "scope as URL that supports all the OpenID >>> extensions". >>> >>> The question is whether this "scope as URL that supports all the >>> OpenID extensions" >>> is too much to ask for "Connect". If not, then it would make much more sense >>> to position Connect as a "Social Network Profile" of OpenID >>> (Core)/AB1.0/AX1.1 >>> and call it "Connect" as a marketing name. (I put "Core" in parens as >>> in OpenID 2.0, >>> the "Core" and "POST/GET" binding are put together in single "Authn 2.0" >>> spec.) >>> >>> =nat >>> >>> On Wed, May 26, 2010 at 9:47 AM, Allen Tom <[email protected]> wrote: >>>> Hi Nat, >>>> >>>> I think the biggest difference with the Artifact Binding spec and the >>>> Connect proposal is that AB defines a new artifact flow that is not >>>> currently defined in OAuth2. >>>> >>>> In contrast, the Connect proposal uses the OAuth2 flows, and just defines >>>> additional data to be returned for the "openid" scope. >>>> >>>> OAuth2 implementers will probably find it easier to implement Connect >>>> (since >>>> it's a small addition to OAuth2) rather than the AB. >>>> >>>> Connect also standardizes on the default AX schema, which is nice to have. >>>> >>>> But yeah, AB and Connect are about 90% the same. >>>> >>>> Allen >>>> >>>> >>>> >>>> >>>> On 5/25/10 5:19 AM, "Nat Sakimura" <[email protected]> wrote: >>>> >>>>> >>>>> If that would be the course, I will give a full support to the connect, >>>>> though I might still want to ask "why duplicate with Artifact Binding?" >>>>> ;-) >>>>> It simply looks like a too much overlap. >>>> >>>> _______________________________________________ >>>> board mailing list >>>> [email protected] >>>> http://lists.openid.net/mailman/listinfo/openid-board >>>> >>> >>> >>> >>> -- >>> Nat Sakimura (=nat) >>> http://www.sakimura.org/en/ >>> http://twitter.com/_nat_en >>> _______________________________________________ >>> board mailing list >>> [email protected] >>> http://lists.openid.net/mailman/listinfo/openid-board >> >> _______________________________________________ >> board mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-board > > <smime.p7s><ATT00001..txt> _______________________________________________ board mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-board
