Re: [OAUTH-WG] Requesting mutliple scope, but user authorizes not all

[Igor Faynberg <[e-mail]>]

Nat Sakimura wrote:
> I think such things are better dealt with extensions.
>   
Sure. But first we need to define that which we will later extend.
> I do not like to overload "scope".
>   

Neither do I, as long as "overloading"  means varying the original 
semantics. But, again, at the moment we have no definition of "scope."
> =nat
>
> On Sat, Nov 27, 2010 at 5:26 AM, Igor Faynberg
> <[e-mail]> wrote:
>   
>> In the context of Martin's question (which concerns end-users understanding
>> and resulting actions), I interpret the citation as follows: The end-user
>> has no control over the value of the "scope" parameter, and, given that "it
>> is defined by the authorization server," the end-user is not expected  even
>> to understand this value. Granted, an implementation can of course fix this
>> specific issue, but the standard does not address it.
>>
>> Overall, I do tsee this is a drawback of 2.0, which needs to be fixed by
>> careful specification of the "scope" values in the future, but I know that
>> 2.0 needs to be out and that it has high-priority items (such as security)
>> to be dealt with right now. I don't want to delay 2.0 by suggesting drastic
>> changes in the design decisions, so I am not harping on the seeming
>> irrelevance of the end-user.
>>
>> With the view of OAuth evolution though, I would like to see the whole token
>> standardized, with the end-user having the overall control of the
>> token--even if in the default situation it is still prepared by the
>> authorization server-- with the ability to assign or change (or both) any
>> value contained in it.
>>
>> Igor
>>
>>
>> Eran Hammer-Lahav wrote:
>>     
>>> -10 4.2:
>>>
>>>   scope
>>>         OPTIONAL.  The scope of the access token as a list of space-
>>>         delimited strings.  The value of the "scope" parameter is
>>>         defined by the authorization server.  If the value contains
>>>         multiple space-delimited strings, their order does not matter,
>>>         and each string adds an additional access range to the
>>>         requested scope.  The authorization server SHOULD include the
>>>         parameter if the requested scope is different from the one
>>>         requested by the client.
>>>
>>> EHL
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>>> Of Martin Ley
>>>> Sent: Friday, November 26, 2010 12:41 AM
>>>> To: [e-mail]
>>>> Subject: [OAUTH-WG] Requesting mutliple scope, but user authorizes not
>>>> all
>>>>
>>>> Dear list,
>>>>
>>>> perhaps I've overread it in the specification or it was not explicit
>>>> about my
>>>> required scenario:
>>>>
>>>>
>>>> The Web-Server-Flow is used. An application requests data about the user.
>>>> The scopes are dateofbirth,isover18,address. Now the user is forwarded to
>>>> the authorization server to identify and authenticate and give
>>>> permissions to
>>>> the applications. The user decides to give only permission for the
>>>> isover18
>>>> scope but not dateofbirth and address.
>>>>
>>>> How would the application be notified about the granted scopes and the
>>>> not
>>>> granted scopes?
>>>>
>>>> Best regards
>>>>
>>>> Martin
>>>>
>>>>
>>>> --
>>>> tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
>>>> Geschäftsführer: Boris Esser, Elmar Geese HRB AG Bonn 5168 - USt-ID
>>>> (VAT):
>>>> DE122264941
>>>>
>>>> Heilsbachstraße 24, 53123 Bonn,   Telefon: [phone]
>>>> Thiemannstraße 36a, 12059 Berlin, Telefon: [phone]
>>>> Internet: http://www.tarent.de/   Telefax: [phone]
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>         
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>       
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>     
>
>
>
>