subject:"\[OAUTH\-WG\] New Version Notification for draft\-hunt\-oauth\-v2\-user\-a4c\-05.txt"


Hi Phil

Thanks for the clarifications,
On 13/10/14 20:18, Phil Hunt wrote:

The point to be made is if the client’s objective is to authenticate the User, 
the base 6749 spec does not guarantee this at all.

It simply authorizes the client to access a resource and nothing more.

It turns out that a significant part of the time authentication does occur, but 
the client does not have access to that information. Nor can it specifically 
request re-authentication.

Further, if the client doesn’t wield the access token, its might not be proof 
that the token received was actually an authorization.

OpenID gives you both authen information and authorization profile information 
(as a resource).


Yes, I experimented with it.

This thread was more about how to do just authentication ONLY. What are the 
requirements for a client to know a User *was* authenticated and when.  While 
some flows of OpenID can achieve this, its not clear that it addresses all 
cases. Furhter there is discussion (as Justin mentions) that a flow that does 
not produce an access token is not an authorization flow and is not OAuth. I 
agree.

Sure.

It an authentication flow and should be distinct IMHO.

I guess that is why the idea of having an OIDC profile dedicated to the 
authentication alone (no access token) which I believe was suggested 
here caught my attention. But then it is not OAuth2 and hence not OIDC. 
The chicken in the egg situation :-). As I said in the prev email, 
having an access token which is really restricted to the OIDC resource 
(profile) seems like a good compromise...



That said, I am in the minority with this opinion and I acknowledge as being as 
such.



Sorry if I hijacked this thread and started the off-topic 'flow'...I 
guess my reasoning here is a bit all over the place, but I'm pretty sure 
now I see the big picture better


Thanks, Sergey


Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin  wrote:


On 13/10/14 15:17, Justin Richer wrote:

You certainly can do authentication without using an access token, but
then I would argue that's no longer OAuth. Basically you're making tofu
carob fudge.


Right, the access token is there for a client to get to the UserInfo endpoint, 
as far as OIDC is concerned. What if the info in the id_token is sufficient ?
I guess as far as a typical OAuth2 client is concerned, requesting "openid 
profile" only effectively gives one an access token that can only be used with the 
UserInfo endpoint.

So yes, may be even though OIDC has an access token returned, unless other 
custom scopes are used, the access token would be pretty much of use in the 
OIDC context only if a client chooses to work with the UserInfo...I guess the 
id_token/at_hash is useful on its own


Cheers, Sergey




-- Justin

/ Sent from my phone /


 Original message 
From: Sergey Beryozkin 
Date:10/13/2014 9:00 AM (GMT-05:00)
To: Justin Richer , oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-v2-user-a4c-05.txt

Hi Justin,
On 13/10/14 12:53, Justin Richer wrote:

You are correct in that OAuth 2 and OpenID Connect are not the same
thing, but your user is correct that OIDC adds a few pieces on top of
OAuth to add authentication capabilities. OIDC was designed very
explicitly to be compatible with vanilla OAuth, partially do that people
would be able to deploy it on top of existing OAuth infrastructure and
code. But the very fact that OIDC adds a few things on top of OAuth to
give more functionality should be sufficient evidence that they're not
equivalent.

It's more proper to say that OpenID Connect is an extension and
application of OAuth. One that provides an authentication and

identity API.



I agree and this is more or less how I answered.

Though the 'borders' can be blurred, one can claim that if a user
actually logs on into a confidential OAuth2 client web application which
redirects this user to AS requesting a code with some scopes such as "a
b" then when it uses "a b openid profile" it is basically does a pure
OAuth2 code flow where the client requests 'a b' plus also a scope
allowing it later to query the identity system on behalf of a user.

I like the "The extension and application of OAuth2" characteristic of
OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO
into non-OAuth2 servers, when it is the case then there's no 'feeling'
that OIDC is just a case of the confidential client adding the extra
scopes and getting the extra (authentication) info back. A standalone
OIDC RP protecting such non OAuth2 servers is very much about the
authentication/identity.

I also thought that having some OID profile (as opposed updating OAuth2
to support no access tokens) where no access but only id token was
returned (as suggested in this thread) wo

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

2014-10-13 Thread Phil Hunt

The point to be made is if the client’s objective is to authenticate the User, 
the base 6749 spec does not guarantee this at all.

It simply authorizes the client to access a resource and nothing more.

It turns out that a significant part of the time authentication does occur, but 
the client does not have access to that information. Nor can it specifically 
request re-authentication.

Further, if the client doesn’t wield the access token, its might not be proof 
that the token received was actually an authorization. 

OpenID gives you both authen information and authorization profile information 
(as a resource).

