:-),
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 assert
en/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-us
ed, 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
>>>
>>>>
>>>
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
t 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. :-)
>> >
>>
--- 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 OAu
inal 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
*From:*OAuth
[mailto:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org>]
*On Behalf Of *Phil Hunt
*Sent:* Wednesday, July 2
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
> 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
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 public
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 a
..@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
&g
uplicates) 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
sponse 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:oau
ribed 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
>>>>>>
;>
>>
>>
>> Best wishes,
>>
>> -- Mike
>>
>>
>>
>> From: OAuth [mailto:oauth-boun...@iet
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 hors
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,
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 develope
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
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 OpenI
[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
>
> @inde
etf.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
>
>
tf.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...@orac
> 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
>>>>>&g
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 bee
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
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
e" 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<mai
: 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,
>>>> 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.
>>>>&g
ant 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
t; 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
&
,
> 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
ation", 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 (“co
“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).
>>>
>>>
>
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, rathe
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:* t
C 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 Be
gnments/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 OAu
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
>
orization 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.
>>>>>>
ready 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:
>
>>>
>>> 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.
>>>
>>>
>>>
>>>
m: 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
>>
>>
>> -- 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:*
>&
ready 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 Not
r. 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 Sakimu
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
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 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
>
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.
Thi
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, 2
Speaking for myself, yes. Defining the simple ID_token grant showing how an ID
token only can be returned is my minimum objective.
I think there needs to be some discussion in the WG on certain features which
may be better suited only within OIDC and those features which fit better as a
founda
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:
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
+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 r
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 wha
60 matches
Mail list logo
