Re: [OAUTH-WG] JWT - scope claim missing

[Phil Hunt <[e-mail]>]

I believe that depending on the resource server that scope is important for both the security layers and application function layers.  For example, an application may wish to use scope as a set of entitlements.  Does client have entitlement "readProfile".

It makes no sense to me to have a scope in the authorization request and then not make it available to the resource endpoint except via back channels.  If that was the case why would I use anything other than an artifact?

That said, I think scope is way underdefined. But that's another issue.

Phil

@independentid
www.independentid.com
[e-mail]





On 2013-02-28, at 9:56 AM, Hannes Tschofenig wrote:

> I guess we first have to agree whether there is a security benefit of communicating the scope from the AS to the RS (in a way that it cannot be modified by the client or any other party).
> 
> The scope indicates permissions (for example, whether the resource owner allowed read access to a certain resource or write access).
> 
> Do you agree that there is a security benefit (or to put it the other way around: do you see the security vulnerability if this information is not communicated to the RS and checked against what the resource owner accepted?
> 
> Then, a secondary question is what the right mechanism is.
> 
> Ciao
> Hannes
> 
> 
> On 02/28/2013 07:29 PM, Phil Hunt wrote:
>> What people are doing now is often issuing saml like assertions. Thats not necessarily indicating intent. It just indicates transition.
>> 
>> Phil
>> 
>> Sent from my phone.
>> 
>> On 2013-02-28, at 9:07, John Bradley <[e-mail]> wrote:
>> 
>>> I am not advocating anything, only sting what people are doing now.
>>> 
>>> How authorization is communicated between the AS and RS via a token that is opaque to the client is out of scope fro OAuth core, it might be magic pixy dust.
>>> 
>>> This has lead to a number of ways people are doing it.
>>> 
>>> JWT along with  JOSE provide a container to get some claims from the AS to the RS though the JWT is not specific to this and is used in the assertions profile and other specs for many things other than access tokens.
>>> 
>>> Yes a profile of JWT for an access token as an access token is needed, Yes further profiling is required for a JWT access token using MAC.
>>> 
>>> The format of the authorization claims is not tightly bound to MAC and might be used with other bearer JWT tokens.
>>> 
>>> I don't know that there will be only one way to communicate those claims because different sorts of implementations need different information for the RS to act on.
>>> Recommendations are fine but defining a field called scope and passing on exactly the scopes the client was granted is not going to work for everyone for lots of good reasons.
>>> 
>>> John B.
>>> On 2013-02-28, at 8:24 AM, Phil Hunt <[e-mail]> wrote:
>>> 
>>>> Are you advocating TWO systems? That seems like a bad choice.
>>>> 
>>>> I would rather fix scope than go to a two system approach.
>>>> 
>>>> Phil
>>>> 
>>>> Sent from my phone.
>>>> 
>>>> On 2013-02-28, at 8:17, John Bradley <[e-mail]> wrote:
>>>> 
>>>>> While scope is one method that a AS could communicate authorization to a RS, it is not the only or perhaps even the most likely one.
>>>>> Using scope requires a relatively tight binding between the RS and AS,  UMA uses a different mechanism that describes finer grained operations.
>>>>> The AS may include roles, user, or other more abstract claims that the the client may (god help them) pass on to EXCML for processing.
>>>>> 
>>>>> While having a scopes claim is possible, like any other claim it is not part of the JWT core security processing claims, and needs to be defined by extension.
>>>>> 
>>>>> John B.
>>>>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <[e-mail]> wrote:
>>>>> 
>>>>>> Hi Mike,
>>>>>> 
>>>>>> when I worked on the MAC specification I noticed that the JWT does not have a claim for the scope. I believe that this would be needed to allow the resource server to verify whether the scope the authorization server authorized is indeed what the client is asking for.
>>>>>> 
>>>>>> Ciao
>>>>>> Hannes
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>