This thread was more about how to do just authentication ONLY. What are the 
requirements for a client to know a User *was* authenticated and when.  While 
some flows of OpenID can achieve this, its not clear that it addresses all 
cases. Furhter there is discussion (as Justin mentions) that a flow that does 
not produce an access token is not an authorization flow and is not OAuth. I 
agree. It an authentication flow and should be distinct IMHO.

That said, I am in the minority with this opinion and I acknowledge as being as 
such.
 
Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin  wrote:

> On 13/10/14 15:17, Justin Richer wrote:
>> You certainly can do authentication without using an access token, but
>> then I would argue that's no longer OAuth. Basically you're making tofu
>> carob fudge.
> 
> Right, the access token is there for a client to get to the UserInfo 
> endpoint, as far as OIDC is concerned. What if the info in the id_token is 
> sufficient ?
> I guess as far as a typical OAuth2 client is concerned, requesting "openid 
> profile" only effectively gives one an access token that can only be used 
> with the UserInfo endpoint.
> 
> So yes, may be even though OIDC has an access token returned, unless other 
> custom scopes are used, the access token would be pretty much of use in the 
> OIDC context only if a client chooses to work with the UserInfo...I guess the 
> id_token/at_hash is useful on its own
> 
> 
> Cheers, Sergey
> 
>> 
>> 
>> -- Justin
>> 
>> / Sent from my phone /
>> 
>> 
>>  Original message ----
>> From: Sergey Beryozkin 
>> Date:10/13/2014 9:00 AM (GMT-05:00)
>> To: Justin Richer , oauth@ietf.org
>> Cc:
>> Subject: Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-05.txt
>> 
>> Hi Justin,
>> On 13/10/14 12:53, Justin Richer wrote:
>> > You are correct in that OAuth 2 and OpenID Connect are not the same
>> > thing, but your user is correct that OIDC adds a few pieces on top of
>> > OAuth to add authentication capabilities. OIDC was designed very
>> > explicitly to be compatible with vanilla OAuth, partially do that people
>> > would be able to deploy it on top of existing OAuth infrastructure and
>> > code. But the very fact that OIDC adds a few things on top of OAuth to
>> > give more functionality should be sufficient evidence that they're not
>> > equivalent.
>> >
>> > It's more proper to say that OpenID Connect is an extension and
>> > application of OAuth. One that provides an authentication and
>> identity API.
>> >
>> I agree and this is more or less how I answered.
>> 
>> Though the 'borders' can be blurred, one can claim that if a user
>> actually logs on into a confidential OAuth2 client web application which
>> redirects this user to AS requesting a code with some scopes such as "a
>> b" then when it uses "a b openid profile" it is basically does a pure
>> OAuth2 code flow where the client requests 'a b' plus also a scope
>> allowing it later to query the identity system on behalf of a user.
>> 
>> I like the "The extension and application of OAuth2" characteristic of
>> OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO
>> into non-OAuth2 servers, when it is the case then there's no 'feeling'
>> that OIDC is just a case of the confidential client adding the extra
>> scopes and getting the extra (authentication) info back. A standalone
>> OIDC RP protecting such non OAuth2 servers is very much about the
>> authentication/identity.
>> 
>> I also thought that having some OID profile (as opposed updating OAuth2
>> to support no access tokens) where no access but only id token was
>> returned (as suggested in this thread) would probably make sense too.
>> 
>> > The way I like to explain it (which I stole from someone else)

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

On 13/10/14 15:17, Justin Richer wrote:

You certainly can do authentication without using an access token, but
then I would argue that's no longer OAuth. Basically you're making tofu
carob fudge.

Right, the access token is there for a client to get to the UserInfo 
endpoint, as far as OIDC is concerned. What if the info in the id_token 
is sufficient ?
I guess as far as a typical OAuth2 client is concerned, requesting 
"openid profile" only effectively gives one an access token that can 
only be used with the UserInfo endpoint.

So yes, may be even though OIDC has an access token returned, unless 
other custom scopes are used, the access token would be pretty much of 
use in the OIDC context only if a client chooses to work with the 
UserInfo...I guess the id_token/at_hash is useful on its own

Cheers, Sergey

-- Justin

/ Sent from my phone /

 Original message 
From: Sergey Beryozkin 
Date:10/13/2014 9:00 AM (GMT-05:00)
To: Justin Richer , oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-v2-user-a4c-05.txt

Hi Justin,
On 13/10/14 12:53, Justin Richer wrote:
 > You are correct in that OAuth 2 and OpenID Connect are not the same
 > thing, but your user is correct that OIDC adds a few pieces on top of
 > OAuth to add authentication capabilities. OIDC was designed very
 > explicitly to be compatible with vanilla OAuth, partially do that people
 > would be able to deploy it on top of existing OAuth infrastructure and
 > code. But the very fact that OIDC adds a few things on top of OAuth to
 > give more functionality should be sufficient evidence that they're not
 > equivalent.
 >
 > It's more proper to say that OpenID Connect is an extension and
 > application of OAuth. One that provides an authentication and
