Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

From: Justin Richer <[email-masked]>
Date: Tue, 22 Jul 2014 11:30:30 -0700

So the draft would literally turn into:

"The a4c response type and grant type return an id_token from the token endpoint with no access token. All parameters and values are defined in OIDC."

Seems like the perfect mini extension draft for OIDF to do.

--Justin

/sent from my phone/

On Jul 22, 2014 10:29 AM, Nat Sakimura <[email-masked]> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <[email-masked]>:
>>
>> That would be nice. However oidc still needs the new grant type in order to implement the same flow. 
>>
>> Phil
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <[email-masked]> wrote:
>>
>>> +1 to Justin. 
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <[email-masked]>:
>>>>
>>>> Errors like these make it clear to me that it would make much more sense to develop this document in the OpenID Foundation. It should be something that directly references OpenID Connect Core for all of these terms instead of redefining them. It's doing authentication, which is fundamentally what OpenID Connect does on top of OAuth, and I don't see a good argument for doing this work in this working group.
>>>>
>>>>  -- Justin
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <[email-masked]> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]> wrote:
>>>>>>
>>>>>> Thanks for your review, Thomas.  The “prompt=consent” definition being missing is an editorial error.  It should be:
>>>>>>
>>>>>>  
>>>>>>
>>>>>> consent
>>>>>>
>>>>>> The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I’ll plan to add it in the next draft.
>>>>>
>>>>>
>>>>> It looks like the consent_required error needs to be defined too, and you might have forgotten to also import account_selection_required from OpenID Connect.
>>>>>  
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I agree that there’s no difference between a response with multiple “amr” values that includes “mfa” and one that doesn’t.  Unless a clear use case for why “mfa” is needed can be identified, we can delete it in the next draft.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> How about "pwd" then? I fully understand that I should return "pwd" if the user authenticated using a password, but what "the service if a client secret is used" means in the definition for the "pwd" value?
>>>>>
>>>>> (Nota: I know you're at IETF-90, I'm ready to wait 'til you come back ;-) )
>>>>>
>>>>> -- 
>>>>> Thomas Broyer
>>>>> /tɔ.ma.bʁwa.je/
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>>
>>> -- 
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 00:46:25 -0400

The new grant type that I was talking about was
"authorization_code_but_do_not_return_access_nor_refresh_token", so to
speak.
It does not return anything per se, but an extension can define something
on top of it.

Then, OIDC can define a binding to it so that the binding only returns ID
Token.
This binding work should be done in OIDF. Should there be such a grant
type,
it will be an extremely short spec.

At the same time, if any other specification wanted to define
other type of tokens and have it returned from the token endpoint,
it can also use this grant type.

If what you want is to define a new grant type that returns ID Token only,
then, I am with Justin. Since "other response than ID Token" is only
theoretical, this is a more plausible way forward, I suppose.

Nat

2014-07-22 14:30 GMT-04:00 Justin Richer <[email-masked]>:

> "The a4c response type and grant type return an id_token from the token
> endpoint with no access token. All parameters and values are defined in
> OIDC."
>
> >>>> Errors like these make it clear to me that it would make much more
> sense to develop this document in the OpenID Foundation. It should be
> something that directly references OpenID Connect Core for all of these
> terms instead of redefining them. It's doing authentication, which is
> fundamentally what OpenID Connect does on top of OAuth, and I don't see a
> good argument for doing this work in this working group.
> >>>>
> >>>>  -- Justin
> >>>>
> >>>>>> Thanks for your review, Thomas.  The “prompt=consent” definition
> being missing is an editorial error.  It should be:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> consent
> >>>>>>
> >>>>>> The Authorization Server SHOULD prompt the End-User for consent
> before returning information to the Client. If it cannot obtain consent, it
> MUST return an error, typically consent_required.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> It looks like the consent_required error needs to be defined too,
> and you might have forgotten to also import account_selection_required from
> OpenID Connect.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I agree that there’s no difference between a response with multiple
> “amr” values that includes “mfa” and one that doesn’t.  Unless a clear use
> case for why “mfa” is needed can be identified, we can delete it in the
> next draft.
> >>>>>
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> How about "pwd" then? I fully understand that I should return "pwd"
> if the user authenticated using a password, but what "the service if a
> client secret is used" means in the definition for the "pwd" value?
> >>>>>
> >>>>> /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 23 Jul 2014 07:21:02 -0400

The draft is very clear. 

Phil

> On Jul 23, 2014, at 0:46, Nat Sakimura <[email-masked]> wrote:
> 
> "authorization_code_but_do_not_return_access_nor_refresh_token", so to speak. 
> It does not return anything per se, but an extension can define something on top of it. 
> 
> Then, OIDC can define a binding to it so that the binding only returns ID Token. 
> This binding work should be done in OIDF. Should there be such a grant type,

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 09:43:19 -0400

Reading back the RFC6749, I am not sure if there is a good way of
suppressing access token from the response and still be OAuth. It will
break whole bunch of implicit definitions like:

authorization server
      The server issuing access tokens to the client after successfully
      authenticating the resource owner and obtaining authorization.

After all, OAuth is all about issuing access tokens.

Also, I take back my statement on the grant type in my previous mail.

The definition of grant and grant_type are respectively:

grant
    credential representing the resource owner's authorization
grant_type
  (string representing the) type of grant sent to the token endpoint to
obtain the access token

Thus, the grant sent to the token endpoint in this case is still 'code'.

Response type on the other hand is not so well defined in RFC6749, but it
seems it is representing what is to be returned from the authorization
endpoint. To express what is to be returned from token endpoint, perhaps
defining a new parameter to the token endpoint, which is a parallel to the
response_type to the Authorization Endpoint seems to be a more symmetric
way, though I am not sure at all if that is going to be OAuth any more. One
straw-man is to define a new parameter called response_type to the token
endpoint such as:

response_type
    OPTIONAL. A string representing what is to be returned from the token
endpoint.

Then define the behavior of the endpoint according to the values as the
parallel to the multi-response type spec.
http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html

Nat

2014-07-23 7:21 GMT-04:00 Phil Hunt <[email-masked]>:

>> >>>>>> I agree that there’s no difference between a response with
>> multiple “amr” values that includes “mfa” and one that doesn’t.  Unless a
>> clear use case for why “mfa” is needed can be identified, we can delete it
>> in the next draft.
>> >>>>>
>> >>>>>
>> >>>>> Thanks.
>> >>>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 23 Jul 2014 10:08:30 -0400

Yes. This is why it has to be discussed in the IETF.

Phil

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

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <[email-masked]> wrote:

> Reading back the RFC6749, I am not sure if there is a good way of suppressing access token from the response and still be OAuth. It will break whole bunch of implicit definitions like: 
> 
> authorization server
>     (string representing the) type of grant sent to the token endpoint to obtain the access token
> 
> Response type on the other hand is not so well defined in RFC6749, but it seems it is representing what is to be returned from the authorization endpoint. To express what is to be returned from token endpoint, perhaps defining a new parameter to the token endpoint, which is a parallel to the response_type to the Authorization Endpoint seems to be a more symmetric way, though I am not sure at all if that is going to be OAuth any more. One straw-man is to define a new parameter called response_type to the token endpoint such as: 
> 
> response_type
>     OPTIONAL. A string representing what is to be returned from the token endpoint. 
>     
> Then define the behavior of the endpoint according to the values as the parallel to the multi-response type spec.

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jul 2014 14:26:50 +0000

The response_type “none” is already used in practice, which returns no access token.  It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.  The registered “id_token” response type also returns no access token.

So I think the question of whether response types that result in no access token being returned are acceptable within OAuth 2.0 is already settled, as a practical matter.  Lots of OAuth implementations are already using such response types.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

Phil

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

On Jul 23, 2014, at 9:43 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

authorization server

grant

grant_type

response_type

Nat

2014-07-23 7:21 GMT-04:00 Phil Hunt <[email-masked]<mailto:[email-masked]>>:
The draft is very clear.

Phil

On Jul 23, 2014, at 0:46, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
The new grant type that I was talking about was
"authorization_code_but_do_not_return_access_nor_refresh_token", so to speak.
It does not return anything per se, but an extension can define something on top of it.

Nat

2014-07-22 14:30 GMT-04:00 Justin Richer <[email-masked]<mailto:[email-masked]>>:
So the draft would literally turn into:

--Justin

/sent from my phone/

On Jul 22, 2014 10:29 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
> 2014-07-22 12:56 GMT-04:00 Phil Hunt <[email-masked]<mailto:[email-masked]>>:
>>
>> On Jul 22, 2014, at 11:35, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> +1 to Justin.
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. <[email-masked]<mailto:[email-masked]>>:
>>>>
>>>> On Jul 22, 2014, at 4:30 AM, Thomas Broyer <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>
>>>>> /tɔ.ma.bʁwa.je/<http://xn--nna.ma.xn--bwa-xxb.je/>
>>>>> [email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 12:17:28 -0400

Fair enough. It is revealing to hear that it is OK to have no access token
after all as OAuth. (Though, in the next rev., I suppose the text needs to
be fixed.)

Then, like Justin says, it probably is just a matter of defining an
'response_type' extension parameter to the token endpoint.
It is practically going to be a few liner as a mini-extension of OIDC. As
far as response_type=id_token is concerned, it probably is better to be
done in OIDF than here. I am amiable in defining this parameter itself in
this WG though.

So, in "OAuth response type parameter to Token endpoint" spec., it defines
one parameter to the token endpoint as:

response_type
  OPTIONAL. A string that expresses what tokens are to be returned from the
Token Endpoint.
  Extension specifications may use this parameter to explicitly expressing
the desire to
  obtain a particular type of token.

Then, in an mini-extension spec to OIDC, such as "OIDC ID Token only
profile"

response_type
   If the value of this parameter is "id_token",  only ID Token SHOULD be
returned in the successful response.

Cheers,

Nat

2014-07-23 10:26 GMT-04:00 Mike Jones <[email-masked]>:

>  The response_type “none” is already used in practice, which returns no
> access token.  It was accepted by the designated experts and registered in
> the IANA OAuth Authorization Endpoint Response Types registry at
> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.
> The registered “id_token” response type also returns no access token.
>
>
>
> So I think the question of whether response types that result in no access
> token being returned are acceptable within OAuth 2.0 is already settled, as
> a practical matter.  Lots of OAuth implementations are already using such
> response types.
>
>
>
>                                                             -- Mike
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, July 23, 2014 7:09 AM
> *To:* Nat Sakimura
> *Cc:* <[email-masked]>
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 23 Jul 2014 18:30:16 +0200

Except that these are about not using the Token Endpoint at all, whereas
the current proposal is about the Token Endpoint not returning an
access_token field in the JSON.

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 23 Jul 2014 16:45:17 +0000

It's only "not using the token endpoint" because the token endpoint copy-pasted and renamed the authentication endpoint.

 -- Justin

On Jul 23, 2014, at 9:30 AM, Thomas Broyer <[email-masked]<mailto:[email-masked]>> wrote:

Except that these are about not using the Token Endpoint at all, whereas the current proposal is about the Token Endpoint not returning an access_token field in the JSON.

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The response_type “none” is already used in practice, which returns no access token.  It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.  The registered “id_token” response type also returns no access token.

                                                            -- Mike

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

Phil

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

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 23 Jul 2014 18:48:04 +0200

No, I mean response_type=none and response_type=id_token don't generate a
code or access token so you don't use the Token Endpoint (which is not the
same as the Authentication Endpoint BTW).
With response_type=code_for_id_token, you get a code and exchange it for an
id_token only, rather than an access_token, so you're changing the
semantics of the Token Endpoint.

I'm not saying it's a bad thing, just that you can't really compare none
and id_token with code_for_id_token.

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <[email-masked]>
wrote:

>  It's only "not using the token endpoint" because the token endpoint
> copy-pasted and renamed the authentication endpoint.
>
>   -- Justin
>
>  On Jul 23, 2014, at 9:30 AM, Thomas Broyer <[email-masked]> wrote:
>
>> So I think the question of whether response types that result in no
>> access token being returned are acceptable within OAuth 2.0 is already
>> settled, as a practical matter.  Lots of OAuth implementations are already
>> using such response types.
>>
>>
>>
>>                                                             -- Mike
>>
>>
>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 13:04:18 -0400

IMHO, changing the semantics of "response_type" @ authz endpoint this way
is not a good thing.

Instead, defining a new parameter "response_type" @ token endpoint, as I
described in my previous message,
probably is better. At least, it does not change the semantics of the
parameters of RFC6749.

 Nat

2014-07-23 12:48 GMT-04:00 Thomas Broyer <[email-masked]>:

> With response_type=code_for_id_token, you get a code and exchange it for
> an id_token only, rather than an access_token, so you're changing the
>>  Except that these are about not using the Token Endpoint at all,
>> whereas the current proposal is about the Token Endpoint not returning an
>>> Response type on the other hand is not so well defined in RFC6749, but
>>> it seems it is representing what is to be returned from the authorization
>>> >>>>> How about "pwd" then? I fully understand that I should return
>>> "pwd" if the user authenticated using a password, but what "the service if
>>> a client secret is used" means in the definition for the "pwd" value?
>>> >>>>>

---

From: [email-masked]
Date: Wed, 23 Jul 2014 13:15:55 -0400

The "response type" of the token endpoint is controlled by the value of
the parameter "grant_type". So there is no need to introduce a new
parameter. 

wrt to a potential "no_access_token" grant type. I do not consider this
a good idea as it changes the semantics of the token endpoint (as
already pointed out by Thomas). This endpoint ALWAYS responds with an
access token to any grant type. I therefore would prefer to use another
endpoint for the intended purpose. 

regards,
Torsten. 

Am 23.07.2014 13:04, schrieb Nat Sakimura: 

> IMHO, changing the semantics of "response_type" @ authz endpoint this way is not a good thing. 
> Instead, defining a new parameter "response_type" @ token endpoint, as I described in my previous message, 
> probably is better. At least, it does not change the semantics of the parameters of RFC6749. 
> 
> Nat 
> 
> No, I mean response_type=none and response_type=id_token don't generate a code or access token so you don't use the Token Endpoint (which is not the same as the Authentication Endpoint BTW). 
> With response_type=code_for_id_token, you get a code and exchange it for an id_token only, rather than an access_token, so you're changing the semantics of the Token Endpoint. 
> 
> I'm not saying it's a bad thing, just that you can't really compare none and id_token with code_for_id_token. 
> 
> On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <[email-masked]> wrote:
> 
> On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <[email-masked]> wrote:
> 
> The response_type "none" is already used in practice, which returns no access token. It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint [1]. The registered "id_token" response type also returns no access token. 
> 
> FROM: OAuth [mailto:[email-masked]] ON BEHALF OF Phil Hunt
> SENT: Wednesday, July 23, 2014 7:09 AM
> TO: Nat Sakimura
> CC: <[email-masked]>
> SUBJECT: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt 
> 
> www.independentid.com [2] 
> 
> [email-masked] 
> 
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [3] 
> 
> Nat 
> 
>>>>>>> Thanks for your review, Thomas. The "prompt=consent" definition being missing is an editorial error. It should be:
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> consent
>>>>>>>
>>>>>>> I'll plan to add it in the next draft.
>>>>>>
>>>>>>
>>>>>>> I agree that there's no difference between a response with multiple "amr" values that includes "mfa" and one that doesn't. Unless a clear use case for why "mfa" is needed can be identified, we can delete it in the next draft.
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> /tɔ.ma.bʁwa.je/ [4]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>>
>>>>>
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://nat.sakimura.org/ [6]
>>>> @_nat_en
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth [5]
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://nat.sakimura.org/ [6]
>> @_nat_en 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> http://nat.sakimura.org/ [6]
> @_nat_en 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> http://nat.sakimura.org/ [6]
> @_nat_en 
> 
> https://www.ietf.org/mailman/listinfo/oauth [5]

 -- 
 Thomas Broyer
 /tɔ.ma.bʁwa.je/ [4] _______________________________________________
 OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth [5] 

 -- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ [4] 
_______________________________________________
 OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth [5]

 -- 
Nat Sakimura (=nat) 
Chairman, OpenID Foundation
http://nat.sakimura.org/ [6]
@_nat_en 

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

Links:
------
[1]
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint
[2] http://www.independentid.com/
[3] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
[4] http://xn--nna.ma.xn--bwa-xxb.je/
[5] https://www.ietf.org/mailman/listinfo/oauth
[6] http://nat.sakimura.org/

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jul 2014 17:21:20 +0000

I agree with Torsten on this.  Also, John Bradley had pointed out earlier that a new grant type was needed.

The ac4 draft defines the grant type urn:ietf:params:oauth:grant-type:code-for-id-token for this purpose, since section 4.5 of RFC 6749 requires extension grants to be absolute URLs.

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 23, 2014 10:16 AM
To: Nat Sakimura
Cc: [email-masked]
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

The "response type" of the token endpoint is controlled by the value of the parameter "grant_type". So there is no need to introduce a new parameter.

wrt to a potential "no_access_token" grant type. I do not consider this a good idea as it changes the semantics of the token endpoint (as already pointed out by Thomas). This endpoint ALWAYS responds with an access token to any grant type. I therefore would prefer to use another endpoint for the intended purpose.

regards,
Torsten.

 Nat

2014-07-23 12:48 GMT-04:00 Thomas Broyer <[email-masked]<mailto:[email-masked]>>:
No, I mean response_type=none and response_type=id_token don't generate a code or access token so you don't use the Token Endpoint (which is not the same as the Authentication Endpoint BTW).
With response_type=code_for_id_token, you get a code and exchange it for an id_token only, rather than an access_token, so you're changing the semantics of the Token Endpoint.

On Wed, Jul 23, 2014 at 6:45 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:
It's only "not using the token endpoint" because the token endpoint copy-pasted and renamed the authentication endpoint.

 -- Justin

On Wed, Jul 23, 2014 at 4:26 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The response_type "none" is already used in practice, which returns no access token.  It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.  The registered "id_token" response type also returns no access token.

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Wed, 23 Jul 2014 12:33:22 -0500

If we use the token endpoint then a new grant_type is the best way. 

It sort of overloads code, but that is better than messing with response_type for the authorization endpoint to change the response from the token_endpoint.  That is in my opinion a champion bad idea. 

In discussions developing Connect we decided not to open this can of worms because no good would come of it.   

The token_endpoint returns a access token.  Nothing requires scope to be associates with the token. 

That is the best solution.  No change required.  Better interoperability in my opinion. 

Still on my way to TO, getting in later today. 

John B. 

Sent from my iPhone

> On Jul 23, 2014, at 12:15 PM, [email-masked] wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 23 Jul 2014 17:39:03 +0000

You need the alternative response_type value (“code_for_id_token” in the A4C draft) to tell the Authorization Server to return a code to be used with the new grant type, rather than one to use with the “authorization_code” grant type (which is what response_type=code does).

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

John B.

Sent from my iPhone

On Jul 23, 2014, at 12:15 PM, [email-masked]<mailto:[email-masked]> wrote:

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: Takahiko Kawasaki <[email-masked]>
Date: Thu, 24 Jul 2014 03:12:22 +0900

Hello,

(1) RFC 6749
  grant_type=authorization_code
  response={"access_token":...}

(2) OpenID Connect Core
  grant_type=authorization_code
  response={"access_token":..., "id_token":...}

(3) Currently being discussed
  (3)-1
    grant_type=authorization_code
    response_type=id_token  (a new parameter for the token endpoint)
    response={"id_token":...}

  (3)-2
    grant_type=something_new  (a new value for the token endpoint)
    response={"id_token":...}

  (3)-3
    response_type=something_new (a new value for the authz endpoint)
    grant_type=something_new

However, taking a logical expansion below into account,

(4) Not being discussed yet, but logically possible
  grant_type=password
  response={"id_token":...}

it seems "grant_type" should be treated as a parameter to specify
just a 'flow'. IMHO, what tokens should be included in the response
from the token endpoint should be specified by another different means.
For example, "response_type" (a new parameter for the *token* endpoint)
as suggested by Nat.

Nat> response_type
Nat>   OPTIONAL. A string that expresses what tokens are to be returned
Nat>   from the Token Endpoint. Extension specifications may use this
Nat>   parameter to explicitly expressing the desire to  obtain a
Nat>   particular type of token.

If asked, I would add the following:

  The default value of "response_type" is "token" which means that
  an access token is requested. However, when the following conditions
  are satisfied, the default value is "token id_token".

    Condition-1:
      grant_type=authorization_code

    Condition-2:
      The authorization code was issued at the authorization endpoint
      with 'openid' scope.

--
Best Regards,
Takahiko Kawasaki

2014-07-24 2:39 GMT+09:00 Mike Jones <[email-masked]>:

>  You need the alternative response_type value (“code_for_id_token” in the
> A4C draft) to tell the Authorization Server to return a code to be used
> with the new grant type, rather than one to use with the
> “authorization_code” grant type (which is what response_type=code does).
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Wednesday, July 23, 2014 10:33 AM
> *To:* [email-masked]
>
> *Cc:* [email-masked]
> It sort of overloads code, but that is better than messing with
> response_type for the authorization endpoint to change the response from
> the token_endpoint.  That is in my opinion a champion bad idea.
>
>
>
> wrt to a potential "no_access_token" grant type. I do not consider this a
> good idea as it changes the semantics of the token endpoint (as already
> pointed out by Thomas). This endpoint ALWAYS responds with an access token
> to any grant type. I therefore would prefer to use another endpoint for the
> intended purpose.
>
> regards,
> Torsten.
>
>
>
> The response_type "none" is already used in practice, which returns no
> The registered "id_token" response type also returns no access token.
>
>
>
> >>>>>> Thanks for your review, Thomas.  The "prompt=consent" definition
> >>>>>> I agree that there's no difference between a response with multiple
> "amr" values that includes "mfa" and one that doesn't.  Unless a clear use
> case for why "mfa" is needed can be identified, we can delete it in the
> next draft.
> >>>>>
> >>>>>
> >>>>> Thanks.
> >>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 14:45:55 -0400

I agree with John that overloading response_type @ authz endpoint is a bad
idea. It completely changes the semantics of this parameter. NOTE: what I
was proposing was not this parameter, but a new parameter response_type @
token endpoint.

I also think overloading grant_type is a bad idea since it changes its
semantics. I quote the definition here again:

grant
    credential representing the resource owner's authorization
grant_type
type of grant sent to the token endpoint to obtain the access token

It is not about controlling what is to be returned from the token endpoint,
but the hint to the token endpoint describing the type of credential the
endpoint has received. It seems the "control of what is being returned from
token endpoint"  is just a side effect.

I am somewhat ambivalent[1] in changing the semantics of token endpoint,
but in as much as "text is the king" for a spec., we probably should not
change the semantics of it as Torsten points out. If it is ok to change
this semantics, I believe defining a new parameter to this endpoint to
control the response would be the best way to go. This is what I have
described previously.

Defining a new endpoint to send code to get ID Token and forbidding the use
of it against token endpoint would not change the semantics of any existing
parameter or endpoint, which is good. However, I doubt if it is not worth
doing. What's the point of avoiding access token scoped to UserInfo
endpoint after all? Defining a new endpoint for just avoiding the access
token for userinfo endpoint seems way too much the heavy wait way and it
breaks interoperabiliy: it defeats the purpose of standardization.

I have started feeling that no change is the best way out.

Nat

[1]  If instead of saying "Token endpoint - used by the client to exchange
an authorization grant for an access token, typically with client
authentication", it were saying "Token endpoint - used by the client to
exchange an authorization grant for tokens, typically with client
authentication", then it would have been OK. It is an expansion of the
capability rather than changing the semantics.

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 14:48:27 -0400

Thanks Takahiko. Good analysis.

2014-07-23 14:12 GMT-04:00 Takahiko Kawasaki <[email-masked]>:

>   You need the alternative response_type value (“code_for_id_token” in
>> the A4C draft) to tell the Authorization Server to return a code to be used
>> >>>>>> I agree that there's no difference between a response with
>> multiple "amr" values that includes "mfa" and one that doesn't.  Unless a
>> clear use case for why "mfa" is needed can be identified, we can delete it
>> in the next draft.
>> >>>>>
>> >>>>>
>> >>>>> Thanks.
>> >>>>>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 23 Jul 2014 21:18:53 +0200

I hadn't realized the JSON response that requires the access_token field is
defined per grant_type, so I'd be OK to "extend the semantics" as in the
current draft.
That was actually my main concern: that the token endpoint mandates
access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" <[email-masked]> a écrit :

> It is not about controlling what is to be returned from the token
> endpoint, but the hint to the token endpoint describing the type of
> credential the endpoint has received. It seems the "control of what is
> being returned from token endpoint"  is just a side effect.
>
> Defining a new endpoint to send code to get ID Token and forbidding the
> use of it against token endpoint would not change the semantics of any
> existing parameter or endpoint, which is good. However, I doubt if it is
> not worth doing. What's the point of avoiding access token scoped to
> UserInfo endpoint after all? Defining a new endpoint for just avoiding the
> access token for userinfo endpoint seems way too much the heavy wait way
> and it breaks interoperabiliy: it defeats the purpose of standardization.
>
> [1]  If instead of saying "Token endpoint - used by the client to
> exchange an authorization grant for an access token, typically with
> client authentication", it were saying "Token endpoint - used by the
> client to exchange an authorization grant for tokens, typically with
> client authentication", then it would have been OK. It is an expansion of
> the capability rather than changing the semantics.
>
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 23 Jul 2014 15:30:34 -0400

Section 5.1 defines _the_ token endpoint response for all grant types. The assumption always was that different grant types allow the client to exchange different authz grants into an access token (and probably a refresh token). 

> Am 23.07.2014 um 15:18 schrieb Thomas Broyer <[email-masked]>:
> 
> I hadn't realized the JSON response that requires the access_token field is defined per grant_type, so I'd be OK to "extend the semantics" as in the current draft.
> That was actually my main concern: that the token endpoint mandates access_token; but its actually not the case.
> 
>> I agree with John that overloading response_type @ authz endpoint is a bad idea. It completely changes the semantics of this parameter. NOTE: what I was proposing was not this parameter, but a new parameter response_type @ token endpoint. 
>> 
>> I also think overloading grant_type is a bad idea since it changes its semantics. I quote the definition here again: 
>> 
>> grant 
>> It is not about controlling what is to be returned from the token endpoint, but the hint to the token endpoint describing the type of credential the endpoint has received. It seems the "control of what is being returned from token endpoint"  is just a side effect. 
>> 
>> I am somewhat ambivalent[1] in changing the semantics of token endpoint, but in as much as "text is the king" for a spec., we probably should not change the semantics of it as Torsten points out. If it is ok to change this semantics, I believe defining a new parameter to this endpoint to control the response would be the best way to go. This is what I have described previously. 
>> 
>> Defining a new endpoint to send code to get ID Token and forbidding the use of it against token endpoint would not change the semantics of any existing parameter or endpoint, which is good. However, I doubt if it is not worth doing. What's the point of avoiding access token scoped to UserInfo endpoint after all? Defining a new endpoint for just avoiding the access token for userinfo endpoint seems way too much the heavy wait way and it breaks interoperabiliy: it defeats the purpose of standardization. 
>> 
>> [1]  If instead of saying "Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication", it were saying "Token endpoint - used by the client to exchange an authorization grant for tokens, typically with client authentication", then it would have been OK. It is an expansion of the capability rather than changing the semantics.
>> 
>> 
>>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 23 Jul 2014 15:32:02 -0400

Is it? Apart from the implicit grant that does not use token endpoint, all
other grant references section 5.1 for the response, i.e., all shares the
same response.

2014-07-23 15:18 GMT-04:00 Thomas Broyer <[email-masked]>:

> I hadn't realized the JSON response that requires the access_token field
> is defined per grant_type, so I'd be OK to "extend the semantics" as in the
> current draft.
>>>  The "response type" of the token endpoint is controlled by the value
>>> of the parameter "grant_type". So there is no need to introduce a new
>>> parameter.
>>>
>>> a good idea as it changes the semantics of the token endpoint (as already
>>> No, I mean response_type=none and response_type=id_token don't generate
>>> a code or access token so you don't use the Token Endpoint (which is not
>>> the same as the Authentication Endpoint BTW).
>>>

---

From: Thomas Broyer <[email-masked]>
Date: Wed, 23 Jul 2014 21:41:38 +0200

Is it said anywhere that ALL grant types MUST use Section 5.1 responses?
Each grant type references Section 5.1, and "access token request" is only
defined in the context of the defined grant types. Section 2.2 doesn't talk
about the request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura" <[email-masked]> a écrit :

>> I agree with John that overloading response_type @ authz endpoint is a
>>> bad idea. It completely changes the semantics of this parameter. NOTE: what
>>> I was proposing was not this parameter, but a new parameter response_type @
>>> token endpoint.
>>>
>>>> With response_type=code_for_id_token, you get a code and exchange it
>>>> for an id_token only, rather than an access_token, so you're changing the
>>>> I'm not saying it's a bad thing, just that you can't really compare
>>>> none and id_token with code_for_id_token.
>>>>
>>>>
>>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 23 Jul 2014 16:04:12 -0400

You are right from a theoretical perspective. Practically this was caused by editorial decisions during the creation of the RFC. As far as I remember, there was a definition of the (one) token endpoint response in early versions. No one every considered to NOT respond with an access token from the token endpoint. So one might call it an implicit assumption.

I'm worried that people get totally confused if an exception is introduced now given the broad adoption of OAuth based on this assumption.

regards,
Torsten.

> Am 23.07.2014 um 15:41 schrieb Thomas Broyer <[email-masked]>:
> 
> Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each grant type references Section 5.1, and "access token request" is only defined in the context of the defined grant types. Section 2.2 doesn't talk about the request or response format.
> 
>> Is it? Apart from the implicit grant that does not use token endpoint, all other grant references section 5.1 for the response, i.e., all shares the same response. 
>> 
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 23 Jul 2014 16:53:37 -0400

I thought I did post this to the list. 

I guess I hit the wrong reply on my phone. 
 
John B. 
Sent from my iPhone

> On Jul 23, 2014, at 4:50 PM, [email-masked] wrote:
> 
> we are two, at least :-)
> 
> Why didn't you post this on the list?
> 
> When will be be arriving?
> 
> Am 23.07.2014 16:39, schrieb John Bradley:
> 
>> Ian Glazer mentioned this in his keynote at CIS yesterday. 
>>  
>> His advice was please stop,  we are creating confusion and uncertainty. 
>>  
>> We are becoming our own wort enemy. ( my view though Ian may share it)
>>  
>> Returning just an id_ token from the token endpoint has little real value. 
>>  
>> Something really useful to do would be sorting out channel_id so we can do PoP for id tokens to make them and other cookies secure in the front channel.   I think that is a better use of time. 
>>  
>> I may be in the minority opinion on that,  it won't be the first time.  
>> 
>> John B. 
>> Sent from my iPhone
>> 
>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <[email-masked]> wrote:
>>> 
>>>>>>>> You need the alternative response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code to be used with the new grant type, rather than one to use with the "authorization_code" grant type (which is what response_type=code does).
>>>>>>>> 
>>>>>>>>  
>>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 23 Jul 2014 17:07:15 -0400

