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

[Brian Campbell <[e-mail]>]

To be fair, I think it was Phil who first conflated the things :) I just
picked up the ball and ran with it. But you are right, I did kind of hijack
the thread which was originally about if a scope claim should be defined in
draft-ietf-oauth-json-web-token. I'd say no but I can see how an argument
could be made the other way.


On Thu, Feb 28, 2013 at 12:03 PM, Brian Campbell <[e-mail]
> wrote:

> I'm not sure anyone really "picked" the titles for the bearer token
> profiles. They just kind of evolved. And evolved in funny ways especially
> when client authn to the AS was added.
>
> You won't hear me argue that the titles are "good" and this is not the
> first time there's been confusion about what they actually do. They define
> new grant types and new client authentication methods. They *do not* define
> an access token format or anything else about access tokens. JWT and SAML
> could be used for that but that's not what these drafts do.
>
> Suggestions for better title(s) would be more than welcome.
>
> Here's what they are now:
>
> SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> draft-ietf-oauth-saml2-bearer
>
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>  draft-ietf-oauth-jwt-bearer
>
> Assertion Framework for OAuth 2.0
> draft-ietf-oauth-assertions
>
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <[e-mail]> wrote:
>
>> Yes the title likely adds to the confusion given that the bearer tokens
>> are not access tokens.
>>
>> Things as separate from OAuth as the Firefox browerID spec use JWS signed
>> JWTs.
>>
>> The bearer token profiles for OAuth 2 are for OAuth2.
>>
>> The JSON Web Token (JWT)<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06> spec
>> did not start in OAuth and is not OAuth specific.
>>
>> A JWT is:
>>
>> JSON Web Token (JWT)  A string representing a set of claims as a JSON
>>       object that is encoded in a JWS or JWE, enabling the claims to be
>>       digitally signed or MACed and/or encrypted.
>>
>>
>> So OAuth or other profiles may define claims to go in a JWT, but the JWT
>> needs to itself only define the claims necessary for security processing.
>>
>> John B.
>> PS that was a soft ball If you hadn't responded I would have been
>> disappointed.  I din't pick the title for the bearer token profiles.
>>
>>
>> On 2013-02-28, at 10:12 AM, Phil Hunt <[e-mail]> wrote:
>>
>>
>>
>>
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>> Note the title says "for OAuth2"
>>
>> Sorry. Couldn't resist.
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-28, at 9:40, John Bradley <[e-mail]> wrote:
>>
>> JWT is an assertion( I am probably going to regret using that word).
>>
>> It is used in openID connect for id_tokens, it is used in OAuth for
>> Assertion grant types and authentication of the client to the token
>> endpoint.
>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
>>
>> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
>>
>>
>> Dosen't define JWT's use for access tokens for the RS.
>>
>> Bottom line JWT is for more than access tokens.
>>
>> John B.
>>
>> On 2013-02-28, at 9:28 AM, Phil Hunt <[e-mail]> wrote:
>>
>> Are you saying jwt is not an access token type?
>>
>> Phil
>>
>> Sent from my phone.
>>
>> On 2013-02-28, at 8:58, John Bradley <[e-mail]> wrote:
>>
>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to
>> the security claims needed to process JWT.
>>
>> I also don't know how far you get requiring a specific authorization
>> format for JWT, some AS will wan to use a opaque reference, some might want
>> to use a user claim or role claim, others may use scopes,  combining scopes
>> and claims is also possible.
>>
>> Right now it is up to a AS RS pair to agree on how to communicate
>> authorization.   I don't want MAC to be more restrictive than bearer when
>> it comes to authorization between AS and RS.
>>
>> Hannes wanted to know why JWT didn't define scope.  The simple answer is
>> that it is out of scope for JWT itself.   It might be defined in a OAuth
>> access token profile for JWT but it should not be specific to MAC.
>>
>> John B.
>> On 2013-02-28, at 8:44 AM, Brian Campbell <[e-mail]>
>> wrote:
>>
>> I think John's point was more that scope is something rather specific to
>> an OAuth access token and, while JWT is can be used to represent an access
>> token, it's not the only application of JWT. The 'standard' claims in JWT
>> are those that are believed (right or wrong) to be widely applicable across
>> different applications of JWT. One could argue about it but scope is
>> probably not one of those.
>>
>> It would probably make sense to try and build a profile of JWT
>> specifically for OAuth access tokens (though I suspect there are some
>> turtles and dragons in there), which might be the appropriate place to
>> define/register a scope claim.
>>
>>
>> On Thu, Feb 28, 2013 at 9: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
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>>
>>
>>
>