[OpenID board] Why Connect?

Wed May 26 14:57:55 UTC 2010

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 <atom at yahoo-inc.com> 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" <sakimura at gmail.com> 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
>>>> board at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-board
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>> http://twitter.com/_nat_en
>>> _______________________________________________
>>> board mailing list
>>> board at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-board
>> 
>> _______________________________________________
>> board mailing list
>> board at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-board
> 
> <smime.p7s><ATT00001..txt>