So….your answer to existing confusion is to avoid talking about it because it would be confusing?

Really?

Phil

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

---

From: John Bradley <[email-masked]>
Date: Wed, 23 Jul 2014 17:16:55 -0400

No I am not saying that we shouldn't discuss it. 

We do however need to be mindful that the perception of Change and uncertainty causes IT people to delay and defer adoption. 

Having people delay because they think that there may be more changes are not helpful. 

The perception of stability may be more important than a small optimization. 

I think that is a legitimate view as part of the discussion. 

John B.  

Sent from my iPhone

> On Jul 23, 2014, at 5:07 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jul 2014 01:43:14 +0000

>Something really useful to do would be sorting out channel_id so we can do PoP for id tokens to make them and other cookies secure in the front channel.   I think that is a better use of time

Folks are already working on this and it does not take a anything from OAuth to make it work, OAuth Tokens can be used and there is not a need for OAuth POP Tokens. A4C is already in use on one of the largest IdPs, but I don’t think you would understand how useful it is

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 1:54 PM
To: [email-masked]
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:50 PM, [email-masked]<mailto:[email-masked]> wrote:

we are two, at least :-)

John B.
Sent from my iPhone

On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
You are right from a theoretical perspective. Practically this was caused by editorial decisions during the creation of the RFC. As far as I remember, there was a definition of the (one) token endpoint response in early versions. No one every considered to NOT respond with an access token from the token endpoint. So one might call it an implicit assumption.

