[OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
My client implementation per latest draft did not work against a major vendor's server implementation. This was because the vendor REQUIRES the scope parameter in the initial request. If I do not supply the scope parameter, it calls back the URL with an error response stating that the request is invalid: error=invalid_request&error_description=Missing+required+parameter:+scope I reported this to the vendor and the vendor claims that the IETF draft specification says scope is OPTIONAL and that means the vendor is free to make it required in a conforming implementation. After a careful reading of the relevant sections of the draft specification, I do not believe that is what is the intent of the specification. It says "OPTIONAL" is to be interpreted per RFC2119, which in turn says: "an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)" This leads me to believe that if I do not supply scope I should not get an error -- I may not be able to perform any API calls but I should get a token back that proves to me that the user was *some* user at the vendor. Could you please clarify or disambiguate? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Hi SM and Eran, I am confused again, after re-reading Eran's response, whether or not an implementation that rejects *missing* (as opposed to empty) scope is conformant or not. (Eran, your response was a bit ambiguous on whether an implementation is free to error out on an missing scope parameter or not -- I can clearly see it is free to error out on an empty scope parameter, but that's a different situation than the one I am concerned about.) The vendor definitely gives a higher priority to claiming conformance and I believe they would change their implementation, but they believe they are conformant. I do feel the IETF Working Group should make this part of the spec less ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, make it clear that an implementation is not conformant to the spec if it requires optional parameters? Additionally, I will resend a use-case for the no-scope parameter because my earlier reply unintentionally went privately to Eran and not to the list: I can suggest a spec modification that says that an implementation MUST accept a request without a scope parameter, in which case one possibility for an implementing server is to return an access token or code that does not allow any operations. The purpose of this otherwise "useless" token/code is that the OAuth server confirms that the user is *some* user without any information on *which* user it is. (If the user is not authenticated by the vendor then of course no valid token/code is returned.) An example might help: Facebook, when it started, would manage social networks based on college email domain -- harvard.edu, etc. Facebook used to do it by asking for your email address and sending a confirmation mail. But what if I wanted to tell Facebook just the fact that I was at foo.edu but I did not want to share my email address with Facebook, or any other unique identifier? If the spec required implementations to work without a scope parameter, it would solve this use case perfectly. Facebook wouldn't really care about my school email address or unique id -- I could use my non-school personal email and all Facebook wanted to know was whether I should be in that school network or not simply by using the barebones no-scope OAuth request. Vendors do not lose anything if the spec requires such no-scope requests to be fulfilled. They are merely confirming that a user is *some* user with the user's consent. There are valid cases on the client side such as determining network membership without needing network identity. And it cleans out the optional semantics of scope. Users win in that they have a way to confirm network membership without having to reveal a unique identifier. Clients win in that users will be more willing to confirm network membership if they are not also required to reveal a unique identitfier. This is off-the-cuff but I will be very happy to formalize it and present it to the list. I hope the essential concept made it through my writing! A. On Mon, Jan 9, 2012 at 3:47 PM, SM wrote: > Hello, > > At 15:14 09-01-2012, agks mehx wrote: > >> Thank you for the response. If I understand correctly, the vendor is >> correctly that their implementation conforms to the specification even >> though it rejects requests that do not specify the scope parameter. That >> answers my question. >> > > The better answer is from Eran ( http://www.ietf.org/mail-** > archive/web/oauth/current/**msg08194.html<http://www.ietf.org/mail-archive/web/oauth/current/msg08194.html>). > > > Whether I was asking for (i) a clarification; or (ii) trying to resolve a >> disagreement. I think I was trying to verify whether indeed there was a >> disagreement. I. e. whether my understanding of the specification was >> correct or not. It seems I was mistaken in understanding the spec. >> > > See comment below. > > > There is no disagreement with the vendor at this point because the two >> responses from this list indicate that the vendor is right. (I still don't >> understand why scope isn't made a required parameter in the specification >> so that such confusion can be avoided, but that's a minor point.) >> > > You locked in on the term "optional" without going into the details of the > draft. I would not claim conformance with a specification if my API > specifies that the optional parts are required as someone writing an > implementation from the draft will run into the same problem as you. > Saying that the vendor is wrong will not get them to fix it. > > Regards, > -sm > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
scope parameter in the HTTP requests. Two choices stand out to me: (a) keep the scope parameter truly optional which implies requiring all implementations to implement un-scoped credentials; (b) make the scope parameter REQUIRED thus removing the confusion and letting implementations choose whether or not they want to allow an empty scope. The former, (a), imposes a little bit of extra work for implementations but benefits users, clients, and arguably implementations, by allowing the un-scoped credentials use-case. The latter, (b), merely improves the quality of the specification -- I do not see what purpose is served by calling the scope parameter OPTIONAL when vendors are free to require it as they please and still claim conformance. On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote: > There are definitely use cases for un-scoped credentials, which the > implementations I have seen implement as an empty scope. Are you worried > specifically about the scope parameter in the HTTP requests, or as > represented in the credential used to access the PR? > > ------ > *From:* agks mehx > *To:* SM ; Eran Hammer ; > oauth@ietf.org > *Sent:* Monday, January 9, 2012 4:17 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > Hi SM and Eran, > > I am confused again, after re-reading Eran's response, whether or not an > implementation that rejects *missing* (as opposed to empty) scope is > conformant or not. (Eran, your response was a bit ambiguous on whether an > implementation is free to error out on an missing scope parameter or not -- > I can clearly see it is free to error out on an empty scope parameter, but > that's a different situation than the one I am concerned about.) > > The vendor definitely gives a higher priority to claiming conformance and > I believe they would change their implementation, but they believe they are > conformant. > > I do feel the IETF Working Group should make this part of the spec less > ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, > make it clear that an implementation is not conformant to the spec if it > requires optional parameters? > > Additionally, I will resend a use-case for the no-scope parameter because > my earlier reply unintentionally went privately to Eran and not to the list: > > I can suggest a spec modification that says that an implementation MUST > accept a request without a scope parameter, in which case one possibility > for an implementing server is to return an access token or code that does > not allow any operations. The purpose of this otherwise "useless" > token/code is that the OAuth server confirms that the user is *some* user > without any information on *which* user it is. (If the user is not > authenticated by the vendor then of course no valid token/code is returned.) > > An example might help: Facebook, when it started, would manage social > networks based on college email domain -- harvard.edu, etc. Facebook > used to do it by asking for your email address and sending a confirmation > mail. But what if I wanted to tell Facebook just the fact that I was at > foo.edu but I did not want to share my email address with Facebook, or > any other unique identifier? If the spec required implementations to work > without a scope parameter, it would solve this use case perfectly. > Facebook wouldn't really care about my school email address or unique id > -- I could use my non-school personal email and all Facebook wanted to know > was whether I should be in that school network or not simply by using the > barebones no-scope OAuth request. > > Vendors do not lose anything if the spec requires such no-scope requests > to be fulfilled. They are merely confirming that a user is *some* user with > the user's consent. There are valid cases on the client side such as > determining network membership without needing network identity. And it > cleans out the optional semantics of scope. > > Users win in that they have a way to confirm network membership without > having to reveal a unique identifier. > > Clients win in that users will be more willing to confirm network > membership if they are not also required to reveal a unique identitfier. > > This is off-the-cuff but I will be very happy to formalize it and present > it to the list. I hope the essential concept made it through my writing! > > A. > > On Mon, Jan 9, 2012 at 3:47 PM, SM wrote: > > Hello, > > At 15:14 09-01-2012, agks mehx wrote: > > Thank you for the response. If I understand correctly, the vendor is > correctly that their implementation conforms to the specification even > though it rejects requests that
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
That's fine and still consistent with the essence of (a), which is to require implementations to accept requests without a scope parameter. If an implementation chooses to issue scoped credentials, that's perfectly fine. My focus is solely on whether the scope parameter should be termed as OPTIONAL or REQUIRED within the specification. Perhaps, (b) is a better choice -- to make it REQUIRED? On Mon, Jan 9, 2012 at 5:51 PM, William Mills wrote: > Re your "a" below: No, implementations may issue scoped credentials if > they have a default scope. It says elsewhere in the spec that the scope > issued by the server may not match the requested scope, which is why the > server returns a scope value. This is for informational purposes only for > the client so it can know what scopes it should already have. > > You don't have to support empty scopes, and it would be completely valid > for the auth server to reject a request for an unknown scope, which could > include the empty scope if the auth server doesn't support it. > > -bill > > -- > *From:* agks mehx > *To:* William Mills ; oauth@ietf.org > *Cc:* SM ; Eran Hammer > *Sent:* Monday, January 9, 2012 5:44 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > scope parameter in the HTTP requests. > > Two choices stand out to me: (a) keep the scope parameter truly optional > which implies requiring all implementations to implement un-scoped > credentials; (b) make the scope parameter REQUIRED thus removing the > confusion and letting implementations choose whether or not they want to > allow an empty scope. > > The former, (a), imposes a little bit of extra work for implementations > but benefits users, clients, and arguably implementations, by allowing the > un-scoped credentials use-case. > > The latter, (b), merely improves the quality of the specification -- I do > not see what purpose is served by calling the scope parameter OPTIONAL when > vendors are free to require it as they please and still claim conformance. > > On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote: > > There are definitely use cases for un-scoped credentials, which the > implementations I have seen implement as an empty scope. Are you worried > specifically about the scope parameter in the HTTP requests, or as > represented in the credential used to access the PR? > > -- > *From:* agks mehx > *To:* SM ; Eran Hammer ; > oauth@ietf.org > *Sent:* Monday, January 9, 2012 4:17 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > Hi SM and Eran, > > I am confused again, after re-reading Eran's response, whether or not an > implementation that rejects *missing* (as opposed to empty) scope is > conformant or not. (Eran, your response was a bit ambiguous on whether an > implementation is free to error out on an missing scope parameter or not -- > I can clearly see it is free to error out on an empty scope parameter, but > that's a different situation than the one I am concerned about.) > > The vendor definitely gives a higher priority to claiming conformance and > I believe they would change their implementation, but they believe they are > conformant. > > I do feel the IETF Working Group should make this part of the spec less > ambiguous -- why not just make 'scope' REQUIRED and end the misery? Or, > make it clear that an implementation is not conformant to the spec if it > requires optional parameters? > > Additionally, I will resend a use-case for the no-scope parameter because > my earlier reply unintentionally went privately to Eran and not to the list: > > I can suggest a spec modification that says that an implementation MUST > accept a request without a scope parameter, in which case one possibility > for an implementing server is to return an access token or code that does > not allow any operations. The purpose of this otherwise "useless" > token/code is that the OAuth server confirms that the user is *some* user > without any information on *which* user it is. (If the user is not > authenticated by the vendor then of course no valid token/code is returned.) > > An example might help: Facebook, when it started, would manage social > networks based on college email domain -- harvard.edu, etc. Facebook > used to do it by asking for your email address and sending a confirmation > mail. But what if I wanted to tell Facebook just the fact that I was at > foo.edu but I did not want to share my email address with Facebook, or > any other unique identifier? If the spec required implementations to work >
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Please allow me to step-back and present the issue again in a different way: I think of Section 4.1.1 as an API specification. In my entire career as a programmer I have never encountered an API specification that said that some parameters were optional yet callers were required to specify them by implementations that claimed conformance. You all are more knowledgeable and experienced with this specification than I am, and I am not sure I am presenting my case sufficiently, but my gut instinct as a programmer tells me something is wrong with either the specification, or the implementation's claim of conformance. If you think other programmers will find themselves similarly puzzled, please fix the specification (I don't know what is the fix but I am convinced a fix is needed if implementations as discussed earlier can be said to be confirming while they require optional parameters.) Thanks for listening so far. I rest my case. On Mon, Jan 9, 2012 at 6:24 PM, William Mills wrote: > I am just not yet convinced that it should be REQUIRED. I think the fact > that we have default language for servers to insert a NULL value for > omitted params is sufficient. Do we need that here too? Would that make > it clearer? > > -- > *From:* agks mehx > *To:* William Mills ; oauth@ietf.org > *Cc:* SM ; Eran Hammer > *Sent:* Monday, January 9, 2012 5:57 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > That's fine and still consistent with the essence of (a), which is to > require implementations to accept requests without a scope parameter. If > an implementation chooses to issue scoped credentials, that's perfectly > fine. > > My focus is solely on whether the scope parameter should be termed as > OPTIONAL or REQUIRED within the specification. > > Perhaps, (b) is a better choice -- to make it REQUIRED? > > On Mon, Jan 9, 2012 at 5:51 PM, William Mills wrote: > > Re your "a" below: No, implementations may issue scoped credentials if > they have a default scope. It says elsewhere in the spec that the scope > issued by the server may not match the requested scope, which is why the > server returns a scope value. This is for informational purposes only for > the client so it can know what scopes it should already have. > > You don't have to support empty scopes, and it would be completely valid > for the auth server to reject a request for an unknown scope, which could > include the empty scope if the auth server doesn't support it. > > -bill > > -- > *From:* agks mehx > *To:* William Mills ; oauth@ietf.org > *Cc:* SM ; Eran Hammer > *Sent:* Monday, January 9, 2012 5:44 PM > > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > scope parameter in the HTTP requests. > > Two choices stand out to me: (a) keep the scope parameter truly optional > which implies requiring all implementations to implement un-scoped > credentials; (b) make the scope parameter REQUIRED thus removing the > confusion and letting implementations choose whether or not they want to > allow an empty scope. > > The former, (a), imposes a little bit of extra work for implementations > but benefits users, clients, and arguably implementations, by allowing the > un-scoped credentials use-case. > > The latter, (b), merely improves the quality of the specification -- I do > not see what purpose is served by calling the scope parameter OPTIONAL when > vendors are free to require it as they please and still claim conformance. > > On Mon, Jan 9, 2012 at 4:53 PM, William Mills wrote: > > There are definitely use cases for un-scoped credentials, which the > implementations I have seen implement as an empty scope. Are you worried > specifically about the scope parameter in the HTTP requests, or as > represented in the credential used to access the PR? > > -- > *From:* agks mehx > *To:* SM ; Eran Hammer ; > oauth@ietf.org > *Sent:* Monday, January 9, 2012 4:17 PM > *Subject:* Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in > Specification > > Hi SM and Eran, > > I am confused again, after re-reading Eran's response, whether or not an > implementation that rejects *missing* (as opposed to empty) scope is > conformant or not. (Eran, your response was a bit ambiguous on whether an > implementation is free to error out on an missing scope parameter or not -- > I can clearly see it is free to error out on an empty scope parameter, but > that's a different situation than the one I am concerned about.) > > The vendor definitely gives a higher priority to
Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
Sounds very good: "... MAY include or omit the scope parameter. If omitted, the server must process the request using an empty scope as the default." On Tue, Jan 10, 2012 at 4:02 PM, William Mills wrote: > 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 > *To:* "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 instead of > changing the > > requirements. > > > > > > Regards, > > > -sm > > > ___ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > ___ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD Review of -22 (part II)
I would be unhappy if things were sugarcoated any further. This is definitely a rare specification where OPTIONAL parameters in the API can be REQUIRED by a conforming implmentation (as I discussed in my note on the scope parameter for which the proposed modification does not really change much) I appreciate that there is a cautionary statement that this specification may produce non-interoperable client / server implementations, as I discovered upon writing my first client. The cautionary statement would be invaluable to programmers in the wild who are not used to the unusual semantics of this particular specification. Hence I strongly support (if it counts) keeping the language the way Eran Hammer has suggested. On Fri, Jan 27, 2012 at 5:12 AM, Eran Hammer wrote: > The specification already has informative references to the two token > types. From purely practical standpoint, I am not adding any more > references because that creates more dependencies and longer wait time. > > There is nothing factually incorrect about the current text. It already > makes it clear that additional work is required and expected. It is also a > fact that it will produce a wide range an non-interoperable > implementations unlike, say, HTTP. We have to make this clear to the > reader upfront because every reader outside this WG has exactly the > opposite expectation, especially coming from 1.0. > > I'll make the small tweak proposed below before this goes to the RFC > editor, but am not making any other changes to the text unless you can > show it is factually incorrect or incomplete. > > EHL > > > > On 1/26/12 1:21 PM, "Justin Richer" wrote: > > >I really don't see it this way, as a failure. Instead, I think we've > >managed to successfully scope the document to address important > >practices and bits of the protocol that will work in tandem with other > >documents to solve different use cases. One of the biggest problems that > >we saw coming in from OAuth1.0 was that it tried to be all things to all > >people all at once, which also didn't help interoperability. I think > >that what we have is a more composable UNIXy approach here. Namely, > >OAuth 2 core/framework/whatever does one thing and does it well: it > >outlines a standard means and structure for getting a token. Does that > >help you use the token against a web service, do service discovery, pack > >information into the token itself? No, but it wasn't meant to. It was > >meant to leave enough space for other docs to take care of that. > > > >But I do not think that it's gone so far as to leave a morass of > >unusable components, much in the way that WS-* did, and I don't think > >the comparison is a fair one. I think the separations are clean and the > >usage profiles are clear. > > > >By pointing developers to other specifications, most of which are > >products of this very working group or members of this working group > >under other umbrellas, we *can* provide a wider view of the world. At > >the absolute least, I think it needs to point to the two token type > >docs, and I'd suggest at least keeping the two token format docs as > >well. And as was pointed out by Phil Hunt, this notion of loosely > >coupled specs and components is actually *beneficial* to today's web > >environment. This is another way that this work differs from WS-*: if > >you're doing one part of WS-*, you're not going to get away without > >doing the rest of it too if you want to have a working system. As you > >point out, and somewhat lament, this is not the case with OAuth 2. You > >can do some parts, and not others, and utalize just the bits that you > >need. The fact that I can use the same endpoints and mechanisms for > >user-delegated auth and machine-directed auth is very powerful, and the > >fact that I can use the same exact client libraries to fetch and use > >both random-hex tokens and signed JWTs is equally powerful. The fact > >that I can reuse 90% of that code and also get signed MAC tokens is > >likewise powerful. > > > >Thus, I stand by my originally-suggested text and respectfully submit it > >to the editor and working group for consideration of inclusion in this > >section. > > > > -- Justin > > > >On 01/26/2012 12:49 PM, Eran Hammer wrote: > >> > >>> -Original Message- > >>> From: Justin Richer [mailto:jric...@mitre.org] > >>> Sent: Thursday, January 26, 2012 6:07 AM > >>> To: Eran Hammer > >>> Cc: OAuth WG > >>> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) > >>> > >>> I realize that -23 is already published with the below text, but since > >>>this is a > >>> whole new section and nobody else seemed to bring it up, I wanted to > >>>make > >>> sure it wasn't missed by the WG. > >>> I think it's a good idea to call it out, and I don't want to > >>>"sugarcoat" it either, > >>> but the phrase "this specification is likely to produce a wide range > >>>of non- > >>> interoperable implementations" is a bit overdramatic in its tone. > >>>Instead, I > >>> t