identity API.
 >
I agree and this is more or less how I answered.

Though the 'borders' can be blurred, one can claim that if a user
actually logs on into a confidential OAuth2 client web application which
redirects this user to AS requesting a code with some scopes such as "a
b" then when it uses "a b openid profile" it is basically does a pure
OAuth2 code flow where the client requests 'a b' plus also a scope
allowing it later to query the identity system on behalf of a user.

I like the "The extension and application of OAuth2" characteristic of
OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO
into non-OAuth2 servers, when it is the case then there's no 'feeling'
that OIDC is just a case of the confidential client adding the extra
scopes and getting the extra (authentication) info back. A standalone
OIDC RP protecting such non OAuth2 servers is very much about the
authentication/identity.

I also thought that having some OID profile (as opposed updating OAuth2
to support no access tokens) where no access but only id token was
returned (as suggested in this thread) would probably make sense too.

 > The way I like to explain it (which I stole from someone else) is that
 > OAuth is like chocolate and authentication is like fudge. They are not
 > the same thing. You can make chocolate into fudge out you can make it
 > into something else or you can just have it on its own. You can make
 > fudge with chocolate or you can make it with peanut butter or you can
 > make it with potatoes if you want to, but it needs a couple ingredients
 > and a very common one is chocolate. OpenID Connect is a recipe for
 > chocolate fudge that a lot of people like. And it makes my fudge
 > compatible with your fudge, which is where the metaphor breaks down. :-)
 >
Thanks for sharing this colourful explanation :-). Perhaps I should
borrow it :-),
Cheers, Sergey

 >
 > -- Justin
 >
 > / Sent from my phone /
 >
 >
 > ---- Original message --------
 > From: Sergey Beryozkin 
 > Date:10/13/2014 6:33 AM (GMT-05:00)
 > To: oauth@ietf.org
 > Cc:
 > Subject: Re: [OAUTH-WG] New Version Notification for
 > draft-hunt-oauth-v2-user-a4c-05.txt
 >
 > Hi
 >
 > We've had a user asserting that "OAuth2 == OpenidConnect", referring to
 > the fact that the 'only' thing OIC adds on top of the authorization code
 > flow is the client specifying few extra scopes like 'openid' and
 > 'profile' and the authorization service returning an extra property, the
 > id_token which can be sufficient in order to get the authenticated
 > user's info.
 >
 > My understanding "OAuth2 != OpenidConnect", the latter utilizes the
 > former and is an authentication mechanism which is not what OAuth2 is
 > (may be except for the client credentials). But I don't feel like it is
 > a convincing enough argument.
 >
 > I thought this thread was relevant, sorry if n

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

Hi Justin,
On 13/10/14 12:53, Justin Richer wrote:

You are correct in that OAuth 2 and OpenID Connect are not the same
thing, but your user is correct that OIDC adds a few pieces on top of
OAuth to add authentication capabilities. OIDC was designed very
explicitly to be compatible with vanilla OAuth, partially do that people
would be able to deploy it on top of existing OAuth infrastructure and
code. But the very fact that OIDC adds a few things on top of OAuth to
give more functionality should be sufficient evidence that they're not
equivalent.

It's more proper to say that OpenID Connect is an extension and
application of OAuth. One that provides an authentication and identity API.

I agree and this is more or less how I answered.

Though the 'borders' can be blurred, one can claim that if a user 
actually logs on into a confidential OAuth2 client web application which 
redirects this user to AS requesting a code with some scopes such as "a 
b" then when it uses "a b openid profile" it is basically does a pure 
OAuth2 code flow where the client requests 'a b' plus also a scope 
allowing it later to query the identity system on behalf of a user.

I like the "The extension and application of OAuth2" characteristic of 
OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO 
into non-OAuth2 servers, when it is the case then there's no 'feeling' 
that OIDC is just a case of the confidential client adding the extra 
scopes and getting the extra (authentication) info back. A standalone 
OIDC RP protecting such non OAuth2 servers is very much about the 
authentication/identity.

I also thought that having some OID profile (as opposed updating OAuth2 
to support no access tokens) where no access but only id token was 
returned (as suggested in this thread) would probably make sense too.

