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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 May 2014 23:04:00 +0200

Hi all,

you might have seen that we pushed the assertion documents and the JWT
documents to the IESG today. We have also updated the milestones on the
OAuth WG page.

This means that we can plan to pick up new work in the group.
We have sent a request to Kathleen to change the milestone for the OAuth
security mechanisms to use the proof-of-possession terminology.

We also expect an updated version of the dynamic client registration
spec incorporating last call feedback within about 2 weeks.

We would like you to think about adding the following milestones to the
charter as part of the re-chartering effort:

-----

Nov 2014 Submit 'Token introspection' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-richer-oauth-introspection-04>

Jan 2015 Submit 'OAuth Authentication' to the IESG for consideration as
a Proposed Standard
Starting point: <draft-hunt-oauth-v2-user-a4c-01>

Jan 2015 Submit 'Token Exchange' to the IESG for consideration as a
Proposed Standard
Starting point: <draft-jones-oauth-token-exchange-00>

-----

We also updated the charter text to reflect the current situation. Here
is the proposed text:

-----

Charter for Working Group

The Web Authorization (OAuth) protocol allows a user to grant a
third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing Web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite encompasses

* a protocol for obtaining access tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these access tokens to resource server
for access to a protected resource,
* guidance for securely using OAuth 2.0,
* the ability to revoke access tokens,
* standardized format for security tokens encoded in a JSON format
  (JSON Web Token, JWT),
* ways of using assertions with OAuth, and
* a dynamic client registration protocol.

The working group also developed security schemes for presenting
authorization tokens to access a protected resource. This led to the
publication of the bearer token, as well as work that remains to be
completed on proof-of-possession and token exchange.

The ongoing standardization effort within the OAuth working group will
focus on enhancing interoperability and functionality of OAuth
deployments, such as a standard for a token introspection service and
standards for additional security of OAuth requests.

-----

Feedback appreciated.

Ciao
Hannes & Derek

---

From: Brian Campbell <[email-masked]>
Date: Wed, 14 May 2014 06:24:32 -0600

I would object to 'OAuth Authentication' being picked up by the WG as a
work item. The starting point draft has expired and it hasn't really been
discusses since Berlin nearly a year ago.  As I recall, there was only very
limited interest in it even then. I also don't believe it fits well with
the WG charter.

I would suggest the WG consider picking up 'OAuth Symmetric Proof of
Possession for Code Extension' for which there is an excellent starting
point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a
relativity simple security enhancement which addresses problems currently
being encountered in deployments of native clients.

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <[email-masked]
> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
    <https://www.pingidentity.com/>
Brian Campbell
Portfolio Architect
  @ [email-masked]   +1 720.317.2061  Connect
with us…   <https://twitter.com/pingidentity> [image:
youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
logo] <https://www.facebook.com/pingidentitypage> [image: Google+
logo]<https://plus.google.com/u/0/114266977739397708540> [image:
slideshare logo] <http://www.slideshare.net/PingIdentity> [image: flipboard
logo] <http://flip.it/vjBF7> [image: rss feed
icon]<https://www.pingidentity.com/blogs/>
   [image: Register for Cloud Identity Summit 2014 | Modern Identity
Revolution | 19–23 July, 2014 | Monterey,
CA]<https://www.cloudidentitysummit.com/>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 08:31:49 -0700

On the contrary. I and others are interested. 

We are waiting for the charter to pick up the work. 

Regardless there will be a new draft shortly. 

Phil

> On May 14, 2014, at 5:24, Brian Campbell <[email-masked]> wrote:
> 
> I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.
> 
> I would suggest the WG consider picking up 'OAuth Symmetric Proof of Possession for Code Extension' for which there is an excellent starting point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients.  
> 
> 
> 
> 
>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <[email-masked]> wrote:
>> Hi all,
>> 
> @	[email-masked]
> 	+1 720.317.2061
> Connect with us…
>        
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 14 May 2014 11:38:42 -0400

I agree with Brian and object to the Authentication work item. I think there’s limited interest and utility in such a draft, especially now that OpenID Connect has been published and its core authentication capabilities are identical to what was called for in the other draft a year ago (a similarity, I’ll add, which was noted at the time). 

 — Justin

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 14 May 2014 08:41:45 -0700

Agree with Brian and Justin here.   Work is already covered in Connect

- cmort

On May 14, 2014, at 8:39 AM, Justin Richer <[email-masked]> wrote:

I agree with Brian and object to the Authentication work item. I think
there’s limited interest and utility in such a draft, especially now that
OpenID Connect has been published and its core authentication capabilities
are identical to what was called for in the other draft a year ago (a
similarity, I’ll add, which was noted at the time).

 — Justin

On May 14, 2014, at 8:24 AM, Brian Campbell <[email-masked]>
wrote:

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 14 May 2014 15:47:17 +0000

I agree with Phil on this one, there are implementations of this already and much interest

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Phil

On May 14, 2014, at 5:24, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
[Ping Identity logo]<https://www.pingidentity.com/>

Brian Campbell
Portfolio Architect
@

