Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
Added to section 1: TLS Version Whenever TLS is required by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 xref target='RFC5246' / is the most recent version, but has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 xref target='RFC2246' / is the most widely deployed version, and will provide the broadest interoperability. Implementations MAY also support additional transport-layer mechanisms that meet their security requirements. And referenced this section when TLS requirements were previously defined. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Barry Leiba Sent: Sunday, December 18, 2011 10:56 AM To: oauth WG Subject: Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base To close out this issue: There's disagreement about whether this proposed text is necessary, but no one thinks it's *bad*, and I see consensus to use it. Eran, please make the following change in two places in the base document: OLD The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future replacements, and MAY support additional transport-layer mechanisms meeting its security requirements. NEW The authorization server MUST implement TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 [RFC2246] is the most widely deployed version, and will give the broadest interoperability. Servers MAY also implement additional transport-layer mechanisms that meet their security requirements. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
New text added to Access Token Scope section: If the client omits the scope parameter when requesting authorization, the authorization server MUST process the request using a pre-defined default value, or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined). EHL From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 10, 2012 11:58 PM To: Eran Hammer; oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Null string, empty string, or server defined default value all work. Default scope doesn't do it for me. From: Eran Hammer e...@hueniverse.commailto:e...@hueniverse.com To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Tuesday, January 10, 2012 5:24 PM Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’. EHL From: William Mills [mailto:wmi...@yahoo-inc.com]mailto:[mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 10, 2012 4:02 PM To: Eran Hammer; oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification On your #1, I don't agree that an empty scope is useless. There are comparable implementations that use an empty scope to be a wildcard scope. I'd say, The client can MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default. The server then processes the request either issuing a grant with it's default scope as defined by the server or failing the request indicating an invalid scope requested. That language isn't quite right, but I think it's clear. From: Eran Hammer e...@hueniverse.commailto:e...@hueniverse.com To: oauth@ietf.orgmailto:oauth@ietf.org oauth@ietf.orgmailto:oauth@ietf.org Sent: Tuesday, January 10, 2012 1:15 PM Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification I don't think the issue here is about the scope value, but who does the OPTIONAL designation applies to. IOW, is it optional for the server to support/require it, or is it optional for the client to include or omit it. The intention was to make it optional for the authorization server to make all decisions about the parameter, including making it required. But the text is confusing since the text is aimed directly at the client when making the request. We need to clarify this and the options are: 1. The client can decide if they want to include or omit the scope parameter. If omitted, the server must process the request using some documented default scope. This default scope can be an empty scope rendering the token useless for anything other than verifying user authentication. 2. The server can declare scope to be a required parameter in which case the client must include it or the request will fail. In this case, we should make the text clearer that clients to find out if the particular server requires it. #1 is better for interoperability, #2 is more in the spirit of the parameter discussions so far. EHL -Original Message- From: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, January 10, 2012 11:33 AM To: SM Cc: oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification The underlying issue is that there was a decision not to in any way standardize values for scope. I agreed this was reasonable since the underlying resource APIs are likely to be very specific requiring some degree of prior knowledge by the client app developer. Thus the resource server OAuth infrastructure is free to decide what are and are not acceptable values including missing or null values for scope. I think the specification is acceptable as it is. I note that other specifications that layer on top of OAuth2 such as OpenID Connect may choose to strictly define acceptable values for scope. This type of layering works well in my opinion. Phil @independentid www.independentid.comhttp://www.independentid.com phil.h...@oracle.commailto:phil.h...@oracle.com On 2012-01-10, at 10:56 AM, SM wrote: At 09:19 10-01-2012, William Mills wrote: That does clear it up! If the implementation returns a proper error when the scope is omitted then it will be in conformance. Sending an error result for the empty scope is valid. Yes. It is not possible to get a clear view of the specs if the discussion about ambiguity relies on the meaning of the word OPTIONAL only. If there is a problem, then
Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
Added to section 1: TLS Version Whenever TLS is required by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 xref target='RFC5246' / is the most recent version, but has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 xref target='RFC2246' / is the most widely deployed version, and will provide the broadest interoperability. Implementations MAY also support additional transport-layer mechanisms that meet their security requirements. And referenced this section when TLS requirements were previously defined. That seems like a very sensible way to organize it; thanks. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
(Strictly editorial.) Just to make the first sentence easiery to parse, I suggest to clarify the scope (no pan intended) of MUST. I read it the server MUST either process the request OR fail it. If so, maybe just inserting the word either would do the job. I would also change punctuation to delineate the using and indicating clauses. Probably putting both clauses in parentheses will make it easier than adding an extra comma. Another thing that I found stands in the way of is whether it is really invalid scope [value]. Maybe it is better to indicate that no scope value has been supplied? As a developer I see the benefit of requiring a default value, incidentally, but since there is an option, I think it might be better to describe the error in a straight-forward way. The suggested text: If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request (using a pre-defined default scope value) or fail the request (indicating that the scope value is missing). The authorization server SHOULD document its scope requirements and default value (if defined). Igor On 1/20/2012 3:32 PM, Eran Hammer wrote: New text added to Access Token Scope section: If the client omits the scope parameter when requesting authorization, the authorization server MUST process the request using a pre-defined default value, or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined). EHL *From:*William Mills [mailto:wmi...@yahoo-inc.com] *Sent:* Tuesday, January 10, 2012 11:58 PM *To:* Eran Hammer; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Null string, empty string, or server defined default value all work. Default scope doesn't do it for me. *From:*Eran Hammer e...@hueniverse.com mailto:e...@hueniverse.com *To:* William Mills wmi...@yahoo-inc.com mailto:wmi...@yahoo-inc.com; oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org *Sent:* Tuesday, January 10, 2012 5:24 PM *Subject:* RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’. EHL *From:*William Mills [mailto:wmi...@yahoo-inc.com] mailto:[mailto:wmi...@yahoo-inc.com] *Sent:* Tuesday, January 10, 2012 4:02 PM *To:* Eran Hammer; oauth@ietf.org mailto:oauth@ietf.org *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification On your #1, I don't agree that an empty scope is useless. There are comparable implementations that use an empty scope to be a wildcard scope. I'd say, The client can MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default. The server then processes the request either issuing a grant with it's default scope as defined by the server or failing the request indicating an invalid scope requested. That language isn't quite right, but I think it's clear. *From:*Eran Hammer e...@hueniverse.com mailto:e...@hueniverse.com *To:* oauth@ietf.org mailto:oauth@ietf.org oauth@ietf.org mailto:oauth@ietf.org *Sent:* Tuesday, January 10, 2012 1:15 PM *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification I don't think the issue here is about the scope value, but who does the OPTIONAL designation applies to. IOW, is it optional for the server to support/require it, or is it optional for the client to include or omit it. The intention was to make it optional for the authorization server to make all decisions about the parameter, including making it required. But the text is confusing since the text is aimed directly at the client when making the request. We need to clarify this and the options are: 1. The client can decide if they want to include or omit the scope parameter. If omitted, the server must process the request using some documented default scope. This default scope can be an empty scope rendering the token useless for anything other than verifying user authentication. 2. The server can declare scope to be a required parameter in which case the client must include it or the request will fail. In this case, we should make the text clearer that clients to find out if the particular server requires it. #1 is better for interoperability, #2 is more in the spirit of the parameter discussions so far. EHL -Original Message- From: oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, January
Re: [OAUTH-WG] TLS version requirements in OAuth 2.0 base
Since there is so much agreement and peace in the air, I would through a little editorial query: Would it not be better to say the appropriate version instead of this somewaht lawyerish version (or versions)? Igor On 1/20/2012 3:44 PM, Barry Leiba wrote: Added to section 1: TLS Version Whenever TLS is required by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2xref target='RFC5246' / is the most recent version, but has a very limited deployment base and might not be readily available for implementation. TLS version 1.0xref target='RFC2246' / is the most widely deployed version, and will provide the broadest interoperability. Implementations MAY also support additional transport-layer mechanisms that meet their security requirements. And referenced this section when TLS requirements were previously defined. That seems like a very sensible way to organize it; thanks. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request
The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the scope response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request
MUST sounds reasonable Eran Hammer e...@hueniverse.com schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the scope response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Server cret verification in 10.9
Stephen asked: (13) 10.9 says that the client MUST verify the server's cert which is fine. However, does that need a reference to e.g. rfc 6125? Also, do you want to be explicit here about the TLS server cert and thereby possibly rule out using DANE with the non PKI options that that WG (may) produce? Can someone help with this? I don't know enough to address. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD Review of -22 (part I)
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, October 13, 2011 10:13 AM List 1 - Fairly sure these need changes: (1) In 2.3.1 MUST the AS support both HTTP basic and the client_id and client_secret in the request schemes? You say it MAY allow credentials in the request body, but that's different from what the AS coder has to implement. Saying an AS that issues passwords MUST support basic over TLS and MAY support including credentials in the body would seem right here. Changed 'MAY allow' to 'MAY support'. Clarified the TLS requirement for sending passwords. (2) In 2.3.1 (and more generally) what does MUST require the use of a transport-layer security mechanism really mean? I think you need to say explicitly what this means in terms of TLS and which version of TLS and which cipher suites etc. Doing that once is fine and you could then have a defined phrase for it, but it needs to be specified for each place where TLS is used. The text at the end of p15 is almost exactly what's needed, and would be if you said which cipher suites are MUSTs. I think you might need to pick cipher suites for each version if you want some combination of tls1.0 and tls1.2 and need server auth at least. Replaced ' transport-layer' with TLS with reference to the new section. (3) Having a MUST for TLS1.0 and a SHOULD for TLS1.2 is going to generate a DISCUSS or two. I think you really need to justify that in the Document and PROTO write up if you want to stick with the current choices. I personally would prefer if those were swapped myself, that is have a MUST for the latest version of TLS (TLS1.2) and a MAY/SHOULD for TLS 1.0. In addition to taking care of process concerns, there is also the recent TLS chosen plaintext attack where TLS1.2 has no problem but TLS1.0 does. (This differs from (2) above, since the former is almost editorial, but I guess this one needs to go to the WG.) This has been resolved by the chair and adjusted as such. (4) The response_type description in 3.1.1 is unclear. You say it MUST be one of various values, but then that it can be a space separated list of values. When 1 value is provided, it doesn't say what that means, it only says that the order is irrelevant. (It could mean any of these or all of these for example, both are order independent, but are not the same.) I suggest adding a sentence to say that code token means please send both if that's what it means. Removed the space-delimited text from the end of the response_type parameter definition and added the following immediate after: Extension response types MAY contain a space-delimited (%x20) list of values, where the order of values does not matter (e.g. response typea b is the same as b a). The meaning of such composite response types is defined by their respective specifications. (5) How does a client implement the MUST in the last sentence of 3.1.2.3? I don't see anything here or in 10.15 that says how to do this. I guess ideally, you'd just need a reference to somewhere else in the doc or to something else, but I do think you need something since you've made this a MUST ensure rule for clients. Adding a sentence/short paragraph here or in 10.15 with some typical/good ways to ensure this would be fine. I took that last paragraph out. Client mitigation isn't really practical here. (6) In 7.1 what does it mean to say that the client MUST NOT use the access token if it doesn't trust the token type? I don't know what code I'd write there in a client. Maybe s/trust/support/ or s/trust/understand/ would fix this. Took 'trust' out. (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. One way to do this would be to mandate that the client MUST support mac and MAY support bearer but to allow the server to choose which token types they support. And as a consequence one or both of the mac/bearer drafts need to end up as normative I think. No change as resolved by the chair. (8) 10.3 says access tokens MUST be kept confidential in transit. Does that not mean that non-anonymous TLS is a MUST? If so, then saying that clearly here would be good. If not, then saying what's really meant clearly is needed. (Same point for refresh tokens in 10.4.) Added to each section: [Access token credentials | Refresh tokens] MUST only be transmitted using TLS as described in xref target='tls' / with server authentication as defined by xref target='RFC2818' /. (9) 10.5 says effort should be made to keep codes confidential, but I expect that'll generate AD comments - that's just a bit too vague - what do you really mean
Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request
+! On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: MUST sounds reasonable Eran Hammer e...@hueniverse.com schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the scope response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request
+1 for MUST. In addition, I suggest slight rewarding: the authorization server MUST include the value of the scope parameter in the response in place of the authorization server SHOULD include the scope response parameter I think there is one parameter, scope, right? Igor On 1/20/2012 6:50 PM, Dick Hardt wrote: +! On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: MUST sounds reasonable Eran Hammer e...@hueniverse.com mailto:e...@hueniverse.com schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the scope response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request
+1 Sent from my iPhone On 2012-01-20, at 8:50 PM, Dick Hardt dick.ha...@gmail.com wrote: +! On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote: MUST sounds reasonable Eran Hammer e...@hueniverse.com schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the scope response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD Review of -22 (part III)
-Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Thursday, October 13, 2011 10:13 AM Original list of nits: -- - Intro: Maybe add some ascii-art showing the roles of the user, browser, client etc. The term client as used here is still commonly confusing and especially worth going the extra mile to clarify, before it is first used. What I think needs to be said early is that what is here called a client is normally (running on) a web server. Happy to take suggestions, but can't come up with a useful diagram myself. Added to the client definition: The term client does not imply any particular implementation characteristics (e.g. whether the application executes on a server, a desktop, or other devices). - p4: Maybe s/a string/an octet string/ in the token descriptions, unless the access token encoding is constrained to what'd be understood as a string. Just a string. - p8: Seems odd to speak of issuing an implicit grant - wouldn't that make something explicit? Maybe say With an implicit grant... instead in the 2nd para of 1.3.2? Changed to 'When issuing an access token during the implicit grant flow'. - p8: I don't get what its device operating system means. Do you mean the client is an already-trusted part of the resource owner's device OS? Changed to 'the client is part of the device operating system'. - p9 - Issuing a refresh token is optional - might be better to say that it's the authorization server's choice and there's no way for the client to signal a request for one. Changed to 'Issuing a refresh token is optional at the discretion of the authorization server.' - p10 - In figure 2, why is the Refresh token shown as optional in step (H) but not in step (B)? I think it'd be clearer for the figure to reflect the protocol options and say that the refresh token is optional in (B) as well. Because this is the refresh token flow. If it is optional, there is no flow... - p12 - the confidential/public terminology isn't great, did the WG consider authenticating vs. non-authenticating? Trying again to find better terms would maybe be worthwhile. Didn't try this particular alternative, but it doesn't flow off my tongue. Also, it may be worth explicitly saying that it doesn't matter how hard to guess a secret the client has nor how good a MAC algorithm you use with that secret - if anyone can get the secret then the client is still public. It nearly says that, but not quite and given that many developers just don't apparently still think that a hardcoded secret embedded into a binary is good enough, I'd argue its worth adding a bit more here. This seems to be cross the line as to what the server defines as confidential, but I'm happy to take text proposals. - p12/13 in the application profile descriptions - is resource owner's device correct? That seems to rule out kiosks, which may be correct, but which isn't obvious. Maybe you mean device being used by the resource owner with no implication as to ownership of the device? Changed to 'the device used by the resource owner' throughout. - p13 - client application: typos: s/such access tokens/such as access tokens/ s/which...interact with/with which the application may interact/ Ok. - p13, establishing trust with the client or its developer is badly phrased, I think you mean the AS SHOULD NOT just accept the client type unless it has some external reason to do so. Trusting the developer might be one such. Being paid is another, and maybe more likely;-) Changed to: The authorization server SHOULD NOT make assumptions about the client type, nor accept the type information provided by the client developer without first establishing trust. - p13, 2.3 has 2119 language both about the things established at registration time and things done in the protocol defined here - would it be better to identify those separately in different sections or maybe move the registration time stuff into 2.2 with a possible renaming of 2.2. Tweaked a bit, but overall it reads fine to me. - 3.1.2.1 has a SHOULD for TLS which I think generated a lot of mail on the list. I think saying why this is not a MUST would be useful, since it's the kind of thing that might get revised later on if the situation changes. This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for most client developers. - Figure 3, (p21) has multiple lines labeled A,B C - saying why might reduce some confusion. Or maybe, say that the labels reflect rough event timing or something. It'd also be good if subsequent sections said which parts of figure 3 they're addressing, e.g. 4.1.1 maps to (A), right? It's hard to tell.
[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-23.txt Pages : 65 Date: 2012-01-20 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.txt
This is ready for IETF LC and closes all open issues. There is one pending question (title 'Server cret verification in 10.9') which is non-blocking and can be resolve after LC. Chairs - per green light from Stephen posted earlier, please push the LC request. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Friday, January 20, 2012 7:05 PM To: i-d-annou...@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-23.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer David Recordon Dick Hardt Filename: draft-ietf-oauth-v2-23.txt Pages : 65 Date: 2012-01-20 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-23.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Works for me. From: Eran Hammer e...@hueniverse.com To: William Mills wmi...@yahoo-inc.com; oauth@ietf.org oauth@ietf.org Sent: Friday, January 20, 2012 12:32 PM Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification New text added to Access Token Scope section: If the client omits the scope parameter when requesting authorization, the authorization server MUST process the request using a pre-defined default value, or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined). EHL From:William Mills [mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 10, 2012 11:58 PM To: Eran Hammer; oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification Null string, empty string, or server defined default value all work. Default scope doesn't do it for me. From:Eran Hammer e...@hueniverse.com To: William Mills wmi...@yahoo-inc.com; oauth@ietf.org oauth@ietf.org Sent: Tuesday, January 10, 2012 5:24 PM Subject: RE: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification I don’t like ‘empty scope’ as it is undefined. I prefer ‘default scope’. EHL From:William Mills [mailto:wmi...@yahoo-inc.com] Sent: Tuesday, January 10, 2012 4:02 PM To: Eran Hammer; oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification On your #1, I don't agree that an empty scope is useless. There are comparable implementations that use an empty scope to be a wildcard scope. I'd say, The client can MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default. The server then processes the request either issuing a grant with it's default scope as defined by the server or failing the request indicating an invalid scope requested. That language isn't quite right, but I think it's clear. From:Eran Hammer e...@hueniverse.com To: oauth@ietf.org oauth@ietf.org Sent: Tuesday, January 10, 2012 1:15 PM Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification I don't think the issue here is about the scope value, but who does the OPTIONAL designation applies to. IOW, is it optional for the server to support/require it, or is it optional for the client to include or omit it. The intention was to make it optional for the authorization server to make all decisions about the parameter, including making it required. But the text is confusing since the text is aimed directly at the client when making the request. We need to clarify this and the options are: 1. The client can decide if they want to include or omit the scope parameter. If omitted, the server must process the request using some documented default scope. This default scope can be an empty scope rendering the token useless for anything other than verifying user authentication. 2. The server can declare scope to be a required parameter in which case the client must include it or the request will fail. In this case, we should make the text clearer that clients to find out if the particular server requires it. #1 is better for interoperability, #2 is more in the spirit of the parameter discussions so far. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt Sent: Tuesday, January 10, 2012 11:33 AM To: SM Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification The underlying issue is that there was a decision not to in any way standardize values for scope. I agreed this was reasonable since the underlying resource APIs are likely to be very specific requiring some degree of prior knowledge by the client app developer. Thus the resource server OAuth infrastructure is free to decide what are and are not acceptable values including missing or null values for scope. I think the specification is acceptable as it is. I note that other specifications that layer on top of OAuth2 such as OpenID Connect may choose to strictly define acceptable values for scope. This type of layering works well in my opinion. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-01-10, at 10:56 AM, SM wrote: At 09:19 10-01-2012, William Mills wrote: That does clear it up! If the implementation returns a proper error when the scope is omitted then it will be in conformance. Sending an error result for the empty scope is valid. Yes. It is not possible to get a clear view of the specs if the discussion about ambiguity relies on the meaning of the word OPTIONAL only. If there is a problem, then clarifying text could be used to fix it