The way I like to explain it (which I stole from someone else) is that
OAuth is like chocolate and authentication is like fudge. They are not
the same thing. You can make chocolate into fudge out you can make it
into something else or you can just have it on its own. You can make
fudge with chocolate or you can make it with peanut butter or you can
make it with potatoes if you want to, but it needs a couple ingredients
and a very common one is chocolate. OpenID Connect is a recipe for
chocolate fudge that a lot of people like. And it makes my fudge
compatible with your fudge, which is where the metaphor breaks down. :-)

Thanks for sharing this colourful explanation :-). Perhaps I should 
borrow it :-),

Cheers, Sergey

-- Justin

/ Sent from my phone /

 Original message 
From: Sergey Beryozkin 
Date:10/13/2014 6:33 AM (GMT-05:00)
To: oauth@ietf.org
Cc:
Subject: Re: [OAUTH-WG] New Version Notification for
draft-hunt-oauth-v2-user-a4c-05.txt

Hi

We've had a user asserting that "OAuth2 == OpenidConnect", referring to
the fact that the 'only' thing OIC adds on top of the authorization code
flow is the client specifying few extra scopes like 'openid' and
'profile' and the authorization service returning an extra property, the
id_token which can be sufficient in order to get the authenticated
user's info.

My understanding "OAuth2 != OpenidConnect", the latter utilizes the
former and is an authentication mechanism which is not what OAuth2 is
(may be except for the client credentials). But I don't feel like it is
a convincing enough argument.

I thought this thread was relevant, sorry if not, would have no problems
starting a new one.

Basically, I wonder what is the proper line of argument for a position
such as "OAuth2 != OpenidConnect" and also what was the action to the
list of options suggested by John below. Is having an OID profile where
no access token is returned would be the cleanest action as far as
breaking the ambiguity/confusion is concerned ?

Cheers, Sergey

On 24/07/14 15:25, John Bradley wrote:
 > 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
 >

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

er, 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.


2014-07-23 13:39 GMT-04:00 Mike Jones
mailto:michael.jo...@microsoft.com>>:

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:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>] *On
                Behalf Of *John Bradley
        *Sent:* Wednesday, July 23, 2014 10:33 AM
        *To:* tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>


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


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,
tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net> wrote:

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

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

Oh yea, real different, give me a freaking break

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

The situations are rather different.

On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin 
mailto:tony...@microsoft.com>> 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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 10:22 AM

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

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 
mailto:ve7...@ve7jtb.com>> wrote:
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.

On Jul 24, 2014, at 6:52 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

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 
mailto:sakim...@gmail.com>> wrote:
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 
mailto:ve7...@ve7jtb.com>>:

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, 
tors...@lodderstedt

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

The situations are rather different.


On Thu, Jul 24, 2014 at 11:25 AM, Anthony Nadalin 
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:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 24, 2014 10:22 AM
>
> *To:* John Bradley
> *Cc:* oauth@ietf.org list
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>
> 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  wrote:
>
>  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.
>
>
>
> On Jul 24, 2014, at 6:52 AM, Brian Campbell 
> wrote:
>
>
>
>   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  wrote:
>
>  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 :
>
>

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

2014-07-24 Thread Nat Sakimura

2014-07-24 14:17 GMT-04:00 Bill Mills :
> 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.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2014-07-24 Thread Bill Mills

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  wrote:
 




2014-07-24 10:30 GMT-04:00 Phil Hunt :

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. 

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2014-07-24 Thread Bill Mills

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, "tors...@lodderstedt.net" 
 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.
> 
>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:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>Sent: Thursday, July 24, 2014 7:34 AM
>To: John Bradley
>Cc: oauth@ietf.org list
>Subject: Re: [OAUTH-WG] New Version Notification for 
>draft-hunt-oauth-v2-user-a4c-05.txt
> 
>+1
> 
>Phil
> 
>@independentid
>www.independentid.com
>phil.h...@oracle.com
> 
> 
> 
>On Jul 24, 2014, at 10:25 AM, John Bradley  wrote:
>
>
>
>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 do

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

2014-07-24 Thread John Bradley

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.

On Jul 24, 2014, at 10:25 AM, Anthony Nadalin  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:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, July 24, 2014 10:22 AM
> To: John Bradley
> Cc: oauth@ietf.org list
> Subject: Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-v2-user-a4c-05.txt
>  
> 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  wrote:
> 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 a

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

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

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

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 
mailto:ve7...@ve7jtb.com>> wrote:
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.

On Jul 24, 2014, at 6:52 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

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 
mailto:sakim...@gmail.com>> wrote:
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 
mailto:ve7...@ve7jtb.com>>:

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, 
tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> 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

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

gt;
>>> 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 <
>>> tors...@lodderstedt.net> 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.
>>>
>>> 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 :
>>>
>>>  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"  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 :
>>>>
>>>>> 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"  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.
>>>>>>
>>>>>> 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 doi

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