[email-masked]<mailto:[email-masked]>

[phone]

+1 720.317.2061

Connect with us…

[twitter logo]<https://twitter.com/pingidentity>[youtube logo]<https://www.youtube.com/user/PingIdentityTV>[LinkedIn logo]<https://www.linkedin.com/company/21870>[Facebook logo]<https://www.facebook.com/pingidentitypage>[Google+ logo]<https://plus.google.com/u/0/114266977739397708540>[slideshare logo]<http://www.slideshare.net/PingIdentity>[flipboard logo]<http://flip.it/vjBF7>[rss feed icon]<https://www.pingidentity.com/blogs/>

[Register for Cloud Identity Summit 2014 | Modern Identity Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Wed, 14 May 2014 09:03:03 -0700 (PDT)

I think there's a use case for this work that may or may not be covered by the PoP spec, and in fact I think this work is related to that.  The MAC token work is really one use case of POP tokens.  Rather than shouting it down let's figure out how to solve this use case.

On Wednesday, May 14, 2014 8:39 AM, Justin Richer <[email-masked]> wrote:

 — Justin

I would suggest the WG consider picking up 'OAuth Symmetric Proof of
 Possession for Code Extension' for which there is an excellent starting
 point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a relativity simple security enhancement which addresses problems currently being encountered in deployments of native clients.  

Hi all,

-- 

 Brian Campbell
Portfolio Architect

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 14 May 2014 09:39:00 -0700

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

On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <[email-masked]>wrote:

> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, May 14, 2014 8:32 AM
> *To:* Brian Campbell
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
>
>
>
> *Brian Campbell*
> *@*
> [email-masked]
>
>
> +1 720.317.2061
>
> Connect with us…
>
>  <https://twitter.com/pingidentity>[image: youtube
> logo] <https://www.youtube.com/user/PingIdentityTV><https://www.linkedin.com/company/21870>[image:
> Facebook logo] <https://www.facebook.com/pingidentitypage>[image: Google+
> logo] <https://plus.google.com/u/0/114266977739397708540>[image:
> slideshare logo] <http://www.slideshare.net/PingIdentity>[image:
> flipboard logo] <http://flip.it/vjBF7><https://www.pingidentity.com/blogs/>
>
> Revolution | 19–23 July, 2014 | Monterey, CA]<https://www.cloudidentitysummit.com/>
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 09:55:37 -0700

For the record, we adjusted draft 01 to make it more compatible with OIDC at the request of the Connect community.  I agreed to change it because I can agree that it is a good stepping stone for adoption of Connect. Others may prefer to have a cleanly separate method. I leave that for the group to decide.

The IETF needs a draft that enables and provides user authentication information to clients. 

Phil

@independentid
www.independentid.com
[email-masked]

On May 14, 2014, at 9:39 AM, Chuck Mortimore <[email-masked]> wrote:

> 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
> 
> 
> On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <[email-masked]> wrote:

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 14 May 2014 10:10:40 -0700

> The IETF needs a draft that enables and provides user authentication

Why?

-cmort

>> point of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's
>> a relativity simple security enhancement which addresses problems currently
>> Facebook logo] <https://www.facebook.com/pingidentitypage>[image:
>> Google+ logo] <https://plus.google.com/u/0/114266977739397708540>[image:

---

From: George Fletcher <[email-masked]>
Date: Wed, 14 May 2014 13:23:00 -0400

I also would like to see the WG not focus on another authentication 
mechanism and instead look at work like Brian suggested.

Thanks,
George

On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
> On May 14, 2014, at 8:39 AM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I agree with Brian and object to the Authentication work item. I 
>> think there’s limited interest and utility in such a draft, 
>> especially now that OpenID Connect has been published and its core 
>> authentication capabilities are identical to what was called for in 
>> the other draft a year ago (a similarity, I’ll add, which was noted 
>> at the time).
>>
>>  — Justin
>>
>> On May 14, 2014, at 8:24 AM, Brian Campbell 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> I would object to 'OAuth Authentication' being picked up by the WG 
>>> as a work item. The starting point draft has expired and it hasn't 
>>> really been discusses since Berlin nearly a year ago.  As I recall, 
>>> there was only very limited interest in it even then. I also don't 
>>> believe it fits well with the WG charter.
>>>
>>> Possession for Code Extension' for which there is an excellent 
>>> starting point of 
>>> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a 
>>> relativity simple security enhancement which addresses problems 
>>> currently being encountered in deployments of native clients.
>>>
>>>
>>>
>>>
>>> On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     Hi all,
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>> Ping Identity logo <https://www.pingidentity.com/> 	
>>> Brian Campbell
>>> Portfolio Architect
>>> @ 	[email-masked] <mailto:[email-masked]>
>>> phone 	+1 720.317.2061
>>> Connect with us…
>>> twitter logo <https://twitter.com/pingidentity> youtube logo 
>>> <https://www.youtube.com/user/PingIdentityTV> LinkedIn logo 
>>> <https://www.linkedin.com/company/21870> Facebook logo 
>>> <https://www.facebook.com/pingidentitypage> Google+ logo 
>>> <https://plus.google.com/u/0/114266977739397708540> slideshare logo 
>>> <http://www.slideshare.net/PingIdentity> flipboard logo 
>>> <http://flip.it/vjBF7> rss feed icon 
>>> <https://www.pingidentity.com/blogs/>
>>>
>>> Register for Cloud Identity Summit 2014 | Modern Identity Revolution 
>>> | 19–23 July, 2014 | Monterey, CA 
>>> <https://www.cloudidentitysummit.com/>
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