regards,
Torsten.

Am 23.07.2014 um 15:41 schrieb Thomas Broyer <[email-masked]<mailto:[email-masked]>>:

Is it said anywhere that ALL grant types MUST use Section 5.1 responses? Each grant type references Section 5.1, and "access token request" is only defined in the context of the defined grant types. Section 2.2 doesn't talk about the request or response format.
Le 23 juil. 2014 21:32, "Nat Sakimura" <[email-masked]<mailto:[email-masked]>> a écrit :
Is it? Apart from the implicit grant that does not use token endpoint, all other grant references section 5.1 for the response, i.e., all shares the same response.

2014-07-23 15:18 GMT-04:00 Thomas Broyer <[email-masked]<mailto:[email-masked]>>:

I hadn't realized the JSON response that requires the access_token field is defined per grant_type, so I'd be OK to "extend the semantics" as in the current draft.
That was actually my main concern: that the token endpoint mandates access_token; but its actually not the case.
Le 23 juil. 2014 20:46, "Nat Sakimura" <[email-masked]<mailto:[email-masked]>> a écrit :

grant

grant_type

Nat

2014-07-23 13:39 GMT-04:00 Mike Jones <[email-masked]<mailto:[email-masked]>>:
You need the alternative response_type value ("code_for_id_token" in the A4C draft) to tell the Authorization Server to return a code to be used with the new grant type, rather than one to use with the "authorization_code" grant type (which is what response_type=code does).

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 24 Jul 2014 08:29:14 -0400