2014-07-24 Thread Justin Richer

We do the same thing with well-known (ie, whitelisted) client apps for both 
OIDC and vanilla OAuth. These are cases where the consent decision isn't in the 
users' hands, so we don't ask them. But here's the thing: that's an 
implementation detail of our AS policy, the clients are all just doing OAuth so 
the developers don't notice, and the users (for the most part) don't even 
realize they're going through an OAuth flow. Coupled with SSO, things "just 
work" for these cases, for both users and developers.

And I would further argue that if it's an unknown or untrusted client, I *want* 
user consent, even for just authentication. TOFU works great here.

--Justin

/sent from my phone/

On Jul 24, 2014 11:33 AM, tors...@lodderstedt.net 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.
>>
>>  
>>
>> 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:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>> Sent: Thursday, July 24, 2014 7:34 AM
>> To: John Bradley
>> Cc: oauth@ietf.org list
>> Subject: Re: [OAUTH-WG] New Version Notification for 
>> draft-hunt-oauth-v2-user-a4c-05.txt
>>
>>  
>>
>> +1
>>
>>  
>>
>> Phil
>>
>>  
>>
>> @independentid
>>
>> www.independentid.com
>>
>> phil.h...@oracle.com
>>
>>  
>>
>>  
>>
>>  
>>
>> On Jul 24, 2014, at 10:25 AM, John Bradley  wrote:
>>
>>
>>
>> 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

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

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  wrote:
> 
> 
> 
>> On 7/24/2014 10:30 AM, Phil Hunt wrote:
>> 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.
> 
>> 
>> 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?
> 
> 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
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2014-07-24 Thread Bill Burke




On 7/24/2014 10:30 AM, Phil Hunt wrote:

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.




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?



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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2014-07-24 Thread Dale Olds

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:

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 > wrote:

2014-07-24 10:30 GMT-04:00 Phil Hunt >:

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.

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en

___
OAuth mailing list
OAuth@ietf.org
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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

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  wrote:
> 
> 
> 2014-07-24 10:30 GMT-04:00 Phil Hunt :
>> 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. 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2014-07-24 Thread Nat Sakimura

2014-07-24 10:30 GMT-04:00 Phil Hunt :

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

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2014-07-24 Thread John Bradley

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  wrote:

> 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:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
> Sent: Thursday, July 24, 2014 7:34 AM
> To: John Bradley
> Cc: oauth@ietf.org list
> Subject: Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-v2-user-a4c-05.txt
>  
> +1
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>  
>  
>  
> On Jul 24, 2014, at 10:25 AM, John Bradley  wrote:
> 
> 
> 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 pu

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

2014-07-24 Thread torsten

 

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. 
> 
> 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:oauth-boun...@ietf.org] ON BEHALF OF Phil Hunt
> SENT: Thursday, July 24, 2014 7:34 AM
> TO: John Bradley
> CC: oauth@ietf.org list
> SUBJECT: Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-v2-user-a4c-05.txt 
> 
> +1 
> 
> Phil 
> 
> @independentid 
> 
> www.independentid.com [3] 
> 
> phil.h...@oracle.com 
> 
> On Jul 24, 2014, at 10:25 AM, John Bradley  wrote: 
> 
> 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. 
> 
> On J

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

2014-07-24 Thread Mike Jones

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:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Thursday, July 24, 2014 7:34 AM
To: John Bradley
Cc: oauth@ietf.org list
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

+1

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>



On Jul 24, 2014, at 10:25 AM, John Bradley 
mailto:ve7...@ve7jtb.com>> wrote:


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.
On Jul 24, 2014, at 6:52 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:


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 
mailto:sakim...@gmail.com>> wrote:
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-s

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

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

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

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
phil.h...@oracle.com

On Jul 24, 2014, at 10:18 AM, Brian Campbell  wrote:

> There is a lot of spin being applied, yes. But not from Ian.
> 
> 
> On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin  
> 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:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Thursday, July 24, 2014 6:53 AM
> To: Nat Sakimura
> Cc: oauth@ietf.org 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  wrote:
> 
> 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 :
> 
>  
> 
> 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, tors...@lodderstedt.net 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 a

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

2014-07-24 Thread John Bradley

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 :
>>>> 
>>>>> 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"  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 :
>>>>> 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"  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. 
>>>>>  
>>>>> 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 
>>>>&g

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

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


On Thu, Jul 24, 2014 at 7:00 AM, Anthony Nadalin 
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:oauth-boun...@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Thursday, July 24, 2014 6:53 AM
> *To:* Nat Sakimura
> *Cc:* oauth@ietf.org 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  wrote:
>
>  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 :
>
>
>
>  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, tors...@lodderstedt.net 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 
> 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.
>
>
>
> 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 :
>
>  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"  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 :
>
> 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"  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.
>
>
>
> 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 o

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

