Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
To summarize, I am weary of registration normative language that appears to disallow common practice implemented by servers to securely support multi-component applications. If these common practices will be non-compliant (or at least it appears to be so on first reading by many different people with detailed knowledge of the spec), isn't it incumbent on this spec to provide guidance on _how_ different components of an application will interoperate under different registration? At least for the very common case of a webserver + browser component, the importance of which is already enshrined in the spec by the definition of two response_types and flows? On Thu, Mar 15, 2012 at 3:54 PM, Breno de Medeiros br...@google.com wrote: On Thu, Mar 15, 2012 at 15:43, Eran Hammer e...@hueniverse.com wrote: I don't know how to better explain myself. Forget about the text you have issue with. Just answer this: Reading the specification (with that text removed), what happens when a hybrid client wants to register? What client type does it provide? How should the server handle this case? In the example case of the webserver + browser-based client components, I think the server should just allow it. The browser does not need to expose the client_secret since it requires no authentication credentials. The webserver should use the client credentials acquired during registration to authenticate itself when using the code flow. It's more interesting when mobile applications and webserver want to share credentials. The mitigation strategy of limiting lifetime of tokens may not work in this case. In general the registration server should not allow the use of a single registration in this case. This case is different from the above in the sense that installed applications are typically _also_ using the 'code' flow, but from a different security context. A server could allow both clients to share the same registration information, but segregate the set of redirect URLs and tie the code to each security context and apply different client authentication requirements to each. Or the server could require separate client registration for each component. EH -Original Message- From: Breno de Medeiros [mailto:br...@google.com] Sent: Thursday, March 15, 2012 2:12 PM To: Eran Hammer Cc: Nat Sakimura; OAuth WG Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 On Thu, Mar 15, 2012 at 13:13, Eran Hammer e...@hueniverse.com wrote: Ok. That's much better than my guess that you wanted to drop all the registration text from the specification. What I'm looking for is a simple text that answers the question: What to do if my client isn't simply public or confidential? If we just drop the current text, the answer is implicitly you can't have such a client because there is no way to register a client of any other type. So let's try this again, and focus exclusively on answering this question. My text takes a position which is, you can't - unless. Your suggestion is more of a vague discussion of the topic. I'd like to see clear, normative answer to this question. The current version is normative but far from clear. In fact, the most natural interpretation is that it bans normal practice and throws away the work that was done in defining different flow types to support normal practice. 1. I don't see the need or desirability to put normative language on registration practices. 2. The contents of said normative language are harmful. I suggest two alternatives: 1. Remove the language. 2. Substitute the language by non-normative informative discussion. You can also do other things, like introduce normative language that makes sense. But I have not yet seen proposed language that would be acceptable. EH On 3/15/12 12:30 PM, Breno de Medeiros br...@google.com wrote: I am proposing the entire removal of: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server. In particular the example of a server-side component versus browser-based components is particularly unhelpful since it violates the entire principle of why two response_type 'code' and 'token' were defined, and how OAuth2 is typically implemented. That's when I claim this normative language is redefining the protocol. On Thu, Mar 15, 2012 at 12:13, Eran Hammer e...@hueniverse.com wrote: Which text in -25 are you proposing we remove exactly? I can't judge the text below without the full context of where and how it is proposed in the current document. Also, you are ignoring my detailed analysis of the current facts. We have two client types and the issue here is what to do with other
Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
On Thu, Mar 15, 2012 at 07:45, Eran Hammer e...@hueniverse.com wrote: This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that’s not an issue but more of an optimization for an edge case raised. It still feels like a horse by committee to me. unless the authorization server provides other registration options to specify such complex clients. seems a very round about way to say that the core spec already provides for such arrangements in the most common scenario. It is a bit of a stretch to say that the server provides other registration options by simply following strategy already laid out in the spec. In particular, I feel that this wording will be harmful to register extended behavior, e.g., alternative response_types by leading to fruitless conversations about spec compliance in the absence of real security risks. I do not believe the current text is the best representation of the spirit in which the spec was written (in particular the effort to specify two flows in detail to deal with precisely this issue) and possibly lead to harmful future interpretation. ** ** EH ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura *Sent:* Thursday, March 15, 2012 2:04 AM *To:* Breno de Medeiros; OAuth WG *Subject:* Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 ** ** ** ** So, Eran's first proposal: ** ** A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server, unless the authorization server provides other registration options to specify such complex clients. ** ** kind of meets my concern. There seems to be another issue around the usefulness of return_type in such case raised by Breno, and if I understand it correctly, Eran's answer was that these separate components may have the same client_id so that return_type is a valid parameter to be sent at the request. ** ** So, to clarify these, perhaps changing the above text slightly to the following solves the problem? ** ** A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server, unless the authorization server provides other registration options to specify such complex clients. Each component MAY have the same client_id, in which case the server *** * judges the client type and the associated security context based on the response_type parameter in the request. ** ** Would it solve your problem, Breno? ** ** Best, ** ** =nat ** ** -- --Breno ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
My proposal is to remove any reference to registration (which is a red herring and has raised all the problems we refer here) and refer to client authentication instead. Proposal: Clients may be implemented as a distributed set of components that run in different security contexts. For instance, a single client may include a webserver component and a script component in a browser. It is not appropriate for the different components to utilize the same client authentication mechanisms, since client authentication credentials that are held securely in one context cannot be deployed securely in another. Servers MUST mitigate security threats from client components that cannot hold client credentials as securely by distinguishing them from client components that can. Example of suitable measures are: - Requiring separate registration of components such as web server and a mobile application. - Restricting the time validity of tokens issued to clients that hold no authentication credentials, such as browser script-based components. Please don't truncate explanations in the interest of space if the resulting text is confusing and possibly misleading. Better to say nothing instead. On Thu, Mar 15, 2012 at 11:32, Eran Hammer e...@hueniverse.com wrote: Here are the facts: The authorization server must know the client type in order to enforce many of the requirements in the specification. The requirement to provide a client type is not decorated with a MUST or SHALL but that is implied. The specification only defines two client types: public and confidential. There is no client type defined for a hybrid client. The specification needs to address the very common use case of clients with both public and private components. I don't want to discuss in the specification how client identifiers are provisioned, nor do I want to discuss the potential binding of response types to client types. But we do need to provide some guidance to clients and authorization servers what to do with clients that do not fit the current type definitions. It is far too late for us to define a new client type, along with all the security considerations that such type imply. Our entire security consideration section and protocol design are based on have a well defined client type. Requiring separate registration for each component is the most straight-forward solution. Allowing the authorization server to offer alternatives is the backdoor to enable extensibility. Within these constraints, I am open to other prose or creative solutions. But the add-ons proposed are all ugly hacks. They clarify specific questions raised which I do not believe represent the core confusion here which is what is the right way to handle hybrid clients. The best way to move forward is to take a minute and ask the group to share how they handle such cases or how they think they should be handled. Based on that we can come up with a clear solution. EH From: Breno de Medeiros br...@google.com Date: Thu, 15 Mar 2012 09:56:13 -0700 To: Eran Hammer-Lahav e...@hueniverse.com Cc: Nat Sakimura sakim...@gmail.com, OAuth WG oauth@ietf.org Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 On Thu, Mar 15, 2012 at 07:45, Eran Hammer e...@hueniverse.com wrote: This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that’s not an issue but more of an optimization for an edge case raised. It still feels like a horse by committee to me. unless the authorization server provides other registration options to specify such complex clients. seems a very round about way to say that the core spec already provides for such arrangements in the most common scenario. It is a bit of a stretch to say that the server provides other registration options by simply following strategy already laid out in the spec. In particular, I feel that this wording will be harmful to register extended behavior, e.g., alternative response_types by leading to fruitless conversations about spec compliance in the absence of real security risks. I do not believe the current text is the best representation of the spirit in which the spec was written (in particular the effort to specify two flows in detail to deal with precisely this issue) and possibly lead to harmful future interpretation. EH From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura Sent: Thursday, March 15, 2012 2:04 AM To: Breno de Medeiros; OAuth WG Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 So, Eran's first proposal: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based
Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
I am proposing the entire removal of: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server. In particular the example of a server-side component versus browser-based components is particularly unhelpful since it violates the entire principle of why two response_type 'code' and 'token' were defined, and how OAuth2 is typically implemented. That's when I claim this normative language is redefining the protocol. On Thu, Mar 15, 2012 at 12:13, Eran Hammer e...@hueniverse.com wrote: Which text in -25 are you proposing we remove exactly? I can't judge the text below without the full context of where and how it is proposed in the current document. Also, you are ignoring my detailed analysis of the current facts. We have two client types and the issue here is what to do with other, undefined types. EH On 3/15/12 11:54 AM, Breno de Medeiros br...@google.com wrote: My proposal is to remove any reference to registration (which is a red herring and has raised all the problems we refer here) and refer to client authentication instead. Proposal: Clients may be implemented as a distributed set of components that run in different security contexts. For instance, a single client may include a webserver component and a script component in a browser. It is not appropriate for the different components to utilize the same client authentication mechanisms, since client authentication credentials that are held securely in one context cannot be deployed securely in another. Servers MUST mitigate security threats from client components that cannot hold client credentials as securely by distinguishing them from client components that can. Example of suitable measures are: - Requiring separate registration of components such as web server and a mobile application. - Restricting the time validity of tokens issued to clients that hold no authentication credentials, such as browser script-based components. Please don't truncate explanations in the interest of space if the resulting text is confusing and possibly misleading. Better to say nothing instead. On Thu, Mar 15, 2012 at 11:32, Eran Hammer e...@hueniverse.com wrote: Here are the facts: The authorization server must know the client type in order to enforce many of the requirements in the specification. The requirement to provide a client type is not decorated with a MUST or SHALL but that is implied. The specification only defines two client types: public and confidential. There is no client type defined for a hybrid client. The specification needs to address the very common use case of clients with both public and private components. I don't want to discuss in the specification how client identifiers are provisioned, nor do I want to discuss the potential binding of response types to client types. But we do need to provide some guidance to clients and authorization servers what to do with clients that do not fit the current type definitions. It is far too late for us to define a new client type, along with all the security considerations that such type imply. Our entire security consideration section and protocol design are based on have a well defined client type. Requiring separate registration for each component is the most straight-forward solution. Allowing the authorization server to offer alternatives is the backdoor to enable extensibility. Within these constraints, I am open to other prose or creative solutions. But the add-ons proposed are all ugly hacks. They clarify specific questions raised which I do not believe represent the core confusion here which is what is the right way to handle hybrid clients. The best way to move forward is to take a minute and ask the group to share how they handle such cases or how they think they should be handled. Based on that we can come up with a clear solution. EH From: Breno de Medeiros br...@google.com Date: Thu, 15 Mar 2012 09:56:13 -0700 To: Eran Hammer-Lahav e...@hueniverse.com Cc: Nat Sakimura sakim...@gmail.com, OAuth WG oauth@ietf.org Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 On Thu, Mar 15, 2012 at 07:45, Eran Hammer e...@hueniverse.com wrote: This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that¹s not an issue but more of an optimization for an edge case raised. It still feels like a horse by committee to me. unless the authorization server provides other registration options to specify such complex clients. seems a very round about way to say that the core spec already provides
Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
On Thu, Mar 15, 2012 at 13:13, Eran Hammer e...@hueniverse.com wrote: Ok. That's much better than my guess that you wanted to drop all the registration text from the specification… What I'm looking for is a simple text that answers the question: What to do if my client isn't simply public or confidential? If we just drop the current text, the answer is implicitly you can't have such a client because there is no way to register a client of any other type. So let's try this again, and focus exclusively on answering this question. My text takes a position which is, you can't - unless. Your suggestion is more of a vague discussion of the topic. I'd like to see clear, normative answer to this question. The current version is normative but far from clear. In fact, the most natural interpretation is that it bans normal practice and throws away the work that was done in defining different flow types to support normal practice. 1. I don't see the need or desirability to put normative language on registration practices. 2. The contents of said normative language are harmful. I suggest two alternatives: 1. Remove the language. 2. Substitute the language by non-normative informative discussion. You can also do other things, like introduce normative language that makes sense. But I have not yet seen proposed language that would be acceptable. EH On 3/15/12 12:30 PM, Breno de Medeiros br...@google.com wrote: I am proposing the entire removal of: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server. In particular the example of a server-side component versus browser-based components is particularly unhelpful since it violates the entire principle of why two response_type 'code' and 'token' were defined, and how OAuth2 is typically implemented. That's when I claim this normative language is redefining the protocol. On Thu, Mar 15, 2012 at 12:13, Eran Hammer e...@hueniverse.com wrote: Which text in -25 are you proposing we remove exactly? I can't judge the text below without the full context of where and how it is proposed in the current document. Also, you are ignoring my detailed analysis of the current facts. We have two client types and the issue here is what to do with other, undefined types. EH On 3/15/12 11:54 AM, Breno de Medeiros br...@google.com wrote: My proposal is to remove any reference to registration (which is a red herring and has raised all the problems we refer here) and refer to client authentication instead. Proposal: Clients may be implemented as a distributed set of components that run in different security contexts. For instance, a single client may include a webserver component and a script component in a browser. It is not appropriate for the different components to utilize the same client authentication mechanisms, since client authentication credentials that are held securely in one context cannot be deployed securely in another. Servers MUST mitigate security threats from client components that cannot hold client credentials as securely by distinguishing them from client components that can. Example of suitable measures are: - Requiring separate registration of components such as web server and a mobile application. - Restricting the time validity of tokens issued to clients that hold no authentication credentials, such as browser script-based components. Please don't truncate explanations in the interest of space if the resulting text is confusing and possibly misleading. Better to say nothing instead. On Thu, Mar 15, 2012 at 11:32, Eran Hammer e...@hueniverse.com wrote: Here are the facts: The authorization server must know the client type in order to enforce many of the requirements in the specification. The requirement to provide a client type is not decorated with a MUST or SHALL but that is implied. The specification only defines two client types: public and confidential. There is no client type defined for a hybrid client. The specification needs to address the very common use case of clients with both public and private components. I don't want to discuss in the specification how client identifiers are provisioned, nor do I want to discuss the potential binding of response types to client types. But we do need to provide some guidance to clients and authorization servers what to do with clients that do not fit the current type definitions. It is far too late for us to define a new client type, along with all the security considerations that such type imply. Our entire security consideration section and protocol design are based on have a well defined client type. Requiring separate registration for each component is the most straight-forward solution
Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Can you explain to me why response_type is necessary at all after this change. If a javascript client (candidate for token usage) and the web server component (candidate for code usage) cannot share registration (since they are different components with different security contexts of the same application) then there is no need to specify response_type. The server can infer the response type from the client and its security context. My objection has nothing to do with code+token flow. I think the change makes response_types irrelevant and is essentially a new protocol. As far as I understand it, the introduction of different code and token flows was precisely to allow different security-context components of the same client to securely operate under the same registration. I think if we change this we need to specify a lot more behavior, such as how a client can request authorization on behalf of several components simultaneously. On Wed, Mar 14, 2012 at 10:08, Eran Hammer e...@hueniverse.com wrote: This was already raised and addressed on this list last week. When someone defines and registers code+token, that specification must define how such a client is registered in light of the text below. This might mean defining a new client type, choosing the confidential client type with other normative text limiting the use of the secret in the public component, etc. IOW, this section doesn't break anything because there is nothing else defined to break. There is no way to avoid explicitly defining these requirements for a code+token response type, or any other new response type for that matter. The text below is required to ensure that the authorization server can properly enforce the rest of the normative security language in the specification. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Marius Scurtescu Sent: Wednesday, March 14, 2012 9:53 AM To: OAuth WG Cc: Breno de Medeiros Subject: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 Hi, Nat Sakimura started a thread on the OpenID Connect list about a breaking change introduced by rev 2.3 The paragraph in question is in section 2.1: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server. The authorization server MAY provider tools to manage such complex clients through a single administration interface. http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=draft-ietf-oauth-v2- 23.txt You can see the thread here: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon- 20120312/001672.html This paragraph basically prevents response_type=code+token which is already implemented by many providers and also relied on by OpenID Connect. The intent, I think, was to prevent clients from embedding the client secret meant for a confidential client into a public client. JavaScript based clients using the token flow do not need the client secret, so this concern does not apply. Thoughts? Thanks, Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- --Breno ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
On Wed, Mar 14, 2012 at 12:23, Eran Hammer e...@hueniverse.com wrote: Let's take a step back for a second. Previous versions of this document stated that during the registration process the client developer specifies the client type as described in 2.1. This has been specified under registration requirements since -17 published July 8th 2011. The only two types provided were (and still are) public and confidential. While there was no MUST or SHALL directive, the text was pretty clear about the need for each client registration to be tied to a single client type. I disagree with this. The spec supplies two response_types explicitly to deal with a single registration (single client_id) that can operate in different security contexts, and provides means for this to securely do so. The security considerations of the spec was previously written in a consistent form. This language is not consistent with that. As an specific example, our server implementation is compliant with the previous approach but not with the new one. Moreover, the current writing of this section leaves unspecified how servers can be made compliant if they support both token and code flows (if they only support one flow type, then clearly this is a non-issue). I am sorry, but with this language this is a different spec with different compliance profiles and without supplying enough guidance for creating interoperable server implementations for common deployment models. -23 was an attempt to clarify this, by making it explicit that hybrid clients are not addressed by the specification, and have to be dealt with as two separate clients. The specification breaks if a client has more than one type. The authorization server cannot enforce some of the security requirements if the client type is unknown. This is all based on how the specification is written and how the security consideration section is structured. The real issue raised here is how to handle hybrid clients which are beyond the scope of this specification. Here is an alternative text: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server, unless the authorization server provides other registration options to specify such complex clients. It's basically saying that unless the authorization server provides a special option other than 'public' and 'confidential', clients MUST register such applications separately for each component. It leaves the decision of how to deal with such clients completely up to the authorization server during the registration process. I think we should also add a SHALL in section 2: When registering a client, the client developer SHALL:, which is implicit already. Another, less desirable alternative is to remove this section and add: The authorization server MAY provide the client with other client types options during the registration process. Such client types are beyond the scope of this specification. Such additional client types will require a different set of security considerations not provided by this specification. My intention was never to introduce a (breaking) change here, just to clarify what was already the prescribed process. I'm open to other suggestions as long as they account for the deep dependency this protocol has on client type identification. EH -Original Message- From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Wednesday, March 14, 2012 11:42 AM To: Eran Hammer; Marius Scurtescu Cc: Breno de Medeiros; OAuth WG Subject: RE: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 All of Marius, Breno, Nat, myself, and several others on the OpenID AB list have read it this way. I believe that either this change needs to be removed (my preference!) or a sentence needs to be explicitly added that states that The same client_id MAY be used with both the code and token response types to explicitly rule out this apparently common misinterpretation of the new text. Otherwise, I agree that it will continue to be perceived by most people as a breaking change. -- Mike P.S. When you make this change, you should also correct the typo in this sentence: The authorization server MAY provider tools to manage such complex clients through a single administration interface by changing provider to provide. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer Sent: Wednesday, March 14, 2012 11:35 AM To: Marius Scurtescu Cc: Breno de Medeiros; OAuth WG Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 You are not reading it correctly
Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types
On Tue, Jul 19, 2011 at 10:08 AM, Aiden Bell aiden...@gmail.com wrote: This seems clearer Eran. I don't blame you for not liking collection, I was searching for a term without too much theoretical background; Your revision reads much better. I'm happy with it. This seems like a good alternative now if parsing is the concensus. Thanks again, Aiden On 19 July 2011 17:33, Mike Jones michael.jo...@microsoft.com wrote: Good Also agree that this is a reasonable compromise. -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, July 19, 2011 9:24 AM To: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to section 8.4. Defining New Authorization Endpoint Response Types Revised text. I changed it to focus on the implementation details. In other words, all response types must be registered. If the type name includes spaces, it changes how the value is compared (space-delimited list of values where the order does not matter). That's it. Spaces only change how values are compared. EHL --- 8.4. Defining New Authorization Endpoint Response Types New response types for use with the authorization endpoint are defined and registered in the authorization endpoint response type registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF. response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = _ / DIGIT / ALPHA If a response type contains one of more space characters (%x20), it is compared as a space-delimited list of values in which the order of values does not matter. Only one order of values can be registered, which covers all other arrangements of the same set of values. For example, the response type token code is left undefined by this specification. However, an extension can define and register the token code response type. Once registered, the same combination cannot be registered as code token, but both values can be used to denote the same response type. Also, change the definition of response_type in section 3.1.1: response_type REQUIRED. The value MUST be one of code for requesting an authorization code as described by Section 4.1.1, token for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4. If the response type contains one or more space characters (%x20), it is interpreted as a space-delimited list of values, where the order of values does not matter (e.g. a b is the same as b a). ___ 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 -- -- Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth v2-18 comment on state parameter
On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eliot Lear Sent: Sunday, July 17, 2011 2:49 AM One other point: if the redirection_uri can have fragments and can be provided, why is state necessary? First, I assume you mean query instead of fragment. This was discussed on the list about a year ago. There isn't a requirement to support both dynamic redirection URIs as well as a special state parameter. However, the state parameter provides a better way to allow customization of the redirection request alongside full registration of the redirection URI. Section 3.1.2 recommends using the state parameter over changing the redirection URI itself. Using state is much simpler because the authorization server does not have to implement potentially insecure URI comparison algorithms for dynamic redirection URIs. Agree -- for instance, Google's provider doesn't allow arbitrary dynamic specification of query or fragment parameters in redirect URIs, for instance, due largely to security considerations. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] defining new response types
On Wed, Jul 20, 2011 at 8:42 AM, Eran Hammer-Lahav e...@hueniverse.comwrote: If you don’t register the combination, how would anyone know (aside from reading every service specific documentation) what the combination means. As clearly stated in your own list, at a minimum, the location of the credentials is not obvious and must be defined. We had a long discussion on this list about the correct implementation of “token code” as one example. Sounds good. ** ** The cost of registration is VERY low. You don’t need an RFC to do it. You just need to publish a specification defining the response type and make it available somewhere stable. For example, on a Google official blog or documentation site, or on the OpenID Foundation site (your personal blog isn’t ideal but can also sometime work). Once published, you send an email to the extension list and ask for registration. The template takes no time at all (requested name, your name or your company/organization name, and the location of the specification). You might get some feedback from the designated expert (e.g. if you try to register ‘token_and_code’ they might suggest changing it to ‘token code’ or if you try to register ‘send_nothing’ they will suggest ‘none’, etc.). ** ** Really the only requirement is that you write a short specification defining the combination. If you maintain a public web page with all the combination you defined, you can keep adding those there instead of writing new specification for each new one, as long as you keep the registered values unchanged once registered. ** ** So the cost is really insignificant, but the benefit of clarity and interop is significant. ** ** EHL ** ** ** ** *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Breno *Sent:* Wednesday, July 20, 2011 7:52 AM *To:* Paul Tarjan *Cc:* OAuth WG *Subject:* Re: [OAUTH-WG] defining new response types ** ** ** ** Comments inline. ** ** On Tue, Jul 12, 2011 at 8:23 PM, Paul Tarjan p...@fb.com wrote: I like splitting on space like scopes. But I'm fine with registering all possible compositions that make sense, if you prefer. ** ** I agree with Marius that registering the combinations are not useful, however also agree with Paul that it's not a show stopper. As I posted to the group about a month ago, we are planning on supporting response_type=none response_type=code response_type=token response_type=signed_request token response_type=token signed_request (and maybe code token/token code) ** ** Google is planning to support the following combinations: ** ** response_type=node response_type=id_token response_type=code response_type=token response_type=code token (in either order, fragment-encoded response) response_type=code id_token (in either order, query-encoded response) response_type=token id_token (in either order, fragment-encoded response)* *** response_type=code token id_token (in any possible order, fragment-encoded response) ** ** We already have support for response_type=none and the signed_request one is a few weeks out. Paul On 7/12/11 1:35 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I will withdraw my objections to the change (parsing the response_type string) if enough support is present. If you care about it, please speak out now. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, July 12, 2011 1:32 PM To: OAuth WG Subject: Re: [OAUTH-WG] defining new response types As a data point motivating this functionality, the OpenID Connect Core spec currently includes: response_type A space delimited, case sensitive list of string values (Pending OAuth 2.0 changes). Acceptable values include code, token, and none. The value MUST include code for requesting an Authorization Code, token for requesting an Access Token, and none if no response is needed. The OpenID Connect Session Management spec also defines an id_token response_type. Combinations of these (other than none) are meaningful and used. The syntax for this can change, but this functionality is very important to OpenID Connect as it is currently written. Thanks, -- Mike -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno de Medeiros Sent: Tuesday, July 12, 2011 11:48 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] defining new response types On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav e...@hueniverse.com wrote: That's pretty farfetched. In previous versions we had 'code_and_token' which was a composite value but without any special characters. If people
Re: [OAUTH-WG] defining new response types
Imposing order and exact string matching on response_type's while simultaneously supporting a special character '+' and introducing the concept of composite response_type is a poor compromise, IMNSHO. What is the rationale to fear allowing multiple-valued response_type as we have for other parameters in the spec? On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav e...@hueniverse.com wrote: As for the plus encoding we can choose another char or give an example. On Jul 11, 2011, at 18:07, Marius Scurtescu mscurte...@google.com wrote: If I read section 8.4 correctly it seems that new response types can be defined but composite values must be registered explicitly. I don't think this approach scales too well. OpenID Connect for example is adding a new response type: id_token. id_token can be combined with either code or token and potentially with both of them, the following combinations must be registered as a result: code+id_token token+id_token code+token+id_token and this assumes that code+token is already registered. I think it makes more sense to define response_type as a space separated list of items, where each item can be individually registered. I do realize that this complicates things quite a bit (not we have to define and deal with both composite response_type and the individual items). As a side note, using + as separator could cause lots of problems. If people naively type code+toke it will be decoded as code token. No one will remember the hex code for +. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- --Breno ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] defining new response types
On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav e...@hueniverse.com wrote: Requiring parsing of the response type parameter is a big change at this point. Even if it is a decent idea, I'm against it for the sole reason that I don't want to introduce such a change - we're done. The + character makes reading values easier because it give composites of existing, individually defined values, a special meaning to *people*, but it does not change any existing code or adds any work. Servers will still perform simple string comparison. Parsing a list of values is unnecessary complexity. Developers can learn to put values in their expected order (since they are all going to cut-n-paste anyway). I disagree. I believe that servers will either not support the composite types at all, or will allow developers to enter it into any order to avoid developer pain. Also, developers will _not_ cut-and-paste. They will expect the fact that order is not meaningful by interacting with providers that don't perform exact string matching and then have interoperability issues with compliant implementations. I rather drop the special character then add parsing, but I think it is a useful *convention*. Do people want to keep it or drop it? EHL -Original Message- From: Breno de Medeiros [mailto:br...@google.com] Sent: Tuesday, July 12, 2011 10:59 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] defining new response types Imposing order and exact string matching on response_type's while simultaneously supporting a special character '+' and introducing the concept of composite response_type is a poor compromise, IMNSHO. What is the rationale to fear allowing multiple-valued response_type as we have for other parameters in the spec? On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav e...@hueniverse.com wrote: As for the plus encoding we can choose another char or give an example. On Jul 11, 2011, at 18:07, Marius Scurtescu mscurte...@google.com wrote: If I read section 8.4 correctly it seems that new response types can be defined but composite values must be registered explicitly. I don't think this approach scales too well. OpenID Connect for example is adding a new response type: id_token. id_token can be combined with either code or token and potentially with both of them, the following combinations must be registered as a result: code+id_token token+id_token code+token+id_token and this assumes that code+token is already registered. I think it makes more sense to define response_type as a space separated list of items, where each item can be individually registered. I do realize that this complicates things quite a bit (not we have to define and deal with both composite response_type and the individual items). As a side note, using + as separator could cause lots of problems. If people naively type code+toke it will be decoded as code token. No one will remember the hex code for +. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- --Breno -- --Breno ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] defining new response types
On Tue, Jul 12, 2011 at 11:36, Eran Hammer-Lahav e...@hueniverse.com wrote: That's pretty farfetched. In previous versions we had 'code_and_token' which was a composite value but without any special characters. If people think that we need to force such values to avoid this claimed developer confusion, let's drop the + and be done. Maybe far fetched, but it's already available in our production environment -- we had implemented the code_and_token approach earlier (though not documented it) but abandoned that route as we thought the exponential explosion was harmful when we started contemplating adding new types and allowing various combinations of them. The only requirement I was asked to cover was to allow response type extensibility. If there is WG consensus to also support the requirement of composite values using any order, we can discuss that. Let's. In addition, defining a parsing method adds a significant amount of new complexity beyond just splitting the string: * It allows for composite values that make no sense (since anything goes, composite values are not registered, just the components). * Additional error codes are needed to indicate bad format, unsupported values (specify which one), unsupported combinations, etc. * Developers lose the benefit of a simple registry with every possible combination they may choose. So the two questions are: 1. Do you find the + proposal as defined in -18 to be useful or confusing? It is ugly. 2. Should the protocol support dynamic composite values with the added complexity (breaking change)? That's my preference. EHL -Original Message- From: Breno de Medeiros [mailto:br...@google.com] Sent: Tuesday, July 12, 2011 11:18 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] defining new response types On Tue, Jul 12, 2011 at 11:10, Eran Hammer-Lahav e...@hueniverse.com wrote: Requiring parsing of the response type parameter is a big change at this point. Even if it is a decent idea, I'm against it for the sole reason that I don't want to introduce such a change - we're done. The + character makes reading values easier because it give composites of existing, individually defined values, a special meaning to *people*, but it does not change any existing code or adds any work. Servers will still perform simple string comparison. Parsing a list of values is unnecessary complexity. Developers can learn to put values in their expected order (since they are all going to cut-n-paste anyway). I disagree. I believe that servers will either not support the composite types at all, or will allow developers to enter it into any order to avoid developer pain. Also, developers will _not_ cut-and-paste. They will expect the fact that order is not meaningful by interacting with providers that don't perform exact string matching and then have interoperability issues with compliant implementations. I rather drop the special character then add parsing, but I think it is a useful *convention*. Do people want to keep it or drop it? EHL -Original Message- From: Breno de Medeiros [mailto:br...@google.com] Sent: Tuesday, July 12, 2011 10:59 AM To: Eran Hammer-Lahav Cc: Marius Scurtescu; OAuth WG Subject: Re: [OAUTH-WG] defining new response types Imposing order and exact string matching on response_type's while simultaneously supporting a special character '+' and introducing the concept of composite response_type is a poor compromise, IMNSHO. What is the rationale to fear allowing multiple-valued response_type as we have for other parameters in the spec? On Mon, Jul 11, 2011 at 18:51, Eran Hammer-Lahav e...@hueniverse.com wrote: As for the plus encoding we can choose another char or give an example. On Jul 11, 2011, at 18:07, Marius Scurtescu mscurte...@google.com wrote: If I read section 8.4 correctly it seems that new response types can be defined but composite values must be registered explicitly. I don't think this approach scales too well. OpenID Connect for example is adding a new response type: id_token. id_token can be combined with either code or token and potentially with both of them, the following combinations must be registered as a result: code+id_token token+id_token code+token+id_token and this assumes that code+token is already registered. I think it makes more sense to define response_type as a space separated list of items, where each item can be individually registered. I do realize that this complicates things quite a bit (not we have to define and deal with both composite response_type and the individual items). As a side note, using + as separator could cause lots of problems. If people naively type code+toke it will be decoded as code token. No one will remember the hex code
Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme
On Tue, Jun 7, 2011 at 17:07, Nico Williams n...@cryptonector.com wrote: On Tue, Jun 7, 2011 at 6:41 PM, Tim tim-proje...@sentinelchicken.org wrote: I have to agree with Nico here. In almost all cases I assert that, on typical modern networks: let P = difficulty of passive attack let M = difficulty of active (man-in-the-middle) attack O(P) = O(M) . This isn't to say the real world difficulty of an active attack is just as easy, but it is within a constant factor. If someone has published a tool that conducts MitM attacks for the specific protocol you're dealing with, the difference in difficulty clearly becomes marginal. Consider the complexity of the attacks implemented by sslstrip and yet the relative ease with which you can use it to MitM all SSL connections. Exactly, and very well put. Active attacks sound harder, and they do actually require more work, but in many cases that work can be automated, and once automated there can be no difference in effort required to mount an active attack versus a passive one. Do we suppose that this proposal can get past secdir, IESG, and IETF reviews as-is? I doubt it. Here's another issue: some of you are saying that an application using this extension will be using TLS for some things but not others, which presumes a TLS session. Does using TLS _with_ session resumption _and_ HTTP/1.1 pipelining for all requests really cost that much more in latency and compute (and electric) power than the proposed alternative? I seriously doubt it, and I'd like to see some real analysis showing that I'm wrong before I'd accept such a rationale for this sort of proposal. Google has performed detailed analysis of SSL performance after several optimizations and we have concluded that the answer is 'no significant overhead' as you suggest. Indeed, in some workload situations it may be actually cheaper to serve SSL traffic because there is reduction in network latency by avoiding bad proxies. We have published some results here: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Or perhaps the motivation relates to accidental leakage of secure cookies in non-secure contexts. But why not just fix the clients in that case? Nico -- ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -- --Breno ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten t.lodderst...@telekom.de wrote: Hi Marius, wrt auto-approval: how is the authorization server supposed to validated the client's identity in a reliable way? Otherwise another application (using the id of the legitimate client) could abuse the authorization previously approved by the user as long as the session with the authorization server is valid. The redirect_uri won't help for all kinds of clients since a native app could use the correct redirect_uri and nevertheless get access to the token. A native app that can screen scrape the browser can probably also install a keylogger. It would be very difficult or impossible to protect against a malicious native app with access to shared OS resources. regards, Torsten. -Ursprüngliche Nachricht- Von: Marius Scurtescu [mailto:mscurte...@google.com] Gesendet: Dienstag, 10. Mai 2011 21:15 An: Doug Tangren Cc: oauth@ietf.org Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience On Tue, May 10, 2011 at 6:25 AM, Doug Tangren d.tang...@gmail.com wrote: Hi, I'm implementing an authorization and resource server at worked based on the oauth2 draft 15. A question arose about the user experience of users of an implicit client flow. I've set a one hour expiry on access tokens but now the question is should the client be forced to re-prompt the user for authorization when their receive an error response from the resource server or when they refresh the page? I realize that some implementation details like this are mentioned as being beyond the scope of the spec but I wanted to get a general sense of what the authors and implementors thoughts about how it would actually be used and what is the expected user experience. I also realize that from a server's perspective, without a client secret, authorization code, or other prior evidence of who a request is coming from that there is little way for a server to be permissive about allowing for the refreshing of an access token in an implicit flow. Has there been any conversation around possible alternatives that would permit users of the implicit flow to have the same user experience as the authorization code flow? This question was raised a few times on this list. The only solution I am aware of is for the authorization server to support auto-approvals and an immediate mode, Auto-approval means that the server will not show the approval page if the same user/scopes/client have already been approved. So as long as the user has an active session the client can get new access tokens in a hidden iframe. If the user session times out then the request in the iframe will hang, the frame will be redirected to a login page. To prevent this the client must be able to tell authorization server that it wants an immediate type request, no UI whatsoever should be shown and if auto-approval is not possible, or not active session, then just return an error. The client then can popup a window and start a regular request, so the user can login and/or approve. Auto-approvals are up to the server to support, no support from the protocol is required. You probably want to support this only for the implicit flow. Immediate mode needs a special request parameter and also a special error code. There is no extension that defines these, the suggestion was that this should go into the OpenID Connect spec, together with a username hint parameter. Hope this helps, Marius ___ 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 -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Wed, May 11, 2011 at 11:44 AM, Lodderstedt, Torsten t.lodderst...@telekom.de wrote: How shall the authorization server ensure that the calling client is a user-agent based app (i.e. a native app could impersonate an user-agent based app)? In my opinion, enforcing explicit user consent is the only way to prevent this kind of attack. Native apps will require access to shared OS resources to retrieve the access token if the redirect URI is a web location registered with the proper web client. If the Native app has such access, the native app can do far more interesting things to compromise the users credentials directly. No amount of protocol sophistication can address this. regards, Torsten. -Ursprüngliche Nachricht- Von: Marius Scurtescu [mailto:mscurte...@google.com] Gesendet: Mittwoch, 11. Mai 2011 20:28 An: Lodderstedt, Torsten Cc: oauth@ietf.org; Doug Tangren Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten t.lodderst...@telekom.de wrote: Hi Marius, wrt auto-approval: how is the authorization server supposed to validated the client's identity in a reliable way? Otherwise another application (using the id of the legitimate client) could abuse the authorization previously approved by the user as long as the session with the authorization server is valid. The redirect_uri won't help for all kinds of clients since a native app could use the correct redirect_uri and nevertheless get access to the token. The only validation is based on the redirect URI. Native apps should not use the implicit flow, and in general there is no need for auto-approval for them. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] oauth2 implicit flow user experience
On Wed, May 11, 2011 at 3:26 PM, Lodderstedt, Torsten t.lodderst...@telekom.de wrote: Through registration and redirect URI validation. A native app does not have to impersonate, they can just register a user-agent client. Everything boils down to the user trusting the app. As Breno mentions, nothing the spec can do to help with that. It could recommend the authorization server not to automatically process repeated authorizations without user consent if it cannot reliably authenticate the client. And, as I explained above, it would provide no additional meaningful security while at the same time eliminating the value of the user-agent profile. Marius ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: OAuth Security Consideration Text
On Wed, May 11, 2011 at 7:23 PM, Lodderstedt, Torsten t.lodderst...@telekom.de wrote: Hi Breno, thanks for the feedback. Please find my comments inline. Now higher level comments: On Native Apps protection of refresh token: On section Definitions, there is a sentence in the Native Apps It is assumed that such applications can protect dynamically issued secrets, such as refresh tokens, from eavesdropping by other applications residing in the same service the original text says: on the same device I suggest that you strike out this sentence from definitions since it is confusing. This should be moved to section 2.4, with a specific headed paragraph about management of refresh tokens for native applications including specific recommendation. This section shall document all assumptions determining the differences between those categories, which are relevant for the security sections. Thus I would like to keep it and probably improve it. This may be a difference of opinion rather than substance, but I find that assumptions stated too far ahead of their use suffer from lack of connection. I would suggest again that the definition remain purely semantic, and the security assumptions be discussed more closely to the attending threats and mitigations. E.g. of substitution paragraph: Native Applications MUST use operating system mediated protections to ensure that the refresh tokens are safe from unauthorized access by other users and applications. It is highly RECOMMENDED that such applications use OS-provided APIs to manage secrets. The applications MUST apply appropriately restrictive access controls to any file system or persistent memory objects where the refresh token is stored. On Client Authentication: Authorization servers are encouraged to consider stronger client authentication means -- This is too vague to be actionable. There is a great tradition of 'innovation' in client security that promotes no security and hinders interoperability. I tend to believe that it is better for servers to be conscious of the limitations of client authentication and implement mitigation measures than to create ad- hoc authentication mechanisms. Suggest to strike out this sentence. Authorization server MUST NOT issue client secrets to native or user agent-based applications in general. - Agreed on user-agent, however at least in principle it is possible to issue secrets to native applications that use hardware-based DRM modules and can hold on to secrets. A couple of comments on this: 1) This statement is intended to prohibit secrets for software packages and not software instances. Thus the text also says An authorization server MAY issue a client secret for an installation of a native application on a specific device.. We just want to get rid of the bad practice of using secrets for authenticating software packages. This practice creates a false feeling of security and people tend to rely on this kind of client authentication too much. They shall be adviced to utilize other means than client secrets. When the spec did define a Native App flow it mandated the opposite (the secret was required not optional), which led Google, for instance, to launch the OAuth2 registration for clients to include secret issuance for native apps---against the recommendation of our internal security team---for pure compliance reasons (not that we are relying on its remaining a secret, our security model does not rely on this). I welcome the change of language (even if we may take some time for Google to catch up with it), but find it a bit too strong. Possibly It is NOT RECOMMENDED ... followed by some description of why this is ineffective as a security measure? 2) The intention of the text is to give simple and clear rules instead of discussing if, then and why. This discussion is subject of the security threats and considerations I-D referenced by the introduction of the text. Yes, and I am not suggesting it should -- my recommendation was to strike it out. However, what about a softened approach as above? 3) DRM modules give you a device specific authentication, they do not authenticate a certain software package or instance. More importantly, since the OAuth2 spec no longer actually specifies how to implement a Native App Flow end-to-end, I am not sure how to even reason about Native App issues. Propose simply strike out 'native or'. The description of how to implement native apps is badly missing right now and has been requested during IETF-80. It will be re-included soon. That's welcome news indeed. On Malicious Client Obtains Authorization: Authorization servers MUST NOT automatically process (without user interaction) repeated authorizations without authenticating the client. - Not sure what to make of this sentence
Re: [OAUTH-WG] Freedom of assembly for response_type
On Fri, Feb 18, 2011 at 7:17 AM, Paul Madsen paul.mad...@gmail.com wrote: Breno, why are you using 'cookie' in this context? SAML's 'session management' (I assume you are referring to SLO?) functionality does not rely on browser cookies, but rather on the participants sending a LogoutRequest carrying an identifier for the Subject in question (and possibly a session index) Is it the session index that you are referring to as a cookie? Yes. As far as I understand it, it is often the case that websso deployments based on SAML commonly use the SAML assertion for the session id as a browser cookie in practice. Facebook Connect has an authenticated user_id blob that can be used as a cookie (and the FB-provided js libraries certainly do so). I agree that 'cookie' is possibly a bad name (there's not a necessity to use it as a browser cookie in the proposed OpenIDConnect interaction either, though it will likely be used as such). However, names such as 'token', 'bearer', are already bound to other meanings in the OAuth2 spec. Another name that I have referred to this in the past is 'session_token'. Of course, both IdPs and SPs typically use cookies for their own local state, but this is independent of SAML. The only application of cookies in SAML are for discovery (arguably deployed even less than the above SLO). See above. I confess I dont know how FB Connect does SLO thanks paul On 2/17/11 7:22 PM, Breno wrote: The use case is very straightforward: - SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: You need to define how this proposed extension works with the overall architecture. This is not just an endpoint people can bastardize (I am not suggesting * *you** are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t). To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 1:58 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly. The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. EHL *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Breno *Sent:* Thursday, February 17, 2011 10:30 AM *To:* oauth@ietf.org *Subject
[OAUTH-WG] Freedom of assembly for response_type
- Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type). - Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=code response_type=token response_type=code+token response_type=cookie response_type=code+cookie response_type=token+cookie response_type=foo+bar Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly. The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. EHL *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Breno *Sent:* Thursday, February 17, 2011 10:30 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type). - Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=code response_type=token response_type=code+token response_type=cookie response_type=code+cookie response_type=token+cookie response_type=foo+bar Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. -- Breno de Medeiros -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Freedom of assembly for response_type
The use case is very straightforward: - SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: You need to define how this proposed extension works with the overall architecture. This is not just an endpoint people can bastardize (I am not suggesting ** you** are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t). To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 1:58 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly. The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. EHL *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Breno *Sent:* Thursday, February 17, 2011 10:30 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type). - Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=code response_type=token response_type=code+token response_type=cookie response_type=code+cookie response_type=token+cookie response_type=foo+bar Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values. 2. Define behaviors in the core only for values 'code
Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: I am not questioning the use case, only how it fits within the OAuth framework. I don’t understand how such an extension is expected to work with the existing grant types. The response_type parameter is used to identify if the flow being used is for an implicit grant or authorization code. Are you suggesting a new grant type? Are you suggesting additional response parameters/headers (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous types. Without full requirements we can’t design an extension point. Asking to make this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the End User Authorization Response, in analogy/in addition to the access_token - If specified in combination with code, it's returned in exchange for the code, in analogy with the access_token EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 4:22 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: You need to define how this proposed extension works with the overall architecture. This is not just an endpoint people can bastardize (I am not suggesting ** you** are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t). To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 1:58 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly. The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. EHL *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Breno *Sent:* Thursday, February 17, 2011 10:30 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants
Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: Is cookie exchanged for an access token? Authorization grants are not meant to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 4:50 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I am not questioning the use case, only how it fits within the OAuth framework. I don’t understand how such an extension is expected to work with the existing grant types. The response_type parameter is used to identify if the flow being used is for an implicit grant or authorization code. Are you suggesting a new grant type? Are you suggesting additional response parameters/headers (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous types. Without full requirements we can’t design an extension point. Asking to make this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the End User Authorization Response, in analogy/in addition to the access_token - If specified in combination with code, it's returned in exchange for the code, in analogy with the access_token EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 4:22 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: You need to define how this proposed extension works with the overall architecture. This is not just an endpoint people can bastardize (I am not suggesting ** you** are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t). To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 1:58 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient
Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav e...@hueniverse.comwrote: So an implicit grant can produce just a cookie or both cookie and token, but not code? Yes, cookies would be returned in the same context of access_tokens, either as the result of an implicit grant or resulting from an explicit exchange from a code-type grant. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 5:10 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Is cookie exchanged for an access token? Authorization grants are not meant to be useful by themselves, only exchanged for an access token. In this scenario, grants are exchanged for access tokens and/or cookies. Can you request only a cookie? Or is it always with either a token or code? The idea is that a grant can be exchanged for only a cookie in some cases. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 4:50 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I am not questioning the use case, only how it fits within the OAuth framework. I don’t understand how such an extension is expected to work with the existing grant types. The response_type parameter is used to identify if the flow being used is for an implicit grant or authorization code. Are you suggesting a new grant type? Are you suggesting additional response parameters/headers (in the case of a cookie) with both grant types? It's a separate grant type that can be combined with either of the previous types. Without full requirements we can’t design an extension point. Asking to make this parameter a free text field is not helpful. The requirement is to allow another grant type, cookie. - cookie can be used separately or in combination with code or token. - if specified by itself or in combination with token, it's returned in the End User Authorization Response, in analogy/in addition to the access_token - If specified in combination with code, it's returned in exchange for the code, in analogy with the access_token EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17, 2011 4:22 PM *To:* Eran Hammer-Lahav *Cc:* oauth@ietf.org *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type The use case is very straightforward: - SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants. - OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios. We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server. The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently. This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations. On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: You need to define how this proposed extension works with the overall architecture. This is not just an endpoint people can bastardize (I am not suggesting ** you** are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn’t). To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That’s like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on. EHL *From:* Breno [mailto:breno.demedei...@gmail.com] *Sent:* Thursday, February 17
Re: [OAUTH-WG] [Openid-specs-ab] JSON Token spec work at IIW
Thanks for circulating these. --Breno. On Tue, Nov 9, 2010 at 21:59, Mike Jones michael.jo...@microsoft.com wrote: I’ve now finished my series of posts on the JSON token spec work that occurred at IIW. For reference, they are: - JSON Token Spec Results at IIW on Tuesday: http://self-issued.info/?p=361 - JSON Token Encryption Spec Results at IIW on Wednesday: http://self-issued.info/?p=378 - JSON Token Naming Spec Results at IIW on Wednesday: http://self-issued.info/?p=386 - JSON Public Key Spec Results at IIW on Thursday: http://self-issued.info/?p=390 Cheers, -- Mike ___ Openid-specs-ab mailing list openid-specs...@lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs-ab -- --Breno ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Request sent to http: instead of https:`
Suppose server A documents that their endpoint X is at https://server.example.com/x; there's no service at the corresponding http location for security reasons. Client developer fatfingers URL as http://server.example.com/x What is the correct response? I understand that this is out of scope for the spec, but maybe there's agreement on some guidance? One thing one shouldn't do is serve a 302 here; it would allow defective clients to remain unpatched. My preference is to simply return a bare 403 or 404 here -- after all the endpoint does not exist (404) or if one uses the convention that resources at http/https are usually identical, then http is a non-authorized method to access the resource (403). Thoughts? -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Request sent to http: instead of https:`
+1 for language in the spec describing how to handle this case On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay progr...@twilio.com wrote: Hopefully you also invalidate the token (if bearer) since it was send over an insecure channel. Excuse my naivety, but perhaps that's worth putting in the spec? EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno Sent: Wednesday, October 13, 2010 11:31 AM To: oauth@ietf.org Subject: [OAUTH-WG] Request sent to http: instead of https:` Suppose server A documents that their endpoint X is at https://server.example.com/x; there's no service at the corresponding http location for security reasons. Client developer fatfingers URL as http://server.example.com/x What is the correct response? I understand that this is out of scope for the spec, but maybe there's agreement on some guidance? One thing one shouldn't do is serve a 302 here; it would allow defective clients to remain unpatched. My preference is to simply return a bare 403 or 404 here -- after all the endpoint does not exist (404) or if one uses the convention that resources at http/https are usually identical, then http is a non-authorized method to access the resource (403). Thoughts? -- Breno de Medeiros ___ 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 -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Request sent to http: instead of https:`
Or a connection to evil will happen. On Wed, Oct 13, 2010 at 6:33 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I don't think so. If you are not running a server on port 80, the connection will never happen and nothing bad will be send on the wire. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of William Mills Sent: Wednesday, October 13, 2010 5:05 PM To: Breno; Jeff Lindsay Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Request sent to http: instead of https:` This rather implies that we're specifying running a full server on port 80 as a stupid detector. We should tread carefully here. +1 for language in the spec describing how to handle this case On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay progr...@twilio.com wrote: Hopefully you also invalidate the token (if bearer) since it was send over an insecure channel. Excuse my naivety, but perhaps that's worth putting in the spec? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal for signatures
On Fri, Jun 25, 2010 at 10:51 AM, Luke Shepard lshep...@facebook.com wrote: What's the purpose of leaving out the key ID? It's one more field that developers have to learn and configure and type in. We should keep the simple case simple, while allowing for more complex cases. I think the fact that many providers now offer only a single, shared secret is an indication that the key ID is not required. Are you arguing here that the key_id should be an optional field, or that it should not be part of the specification at all? On Jun 25, 2010, at 7:40 AM, Breno wrote: Key ids are an optimization in the case of rotating public keys, but pretty much an operational requirement if you wish to support automatic rotation of shared keys. On Jun 23, 2010 2:56 AM, Ben Laurie b...@google.com wrote: On 22 June 2010 21:45, David Recordon record...@gmail.com wrote: Hey Dick, in answering my quest... I don't understand why they are unnecessary no matter how keys are managed: if there's ever a possibility that you might have more than one key for someone, then key IDs are a useful optimisation. Put it another way: what's the purpose of leaving out the key ID? And yes, Applied Cryptography is worth reading. :) --David On Tue, Jun 22, 2010 at 12:5... ATT1..txt -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Understanding the reasoning for Base64
On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard lshep...@facebook.com wrote:
Brian, Dirk - just wondering if you had thoughts here?
The only strong reason I can think of for base64 encoding is that it allows
for a delimiter between the body and the signature. Is there any other reason?
Without base64 encoding we have to define canonicalization procedures
around spaces and we still have to URL encode separator characters
such as {. There is also the risk that developers might be confused
whether the URL encoding is to be performed before or after
computation of the signature. If you say that the signature is
computed on the base64 encoded blob, there's less scope for confusion
and interoperability issues.
On Jun 24, 2010, at 11:33 AM, Naitik Shah wrote:
I've been following some of the discussions wrt the new Signature proposal,
and I think I get the reason for needing Base64, but wasn't quite sure if I
understood it correctly (allows the use of a separator?). Would someone mind
elaborating?
The payload looks is urlencode(web_base64(json_encode(data))) -- and the
urlencode in this case should be an identity function.
I'm wondering if urlencode(json_encode(data)) would be acceptable.
Thanks,
-Naitik
ATT1..txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Breno de Medeiros
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow
On Wed, Jun 16, 2010 at 8:49 AM, Justin Richer jric...@mitre.org wrote: We're looking at using the rescope operation to support redelegation, and in this we wouldn't want to give the second client a refresh token of their own, just an access token that is good for a subset of scopes attached to the original refresh/access combination that the user authorized. I'm not seeing a use case for asking for a new refresh token using an existing refresh token as auth, though. Could you elaborate what this might be? Looking at the beginning of this thread, there is a proposal to return each scope as a separate token. This is presumably a separation of trust issue that the client would like to enforce. From a protocol perspective, it would be simpler to exchange the new refresh token for one with fewer privileges instead of requesting/receiving one token per scope. -- Justin On Wed, 2010-06-16 at 11:32 -0400, Eran Hammer-Lahav wrote: The refresh token represents what the resource owner authorized. The access token can be a subset of that. The current draft already supports asking for less scope than was granted. It doesn’t support asking for a new refresh token with less scope. Well, what about just returning a refresh token with the access token when the requested set of scopes for the access token is stricter? Of course, in the user-agent flow there is no refresh token. EHL From: Breno [mailto:breno.demedei...@gmail.com] Sent: Wednesday, June 16, 2010 8:17 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] proposal: multiple access tokens from a single authorization flow Alternative proposal. Create a new call for 'dropping privileges' where a client can present a single refresh token and scopes and obtain a new refresh token/access token with defined scopes provided that these scopes were already granted to the original token. The advantage of a separate call is that it has less impact in implementations because it does not modify existing flows. It is also more flexible. For instance it would allow a client too split its privileges into tokens with overlapping scopes for arbitrary requirements around security and functionality of delegating its privileges. On Jun 11, 2010 1:12 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: I'll let you know when I see the I-D :-) EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: F... -- Breno de Medeiros ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] A display parameter for user authorization requests
On Wed, Jun 9, 2010 at 12:06, David Recordon record...@gmail.com wrote: First draft of the UX Extension is at http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-ux-00.txt. Eran, I'm more than happy to have you take over as editor. I included Allen and Breno as authors since I followed Allen's suggestion and adopted the language preference parameter from the OpenID extension. I also included Luke as an author since he wrote the first pass of a display parameter. That said, none of them have seen this draft yet. Thanks. At a higher-level, is the extension model of OAuth2 to add new parameters at the top-level namespace? Works fine for extensions such as this one that are probably of interest to a large part of the community, but I wonder if we should give guidance for a generic approach to doing this (even if not adhering to it in the 'main' extensions). --David On Tue, Apr 13, 2010 at 12:36 PM, Allen Tom a...@yahoo-inc.com wrote: At least with regards to the language preference, how about if we just copy the openid.ui.lang parameter from the OpenID UI Extension? http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor3 In flows in which the client redirects the user’s web browser to authorize access, the client MAY send the Authorization Server a hint regarding the user’s preferred language by sending the following parameter: lang The user’s preferred languages as a [BCP 47] language priority list, represented as a comma-separated list of BCP 47 basic language ranges in decending priority order. For instance, the value “fr-CA,fr-FR,en-CA” represents the preference for French spoken in Canada, French spoken in France, followed by English spoken in Canada. The language preference hint SHOULD take precedence over the Accept-Language HTTP header sent by the user’s browser, and SHOULD take precedence over the language preference inferred by the user’s IP Address. BCP 47: http://tools.ietf.org/html/bcp47 Allen On 4/12/10 1:32 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Between language preferences, display configuration, and immediate check, I think it might be worth to move that work to another draft. Timeline-wise, this has the potential of slowing us down. I also fear getting what is now a pretty simple spec much more complicated. Anyone cares to try a first draft or outline? I can do the editorial work if needed, but someone needs to write something first. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
