Return-Path: 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 2219111E80A1 for ; Mon, 9 Jan 2012 17:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 dXpIGaKyFhiv for ; Mon, 9 Jan 2012 17:44:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E111E809B for ; Mon, 9 Jan 2012 17:44:35 -0800 (PST) Received: by yenl8 with SMTP id l8so1514575yen.31 for ; Mon, 09 Jan 2012 17:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C9cg+spXjy+0CjafyweqLasWwCocNO3OFfSt95wBzi0=; b=CK087W1jM2xehWqy0wIZvXPpVluoGJD24EtoNDk5Sk31AbFmEEHm3BO2vZZiZIn4kC ohD8pHuS8yQx4Gaj3x0QH29Z1ruRn7RlWyVg1coaZ85xW3+y/IsrFbGNaGIr+jQIPC6p gZHgQjJpuxea0vjD2G0Efq0rJD1h6TrrxQAWw= MIME-Version: 1.0 Received: by 10.236.183.200 with SMTP id q48mr150283yhm.49.1326159875446; Mon, 09 Jan 2012 17:44:35 -0800 (PST) Received: by 10.236.67.41 with HTTP; Mon, 9 Jan 2012 17:44:35 -0800 (PST) In-Reply-To: <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> References: <6.2.5.6.2.20120109070921.0aec8d00@resistor.net> <6.2.5.6.2.20120109153323.0ab3bf80@resistor.net> <1326156786.88572.YahooMailNeo@web31812.mail.mud.yahoo.com> Date: Mon, 9 Jan 2012 17:44:35 -0800 Message-ID: From: agks mehx To: William Mills , oauth@ietf.org Content-Type: multipart/alternative; boundary=20cf305b13da4a985804b622a8ce Subject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 01:44:37 -0000 --20cf305b13da4a985804b622a8ce Content-Type: text/plain; charset=ISO-8859-1 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 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 > > > --20cf305b13da4a985804b622a8ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable scope parameter in t= he HTTP requests.

Two choices stand out to me: =A0(a) ke= ep the scope parameter truly optional which implies requiring all implement= ations to implement un-scoped credentials; =A0(b) make the scope parameter = REQUIRED thus removing the confusion and letting implementations choose whe= ther 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 n= ot 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.<= /div>

On Mon, Jan 9, 2012 at 4:53 PM, William= Mills <wmills= @yahoo-inc.com> wrote:
There are d= efinitely use cases for un-scoped credentials, which the implementations I = have seen implement as an empty scope.=A0 Are you worried specifically abou= t the scope parameter in the HTTP requests, or as represented in the creden= tial used to access the PR?

From: agks mehx <agksmehx@gmail.com>= ;
To: SM <sm@resistor.net>; Eran Ham= mer <eran@hueni= verse.com>; oaut= h@ietf.org
Sent: Monday, January 9, 2012 4:17 PM
Su= bject: Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity= in Specification

Hi SM and Eran,

I am confused again, after re-readi= ng Eran's response, whether or not an implementation that rejects *miss= ing* (as opposed to empty) scope is conformant or not. =A0(Eran, your respo= nse was a bit ambiguous on whether an implementation is free to error out o= n an missing scope parameter or not -- I can clearly see it is free to erro= r out on an empty scope parameter, but that's a different situation tha= n the one I am concerned about.)

The vendor definitely gives a higher priority to claimi= ng conformance and I believe they would change their implementation, but th= ey 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? =A0Or, make it clear= that an implementation is not conformant to the spec if it requires option= al 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 acc= ept 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 a= llow any operations. =A0The purpose of this otherwise "useless" t= oken/code is that the OAuth server confirms that the user is *some* user wi= thout any information on *which* user it is. =A0(If the user is not authent= icated by the vendor then of course no valid token/code is returned.)

An example might help: =A0Fac= ebook, when it started, would manage social networks based on college email= domain --=A0harvard.edu, etc. =A0Facebook used to= do it by asking for your email address and sending a confirmation mail. = =A0But what if I wanted to tell Facebook just the fact that I was at=A0foo.edu=A0but I did not want to share my email address wit= h Facebook, or any other unique identifier? =A0If the spec required impleme= ntations to work without a scope parameter, it would solve this use case pe= rfectly. =A0Facebook 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 merel= y confirming that a user is *some* user with the user's consent. =A0The= re are valid cases on the client side such as determining network membershi= p without needing network identity. =A0And it cleans out the optional seman= tics of scope.

Users win in that they have a= way to confirm network membership without having to reveal a unique identi= fier.

Clients win in that users wil= l be more willing to confirm network membership if they are not also requir= ed to reveal a unique identitfier.

This is off-the-cuff but I wi= ll be very happy to formalize it and present it to the list. =A0I 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. =A0If I understand correctly, the vendor is cor= rectly that their implementation conforms to the specification even though = it rejects requests that do not specify the scope parameter. =A0That answer= s my question.

The better answer is from Eran ( http://www.ietf.org/ma= il-archive/web/oauth/current/msg08194.html ).


Whether I was asking for (i) a clarification; or (ii) trying to resolve a d= isagreement. =A0I think I was trying to verify whether indeed there was a d= isagreement. I. e. whether my understanding of the specification was correc= t or not. =A0It seems I was mistaken in understanding the spec.

See comment below.


There is no disagreement with the vendor at this point because the two resp= onses from this list indicate that the vendor is right. =A0(I still don'= ;t understand why scope isn't made a required parameter in the specific= ation so that such confusion can be avoided, but that's a minor point.)=

You locked in on the term "optional" without going into the detai= ls of the draft. =A0I would not claim conformance with a specification if m= y API specifies that the optional parts are required as someone writing an = implementation from the draft will run into the same problem as you. =A0Say= ing 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/o= auth



--20cf305b13da4a985804b622a8ce--