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

[Brian Campbell <[e-mail]>]

Thanks Prateek. I like it and I think wordy might be the way to go here.


On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra
<[e-mail]>wrote:

>  SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
> Grants
> JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
> Assertion Framework for OAuth 2.0 <as above>
>
> a bit wordy, but does get the point across IMO
>
> - prateek
>
>  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
>>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>