Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

[Brian Campbell <[e-mail]>]

"We're still dealing with ws-federation passive profile in saml dominated
world.  The oauth working group shouldn't repeat that sin."

Well said, Chuck, I couldn't agree more.

The world doesn't need two different OAuth-like SSO protocols and all the
confusion and interoperability problems that would come with it for years
to come. And that's what we will have, if a4c diverges from either OAuth or
Connect. And if it doesn't diverge, it'll just be a restatement of parts of
Connect in the IETF. I think that would be a waste of the valuable time of
this WG, which has other important work to do.


On Wed, May 14, 2014 at 6:31 PM, Chuck Mortimore
<[e-mail]>wrote:

> a4c is connect.    For example here's the sample requests:
>
> draft-hunt-oauth-v2-user-a4c-01, section 2.1:
>
>     GET /authenticate?
>     response_type=code
>     &client_id=s6BhdRkqt3
>     &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
>     &state=af0ifjsldkj
>     &prompt=login
>     Host: server.example.com
>
> OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section
> 2.1.2:
>
>   GET /authorize?
>     response_type=code
>     &client_id=s6BhdRkqt3
>     &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
>     &scope=openid%20profile
>     &state=af0ifjsldkj HTTP/1.1
>   Host: server.example.com
>
>
> The primary contribution of a4c in this case seems to be malformed HTTP,
> and implying that implementors should deploy a redundant authenticate
> endpoint.
>
> Sample Responses:
>
> draft-hunt-oauth-v2-user-a4c-01, section 2.4:
>
>
>      HTTP/1.1 200 OK
>        Content-Type: application/json;charset=UTF-8
>        Cache-Control: no-store
>        Pragma: no-cache
>        {
>          "access_token":"2YotnFZFEjr1zCsicMWpAA",
>          "token_type":"example",
>          "expires_in":3600,
>          "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>          "id_token":"eyJhbGciOiJub25lIn0.
>   eyAic3ViIjoiNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlmIiwicHJvZmlsZSI6Imh0
>   dHBzOi8vZXhhbXBsZS5jb20vVXNlcnMvNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlm
>   IiwiYXV0aF90aW1lIjoiMTM2Nzk1NjA5NiIsImV4cCI6IjEzNjgwNDI0OTYiLCJh
>   bHYiOiIyIiwiaWF0IjoiMTM2Nzk1NjA5OCIsImlzcyI6Imh0dHBzOi8vc2VydmVy
>   LmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4YW1wbGVfc2Vzc2lv
>   bl9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIn0=."
>        }
>
>
>
> OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section
> 2.1.6.2:
>
>
>    HTTP/1.1 200 OK
>    Content-Type: application/json
>    Cache-Control: no-store
>    Pragma: no-cache
>    {
>     "access_token":"SlAV32hkKG",
>     "token_type":"Bearer",
>     "expires_in":3600,
>     "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>     "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
>    }
>
>
>
> a4c seems to toss in a little confusion with an arbitrary example token
> type.
>
> We're still dealing with ws-federation passive profile in saml dominated
> world.  The oauth working group shouldn't repeat that sin.
>
> -cmort
>
>
> On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin <[e-mail]>wrote:
>
>>  There are folks that are not implementing connect for various reasons
>> (i.e. security reasons, complexity reasons, etc.). thus this is compatible
>> with connect if folks want to move on to connect,  we surely don’t use
>> connect everwhere as it’s over kill where we only need a the functionality
>> of a4c.
>>
>>
>>
>> *From:* Chuck Mortimore [mailto:[e-mail]]
>> *Sent:* Wednesday, May 14, 2014 9:39 AM
>> *To:* Anthony Nadalin
>> *Cc:* Phil Hunt; Brian Campbell; [e-mail]
>>
>> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
>>
>>
>>
>> Can you point to one publicly available or publicly documented
>> implementation of a4c?    I've never seen one.
>>
>>
>>
>> I will say the a4c spec is almost 100% overlapped with OpenID Connect.
>> Some minor variations in claim names, but it adds 0 incremental value over
>> what we have in Connect.
>>
>>
>>
>> Connect is being successfully deployed at large scale.  It would be
>> irresponsible for this working group to confuse developers and the industry
>> with duplicate work, especially given this feels more like an argument over
>> signing IPR agreements.
>>
>>
>>
>> -cmort
>>
>>
>>
>