And here is a quote from Ian's blog.

And although the authentication wheel is round, that doesn’t mean it isn’t
> without its lumps. First, we do see some reinventing the wheel just to
> reinvent the wheel. OAuth A4C is simply not a fruitful activity and should
> be put down.

> (Source)
> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley <[email-masked]>:

> Something really useful to do would be sorting out channel_id so we can do
> PoP for id tokens to make them and other cookies secure in the front
> channel.   I think that is a better use of time.
>
>  You are right from a theoretical perspective. Practically this was
> caused by editorial decisions during the creation of the RFC. As far as I
> remember, there was a definition of the (one) token endpoint response in
> early versions. No one every considered to NOT respond with an access token
> from the token endpoint. So one might call it an implicit assumption.
>
> I'm worried that people get totally confused if an exception is introduced
> now given the broad adoption of OAuth based on this assumption.
>
> regards,
> Torsten.
>
>> Is it? Apart from the implicit grant that does not use token endpoint,
>> all other grant references section 5.1 for the response, i.e., all shares
>> the same response.
>>
>>
>>>> I am somewhat ambivalent[1] in changing the semantics of token
>>>> endpoint, but in as much as "text is the king" for a spec., we probably
>>>> should not change the semantics of it as Torsten points out. If it is ok to
>>>> change this semantics, I believe defining a new parameter to this endpoint
>>>> to control the response would be the best way to go. This is what I have
>>>> described previously.
>>>>
>>>>>  You need the alternative response_type value ("code_for_id_token" in
>>>>> "authorization_code" grant type (which is what response_type=code does).
>>>>>
>>>>>
>>>>>
>>>>> wrt to a potential "no_access_token" grant type. I do not consider
>>>>> this a good idea as it changes the semantics of the token endpoint (as
>>>>> No, I mean response_type=none and response_type=id_token don't
>>>>> generate a code or access token so you don't use the Token Endpoint (which
>>>>> is not the same as the Authentication Endpoint BTW).
>>>>>
>>>>> Then define the behavior of the endpoint according to the values as
>>>>> the parallel to the multi-response type spec.
>>>>>
>>>>> "The a4c response type and grant type return an id_token from the
>>>>> token endpoint with no access token. All parameters and values are defined
>>>>> in OIDC."
>>>>>
>>>>> >>>> Errors like these make it clear to me that it would make much
>>>>> more sense to develop this document in the OpenID Foundation. It should be
>>>>> >>>>>> Thanks for your review, Thomas.  The "prompt=consent"
>>>>> definition being missing is an editorial error.  It should be:
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> consent
>>>>> >>>>>>
>>>>> >>>>> It looks like the consent_required error needs to be defined
>>>>> too, and you might have forgotten to also import account_selection_required
>>>>> from OpenID Connect.
>>>>> >>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jul 2014 13:08:22 +0000

if we take Ian’s non technical  advice then most of the work in Oauth should be put down.

From: OAuth [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Thursday, July 24, 2014 5:29 AM
To: John Bradley
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down.

(Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html

2014-07-23 16:53 GMT-04:00 John Bradley <[email-masked]<mailto:[email-masked]>>:
I thought I did post this to the list.

John B.
Sent from my iPhone

we are two, at least :-)

John B.
Sent from my iPhone

regards,
Torsten.

grant

grant_type

Nat

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 06:52:32 -0700

I'd note that the reaction at the conference to Ian's statement was
overwhelmingly positive. There was a wide range of industry people here -
implementers, practitioners, deployers, strategists, etc. - and it seems
pretty clear that the "rough consensus" of the industry at large is that
a4c is not wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <[email-masked]> wrote:

>> Something really useful to do would be sorting out channel_id so we can
>> do PoP for id tokens to make them and other cookies secure in the front
>> I'm worried that people get totally confused if an exception is
>> introduced now given the broad adoption of OAuth based on this assumption.
>>
>> regards,
>> Torsten.
>>
>>  Is it said anywhere that ALL grant types MUST use Section 5.1
>> responses? Each grant type references Section 5.1, and "access token
>> request" is only defined in the context of the defined grant types. Section
>> 2.2 doesn't talk about the request or response format.
>>>> I hadn't realized the JSON response that requires the access_token
>>>> field is defined per grant_type, so I'd be OK to "extend the semantics" as
>>>> in the current draft.
>>>>  I agree with John that overloading response_type @ authz endpoint is
>>>>> a bad idea. It completely changes the semantics of this parameter. NOTE:
>>>>> what I was proposing was not this parameter, but a new parameter
>>>>> response_type @ token endpoint.
>>>>>
>>>>> Defining a new endpoint to send code to get ID Token and forbidding
>>>>> the use of it against token endpoint would not change the semantics of any
>>>>>>  You need the alternative response_type value ("code_for_id_token"
>>>>>> in the A4C draft) to tell the Authorization Server to return a code to be
>>>>>> used with the new grant type, rather than one to use with the
>>>>>>  The "response type" of the token endpoint is controlled by the
>>>>>> value of the parameter "grant_type". So there is no need to introduce a new
>>>>>> parameter.
>>>>>>
>>>>>> The response_type "none" is already used in practice, which returns
>>>>>> no access token.  It was accepted by the designated experts and registered
>>>>>> in the IANA OAuth Authorization Endpoint Response Types registry at
>>>>>> Response type on the other hand is not so well defined in RFC6749,
>>>>>> but it seems it is representing what is to be returned from the
>>>>>> authorization endpoint. To express what is to be returned from token
>>>>>> endpoint, perhaps defining a new parameter to the token endpoint, which is
>>>>>> a parallel to the response_type to the Authorization Endpoint seems to be a
>>>>>> more symmetric way, though I am not sure at all if that is going to be
>>>>>> OAuth any more. One straw-man is to define a new parameter called
>>>>>> response_type to the token endpoint such as:
>>>>>>
>>>>>>
>>>>>>
>>>>>> response_type
>>>>>>
>>>>>> >>>>>> The Authorization Server SHOULD prompt the End-User for
>>>>>> consent before returning information to the Client. If it cannot obtain
>>>>>> consent, it MUST return an error, typically consent_required.
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jul 2014 14:00:41 +0000

I’m sure it was spun in a way that could be true since there was no technical value to Ian’s statement and I’m sure that folks had not read or understand the usage.

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

I'd note that the reaction at the conference to Ian's statement was overwhelmingly positive. There was a wide range of industry people here - implementers, practitioners, deployers, strategists, etc. - and it seems pretty clear that the "rough consensus" of the industry at large is that a4c is not wanted or needed.

On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
And here is a quote from Ian's blog.

John B.
Sent from my iPhone

we are two, at least :-)

John B.
Sent from my iPhone

regards,
Torsten.

grant

grant_type

Nat

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 24 Jul 2014 14:05:40 +0000

I'll second this sentiment. Ian's overall talk was about when reinventing wheels was a good thing (like XML -> JSON), and he called out A4C specifically as an example of reinvention for its own sake, a harmful and wasteful practice. It was a very good keynote talk, and I highly recommend that people read the blog post(s) and look for the videos once they're posted.

 -- Justin

On Jul 24, 2014, at 9:52 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

John B.
Sent from my iPhone

we are two, at least :-)