-- 
George Fletcher <http://connect.me/gffletch>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 10:29:58 -0700

This is not an authentication mechanism - it is a method for providing end-user authentication information to client applications.  I will publish a revised draft shortly. 

Phil

@independentid
www.independentid.com
[email-masked]

On May 14, 2014, at 10:23 AM, George Fletcher <[email-masked]> wrote:

> I also would like to see the WG not focus on another authentication mechanism and instead look at work like Brian suggested.
> 
> Thanks,
> George
> 
> <XeC.html>

---

From: Anil Saldhana <[email-masked]>
Date: Wed, 14 May 2014 12:33:46 -0500

Tony/Phil,
   any chance you can have this work done at OIDC?

The reason is that it is commonly understood/accepted now that OAuth 
provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).

Regards,
Anil

On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> On May 14, 2014, at 5:24, Brian Campbell <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     really been discusses since Berlin nearly a year ago.  As I
>     recall, there was only very limited interest in it even then. I
>     also don't believe it fits well with the WG charter.
>
>     I would suggest the WG consider picking up 'OAuth Symmetric Proof
>     of Possession for Code Extension' for which there is an excellent
>     starting point of
>     [email-masked] <mailto:[email-masked]>
>
>     phone
>
>     	
>
>     +1 720.317.2061
>
>     Connect with us...
>
>     twitter logo <https://twitter.com/pingidentity>youtube logo
>     <https://www.youtube.com/user/PingIdentityTV>LinkedIn logo
>     <https://www.linkedin.com/company/21870>Facebook logo
>     <https://www.facebook.com/pingidentitypage>Google+ logo
>     <https://plus.google.com/u/0/114266977739397708540>slideshare logo
>     <http://www.slideshare.net/PingIdentity>flipboard logo
>     <http://flip.it/vjBF7>rss feed icon
>     Register for Cloud Identity Summit 2014 | Modern Identity
>     Revolution | 19--23 July, 2014 | Monterey, CA

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 14 May 2014 10:44:53 -0700

Would still love to hear you answer _why_ "the IETF needs a draft that
enables and provides user authentication information to clients."

Would still love to see Tony point to the existing a4c implementations.

On Wed, May 14, 2014 at 10:29 AM, Phil Hunt <[email-masked]> wrote:

> This is not an authentication mechanism - it is a method for providing
> end-user authentication information to client applications.  I will publish
> a revised draft shortly.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
> logo] <https://www.facebook.com/pingidentitypage> <https://plus.google.com/u/0/114266977739397708540> [image:
> slideshare logo] <http://www.slideshare.net/PingIdentity> [image:
> flipboard logo] <http://flip.it/vjBF7> <https://www.pingidentity.com/blogs/>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> <XeC.html> <http://connect.me/gffletch>

---

From: Paul Madsen <[email-masked]>
Date: Wed, 14 May 2014 13:48:24 -0400

Phil, neither is Connect an authentication mechanism, it (and SAML, 
WS-fed etc) is also a 'method for providing end-user authentication 
information to client applications'

We don't need a Connect--

paul
On 5/14/14, 1:29 PM, Phil Hunt wrote:
> end-user authentication information to client applications.  I will 
> publish a revised draft shortly.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
> On May 14, 2014, at 10:23 AM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>>> think there's limited interest and utility in such a draft, 
>>>> the other draft a year ago (a similarity, I'll add, which was noted 
>>>> at the time).
>>>>
>>>>  --- Justin
>>>>
>>>>> <https://plus.google.com/u/0/114266977739397708540> slideshare 
>>>>> logo <http://www.slideshare.net/PingIdentity> flipboard logo

---

From: John Bradley <[email-masked]>
Date: Wed, 14 May 2014 19:59:14 +0200

I know a number of people implementing

> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03

Having it on a RFC track may make sense. 

I remain to be convinced that a4c ads anything other than confusion. 

If the WG wants to take it up it should be aligned with Connect.  I think there are more important things to spend time on. 

Sent from my iPhone

> On May 14, 2014, at 2:24 PM, Brian Campbell <[email-masked]> wrote:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 14 May 2014 21:16:41 +0000

Please list the implementstions

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Sent from my iPhone

On May 14, 2014, at 2:24 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
I would object to 'OAuth Authentication' being picked up by the WG as a work item. The starting point draft has expired and it hasn't really been discusses since Berlin nearly a year ago.  As I recall, there was only very limited interest in it even then. I also don't believe it fits well with the WG charter.

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

Brian Campbell
Portfolio Architect
@

[phone]

+1 720.317.2061