2014-07-24 Thread Richer, Justin P.

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.



2014-07-23 13:39 GMT-04:00 Mike Jones 
mailto:michael.jo...@microsoft.com>>:
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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of John Bradley
Sent: Wednesday, July 23, 2014 10:33 AM
To: tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>

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


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, 
tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> wrote:

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

2014-07-23 12:48 GMT-04:00 Thomas Broyer 
mailto:t.bro...@gmail.com>>:
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. 
mailto:jric...@mitre.org>> 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 
mailto:t.bro...@gmail.com>> 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 
mailto:michael.jo...@microsoft.com>> wrote:
The response_type "none" is already used in practice, which returns no access 
token.  It was accepted by the designated experts and re

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

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:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, July 24, 2014 6:53 AM
To: Nat Sakimura
Cc: oauth@ietf.org 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 
mailto:sakim...@gmail.com>> wrote:
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 
mailto:ve7...@ve7jtb.com>>:

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, 
tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> 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 
mailto:tors...@lodderstedt.net>> 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.

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 
mailto:t.bro...@gmail.com>>:

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" 
mailto:sakim...@gmail.com>> 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 
mailto:t.bro...@gmail.com>>:

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" 
mailto:sakim...@gmail.com>> 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.

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 ch

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

oint, 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.
>>>>>
>>>>>
>>>>>
>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones :
>>>>>
>>>>>>  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:oauth-boun...@ietf.org] *On Behalf Of *John
>>>>>> Bradley
>>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>>>>>> *To:* tors...@lodderstedt.net
>>>>>>
>>>>>> *Cc:* oauth@ietf.org
>>>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>>>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>

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

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

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

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 
mailto:ve7...@ve7jtb.com>>:
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, 
tors...@lodderstedt.net<mailto:tors...@lodderstedt.net> 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 
mailto:tors...@lodderstedt.net>> 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.

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 
mailto:t.bro...@gmail.com>>:

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" 
mailto:sakim...@gmail.com>> 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 
mailto:t.bro...@gmail.com>>:

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" 
mailto:sakim...@gmail.com>> 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.

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

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

2014-07-24 Thread Nat Sakimura

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.
>>>>
>>>>
>>>>
>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones :
>>>>
>>>>>  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:oauth-boun...@ietf.org] *On Behalf Of *John
>>>>> Bradley
>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>>>>> *To:* tors...@lodderstedt.net
>>>>>
>>>>> *Cc:* oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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, tors...@lodderstedt.net wrote:
>>>>>
>>>>>  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
>>>>> t

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

2014-07-23 Thread Justin Richer

But... this proposal issues id_tokens. Is this proposal stupid for doing so, or 
does Microsoft not actually implement it as written?

Also, I can't find any mention of this in your docs. Can you point us to it?

And doesn't Microsoft implement OpenID Connect already? You guys joined the 
OIDC interop with your implementation after all. If you're doing both, great, 
all the more reason to do this work in OIDF.

--Justin

/sent from my phone/

On Jul 23, 2014 9:55 PM, Anthony Nadalin  wrote:
>
> I already indicated that Microsoft has implemented this and is in production, 
> as id_tokens are stupid on intersystem and partner collaboration sites 
>
> -Original Message- 
> From: Justin Richer [mailto:jric...@mit.edu] 
> Sent: Wednesday, July 23, 2014 6:52 PM 
> To: Anthony Nadalin 
> Subject: Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-v2-user-a4c-05.txt 
>
> And which IdP is that? Can you point us to the implementation? 
>
> --Justin 
>
> /sent from my phone/ 
>
> On Jul 23, 2014 9:43 PM, Anthony Nadalin  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 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:oauth-boun...@ietf.org] On Behalf Of John Bradley 
> > Sent: Wednesday, July 23, 2014 1:54 PM 
> > To: tors...@lodderstedt.net 
> > Cc: oauth@ietf.org list 
> > Subject: Re: [OAUTH-WG] New Version Notification for 
> > draft-hunt-oauth-v2-user-a4c-05.txt 
> > 
> >   
> > 
> > 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, tors...@lodderstedt.net 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 
> >>>  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. 
> >>>> 
> >>>>   
> >>>> 
> >>>> 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. 
> >>>> 
> >>>> 
> >&

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

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"  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 :
>
>> 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"  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.
>>>
>>> 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.
>>>
>>>
>>>
>>> 2014-07-23 13:39 GMT-04:00 Mike Jones :
>>>
>>>>  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:oauth-boun...@ietf.org] *On Behalf Of *John
>>>> Bradley
>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>>>> *To:* tors...@lodderstedt.net
>>>>
>>>> *Cc:* oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>>
>>>>
>>>>
>>>> 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
>>>>

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

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 :