John B.
Sent from my iPhone

regards,
Torsten.

grant

grant_type

Nat

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 07:18:32 -0700

There is a lot of spin being applied, yes. But not from Ian.

On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin <[email-masked]>
wrote:

>  I’m sure it was spun in a way that could be true since there was no
> technical value to Ian’s statement and I’m sure that folks had not read or
> understand the usage.
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 24, 2014 6:53 AM
> *To:* Nat Sakimura
> *Cc:* [email-masked] list
>
>  You need the alternative response_type value ("code_for_id_token" in the

---

From: John Bradley <[email-masked]>
Date: Thu, 24 Jul 2014 07:25:04 -0700

I am not against discussion in the WG.

I happen to agree with Phil's fundamental premise that some developers are using OAuth in a insecure way to do authentication.

That raises the question of how to best educate them, and or address technical barriers.

It is on the second point that people's opinions seem to divide.

Some people thing that if we have a OAuth flow that eliminates the access token (primarily to avoid asking for consent as I understand it) and just return a id_token from the token endpoint that can be done in a spec short enough to het people to read.   The subtext of this is that the Connect specification is too large that it scare people,  and they don't find the spec in the first place because it is not a RFC.

An other common possession is that if you don't want to prompt the user for consent then don't ask for scopes.  Twisting the OAuth spec to not return an access token is not OAuth,  yes you could use a different endpoint rather than the token endpoint, but that is not OAuth.   Connect was careful not to break the OAuth spec.    As long as you are willing to take a access token with no scopes (the client needs to understand that there are no attributes one way or another anyway or it will break) then you don't need to change OAuth.   You can publish a profile of connect that satisfies the use case.

I think Mike has largely done that but it might be better being less stingy on references back to the larger spec.

The questions are do we modify OAuth to not return an access token, and if so how,  and if we do is it still OAuth.

The other largely separable question is do we create confusion in the market and slow the the adoption of identity federation on top of OAuth, or find a way to make this look like a positive alignment of interests around a subset of Connect.

There are a number of options.  
1: We can do a profile in the OIDF and publish it as a IETF document.   Perhaps the cleanest from an IPR point of view.
2:We can do a profile in the OAuth WG referencing connect.
3:We can do a AD sponsored profile that is not in the OAuth WG.
4:We can do a small spec in OAuth to add response_type to the token endpoint.  in combination with 1, 2, or 3

I agree that stoping developers doing insecure things needs to be addressed somehow.  
I am not personally convinced that Oauth without access tokens is sensible.

Looking forward to the meeting:)

