Re: [OAUTH-WG] treatment of client_id for authentication and identification
Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-07.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt
This version adds a missing comma in an error response example. Thanks to Stephen Farrell for his donation of the comma. This version should be the subject of the working group last call. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, July 27, 2011 6:17 AM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-07.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-07.txt ___ 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
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Updated references to oauth-v2 and httpbis. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, July 27, 2011 6:45 AM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt ___ 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] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Mike, Regarding the allowed characters for scope values (grammar of scope-v), is the non-support of percent encoding intentional ? That would preclude scope values to be (every kind of) UTF-8 strings, or URNs, or JSON (short) payload, etc. This character set limitation does not exist in the core spec, wherever scope parameter can be included in a request or response, either because percent encoding is usable, or else because scope parameter is a JSON string. It seems besides strange that the set of characters safe to use for scope values is not defined in the core spec, and instead is constrained by/dependent from the type of access token used (here, bearer token). Note that this question was raised also by the Liaison Statement received from the Open Mobile Alliance. Best regards, Jerome -Message d'origine- De : oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] De la part de Mike Jones Envoyé : mercredi 27 juillet 2011 15:47 À : oauth@ietf.org Objet : Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt Updated references to oauth-v2 and httpbis. -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Wednesday, July 27, 2011 6:45 AM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename: draft-ietf-oauth-v2-bearer-08.txt Pages : 17 Date: 2011-07-27 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Minutes from IETF 81 meeting
I have uploaded minutes to the meeting materials page, and they can be found here: http://www.ietf.org/proceedings/81/minutes/oauth.txt Corrections, please; and thanks to Tony Nadalin for taking notes. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
In the bearer token spec, Section 2.4 (The WWW-Authenticate Response Header
Field), scope is unambiguously defined to permit these characters:
scope = scope = scope-v *( SP scope-v )
scope-v = 1*quoted-char
quoted-char = ALPHA / DIGIT /
! / # / $ / % / / ' / ( / ) /
* / + / - / . / / / : / / = /
/ ? / @ / [ / ] / ^ / _ / ` /
{ / | / } / ~ / \ / , / ;
I misspoke in the meeting thinking that this definition was also in the core
spec. I believe that it used to be there, but apparently it has been removed.
There it just says that The scope of the access request expressed as a list of
space-delimited, case sensitive strings.
This set of characters does permit, but does not mandate, support for
percent-encoding of characters.
-- Mike
-Original Message-
From: MARCON, JEROME (JEROME) [mailto:jerome.mar...@alcatel-lucent.com]
Sent: Wednesday, July 27, 2011 7:53 AM
To: Mike Jones; oauth@ietf.org
Subject: RE: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Mike,
Regarding the allowed characters for scope values (grammar of scope-v), is
the non-support of percent encoding intentional ? That would preclude scope
values to be (every kind of) UTF-8 strings, or URNs, or JSON (short) payload,
etc.
This character set limitation does not exist in the core spec, wherever scope
parameter can be included in a request or response, either because percent
encoding is usable, or else because scope parameter is a JSON string.
It seems besides strange that the set of characters safe to use for scope
values is not defined in the core spec, and instead is constrained by/dependent
from the type of access token used (here, bearer token).
Note that this question was raised also by the Liaison Statement received from
the Open Mobile Alliance.
Best regards,
Jerome
-Message d'origine-
De : oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] De la part de Mike
Jones Envoyé : mercredi 27 juillet 2011 15:47 À : oauth@ietf.org Objet : Re:
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
Updated references to oauth-v2 and httpbis.
-- Mike
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Wednesday, July 27, 2011 6:45 AM
To: i-d-annou...@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : The OAuth 2.0 Protocol: Bearer Tokens
Author(s) : Michael B. Jones
Dick Hardt
David Recordon
Filename: draft-ietf-oauth-v2-bearer-08.txt
Pages : 17
Date: 2011-07-27
This specification describes how to use bearer tokens when accessing
OAuth 2.0 protected resources.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-08.txt
___
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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in --18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to --15. In --16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in --17 I reverted back to the --15 approach. What makes this stand out in --20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from --15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt
This version should be the subject of the working group last call. As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August. Everyone: please review this version of the document, and make any comments by 12 August. The goal will be to have Mike incorporate any comments at that point, put out a final version, and send it to the IESG. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 10:38:36 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com, oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav
Re: [OAUTH-WG] Draft -20
As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August. Everyone: please review this version of the document, and make any comments by 12 August. The goal will be to have Eran incorporate any comments at that point, put out a final version, and send it to the IESG. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
That was more or less what I was trying to say as well. There are times when client identification is needed at the token endpoint and it's not clear if or how, short of actual authentication, the current spec allows for it. On Wed, Jul 27, 2011 at 11:38 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt
Thanks, Barry. For what it's worth, after submitting -07, I realized that the references to the oauth-v2 and httpbis specs needed to be updated, and did this in -08 (making no other changes). Thus, -08 should be the version that is the subject of the working group last call. Cheers, -- Mike -Original Message- From: barryleiba.mailing.li...@gmail.com [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba Sent: Wednesday, July 27, 2011 10:44 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-07.txt This version should be the subject of the working group last call. As announced in the working group session this morning at IETF 81: This document goes into working-group last call today, ending on 12 August. Everyone: please review this version of the document, and make any comments by 12 August. The goal will be to have Mike incorporate any comments at that point, put out a final version, and send it to the IESG. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
There is no need and I don't intend to pro-forma issue client secrets just to conform to some text of the spec. I thought we are beyond that point. The obvious approach would be to use the client_id the same way as it is used on the authz endpoint. regards, Torsten. Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav: You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials. EHL From: Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 10:38:36 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com, oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open
Re: [OAUTH-WG] treatment of client_id for authentication and identification
This is the best way to keep the protocol simple and secure of the main use cases it explicitly addresses. There is not clean way to introduce the client_id parameter at the token endpoint without making it confusing for developers. The problem is how do explain when to perform authentication and when to perform identification and the different trust levels in each. I have no interest in going down that road. The current language allows you to do exactly what you want but issuing a set of password credentials and supporting the client_id/client_secret parameters. You should support the client sending an empty client_secret and omitting it when no secret is issued. If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 11:02:18 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com, oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification There is no need and I don't intend to pro-forma issue client secrets just to conform to some text of the spec. I thought we are beyond that point. The obvious approach would be to use the client_id the same way as it is used on the authz endpoint. regards, Torsten. Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav: You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 10:38:36 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com, oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahave...@hueniverse.com wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
There is not clean way of adding it. First where? In each flow of the token endpoint or just in 3.2? Then how is it defined? Optional? Required for public clients? How does it work alongside authentication? If you use client_password or Basic then it becomes authentication but otherwise identification? What about duplication between Basic and the parameter? It also means adding a new section discussing client authentication vs identification which is currently implicit. I strongly believe that it is better to have a simple model as the one already defined in –20 and let other use case find their way around it instead of producing a confusing document that is trying to hard to solve every possible combination. As I said before, we can tweak the definition of client_secret to make it more esthetically pleasing (the server doesn't mind having an empty parameter included, just people), but that's as far am I'm (as wg member) willing to support, especially at this point. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 15:21:16 -0700 To: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Cc: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahave...@hueniverse.commailto:e...@hueniverse.com wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I'll take this as –20 last call comment. From: Brian Campbell bcampb...@pingidentity.commailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 15:17:48 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net, oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
