Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions
So how do we resolve if the language goes into the spec? Thanks, Yaron -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 27, 2010 8:36 AM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions Makes sense. Personally, I don't have any preference on including it or not. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, July 27, 2010 5:49 AM To: oauth Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions A client_id parameter would still be presented in the end user authorization request. The text Brian E. quoted is what mandates any specifications/documents/agreements that define how to use client assertions must also define the association between the client_id and some field(s) in the assertion. If someone sees a cleaner way to deal with client identity on the user authorization request when using assertions to authenticate the client to the token endpoint, please speak up and lets discuss it. However, in general I do feel it's important to have better defined support in the core OAuth spec to allow for client authentication methods beyond just password. -Brian On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton bea...@google.com wrote: On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? In theory: any document that defines how to use an assertion of a particular type with OAuth 2.0 MUST define how to map the value from the client_id parameter in the authorization request to a value or values in the assertion subsequently submitted with the code to obtain an access token. In practice: you do it the same way you handle any kind of identity assertion. There is some combination of issuer and subject and signature that ends up producing an identity that you trust. ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions
[Seems like the only way is for me to say this] I am going to include this text in -11 unless someone objects (and explains why). EHL -Original Message- From: Yaron Goland [mailto:yar...@microsoft.com] Sent: Monday, August 09, 2010 2:16 PM To: Eran Hammer-Lahav; Brian Campbell; oauth Subject: RE: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions So how do we resolve if the language goes into the spec? Thanks, Yaron -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 27, 2010 8:36 AM To: Brian Campbell; oauth Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions Makes sense. Personally, I don't have any preference on including it or not. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, July 27, 2010 5:49 AM To: oauth Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions A client_id parameter would still be presented in the end user authorization request. The text Brian E. quoted is what mandates any specifications/documents/agreements that define how to use client assertions must also define the association between the client_id and some field(s) in the assertion. If someone sees a cleaner way to deal with client identity on the user authorization request when using assertions to authenticate the client to the token endpoint, please speak up and lets discuss it. However, in general I do feel it's important to have better defined support in the core OAuth spec to allow for client authentication methods beyond just password. -Brian On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton bea...@google.com wrote: On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? In theory: any document that defines how to use an assertion of a particular type with OAuth 2.0 MUST define how to map the value from the client_id parameter in the authorization request to a value or values in the assertion subsequently submitted with the code to obtain an access token. In practice: you do it the same way you handle any kind of identity assertion. There is some combination of issuer and subject and signature that ends up producing an identity that you trust. ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions
A client_id parameter would still be presented in the end user authorization request. The text Brian E. quoted is what mandates any specifications/documents/agreements that define how to use client assertions must also define the association between the client_id and some field(s) in the assertion. If someone sees a cleaner way to deal with client identity on the user authorization request when using assertions to authenticate the client to the token endpoint, please speak up and lets discuss it. However, in general I do feel it's important to have better defined support in the core OAuth spec to allow for client authentication methods beyond just password. -Brian On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton bea...@google.com wrote: On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? In theory: any document that defines how to use an assertion of a particular type with OAuth 2.0 MUST define how to map the value from the client_id parameter in the authorization request to a value or values in the assertion subsequently submitted with the code to obtain an access token. In practice: you do it the same way you handle any kind of identity assertion. There is some combination of issuer and subject and signature that ends up producing an identity that you trust. ___ 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] Proposed language for section 2.2 on Client Assertions
Makes sense. Personally, I don't have any preference on including it or not. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, July 27, 2010 5:49 AM To: oauth Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions A client_id parameter would still be presented in the end user authorization request. The text Brian E. quoted is what mandates any specifications/documents/agreements that define how to use client assertions must also define the association between the client_id and some field(s) in the assertion. If someone sees a cleaner way to deal with client identity on the user authorization request when using assertions to authenticate the client to the token endpoint, please speak up and lets discuss it. However, in general I do feel it's important to have better defined support in the core OAuth spec to allow for client authentication methods beyond just password. -Brian On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton bea...@google.com wrote: On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? In theory: any document that defines how to use an assertion of a particular type with OAuth 2.0 MUST define how to map the value from the client_id parameter in the authorization request to a value or values in the assertion subsequently submitted with the code to obtain an access token. In practice: you do it the same way you handle any kind of identity assertion. There is some combination of issuer and subject and signature that ends up producing an identity that you trust. ___ 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] Proposed language for section 2.2 on Client Assertions
On Mon, Jul 26, 2010 at 2:08 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I understand that in many assertions, the client identifier is established internally, but this approach will completely prevent using the assertion client authentication method with other flows that involve getting a code. I'm pretty sure that's exactly the opposite of what Yaron was trying to achieve. client_id will continue to be passed on the authorization URL. No client_id will be passed on the token endpoint, because it's either insecure, or not necessary. The assertion has to contain the client identifier. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions
How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? EHL -Original Message- From: Brian Eaton [mailto:bea...@google.com] Sent: Monday, July 26, 2010 3:51 PM To: Eran Hammer-Lahav Cc: Yaron Goland; oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions On Mon, Jul 26, 2010 at 2:08 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I understand that in many assertions, the client identifier is established internally, but this approach will completely prevent using the assertion client authentication method with other flows that involve getting a code. I'm pretty sure that's exactly the opposite of what Yaron was trying to achieve. client_id will continue to be passed on the authorization URL. No client_id will be passed on the token endpoint, because it's either insecure, or not necessary. The assertion has to contain the client identifier. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions
On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: How do you link the client_id using in the authorization endpoint with the client assertion using in the token endpoint? In theory: any document that defines how to use an assertion of a particular type with OAuth 2.0 MUST define how to map the value from the client_id parameter in the authorization request to a value or values in the assertion subsequently submitted with the code to obtain an access token. In practice: you do it the same way you handle any kind of identity assertion. There is some combination of issuer and subject and signature that ends up producing an identity that you trust. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