John B.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 Jul 2014 10:30:04 -0400

Horseshit.

Ian failed to mention that we’re responding to bad use of 6749 by assuming receipt of access token == authentication.

The OAuth WG is not creating a new feature and we are not re-inventing here. If anyone is, one could argue that would be OpenID —> at least in the minds of the web developers. They don’t get why they have to use OpenID at all.  Doesn’t OAuth already do this???

The working group is responding to an issue that the market has ALREADY chosen to do all by itself without the presence of any additional specification like A4C or for that matter OpenID.

The market is doing this because they are under the false assumption that OAuth is doing authentication and that receipt of the access token IS authentication. It is unbelievable how many developers think OAuth stands for Open Authentication.  The specifications are clear. Yet, the problem persists.

If a developer already thinks they have a solution that is good enough, why would they go to another standards organization? They aren’t even looking for an OpenID. They think they already have THE solution!  Which is precisely why OpenID can’t address the issue by itself!  OpenID as an authenticator *is* re-invenention.  Yes, OpenID as an IDP provider standard is its own innovation (re-inventing SAML and many many other protocols of the past), but within the realm of OAuth, yes it is innovation in my opinion.. 

But keep in mind that these developers do NOT want an IDP architecture.

My point in producing the original draft was to show how simple the correction could be — a few pages of clarifying text.

Since OpenID has been proposed as the simple solution, let me point out why it is not for these developers: it is a specification that incredibly complicates OAuth:
OpenID adds 6 response types to OAuth’s 2
OpenID adds 6 errors to OAuth’s 4
OpenID doubles the number of parameters
OpenID’s core specification is approximately NINETY THREE pages to 6749’s 76 pages

I’m not at all saying that OpenID is bad. If you want an IDP, its fine.  But if all a client wants is authentication, they think why can’t I just use RFC6749?

The people in the CIS audience were not aware of the facts, so of course, they cheered against what appears to be a fork. That’s after all how it was presented. In fact, Ian’s presentation sounds horribly trivial and insensitive in its handling of this case.

The point is, NOT responding to this issue does not mean it goes away. It gets worse. The market is already choosing to use OAuth for authentication. Apparently none of those people were at CIS.  They should have listened to Ian!

Phil

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

On Jul 24, 2014, at 10:18 AM, Brian Campbell <[email-masked]> wrote:

> On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin <[email-masked]> wrote:

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 Jul 2014 10:33:41 -0400

+1

Phil

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Jul 2014 14:49:25 +0000

Here’s a point of technical discussion for your consideration about the current content of a4c and a possible simplification.

Having thought about the views expressed about defining the new response type and grant type values, I came up with a possible syntax change that would be much more minimal and accomplish the same thing.  Rather than defining a new response type and a new grant type, instead, we could just use the existing code flow and say that it's legal for the token endpoint to return the value "access_token=none".  That way, the delta to OAuth 2.0 for the no-access-token case would be very small and the syntax of the response from the token endpoint would be unchanged.

And while people might initially think that since we’d be defining a distinguished access_token result value we might be stepping on implementations, "none" doesn't meet the minimum entropy requirements in OAuth 2.0, so wouldn't conflict with any conforming implementation.

                                                            Best wishes,

                                                            -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, July 24, 2014 7:34 AM
To: John Bradley
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

+1

Phil

@independentid

On Jul 24, 2014, at 10:25 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.
On Jul 24, 2014, at 6:52 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

John B.
Sent from my iPhone

we are two, at least :-)

John B.
Sent from my iPhone

regards,
Torsten.

grant

grant_type

Nat

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Thu, 24 Jul 2014 08:32:16 -0700

The audience of a access token is a RS,  and we have a principal of the token being opaque to the client.

On the other hand that is in line with what In was thinking.   It is a access token with no scopes that confers no access to a resource.
We can define a sting for that or perhaps a JWT with a claim, to fit with future interoperable access tokens using JWT in PoP and other places.

I was thinking that the token_endpoint also returns the scopes granted as another parameter.

Given that the access token is opaque but the scopes for the token are not, it may fit better with existing libraries to just have a reserved scope "urn:ietf:oauth:no-at-scopes"  returned to indicate that there are no resource grants associated with the issued AT.

If we want to get down to it that doesn't step on namespace and is 100% compatible with the existing OAuth spec.   
A scope and a flag for each of the token types, eg none for bearer and a claim in the JWT for the PoP types, but that probably should be part of the token definition.  

John B.

On Jul 24, 2014, at 7:49 AM, Mike Jones <[email-masked]> wrote:

> The response_type "none" is already used in practice, which returns no access token.  It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry athttp://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint.  The registered "id_token" response type also returns no access token.
>  
> From: OAuth [mailto:[email-masked]] On Behalf OfPhil Hunt

---

From: [email-masked]
Date: Thu, 24 Jul 2014 11:33:46 -0400

I honestely don't understand why you care about omiting the access token
on the token endpoint response. You want to omit user consent? Fine, do
it. There is no text in the spec that forces an AS to explicitely
acquire user consent. Authorization from the resource owner can be
acquired in many ways, showing an user consent page is just one option.
We authorize DT internal services using a pre-configured policy. So the
customer will never (need to) see a consent screen. The same approach
can be used in enterprise deployments. 

regards,
Torsten. 

Am 24.07.2014 10:49, schrieb Mike Jones: 

> Here's a point of technical discussion for your consideration about the current content of a4c and a possible simplification. 
> 
> And while people might initially think that since we'd be defining a distinguished access_token result value we might be stepping on implementations, "none" doesn't meet the minimum entropy requirements in OAuth 2.0, so wouldn't conflict with any conforming implementation. 
> 
> Best wishes, 
> 
> -- Mike 
> 
> SENT: Thursday, July 24, 2014 7:34 AM
> TO: John Bradley
> CC: [email-masked] list
> www.independentid.com [3] 
> 
> [email-masked] 
> 
>> And although the authentication wheel is round, that doesn't mean it isn't without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity and should be put down.
> 
>> (Source) http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html [1]
> 
> FROM: OAuth [mailto:[email-masked]] ON BEHALF OF John Bradley
> SENT: Wednesday, July 23, 2014 10:33 AM
> TO: [email-masked] 
> 
> CC: [email-masked]
> The response_type "none" is already used in practice, which returns no access token. It was accepted by the designated experts and registered in the IANA OAuth Authorization Endpoint Response Types registry at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint [4]. The registered "id_token" response type also returns no access token. 
> 
> www.independentid.com [5] 
> 
> [email-masked] 
> 
> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html [6] 
> 
> Nat 
> 
>>>>>> /tɔ.ma.bʁwa.je/ [7]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth [2]
>>>>>
>>>>>
>>>>>
>>>>> https://www.ietf.org/mailman/listinfo/oauth [2]
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> http://nat.sakimura.org/ [8]
>>>> @_nat_en
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth [2]
>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://nat.sakimura.org/ [8]
>> @_nat_en 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> http://nat.sakimura.org/ [8]
> @_nat_en 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> http://nat.sakimura.org/ [8]
> @_nat_en 
> 
> https://www.ietf.org/mailman/listinfo/oauth [2] 
> 
> -- 
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ [7] 
> 
> https://www.ietf.org/mailman/listinfo/oauth [2] 
> 
> -- 
> Thomas Broyer
> /tɔ.ma.bʁwa.je/ [7] 
> 
> https://www.ietf.org/mailman/listinfo/oauth [2] 
> 
> -- 
> Nat Sakimura (=nat) 
> 
> http://nat.sakimura.org/ [8]
> @_nat_en 
> 
> https://www.ietf.org/mailman/listinfo/oauth [2]

> https://www.ietf.org/mailman/listinfo/oauth [2]

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

-- 
 Nat Sakimura (=nat) 

Chairman, OpenID Foundation
http://nat.sakimura.org/ [8]
 @_nat_en 

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

-- 
 Nat Sakimura (=nat) 

Chairman, OpenID Foundation
http://nat.sakimura.org/ [8]
 @_nat_en 

> https://www.ietf.org/mailman/listinfo/oauth [2]

> https://www.ietf.org/mailman/listinfo/oauth [2]

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

-- 
 Nat Sakimura (=nat) 

Chairman, OpenID Foundation
http://nat.sakimura.org/ [8]
 @_nat_en 

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

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

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