> 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"  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.
>>
>> 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.
>>
>>
>>
>> 2014-07-23 13:39 GMT-04:00 Mike Jones :
>>
>>>  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:oauth-boun...@ietf.org] *On Behalf Of *John
>>> Bradley
>>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>>> *To:* tors...@lodderstedt.net
>>>
>>> *Cc:* oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
&

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

2014-07-23 Thread Torsten Lodderstedt

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 :
> 
> 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"  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. 
>> 
>> 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.
>> 
>> 
>> 
>> 2014-07-23 13:39 GMT-04:00 Mike Jones :
>>> 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:oauth-boun...@ietf.org] On Behalf Of John Bradley
>>> Sent: Wednesday, July 23, 2014 10:33 AM
>>> To: tors...@lodderstedt.net
>>> 
>>> 
>>> Cc: oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] New Version Notification for 
>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>  
>>> 
>>> 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 
>>

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

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"  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.
>
> 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.
>
>
>
> 2014-07-23 13:39 GMT-04:00 Mike Jones :
>
>>  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:oauth-boun...@ietf.org] *On Behalf Of *John Bradley
>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>> *To:* tors...@lodderstedt.net
>>
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-05.txt
>>
>>
>>
>> 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, tors...@lodderstedt.net wrote:
>>
>>  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 respo

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

Thanks Takahiko. Good analysis.


2014-07-23 14:12 GMT-04:00 Takahiko Kawasaki :

> 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 :
>
>   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:oauth-boun...@ietf.org] *On Behalf Of *John Bradley
>> *Sent:* Wednesday, July 23, 2014 10:33 AM
>> *To:* tors...@lodderstedt.net
>>
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-05.txt
>>
>>
>>
>> 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, tors...@lodderstedt.net wrote:
>>
>>  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

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

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.

2014-07-23 13:39 GMT-04:00 Mike Jones :

>  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:oauth-boun...@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Wednesday, July 23, 2014 10:33 AM
> *To:* tors...@lodderstedt.net
>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>
> 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, tors...@lodderstedt.net wrote:
>
>  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
>
>
>
> 2014-07-23 12:48 GMT-04:00 Thomas Broyer :
>
> 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 (whi

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

2014-07-23 Thread Takahiko Kawasaki

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 :

>  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:oauth-boun...@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Wednesday, July 23, 2014 10:33 AM
> *To:* tors...@lodderstedt.net
>
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>
> 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, tors...@lodderstedt.net wrote:
>
>  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
>
>
>
> 2014-07-23 12:48 GMT-04:00 Thomas Broyer :
>
> 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

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

2014-07-23 Thread John Bradley

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, tors...@lodderstedt.net wrote:
> 
> 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 
>> 
>> 
>> 2014-07-23 12:48 GMT-04:00 Thomas Broyer :
>>> 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.  
>>>> 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  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 
>>>>>>  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.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> 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:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
>>>>>> Sent: Wednesday, July 23, 2014 7:09 AM
>>>>>> To: Nat Sakimura
>>>>>> Cc: 
>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for 
>>>>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> Yes.

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

2014-07-23 Thread torsten

 

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 
> 
> 2014-07-23 12:48 GMT-04:00 Thomas Broyer :
> 
> 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.  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  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  
> 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. 
> 
> 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:oauth-boun...@ietf.org] ON BEHALF OF Phil Hunt
> SENT: Wednesday, July 23, 2014 7:09 AM
> TO: Nat Sakimura
> CC: 
> SUBJECT: Re: [OAUTH-WG] New Version Notification for 
> draft-hunt-oauth-v2-user-a4c-05.txt 
> 
> Yes. This is why it has to be discussed in the IETF. 
> 
> Phil 
> 
> @independentid 
> 
> www.independentid.com [2] 
> 
> phil.h...@oracle.com 
> 
> On Jul 23, 2014, at 9:43 AM, Nat Sakimura  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
> 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

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

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 :

> 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. 
> 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  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 
>> 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.
>>>
>>>
>>>
>>> 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:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
>>> *Sent:* Wednesday, July 23, 2014 7:09 AM
>>> *To:* Nat Sakimura
>>> *Cc:* 
>>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>>> draft-hunt-oauth-v2-user-a4c-05.txt
>>>
>>>
>>>
>>> Yes. This is why it has to be discussed in the IETF.
>>>
>>>
>>>
>>> Phil
>>>
>>>
>>>
>>> @independentid
>>>
>>> www.independentid.com
>>>
>>> phil.h...@oracle.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura  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
>>>   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
>>> respons

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

