Re: [OAUTH-WG] Seeking Clarification: Potential Ambiguity in Specification

[agks mehx <[e-mail]>]

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 <[e-mail]> 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
>