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 <[email protected]>
To: William Mills <[email protected]>; [email protected]
Cc: SM <[email protected]>; Eran Hammer <[email protected]>
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 <[email protected]> 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 <[email protected]>
>To: SM <[email protected]>; Eran Hammer <[email protected]>; [email protected]
>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 <[email protected]> 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
>[email protected]
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
