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
