Re: [OAUTH-WG] treatment of client_id for authentication and identification
New tweak: The security ramifications of allowing unauthenticated access by public clients to the token endpoint, as well as the issuance of refresh tokens to public clients MUST be taken into consideration. EHL -Original Message- From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Friday, August 19, 2011 4:56 AM To: Eran Hammer-Lahav; Lu, Hui-Lan (Huilan); Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification I find the original text clearer, myself. -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav [e...@hueniverse.com] Sent: Thursday, August 18, 2011 5:16 PM To: Lu, Hui-Lan (Huilan); Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification -Original Message- From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com] Sent: Thursday, August 18, 2011 1:45 PM To: Eran Hammer-Lahav; Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL ___ 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
I find the original text clearer, myself. -- Justin From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav [e...@hueniverse.com] Sent: Thursday, August 18, 2011 5:16 PM To: Lu, Hui-Lan (Huilan); Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification -Original Message- From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com] Sent: Thursday, August 18, 2011 1:45 PM To: Eran Hammer-Lahav; Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL ___ 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
Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Huilan ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
-Original Message- From: Lu, Hui-Lan (Huilan) [mailto:huilan...@alcatel-lucent.com] Sent: Thursday, August 18, 2011 1:45 PM To: Eran Hammer-Lahav; Brian Campbell Cc: oauth Subject: RE: [OAUTH-WG] treatment of client_id for authentication and identification Eran Hammer-Lahav wrote: Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? 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
FWIW, I was okay with the text EHL had originally proposed for 21. client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. I would suggest rewording the above as follows: client_secret REQUIRED unless it is an empty string. The client secret. unless its value is an empty string. Do people read this new text to mean OPTIONAL if not empty? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL Here is my stab: Allowing unauthenticated access by public clients has security ramifications. So does the issuance of refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details. Huilan ___ 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 just noticed that some words were missing in my previous post. Here is the full text that Eran requested: Allowing unauthenticated access to the token endpoint by public clients has security ramifications. So does issuing refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details. Huilan -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lu, Hui-Lan (Huilan) Sent: Thursday, August 18, 2011 5:47 PM To: 'Eran Hammer-Lahav'; Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification It is difficult to parse the last sentence of 3.2.1: The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime. I think it should be rewritten and reference relevant parts of security considerations. Text? EHL Here is my stab: Allowing unauthenticated access by public clients has security ramifications. So does the issuance of refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details. Huilan ___ 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
Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. Added to 3.2.1: A public client that was not issued a client password MAY use the 'client_id' request parameter to identify itself when sending requests to the token endpoint. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Thursday, July 28, 2011 12:11 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. 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
the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods. quote from http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html: The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, The authorization server MUST ensure the two identifiers belong to the same client. So the client_id's (request parameter and header) may differ. You removed the parameter in -17, can you please explain why? regards, Torsten. Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav: 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.net mailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 15:21:16 -0700 To: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Cc: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com, oauth oauth@ietf.org mailto: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.com mailto: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 would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. 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
+1 Am 28.07.2011 15:10, schrieb Brian Campbell: I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. 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
Perfect. I'll make this change after the last call before sending this to IETF LC. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Thu, 28 Jul 2011 12:59:19 -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 +1 Am 28.07.2011 15:10, schrieb Brian Campbell: I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.commailto:e...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. 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
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
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] 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] 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] 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
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
Re: [OAUTH-WG] treatment of client_id for authentication and identification
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
[OAUTH-WG] treatment of client_id for authentication and identification
I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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
How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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
It shouldn't. You are still allowed to reuse client_id outside the specific password credentials use case. Just make sure the way the parameter is defined in v2 is consistent. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 25, 2011 9:28 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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
I'm asking from both an implementation perspective as well as the spec perspective. On the spec side, draft-ietf-oauth-assertions will deal with client_id and while it's currently required I'd guess it will become optional or even forbidden. On the implementation side, let me make sure I understand. Clients without a secret must present client_id on token endpoint requests and must use only that method of identifying themselves? HTTP Basic and other means of client authentication are reserved for clients that actually have some secret to authenticate with? On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: It shouldn't. You are still allowed to reuse client_id outside the specific password credentials use case. Just make sure the way the parameter is defined in v2 is consistent. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 25, 2011 9:28 AM To: Eran Hammer-Lahav Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification How should HTTP Basic be used for a client not in possession of a client secret? On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate). EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 25, 2011 7:02 AM To: oauth Subject: [OAUTH-WG] treatment of client_id for authentication and identification I need to revisit a question that came up about two months ago. I thought I had a clear understanding of when client_id was and wasn't included in access token requests but drafts 18/19 seemed to have changed things (or my understanding of 16 was wrong). The question is, when is client_id a required parameter on requests to the token endpoint and when can/should it be omitted? In -16 I was under the impression that client_id was always to be included even when using HTTP Basic or other means of authentication. See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for example. But the text and examples in -18/-19 would suggest that client_id is to be omitted when using HTTP Basic. Text in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3 I don't have a strong preference for either direction but do feel it needs to be more explicitly spelled out. Scenarios that should be accounted for are, for both clients in possession of a client password and clients without, using client_id/client_secret, using HTTP Basic and using other means of authentication/identification. ___ 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