Connect with us…

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 14 May 2014 21:40:29 +0000

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:[email-masked]]
Sent: Wednesday, May 14, 2014 9:39 AM
To: Anthony Nadalin
Cc: Phil Hunt; Brian Campbell; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

-cmort

On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Phil on this one, there are implementations of this already and much interest

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Phil

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

Brian Campbell
Portfolio Architect
@

[phone]

+1 720.317.2061<tel:%2B1%20720.317.2061>

Connect with us…

---

From: John Bradley <[email-masked]>
Date: Thu, 15 May 2014 00:04:32 +0200

I have been told that DT has a implementation and I know Google is using it for the apps they publish on iOS and perhaps other places, though they may use pre Draft parameter names currently.

There are some others I have talked to, but I will need to get there permission to disclose there names.

John B.
On May 14, 2014, at 11:59 PM, Brian Campbell <[email-masked]> wrote:

> I did an implementation of http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 last week. We are seeing growing demand for some kind of solution to the code callback interception attack. The industry needs a well documented standard solution.
> 
> 
> On Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin <[email-masked]> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Wed, 14 May 2014 15:59:20 -0600

I did an implementation of
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 last week. We are
seeing growing demand for some kind of solution to the code callback
interception attack. The industry needs a well documented standard solution.

On Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin <[email-masked]>wrote:

> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Wednesday, May 14, 2014 10:59 AM
>
> *To:* Brian Campbell
> *Cc:* [email-masked]
> If the WG wants to take it up it should be aligned with Connect.  I think
> there are more important things to spend time on.
>
>
>
>
> Sent from my iPhone
>
>

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 14 May 2014 17:31:45 -0700

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 <[email-masked]>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:[email-masked]]
> *Sent:* Wednesday, May 14, 2014 9:39 AM
> *To:* Anthony Nadalin
> *Cc:* Phil Hunt; Brian Campbell; [email-masked]
>

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 14 May 2014 17:37:37 -0700

Anil,

the challenge is that OIDC is a rather large set of specifications, and 
to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about 
boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few 
arbitrarily selected features from OIDC is not the same as implementing 
OIDC.

As we all know, the core problem is that of adding an authenticator 
token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to 
describe some minimal subset which we could all reasonably implement. I 
was told that  the specification was "locked down" and fully debugged 
and so on, so no changes could be made. Imagine my surprise to find that 
in the final drafts there was a whole new flow - the hybrid flow - that 
had been added at the last minute. I had never heard of the hybrid flow 
in the OAuth context - have you? So now you have an even larger 
specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes 
precisely a minimal extension to OAuth flows to support an authenticator 
token.  In my experience, this is the subset that most customers and 
implementors are looking for.

- prateek

>>     I would object to 'OAuth Authentication' being picked up by the
>>     WG as a work item. The starting point draft has expired and it
>>     hasn't really been discusses since Berlin nearly a year ago.  As
>>     I recall, there was only very limited interest in it even then. I
>>     <https://plus.google.com/u/0/114266977739397708540>slideshare
>>     logo <http://www.slideshare.net/PingIdentity>flipboard logo

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 14 May 2014 17:44:44 -0700

"I had personally requested the OIDC community about six months ago to
describe some minimal subset which we could all reasonably implement."

I believe you're looking for this:
http://openid.net/specs/openid-connect-basic-1_0.html

-cmort

On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra
<[email-masked]>wrote:

>  Anil,
>
> the challenge is that OIDC is a rather large set of specifications, and to
> my knowledge even the core specification has NOT found
> As we all know, the core problem is that of adding an authenticator token
> to OAuth flows, which is a rather modest extension to OAuth.
>
> describe some minimal subset which we could all reasonably implement. I was
> told that  the specification was "locked down" and fully debugged and so
> on, so no changes could be made. Imagine my surprise to find that in the
> final drafts there was a whole new flow - the hybrid flow - that had been
> added at the last minute. I had never heard of the hybrid flow in the OAuth
> context - have you? So now you have an even larger specification!
>
> *From:* OAuth [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Phil Hunt

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 18:18:03 -0700

That’s not a minimalistic authn only profile.

If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.

Phil

@independentid
www.independentid.com
[email-masked]

On May 14, 2014, at 5:44 PM, Chuck Mortimore <[email-masked]> wrote:

> "I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."
> 
> I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html
> 
> -cmort
> 
> 
> 
> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <[email-masked]> wrote:
> Anil,
> 
> the challenge is that OIDC is a rather large set of specifications, and to my knowledge even the core specification has NOT found
> a complete implementation at any large IdP. I am not talking here about boutique toolkits or startups, I am talking about the folks
> who have 100s of millions of users. And, BTW, implementing a few arbitrarily selected features from OIDC is not the same as implementing OIDC.
> 
> As we all know, the core problem is that of adding an authenticator token to OAuth flows, which is a rather modest extension to OAuth.
> 
> I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement. I was told that  the specification was "locked down" and fully debugged and so on, so no changes could be made. Imagine my surprise to find that in the final drafts there was a whole new flow - the hybrid flow - that had been added at the last minute. I had never heard of the hybrid flow in the OAuth context - have you? So now you have an even larger specification!
> 
> The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes precisely a minimal extension to OAuth flows to support an authenticator token.  In my experience, this is the subset that most customers and implementors are looking for. 
> 
> 
> - prateek
> 
> 
> 
> 
> 
>> Tony/Phil,
>> The reason is that it is commonly understood/accepted now that OAuth provides authorization related specs while authentication/profile

---

From: Justin Richer <[email-masked]>
Date: Wed, 14 May 2014 21:21:45 -0400

How is this functionally different from the a4c draft that also allows 
the return of both an id_token and an access token?

  -- Justin

On 5/14/2014 9:18 PM, Phil Hunt wrote:
> That's not a minimalistic authn only profile.
>
> If you return both an access token AND an id token than the service 
> provide has to implement both and the client has to figure out what to 
> do with it.
>
> Phil
>
> @independentid
> On May 14, 2014, at 5:44 PM, Chuck Mortimore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> "I had personally requested the OIDC community about six months ago 
>> to describe some minimal subset which we could all reasonably implement."
>>
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Anil,
>>
>>     the challenge is that OIDC is a rather large set of
>>     specifications, and to my knowledge even the core specification
>>     has NOT found
>>     a complete implementation at any large IdP. I am not talking here
>>     about boutique toolkits or startups, I am talking about the folks
>>     arbitrarily selected features from OIDC is not the same as
>>     implementing OIDC.
>>
>>     As we all know, the core problem is that of adding an
>>     authenticator token to OAuth flows, which is a rather modest
>>     extension to OAuth.
>>
>>     I had personally requested the OIDC community about six months
>>     ago to describe some minimal subset which we could all reasonably
>>     implement. I was told that  the specification was "locked down"
>>     and fully debugged and so on, so no changes could be made.
>>     Imagine my surprise to find that in the final drafts there was a
>>     whole new flow - the hybrid flow - that had been added at the
>>     last minute. I had never heard of the hybrid flow in the OAuth
>>     precisely a minimal extension to OAuth flows to support an
>>     authenticator token.  In my experience, this is the subset that
>>     most customers and implementors are looking for.
>>
>>
>>     - prateek
>>
>>
>>
>>
>>
>>>     Tony/Phil,
>>>     The reason is that it is commonly understood/accepted now that
>>>     OAuth provides authorization related specs while
>>>     authentication/profile
>>>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>>>         I would object to 'OAuth Authentication' being picked up by
>>>>         the WG as a work item. The starting point draft has expired
>>>>         and it hasn't really been discusses since Berlin nearly a
>>>>         year ago.  As I recall, there was only very limited
>>>>         interest in it even then. I also don't believe it fits well
>>>>         with the WG charter.
>>>>
>>>>         I would suggest the WG consider picking up 'OAuth Symmetric
>>>>         Proof of Possession for Code Extension' for which there is
>>>>         an excellent starting point of
>>>>         http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 -
>>>>         it's a relativity simple security enhancement which
>>>>         addresses problems currently being encountered in
>>>>         deployments of native clients.
>>>>
>>>>         <[email-masked]
>>>>         <mailto:[email-masked]>> wrote:
>>>>
>>>>             Hi all,
>>>>
>>>>         +1 720.317.2061 <tel:720.317.2061>
>>>>
>>>>         Connect with us...
>>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 18:24:10 -0700

It isn’t required (or should not be).  This issue is OIDC compatibility.

Phil

@independentid
www.independentid.com
[email-masked]

On May 14, 2014, at 6:21 PM, Justin Richer <[email-masked]> wrote:

> How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token? 
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 14 May 2014 21:41:03 -0400

Actually, it's about OAuth compatibility. With OAuth, you get an access 
token to be used at a protected resource. That's what it's for, that's 
what clients do the OAuth dance(s) for. Connect defines that protected 
resource as the userinfo endpoint (ie, "tells the client what to do with 
it"). Connect also defines the id token that comes in along side of the 
bog-standard OAuth token, and Connect is turned on and off through the 
use of bog-standard OAuth scopes. So that makes it very, very, very easy 
to take an OAuth server and turn it into a Connect server. I know, I've 
done just that, and I've walked others through the process as well.

But the a4c draft is using something that's almost-but-not-quite-OAuth: 
You might not get an access token, which is going to confuse the heck 
out of most OAuth clients that I know since that's what they're trying 
to get at in the first place, and there's no real way for a client to 
distinguish its request for something with an id_token vs. without. 
Additionally, in practice, that access token is hugely useful. Just look 
at all of the weird OpenID2 and OAuth1 hybrid stuff that people were 
trying to do back a few years ago on top of all the OpenID2 extensions 
-- this is exactly because OpenID2 was built for "authentication only" 
because that's what people thought developers wanted, but it turned out 
that developers wanted a whole lot more than that. This is one main 
reason the Facebook Connect and Twitter's OAuth-based login came along 
and ate everyone's lunch: they gave you authentication, but also 
something useful about the end user.

All said, it sounds like you want Connect but without the UserInfo 
Endpoint. You'll be glad to know that you can already do that as per the 
MTI definitions of the server:

   http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI

You are free to implement a SCIM endpoint (which, by the way, you'll 
probably need that access_token to access) or no endpoint at all, and a 
compliant client ought to be able to deal with that. In fact, there's a 
way to get just the id_token in Connect if that's all you care about, 
but instead of hiding it inside of an existing flow that might return 
something different depending on (currently-undefined) special 
circumstances, it puts this mode into a separate response_type entirely 
to enforce the point that it is different from regular OAuth.

  -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
> On May 14, 2014, at 6:21 PM, Justin Richer <[email-masked] 
>> How is this functionally different from the a4c draft that also 
>> allows the return of both an id_token and an access token?
>>
>>  -- Justin
>>
>>> provide has to implement both and the client has to figure out what 
>>> to do with it.
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>
>>>>     a complete implementation at any large IdP. I am not talking
>>>>     here about boutique toolkits or startups, I am talking about
>>>>     the folks
>>>>     who have 100s of millions of users. And, BTW, implementing a
>>>>     few arbitrarily selected features from OIDC is not the same as
>>>>     implementing OIDC.
>>>>
>>>>     ago to describe some minimal subset which we could all
>>>>     reasonably implement. I was told that  the specification was
>>>>     "locked down" and fully debugged and so on, so no changes could
>>>>     be made. Imagine my surprise to find that in the final drafts
>>>>     there was a whole new flow - the hybrid flow - that had been
>>>>     added at the last minute. I had never heard of the hybrid flow
>>>>     The value of draft-hunt-oauth-v2-user-a4c-01 is that it
>>>>     describes precisely a minimal extension to OAuth flows to
>>>>     support an authenticator token.  In my experience, this is the
>>>>     subset that most customers and implementors are looking for.
>>>>
>>>>
>>>>     - prateek
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>     Tony/Phil,
>>>>>>         I would object to 'OAuth Authentication' being picked up
>>>>>>         by the WG as a work item. The starting point draft has
>>>>>>         expired and it hasn't really been discusses since Berlin
>>>>>>         nearly a year ago.  As I recall, there was only very
>>>>>>         limited interest in it even then. I also don't believe it
>>>>>>         fits well with the WG charter.
>>>>>>
>>>>>>         I would suggest the WG consider picking up 'OAuth
>>>>>>         Symmetric Proof of Possession for Code Extension' for
>>>>>>         which there is an excellent starting point of
>>>>>>         <mailto:[email-masked]>
>>>>>>
>>>>>>         phone
>>>>>>
>>>>>>         	
>>>>>>
>>>>>>         <https://www.youtube.com/user/PingIdentityTV>LinkedIn
>>>>>>         logo <https://www.linkedin.com/company/21870>Facebook
>>>>>>         logo <https://www.facebook.com/pingidentitypage>Google+
>>>>>>         logo
>>>>>>         logo <http://www.slideshare.net/PingIdentity>flipboard
>>>>>>         logo <http://flip.it/vjBF7>rss feed icon
>>>>>>         Revolution | 19–23 July, 2014 | Monterey, CA

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 18:42:53 -0700

Right.  This is why it has a different point because the client does NOT want a resource token.

Phil

@independentid
www.independentid.com
[email-masked]

On May 14, 2014, at 6:41 PM, Justin Richer <[email-masked]> wrote:

> Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well. 
> 
> But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.
> 
> All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:
> 
> You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth. 
> 
>  -- Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 18:43:43 -0700

Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 14 May 2014 21:57:59 -0400

Right, so instead of being able to use my authorization endpoint, which 
already authenticates the user and can gather consent, I need to 
implement a new endpoint that's not-quite-OAuth but is almost like it. 
But it's enough to be confusing because sometimes I go to this new 
endpoint endpoint and also get an access token anyway, to use somewhere 
that I'm not sure where. And I'm not sure I can collapse the two 
endpoints and re-use my OAuth infrastructure. After all, I still need to 
use the token endpoint, and by that point my server needs to know which 
endpoint the user went to in the first place to make that switch. As a 
developer, this all sounds horribly convoluted and complicated to track. 
Do I get to re-use any of the components from an authorization endpoint? 
How do I know whether or not to issue the access token if the user goes 
to the authentication endpoint? And then there are the optimizations for 
existing well-known and well-understood use cases: what if my client is 
sitting in the same browser session and just wants to get the user 
assertion directly instead of going through a round trip? Do I need to 
make two round trips if I'm getting a protected API at the same time as 
authn data? Can I use the same response_type functionality and other 
extensions on the authentication endpoint?

In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is 
dangerous and confusing and not something I think the OAuth WG should be 
a part of. And I really just don't see the point of it, unless the goal 
is to pollute the standards space which Connect currently occupies. Is 
Connect perfect? Heck no. But it's far and away the best thing we've had 
in a long time, and it already does every single thing you are asking 
for from this new draft.

  -- Justin

On 5/14/2014 9:43 PM, Phil Hunt wrote:
> Sorry I meant to say this is why it has the /authenticate endpoint to 
> indicate the client only wants the users session information.
>
> Phil
>
> @independentid
> On May 14, 2014, at 6:42 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> On May 14, 2014, at 6:41 PM, Justin Richer <[email-masked] 
>>> Actually, it's about OAuth compatibility. With OAuth, you get an 
>>> access token to be used at a protected resource. That's what it's 
>>> for, that's what clients do the OAuth dance(s) for. Connect defines 
>>> that protected resource as the userinfo endpoint (ie, "tells the 
>>> client what to do with it"). Connect also defines the id token that 
>>> comes in along side of the bog-standard OAuth token, and Connect is 
>>> turned on and off through the use of bog-standard OAuth scopes. So 
>>> that makes it very, very, very easy to take an OAuth server and turn 
>>> it into a Connect server. I know, I've done just that, and I've 
>>> walked others through the process as well.
>>>
>>> But the a4c draft is using something that's 
>>> almost-but-not-quite-OAuth: You might not get an access token, which 
>>> is going to confuse the heck out of most OAuth clients that I know 
>>> since that's what they're trying to get at in the first place, and 
>>> there's no real way for a client to distinguish its request for 
>>> something with an id_token vs. without. Additionally, in practice, 
>>> that access token is hugely useful. Just look at all of the weird 
>>> OpenID2 and OAuth1 hybrid stuff that people were trying to do back a 
>>> few years ago on top of all the OpenID2 extensions -- this is 
>>> exactly because OpenID2 was built for "authentication only" because 
>>> that's what people thought developers wanted, but it turned out that 
>>> developers wanted a whole lot more than that. This is one main 
>>> reason the Facebook Connect and Twitter's OAuth-based login came 
>>> along and ate everyone's lunch: they gave you authentication, but 
>>> also something useful about the end user.
>>>
>>> Endpoint. You'll be glad to know that you can already do that as per 
>>> the MTI definitions of the server:
>>>
>>> probably need that access_token to access) or no endpoint at all, 
>>> and a compliant client ought to be able to deal with that. In fact, 
>>> there's a way to get just the id_token in Connect if that's all you 
>>> care about, but instead of hiding it inside of an existing flow that 
>>> might return something different depending on (currently-undefined) 
>>> special circumstances, it puts this mode into a separate 
>>> response_type entirely to enforce the point that it is different 
>>> from regular OAuth.
>>>
>>>  -- Justin
>>>
>>>>>> If you return both an access token AND an id token than the 
>>>>>> service provide has to implement both and the client has to 
>>>>>> figure out what to do with it.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>>> "I had personally requested the OIDC community about six months 
>>>>>>> reasonably implement."
>>>>>>>     specifications, and to my knowledge even the core
>>>>>>>     specification has NOT found
>>>>>>>     few arbitrarily selected features from OIDC is not the same
>>>>>>>     as implementing OIDC.
>>>>>>>
>>>>>>>     I had personally requested the OIDC community about six
>>>>>>>     months ago to describe some minimal subset which we could
>>>>>>>     all reasonably implement. I was told that  the specification
>>>>>>>     was "locked down" and fully debugged and so on, so no
>>>>>>>     changes could be made. Imagine my surprise to find that in
>>>>>>>     the final drafts there was a whole new flow - the hybrid
>>>>>>>     flow - that had been added at the last minute. I had never
>>>>>>>     heard of the hybrid flow in the OAuth context - have you? So
>>>>>>>     now you have an even larger specification!
>>>>>>>
>>>>>>>     support an authenticator token.  In my experience, this is
>>>>>>>     the subset that most customers and implementors are looking
>>>>>>>     for.
>>>>>>>
>>>>>>>
>>>>>>>     - prateek
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     Tony/Phil,
>>>>>>>>     The reason is that it is commonly understood/accepted now
>>>>>>>>     that OAuth provides authorization related specs while
>>>>>>>>     authentication/profile
>>>>>>>>>         I would object to 'OAuth Authentication' being picked
>>>>>>>>>         up by the WG as a work item. The starting point draft
>>>>>>>>>         has expired and it hasn't really been discusses since
>>>>>>>>>         Berlin nearly a year ago.  As I recall, there was only
>>>>>>>>>         very limited interest in it even then. I also don't
>>>>>>>>>         Register for Cloud Identity Summit 2014 | Modern
>>>>>>>>>         Identity Revolution | 19–23 July, 2014 | Monterey, CA

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 21:55:51 -0700

I think those are things to discuss if the authen is on the charter. 

So we have now clarified that the basic connect profile doesn't do just authen and requires identity profile services. 

Phil

> On May 14, 2014, at 18:57, Justin Richer <[email-masked]> wrote:
> 
> Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint? 
> 
> In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG       should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.
> 
>  -- Justin
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 15 May 2014 05:30:55 +0000

Very odd since you took the registration from connect and pushed it OAuth.

Sent from my Windows Phone
________________________________
From: Justin Richer<mailto:[email-masked]>
Sent: ‎5/‎15/‎2014 3:58 AM
To: Phil Hunt<mailto:[email-masked]>
Cc: OAuth WG<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On May 14, 2014, at 6:42 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On May 14, 2014, at 6:41 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On May 14, 2014, at 6:21 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On May 14, 2014, at 5:44 PM, Chuck Mortimore <[email-masked]<mailto:[email-masked]>> wrote:

-cmort

On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Anil,

- prateek

Tony/Phil,

Regards,
Anil

Phil

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

Brian Campbell
Portfolio Architect
@

[phone]

+1 720.317.2061<tel:720.317.2061>

Connect with us…

---

From: John Bradley <[email-masked]>
Date: Thu, 15 May 2014 07:31:40 +0200

No.

OAuth requires that if you use the code response type, the token endpoint must return an access token.

Connect dosen't require a user_info endpoint.

In the response_type "id_token"  only a id_token is returned in the front channel in a manner similar to SAML POST binding but fragment encoded by default.

So there is a flow in Connect that doesn't deliver an access token.

I think this discussion is more about what changes you want to the core of OAuth.

Connect worked around the OAuth spec to be compatible with it.

Only the OAuth WG can change OAuth and that seems to be what you want.  
a4c is a justification for making those changes.

We should probably focus on the core issue of what changes to RFC 6749 you are after, to determine if the WG wants to change the charter.

I think focusing on a4c is a read herring.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 May 2014 23:12:28 -0700

Which flow is that? It certainly wasn't the one Justin pointed to. 

Phil

> On May 14, 2014, at 22:31, John Bradley <[email-masked]> wrote:
> 
> No.
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 15 May 2014 07:03:17 +0000

So Oauth already treads into the authentication space to some extent and enough of an extent to create additional security issues and threats.

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:32 PM
To: Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

No.

John B.

On May 15, 2014, at 6:55 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On May 14, 2014, at 18:57, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint?

 -- Justin

Phil

@independentid

Phil

@independentid

 -- Justin

On 5/14/2014 9:24 PM, Phil Hunt wrote:
It isn't required (or should not be).  This issue is OIDC compatibility.

Phil

@independentid

 -- Justin

Phil

@independentid

-cmort

- prateek

Tony/Phil,

Regards,
Anil

Phil

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

Brian Campbell
Portfolio Architect
@

[phone]

Connect with us...

[Register                                                            for Cloud                                                            Identity                                                            Summit 2014 |                                                            Modern                                                            Identity                                                            Revolution |                                                            19-23 July,                                                            2014 |                                                            Monterey, CA]<https://www.cloudidentitysummit.com/>

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 15 May 2014 07:12:41 +0000

Where is the confusion ?

Sent from my iPhone

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

Brian Campbell
Portfolio Architect
@

[phone]

+1 720.317.2061

Connect with us…

---

From: John Bradley <[email-masked]>
Date: Thu, 15 May 2014 10:22:57 +0200

Phil,  I recommend reading the specification. 

Sent from my iPhone

> On May 15, 2014, at 8:12 AM, Phil Hunt <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Thu, 15 May 2014 10:26:52 +0200

OAuth covers authentication in security consideration 

This was debated in the WG at the time. 

Just say that you want to reopen the RFC. 

Sent from my iPhone

> On May 15, 2014, at 9:03 AM, Anthony Nadalin <[email-masked]> wrote:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 15 May 2014 08:30:44 +0000

Have no idea what you are saying here, not asking to for errata on the RFC

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, May 15, 2014 1:27 AM
To: Anthony Nadalin
Cc: Phil Hunt; OAuth WG
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Sent from my iPhone

On May 15, 2014, at 9:03 AM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
So Oauth already treads into the authentication space to some extent and enough of an extent to create additional security issues and threats.

No.

John B.

Phil

 -- Justin

Phil

@independentid

Phil

@independentid

 -- Justin

Phil

@independentid

 -- Justin

Phil

@independentid

-cmort

- prateek

Tony/Phil,

Regards,
Anil

Phil

-----

-----

-----

-----

Feedback appreciated.

Ciao
Hannes & Derek

Brian Campbell
Portfolio Architect
@

[phone]

Connect with us…

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Thu, 15 May 2014 10:40:21 +0200

I thought the a4c required changes to eliminate client registration and to not return an access token. 

Being clear on if there will be an errata required for a2c to be compliant,  would be helpful. 

Sent from my iPhone

> On May 15, 2014, at 10:30 AM, Anthony Nadalin <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 May 2014 03:12:37 -0700

John,

Nope. Read the draft please. 

The draft is about providing end-user authentication results to clients. 

It does not saying anything about registration pr require any changes to oauth. 

Phil

> On May 15, 2014, at 1:40, John Bradley <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 15 May 2014 06:37:17 -0600

context - have you? So now you have an even larger specification!"

Prateek,

The hybrid flow wasn't new at all. It was an editorial change that
attempted to better explain multiple response types like code+token, which
is something allowed for by OAuth
http://tools.ietf.org/html/rfc6749#section-8.4 and used in Connect since
the very beginning (at least as long as I'd been involved, which is 2+
years).  Nothing was added to the actual protocol.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 15 May 2014 06:54:22 -0600

"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.