2014-07-23 Thread Richer, Justin P.

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 
mailto:t.bro...@gmail.com>> 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 
mailto:michael.jo...@microsoft.com>> 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.

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:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

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

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>

On Jul 23, 2014, at 9:43 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> 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
  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 
mailto:phil.h...@oracle.com>>:
The draft is very clear.

Phil

On Jul 23, 2014, at 0:46, Nat Sakimura 
mailto:sakim...@gmail.com>> 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.

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 
mailto:jric...@mit.edu>>:
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 
mailto:sakim...@gmail.com>> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt 
> mailto:phil.h...@oracle.com>>:
>>

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

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. 
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  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 
> 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.
>>
>>
>>
>> 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:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
>> *Sent:* Wednesday, July 23, 2014 7:09 AM
>> *To:* Nat Sakimura
>> *Cc:* 
>> *Subject:* Re: [OAUTH-WG] New Version Notification for
>> draft-hunt-oauth-v2-user-a4c-05.txt
>>
>>
>>
>> Yes. This is why it has to be discussed in the IETF.
>>
>>
>>
>> Phil
>>
>>
>>
>> @independentid
>>
>> www.independentid.com
>>
>> phil.h...@oracle.com
>>
>>
>>
>>
>>
>>
>>
>> On Jul 23, 2014, at 9:43 AM, Nat Sakimura  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
>>   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 :
>>
>> The draft is very clear.
>>

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

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 
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.
>
>
>
> 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:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, July 23, 2014 7:09 AM
> *To:* Nat Sakimura
> *Cc:* 
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>
> Yes. This is why it has to be discussed in the IETF.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On Jul 23, 2014, at 9:43 AM, Nat Sakimura  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
>   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 :
>
> The draft is very clear.
>
> Phil
>
>
> On Jul 23, 2014, at 0:46, Nat Sakimura  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.
>
>
>
> 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 :
>
> 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

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

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 :

>  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:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, July 23, 2014 7:09 AM
> *To:* Nat Sakimura
> *Cc:* 
> *Subject:* Re: [OAUTH-WG] New Version Notification for
> draft-hunt-oauth-v2-user-a4c-05.txt
>
>
>
> Yes. This is why it has to be discussed in the IETF.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> phil.h...@oracle.com
>
>
>
>
>
>
>
> On Jul 23, 2014, at 9:43 AM, Nat Sakimura  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
>   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 :
>
> The draft is very clear.
>
> Phil
>
>
> On Jul 23, 2014, at 0:46, Nat Sakimura  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.
>
>
>
> Then, OIDC can define a binding to it so that the binding only

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

2014-07-23 Thread Mike Jones

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:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, July 23, 2014 7:09 AM
To: Nat Sakimura
Cc: 
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-v2-user-a4c-05.txt

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

Phil

@independentid
www.independentid.com<http://www.independentid.com>
phil.h...@oracle.com<mailto:phil.h...@oracle.com>

On Jul 23, 2014, at 9:43 AM, Nat Sakimura 
mailto:sakim...@gmail.com>> 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
  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 
mailto:phil.h...@oracle.com>>:
The draft is very clear.

Phil

On Jul 23, 2014, at 0:46, Nat Sakimura 
mailto:sakim...@gmail.com>> 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.

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 
mailto:jric...@mit.edu>>:
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 
mailto:sakim...@gmail.com>> wrote:
>
> What about just defining a new grant type in this WG?
>
>
> 2014-07-22 12:56 GMT-04:00 Phil Hunt 
> mailto:phil.h...@oracle.com>>:
>>
>> 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 
>> mailto:sakim...@gmail.com>> wrote:
>>
>>> +1 to Justin.
>>>
>>>
>>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. 
>>> mailto:jric...@mitre.org>>:
>>>>
>>>> Errors like these make it clear to me that it would make much more sense 
>>>> to develop this document in

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

2014-07-23 Thread Phil Hunt

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

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Jul 23, 2014, at 9:43 AM, Nat Sakimura  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
>   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 :
> The draft is very clear. 
> 
> Phil
> 
> On Jul 23, 2014, at 0:46, Nat Sakimura  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. 
>> 
>> 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 :
>> 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  wrote:
>> >
>> > What about just defining a new grant type in this WG?
>> >
>> >
>> > 2014-07-22 12:56 GMT-04:00 Phil Hunt :
>> >>
>> >> 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  wrote:
>> >>
>> >>> +1 to Justin. 
>> >>>
>> >>>
>> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. :
>> 
>>  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  wrote:
>> 
>> >
>> >
>> >
>> > On Mon, Jul 21, 2014 at 11:52 PM, Mike Jones 
>> >  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

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