Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
William Mills <wmills@yahoo-inc.com> Tue, 10 January 2012 17:21 UTC
Return-Path: <wmills@yahoo-inc.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690BA21F878A for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 09:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.849
X-Spam-Level:
X-Spam-Status: No, score=-16.849 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgZs-1+vFRCQ for <oauth@ietfa.amsl.com>; Tue, 10 Jan 2012 09:21:01 -0800 (PST)
Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id C809021F8772 for <oauth@ietf.org>; Tue, 10 Jan 2012 09:21:01 -0800 (PST)
Received: from [98.139.91.68] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2012 17:20:59 -0000
Received: from [98.139.91.8] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jan 2012 17:19:59 -0000
Received: from [127.0.0.1] by omp1008.mail.sp2.yahoo.com with NNFMP; 10 Jan 2012 17:19:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 103268.86968.bm@omp1008.mail.sp2.yahoo.com
Received: (qmail 49706 invoked by uid 60001); 10 Jan 2012 17:19:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1326215998; bh=a3kyhsfU1TmTB7VtMN6ekKq6ukP3+m3mmW6nsfdkwGQ=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZFtmhwxpNdLy7VOPzBkleWhfWTmhgN1oWUOPSs+DPbXuAQzgglPgBpSU5Oo5EeZizE8Lu+viKeb89C67I1esW2ncKNup/sSU2Dpg7Zfm9RnDY54ZKqqYqLWv/ii7BwnQr9czY21G0IlPq6AMo5kYdkwQ7hV/ONxKPfvpUynewNA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nVhjkeGzwnt+byXhUu+k0cb8xD3DcBL6kJorebomVEV30x0vLCySndcgEMymLOU0wOmz35q13LPuwu2yAu2n/X1B+oB17qF5dd8ZFWEem6pPKUQ7UY6CQBC9At5b1jDShvRl2O6lJCTikfbC37/rGF0S9hoyucIn23qd4Hi+j4s=;
X-YMail-OSG: 8mi6Co4VM1kEzeMqDyfXux6mqeXlJFZYiofeIqZ6pB5Xlo2 yBOwz97w2AkBaTbECqbtmOZFAkcG645VM19sgpFqJv3m5qaV7ZsOJvsLVcWh rpQQnuZmhjahb4E0ucSk0YsfGXuUFpSH0410NjrJ7d2uQYSm8FpASH.5yBNG LqRMaISae.H_LAOgtTSLUrdMK9qjxoSrnRfMyO43ngDn1iWDhZJA4Ey2LMlF VNUmslk2FAbKK63iD6QGQItpW2Z0WKBc6bfpj8ABFQnO2BCQ504K6ApgpTPK vptf2lRXml18FDJ7SnmjxLp.zgRPPQvStm4fEoizvfUiSTkrEticBwX3uQ2l SEEcKrl89hfLdw62DIBkIIfq1bKj8tePVIUoW_CSMozyRWEgE3cxYREuydIc VQ.e5zgIVZOHpMqwcokef_PN7sEfBBpXq_Mgjf1V8VnRvNaiFe2X39MIHVGR wmYBtNkdXMWUJGvjAMNmvBqAQ.oFLbvbIBSubWtMePHt7KlQTsCDw4I1t75s LD.kVtGbO_oZ8_l8yBeJbxUE9Gw--
Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 10 Jan 2012 09:19:57 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/0.8.116.331537
References: <CAG+j4TrQGwiDj01huDgfEy+02b4=tTDYifiXcvhDHrw3i32-6Q@mail.gmail.com> <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <CAG+j4TrFoxvMMK_Bx=0e1qFLjUmKKaEmJD6hBnR06H6Fm75xfw@mail.gmail.com> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <CAG+j4TpuO0N7n9xxB=3mh7EZhsjXDtB2DPa0S8BBJmhV_mv4Xw@mail.gmail.com> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> <CAG+j4TrUGtua8umh+GqJM_i6OeZrwHy7NwoGK1dTYGpHBuuV2Q@mail.gmail.com> <1326160314.71861.YahooMailNeo@web31806.mail.mud.yahoo.com> <CAG+j4TrkXE_N6T35LaApswKJMRzNmBYbB_CnqUi37s6sK5nQAw@mail.gmail.com> <1326162276.40306.YahooMailNeo@web31811.mail.mud.yahoo.com> <CAG+j4TqhGi_0Z=C7gPbxAx6L7DV-NeLCewYyc4T-SbfdfWR=GA@mail.gmail.com>
Message-ID: <1326215997.44445.YahooMailNeo@web31816.mail.mud.yahoo.com>
Date: Tue, 10 Jan 2012 09:19:57 -0800
From: William Mills <wmills@yahoo-inc.com>
To: agks mehx <agksmehx@gmail.com>, Eran Hammer <eran@hueniverse.com>, "oauth@ietf.org" <oauth@ietf.org>
In-Reply-To: <CAG+j4TqhGi_0Z=C7gPbxAx6L7DV-NeLCewYyc4T-SbfdfWR=GA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1238014912-2107763349-1326215997=:44445"
Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <wmills@yahoo-inc.com>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2012 17:21:03 -0000
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. ________________________________ From: agks mehx <agksmehx@gmail.com> To: William Mills <wmills@yahoo-inc.com>; Eran Hammer <eran@hueniverse.com>; oauth@ietf.org Cc: SM <sm@resistor.net> Sent: Monday, January 9, 2012 10:45 PM Subject: 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 <wmills@yahoo-inc.com> 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 <agksmehx@gmail.com> >To: William Mills <wmills@yahoo-inc.com>; oauth@ietf.org >Cc: SM <sm@resistor.net>; Eran Hammer <eran@hueniverse.com> >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 <wmills@yahoo-inc.com> 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 <agksmehx@gmail.com> >>To: William Mills <wmills@yahoo-inc.com>; oauth@ietf.org >>Cc: SM <sm@resistor.net>; Eran Hammer <eran@hueniverse.com> >>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 <wmills@yahoo-inc.com> 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 <agksmehx@gmail.com> >>>To: SM <sm@resistor.net>; Eran Hammer <eran@hueniverse.com>; 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 <sm@resistor.net> 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 ). >>>> >>>> >>>> >>>>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 >>> >>> >>> >> >> >> > > >
- [OAUTH-WG] Seeking Clarification: Potential Ambig… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… SM
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… SM
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Phil Hunt
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… agks mehx
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Igor Faynberg
- Re: [OAUTH-WG] Seeking Clarification: Potential A… William Mills
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Andreas Åkre Solberg
- Re: [OAUTH-WG] Seeking Clarification: Potential A… Eran Hammer