Links:
------
[1]
http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html
[2] https://www.ietf.org/mailman/listinfo/oauth
[3] http://www.independentid.com
[4]
http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint
[5] http://www.independentid.com/
[6] http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
[7] http://xn--nna.ma.xn--bwa-xxb.je/
[8] http://nat.sakimura.org/

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 24 Jul 2014 11:50:37 -0400

2014-07-24 10:30 GMT-04:00 Phil Hunt <[email-masked]>:

> I’m not at all saying that OpenID is bad. If you want an IDP, its fine.
>  But if all a client wants is authentication, they think why can’t I just
> use RFC6749?

If all what one wants is to build a simple client, there is a standing
document called OpenID Connect Basic Client Implementer's Guide 1.0.

It is a profile that deals only the 'code' flow.
Size-wise, it is 32 pages. The break down are as below approximately:

Abstract, Intro, ToC - 2.5 pages
Terminology - 1.5 pages
Getting ID Token - 9 pages
ID Token Validation - 1 page (Seems missing from a4c draft?)
Userinfo Endpoint - 7 pages
Serializations - 1 page (missing in a4c?)
String Operations etc. - 1 pages (missing in a4c?)
Considerations - 2 pages (very brief in a4c)
References, Acknowledgement - 2 pages
Document History etc. - 7 pages

The a4c draft is 14 pages long. It will be longer than this in the end as
it is missing bunch of things.
The comparable portion of the Basic Client Profile is 14 pages or so.

Just one data point.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 Jul 2014 11:57:33 -0400

Nat,

You don't have to convince me. 

You have to sell all the people not implementing OpenId who think OAuth is sufficient. 

I agree A4C is currently too long. I think Mike and John may be on to something even better. 

Phil

> On Jul 24, 2014, at 11:50, Nat Sakimura <[email-masked]> wrote:
> 
> 
> If all what one wants is to build a simple client, there is a standing document called OpenID Connect Basic Client Implementer's Guide 1.0. 
> 
> The a4c draft is 14 pages long. It will be longer than this in the end as it is missing bunch of things.

---

From: Dale Olds <[email-masked]>
Date: Thu, 24 Jul 2014 09:32:12 -0700

Phil,

I thoroughly enjoy working with you whenever I can, and I really liked 
your work on SCIM, but from the perspective of the web developers I work 
with, I have a few concerns about what you wrote:

1. Developer experience and usability of the standards

You keep mentioning that web developers are demanding the new spec 
because they don't understand/use OAuth2 properly. I estimate that most 
people on this thread know web developers that they can claim to 
represent -- so I'd rather hear what you think and why.

 From my reading, the rough consensus appears to be that everyone agrees 
that OIDC and OAuth2 could be improved, and better developer experience 
is one of those improvements.

However, after reading your draft (basically because of Ian's 
presentation) it does appear to me that some minor changes/additions to 
OIDC would suffice. Personally, I don't see the requirement to NOT 
return an access token as significant or even desirable in most use cases.

I'd rather focus on the one point in 30 years where the industry has 
agreed on a core identity stack (OAuth2/OIDC/SCIM) and move on to 
adoption and improved developer education/experience.

2. Standards bodies, corporations, and IPR issues

John's suggestion to link OIDC and an IETF draft for the minor additions 
sounds reasonable as well, but, from my limited recent involvement, it 
brings up a MUCH more concerning issue. I've always associated IETF as 
the primary example of successful standards that are not overly 
influenced by useless specs and large corporations. Interestingly, 
overlarge, unnecessary specs and large corporations tend to go together.

Is the real issue here that some large corporations object to OIDF IPR 
policy or weren't in the initial bandwagon -- so they must drive another 
spec. Really? Is this just WS-Fed vs SAML again?

Personally, I'd hate to see the great individualistic, running-code, 
rough-consensus body of the IETF do unnecessary (and market confusing) 
work to satisfy a few lawyers' comfort zone.

--Dale

On 07/24/2014 08:57 AM, Phil Hunt wrote:
> On Jul 24, 2014, at 11:50, Nat Sakimura <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>> 2014-07-24 10:30 GMT-04:00 Phil Hunt <[email-masked] 
>> <mailto:[email-masked]>>:
>>
>>     I’m not at all saying that OpenID is bad. If you want an IDP, its
>>     fine.  But if all a client wants is authentication, they think
>>     why can’t I just use RFC6749?
>>
>>
>> If all what one wants is to build a simple client, there is a 
>> standing document called OpenID Connect Basic Client Implementer's 
>> Guide 1.0.
>>
>> <https://urldefense.proofpoint.com/v1/url?u=http://nat.sakimura.org/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=tZSv3T50ptdrF5VJeQfPow%3D%3D%0A&m=%2FHNlBS8t0nyksP6%2BTpUnVRbQACmczqcvThYucu1ZQ2w%3D%0A&s=732c8cb2c5d1c3c9a006c865feda78fd7564d8b192d20b2c7879bb53c23d25d9>
>> @_nat_en
>
>
> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/listinfo/oauth&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=tZSv3T50ptdrF5VJeQfPow%3D%3D%0A&m=%2FHNlBS8t0nyksP6%2BTpUnVRbQACmczqcvThYucu1ZQ2w%3D%0A&s=a9405b77aec5d4156f53d2912a337b972dbbc4ba7ebd16121efbd325de47c65a

---

From: Bill Burke <[email-masked]>
Date: Thu, 24 Jul 2014 12:47:20 -0400

> Horseshit.

Horseshit to your horseshit.

> Ian failed to mention that we’re responding to bad use of 6749 by
> assuming receipt of access token == authentication.
>
> The OAuth WG is not creating a new feature and we are not re-inventing
> here. If anyone is, one could argue that would be OpenID —> at least in
> the minds of the web developers. They don’t get why they have to use
> OpenID at all.  Doesn’t OAuth already do this???
>

Maybe from your perspective.  From my perspective in the Java community 
at least, security for REST services is a cluster fuck.  Developers in 
the Java community are looking for answers.  For most of them, security 
is an afterthought done at the last minute.  They think OAuth will solve 
their RESTful security issues only to find that OAuth is just a 
framework not a protocol and delegates many difficult issues to 
underlying implementations.

> The working group is responding to an issue that the market has ALREADY
> chosen to do all by itself without the presence of any additional
> specification like A4C or for that matter OpenID.
>
> The market is doing this because_ they are under the false assumption
> that OAuth is doing authentication_ and that receipt of the access token
> IS authentication. It is unbelievable how many developers think OAuth
> stands for Open Authentication.  The specifications are clear. Yet, the
> problem persists.
>
> If a developer already thinks they have a solution that is good enough,
> why would they go to another standards organization? They aren’t even
> looking for an OpenID. They think they already have THE solution!  Which
> is precisely why OpenID can’t address the issue by itself!  OpenID as an
> authenticator *is* re-invenention.  Yes, OpenID as an IDP provider
> standard is its own innovation (re-inventing SAML and many many other
> protocols of the past), but within the realm of OAuth, yes it is
> innovation in my opinion..
>

Ridiculous statements.  How does anything above justify the existence of 
A4C.  If developers already have their solutions, why would they give a 
shit about A4C?

> But keep in mind that these developers do NOT want an IDP architecture.

Says who?  You?  And what does an IDP architecture have to do with Open 
ID Connect or its use with OIDC?  You can still use a vanilla OAuth2 
client library with an IDP that implements Open ID Connect.

> My point in producing the original draft was to show how simple the
> correction could be — a few pages of clarifying text.
>
> Since OpenID has been proposed as the simple solution, let me point out
> why it is not for these developers: it is a specification that
> incredibly complicates OAuth:
>
>   * OpenID adds 6 response types to OAuth’s 2
>   * OpenID adds 6 errors to OAuth’s 4
>   * OpenID doubles the number of parameters
>   * OpenID’s core specification is approximately NINETY THREE pages to
>     6749’s 76 pages
>

Like many have said over and over, A4C is already covered by OpenID. 
The subset of A4C is already legal under OpenID.

Besides, you actually think web developers care about reading some IETF 
specification?  From my 20+ years of developing middleware, developers 
do not read specifications!  They read the documentation and examples of 
the frameworks that implement these specifications.

>   But if all a client wants is authentication, they think why can’t I
> just use RFC6749?
>

Yup.  Like I said before.  If the IDP implements OpenID Connect, there 
is nothing stopping a client just using vanilla OAuth.

> The people in the CIS audience were not aware of the facts, so of
> course, they cheered against what appears to be a fork. That’s after all
> how it was presented. In fact, Ian’s presentation sounds horribly
> trivial and insensitive in its handling of this case.
>
> The point is, NOT responding to this issue does not mean it goes away.
> It gets worse. The market is already choosing to use OAuth for
> authentication.

And OpenID Connect is OAUTH!

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: Phil Hunt <[email-masked]>
Date: Thu, 24 Jul 2014 13:15:48 -0400

My comments are not motivated in any way by my employer. The probably wish like you I would drop it. 

I am simply reporting what I see in the wild. 

Phil

> On Jul 24, 2014, at 12:47, Bill Burke <[email-masked]> wrote:
> 
> 
> 
> Maybe from your perspective.  From my perspective in the Java community at least, security for REST services is a cluster fuck.  Developers in the Java community are looking for answers.  For most of them, security is an afterthought done at the last minute.  They think OAuth will solve their RESTful security issues only to find that OAuth is just a framework not a protocol and delegates many difficult issues to underlying implementations.
> 
> Ridiculous statements.  How does anything above justify the existence of A4C.  If developers already have their solutions, why would they give a shit about A4C?
> 
> Says who?  You?  And what does an IDP architecture have to do with Open ID Connect or its use with OIDC?  You can still use a vanilla OAuth2 client library with an IDP that implements Open ID Connect.
> 
> Like many have said over and over, A4C is already covered by OpenID. The subset of A4C is already legal under OpenID.
> 
> 
> Besides, you actually think web developers care about reading some IETF specification?  From my 20+ years of developing middleware, developers do not read specifications!  They read the documentation and examples of the frameworks that implement these specifications.
> 
>> 
> Yup.  Like I said before.  If the IDP implements OpenID Connect, there is nothing stopping a client just using vanilla OAuth.
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 10:21:43 -0700

I'm sorry to miss what will likely be a very engaging meeting today.

The premise that some developers are using OAuth in a insecure way to do
authentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solution
is yet another spec which either duplicates some subset of OpenID Connect
(in a different SDO) or forks how to do SSO/authentication using OAuth.

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley <[email-masked]> wrote:

> I happen to agree with Phil's fundamental premise that some developers are
> using OAuth in a insecure way to do authentication.
>
> Some people thing that if we have a OAuth flow that eliminates the access
> token (primarily to avoid asking for consent as I understand it) and just
> return a id_token from the token endpoint that can be done in a spec short
> enough to het people to read.   The subtext of this is that the Connect
> specification is too large that it scare people,  and they don't find the
> spec in the first place because it is not a RFC.
>
> An other common possession is that if you don't want to prompt the user
> for consent then don't ask for scopes.  Twisting the OAuth spec to not
> return an access token is not OAuth,  yes you could use a different
> endpoint rather than the token endpoint, but that is not OAuth.   Connect
> was careful not to break the OAuth spec.    As long as you are willing to
> take a access token with no scopes (the client needs to understand that
> there are no attributes one way or another anyway or it will break) then
> you don't need to change OAuth.   You can publish a profile of connect that
> satisfies the use case.
>
> I think Mike has largely done that but it might be better being less
> stingy on references back to the larger spec.
>
> The other largely separable question is do we create confusion in the
> market and slow the the adoption of identity federation on top of OAuth, or
> find a way to make this look like a positive alignment of interests around
> a subset of Connect.
>
> 1: We can do a profile in the OIDF and publish it as a IETF document.
> Perhaps the cleanest from an IPR point of view.
>> And although the authentication wheel is round, that doesn’t mean it
>>> isn’t without its lumps. First, we do see some reinventing the wheel just
>>> to reinvent the wheel. OAuth A4C is simply not a fruitful activity and
>>> should be put down.
>>
>>
>>
>>> (Source)
>>>>>> I also think overloading grant_type is a bad idea since it changes
>>>>>> its semantics. I quote the definition here again:
>>>>>>
>>>>>>  grant

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Jul 2014 17:25:41 +0000

OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) but that is OK to do

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM
To: John Bradley
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

The premise that some developers are using OAuth in a insecure way to do authentication is something we can probably all agree on.

It doesn't necessarily follow from that premise, however, that the solution is yet another spec which either duplicates some subset of OpenID Connect (in a different SDO) or forks how to do SSO/authentication using OAuth.

On Thu, Jul 24, 2014 at 7:25 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I am not against discussion in the WG.

John B.

John B.
Sent from my iPhone

we are two, at least :-)

John B.
Sent from my iPhone

regards,
Torsten.

grant

grant_type

Nat

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list

---

From: John Bradley <[email-masked]>
Date: Thu, 24 Jul 2014 10:50:46 -0700

Connect needed to be completed.  To do that some things that were not Identity specific but required for Connect to be interoperable also needed to be completed in a stable form.

The fact that with some tweaking based on input from the IETF community like software statements Connect's dynamic registration could be generally applied to the problem of dynamic client registration for OAuth, should not come as a surprise.

Given the OIDF copyright of allowing derivative works with attribution this is not a unexpected or undesired outcome.

The outcome is more support for a spec that increases support and interoperability.

Yes the two are similar but not the same.

A IETF published profile of Connect using code flow only and not attaching scopes to the access token or additional claims to the id_token could be seen as a fine bridge for enterprise SSO moving from the old WS-* to something REST friendly on the road to full OAuth and Connect support.

The point for many of us is to make it clear that it is a step on a path and not to become it's own incompatible dead end where the clients libraries can't deal with access tokens or multiple issuers etc.

I also take Bills point about developers.

They care far more about good code examples on SalesForece,  Google, Microsoft and other sites as well as packaged library support from reliable open-source projects than they do about IETF or OIDF specifications

Better communication and support for developers is required.  How to do that is the more important discussion.   The format of a parameter to suppress an access_token being issued is largely a snipe hunt.

It is unfortunate that this is making some people cranky.

I think we do mostly agree that we have a communications and education problem.   Just because our main tool is crating new RFC's that doesn't necessarily mea that it is our only or best option in this case.

Best Regards
John B.

---

From: Bill Mills <[email-masked]>
Date: Thu, 24 Jul 2014 11:11:11 -0700

This could also be solved by explicitly defining a scope for access tokens specific to the needed (no-op?) behavior for ac4.

On Thursday, July 24, 2014 8:34 AM, "[email-masked]" <[email-masked]> wrote:

I honestely don't understand why you care about omiting the access token on the token endpoint response. You want to omit user consent? Fine, do it. There is no text in the spec that forces an AS to explicitely acquire user consent. Authorization from the resource owner can be acquired in many ways, showing an user consent page is just one option. We authorize DT internal services using a pre-configured policy. So the customer will never (need to) see a consent screen. The same approach can be used in enterprise deployments. 
regards,
Torsten.
Am 24.07.2014 10:49, schrieb Mike Jones:
Here's a point of technical discussion for your consideration about the current content of a4c and a possible simplification.
>From:OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
>>>>>>>From:OAuth [mailto:[email-masked]] On Behalf Of John Bradley
>>>>>>>>>From:OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Thu, 24 Jul 2014 11:17:41 -0700

Then why aren't people using this instead of (mis)using OAuth for this?

Different question, if we do define AC4 will people move to that, or continue doing the wrong thing anyway?

On Thursday, July 24, 2014 8:57 AM, Nat Sakimura <[email-masked]> wrote:

Just one data point.

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 24 Jul 2014 14:52:06 -0400

> Then why aren't people using this instead of (mis)using OAuth for this?

Even with a spec this short, IMHO, developers would not read it.
What they want is easy to read description with sample code, I suppose.
It also does not have adequate amount of publicity/marketing/education,
etc.
Example code repository in Github and Bitbucket etc. may help a bit.

> Different question, if we do define AC4 will people move to that, or
continue doing the wrong thing anyway?

They would not move to it because they will not read a spec.
Instead they will google or search stackoverflow for "OAuth Authentication
sample REST" or something like that and will use whatever comes up as easy
and appealing to read.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Jul 2014 19:30:57 -0600

The situations are rather different.

On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin <[email-masked]>
wrote:

> *Sent:* Thursday, July 24, 2014 10:22 AM
>
> *To:* John Bradley
> It doesn't necessarily follow from that premise, however, that the
> solution is yet another spec which either duplicates some subset of OpenID
> Connect (in a different SDO) or forks how to do SSO/authentication using
> OAuth.
>
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 25 Jul 2014 02:04:38 +0000

Oh yea, real different, give me a freaking break

From: Brian Campbell [mailto:[email-masked]]
Sent: Thursday, July 24, 2014 6:31 PM
To: Anthony Nadalin
Cc: John Bradley; [email-masked] list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
OMG, how can you say that when the Dynamkc Reg does the same thing (duplicates) but that is OK to do

From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM

To: John Bradley
Cc: [email-masked]<mailto:[email-masked]> list
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt

John B.

John B.
Sent from my iPhone

we are two, at least :-)

John B.
Sent from my iPhone

regards,
Torsten.

grant

grant_type

Nat

John B.

Sent from my iPhone

regards,
Torsten.

 Nat

 -- Justin

                                                            -- Mike

Phil

@independentid

authorization server

grant

grant_type

response_type

Nat

Phil

Nat

--Justin

/sent from my phone/

OAuth mailing list