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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Feb 2013 12:29:38 +0200

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

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 08:17:44 -0800

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 <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 08:24:32 -0800

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.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 08:29:34 -0800

Personally I am starting to feel strongly that access tokens should be highly contextual and therefore tightly bound to specific resources. 

It seems to me trust will get incredibly complex if we start federating access tokens. My belief is that uma needs to still chain to local authorization servers and should never expect a federated token to be accepted directly. 

I hope to blog on this in more detail. But i wanted to express concerns about trust with federated authorization vs federated authn. 

Scope is just the tip of the iceberg. 

Phil

Sent from my phone.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Feb 2013 09:44:21 -0700

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 <[email-masked]> 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.
> >> 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
> >>

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 08:58:42 -0800

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 <[email-masked]> 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.
> 
>

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 09:07:48 -0800

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.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 09:27:22 -0800

Am I missing something. JWT is firstly an oauth spec. Otherwise why isnt it in jose wg?

Phil

Sent from my phone.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 09:28:03 -0800

Are you saying jwt is not an access token type?

Phil

Sent from my phone.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 09:29:47 -0800

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.

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 09:34:27 -0800

Yes IETF WG politics:)

Should JWT and JOSE  be together ?  Through a number of twists and turns they are not, lets not go there.

But to the point a number of us have made JWT is used in OAuth for more than access tokens.  
Currently it's only use in OAuth is in the JWT assertions profile that has nothing to do with access tokens.

John B.

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 09:40:26 -0800

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Feb 2013 19:56:44 +0200

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

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 28 Feb 2013 17:57:40 +0000

Adding my 2 cents ...

I am looking to use JWT as the structure for my access tokens, and will likely profile it to look just like an id_token, plus the scope claim which triggered this thread :-)

I am also looking at JWT as a grant type.

I am also looking into federating my access tokens (one of the main reasons I am looking to use JWT as the structure for the AT).

All is subject to change, but that is where my head is today.

adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, February 28, 2013 11:34 AM
To: Phil Hunt
Cc: "WG <[email-masked]>"@il06exr02.mot.com
Subject: Re: [OAUTH-WG] JWT - scope claim missing

Yes IETF WG politics:)

John B.

On 2013-02-28, at 9:27 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Sent from my phone.

On 2013-02-28, at 8:44, Brian Campbell <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Are you advocating TWO systems? That seems like a bad choice.

Phil

Sent from my phone.

On 2013-02-28, at 8:17, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi Mike,
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 10:12:31 -0800

Note the title says "for OAuth2"

Sorry. Couldn't resist. 

Phil

Sent from my phone.

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 10:36:01 -0800

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) 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.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Feb 2013 12:03:10 -0700

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 <[email-masked]> wrote:

> 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:
>
> 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.
>
>
> 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.
> 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.
> 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
> 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.
>
>
>> > 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.

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Feb 2013 14:12:15 -0500

Brian, I think you're conflating two things (and John might be, too). On 
the one hand, we've got the JWT document, which talks about what goes 
into the token itself. This can be used as an assertion, as an access 
token, as a floor wax / dessert topping. JWT doesn't really care, and 
this is really only in the OAuth WG thanks to IETF politics. Then we 
have the assertion profiles which say how to use things like JWT to do 
specific things in OAuth, and these are what Brian's talking about below.

Ultimately, this conversation is about the former and not the latter. 
That said, since an OAuth access token is a valid (and common) use of 
JWT, I think that having a common way to put things like "scope" and 
"client_id" and other OAuthy things into a JWT makes a whole heck of a 
lot of sense. Whether or not that is inside of the base JWT draft (since 
it's supposed to be for many use cases), I don't particularly care, and 
I can see the arguments from both sides.

  -- Justin

On 02/28/2013 02:03 PM, Brian Campbell wrote:
> profiles. They just kind of evolved. And evolved in funny ways 
> especially when client authn to the AS was added.
>
> 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.
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The JSON Web Token (JWT)
>     <http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06> spec
>     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.
>     On 2013-02-28, at 10:12 AM, Phil Hunt <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>>              
>>
>>
>>     On 2013-02-28, at 9:40, John Bradley <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>>     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.
>>>     On 2013-02-28, at 9:28 AM, Phil Hunt <[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>>     On 2013-02-28, at 8:58, John Bradley <[email-masked]
>>>>     <mailto:[email-masked]>> 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
>>>>>     <[email-masked]
>>>>>     <mailto:[email-masked]>> 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
>>>>>>     <[email-masked] <mailto:[email-masked]>> 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
>>>>>>         <[email-masked]
>>>>>>         <mailto:[email-masked]>> 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
>>>>>>         >> [email-masked] <mailto:[email-masked]>
>>>>>>         > [email-masked] <mailto:[email-masked]>
>>>>>>         [email-masked] <mailto:[email-masked]>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 28 Feb 2013 19:13:20 +0000

Hi Brian, a few thoughts from somebody outside of the WG ...

As a newcomer to OAuth last year, I was initially confused by the titles.  It was confusing because we have SAML bearer *assertions* and JWT bearer *tokens* ... and as John just (begrudgingly) stated in this thread, the JWT is being used as an assertion in this profile (and in OIDC).  I think it will be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new grant type and define a new method of client authentication).  One could argue that as long as the WG is at it, then why not add a third section to the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related than the other two focuses of the doc.  Then the document could be called something simple like "profiles of JWT usage in OAuth" or something like that.

On one hand, it is probably naïve to think that an access token can be standardized in a profile given how many have already been released into the wild, but on the other hand, a WG profile of a JWT-structured access token could lend itself to interoperability, where AS implementations can advertise conformance to the profile and who knows ... maybe the RS's of the future will be good with this.

adam

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

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.

On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Yes the title likely adds to the confusion given that the bearer tokens are not access tokens.

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:

John B.

On 2013-02-28, at 10:12 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Sorry. Couldn't resist.

Phil

Sent from my phone.

On 2013-02-28, at 9:40, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
JWT is an assertion( I am probably going to regret using that word).

John B.

On 2013-02-28, at 9:28 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Sent from my phone.

On 2013-02-28, at 8:58, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the security claims needed to process JWT.

John B.
On 2013-02-28, at 8:44 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Sent from my phone.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Feb 2013 12:24:31 -0700

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 <[email-masked]
> wrote:

>> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to
>> the security claims needed to process JWT.
>>
>>> > 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.
>>> >> 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
>>> >>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Feb 2013 12:36:25 -0700

I do agree that a WG profile of a JWT-structured access token could lend
itself to interoperability and ultimately be a useful thing. But you are
right that there already are many implementations out there in the wild
(heck, I've written one myself) and that might make it difficult to
standardize on something.

Because of that, and many other reasons, I don't want to try and add that
to existing assertion drafts.

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 <
[email-masked]> wrote:

>  Hi Brian, a few thoughts from somebody outside of the WG … ****
>
> ** **
>
> As a newcomer to OAuth last year, I was initially confused by the titles.
> It was confusing because we have SAML bearer **assertions** and JWT
> bearer **tokens** … and as John just (begrudgingly) stated in this
> thread, the JWT is being used as an assertion in this profile (and in
> OIDC).  I think it will be difficult to find a good name for these profiles
> since they do two entirely different things (e.g. define a new grant type
> and define a new method of client authentication).  One could argue that as
> long as the WG is at it, then why not add a third section to the JWT
> profile, which talks about usage of JWT-structured bearer access tokens: it
> would not be any less related than the other two focuses of the doc.  Then
> the document could be called something simple like “profiles of JWT usage
> in OAuth” or something like that.  ****
>
> ** **
>
> On one hand, it is probably naïve to think that an access token can be
> standardized in a profile given how many have already been released into
> the wild, but on the other hand, a WG profile of a JWT-structured access
> token could lend itself to interoperability, where AS implementations can
> advertise conformance to the profile and who knows … maybe the RS’s of the
> future will be good with this.  ****
>
> ** **
>
> adam****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Brian Campbell
> *Sent:* Thursday, February 28, 2013 1:03 PM
> *To:* John Bradley
> *Cc:* [email-masked] WG
>
> *Subject:* Re: [OAUTH-WG] JWT - scope claim missing****
>
>  ** **
>
> when client authn to the AS was added. ****
>
> 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:****
>
>
> draft-ietf-oauth-assertions****
>
> ** **
>
> On Thu, Feb 28, 2013 at 11:36 AM, John Bradley <[email-masked]> 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.****
>
> ** **
>
> 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.****
>
>  ** **
>
> ****
> ** **
> John B.****
> disappointed.  I din't pick the title for the bearer token profiles.****
>
> ** **
>
> ** **
>
> On 2013-02-28, at 10:12 AM, Phil Hunt <[email-masked]> 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 <[email-masked]> wrote:****
>
> JWT is an assertion( I am probably going to regret using that word).****
>
> ** **
>
> 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 <[email-masked]> wrote:****
>
>
>
> ****
>
> Phil****
> ** **
> Sent from my phone.****
> On 2013-02-28, at 8:58, John Bradley <[email-masked]> wrote:****
>
> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the
> security claims needed to process JWT.****
>
> ** **
>
> and claims is also possible.****
>
> ** **
>
> it comes to authorization between AS and RS.****
>
> ** **
>
> 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 <[email-masked]>
> wrote:****
>
>
>
> ****
>
> probably not one of those.****
>
> define/register a scope claim.****
>
> ** **
>
> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <[email-masked]> wrote:**
> **
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> ** **
>
>  ** **
>
>  ** **
>
> ** **
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 28 Feb 2013 14:39:25 -0500

It doesn't belong in the assertion drafts, but maybe it can be combined 
with the token introspection piece I've started (but isn't an item yet)? 
I think that would address the other thread that Hannes was talking 
about as well. We'd essentially be defining one set of token metadata 
(including scopes, client_id, subject, audience, expiration and a few 
others) and two methods to get at it: either by making an introspection 
call, or by packing it into the token directly. And the two could even 
work together if you wanted to.

  -- Justin

On 02/28/2013 02:36 PM, Brian Campbell wrote:
> I do agree that a WG profile of a JWT-structured access token could 
> lend itself to interoperability and ultimately be a useful thing. But 
> you are right that there already are many implementations out there in 
> the wild (heck, I've written one myself) and that might make it 
> difficult to standardize on something.
>
> Because of that, and many other reasons, I don't want to try and add 
> that to existing assertion drafts.
>
>
> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     As a newcomer to OAuth last year, I was initially confused by the
>     titles.  It was confusing because we have SAML bearer
>     **assertions** and JWT bearer **tokens** ... and as John just
>     (begrudgingly) stated in this thread, the JWT is being used as an
>     assertion in this profile (and in OIDC).  I think it will be
>     difficult to find a good name for these profiles since they do two
>     entirely different things (e.g. define a new grant type and define
>     a new method of client authentication).  One could argue that as
>     long as the WG is at it, then why not add a third section to the
>     JWT profile, which talks about usage of JWT-structured bearer
>     access tokens: it would not be any less related than the other two
>     focuses of the doc.  Then the document could be called something
>     simple like "profiles of JWT usage in OAuth" or something like that.
>
>     On one hand, it is probably naïve to think that an access token
>     can be standardized in a profile given how many have already been
>     released into the wild, but on the other hand, a WG profile of a
>     JWT-structured access token could lend itself to interoperability,
>     where AS implementations can advertise conformance to the profile
>     and who knows ... maybe the RS's of the future will be good with
>     this.
>
>     adam
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *Brian Campbell
>     *Cc:* [email-masked] <mailto:[email-masked]> WG
>
>
>     *Subject:* Re: [OAUTH-WG] JWT - scope claim missing
>
>     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.
>
>         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.
>
>             Yes, defining scope in JWT is the wrong place. JWT needs
>             to stick to the security claims needed to process JWT.
>
>             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.
>
>             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.
>
>             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.
>
>             there are some turtles and dragons in there), which might
>             be the appropriate place to define/register a scope claim.
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 28 Feb 2013 19:45:37 +0000

I believe that a "scope" claim should be defined by a particular profile or profiles that use JWT in a way that needs it, since it's not of general applicability.  The JSON Web Token Claims Registry (http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-9.1) is defined exactly for the purpose of registering claims that aren't in the base JWT spec.  Let's use that, once there's a profile written that needs a "scope" claim.

                                                            Cheers,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 11:25 AM
To: John Bradley
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

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 <[email-masked]<mailto:[email-masked]>> 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.

A JWT is:

John B.

Sorry. Couldn't resist.

Phil

Sent from my phone.

John B.

Phil

Sent from my phone.

John B.

Phil

Sent from my phone.

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 11:57:08 -0800

Agreed profiling needs to happen for access tokens someplace.   In the MAC spec is probably not the best place if the claims are used outside of MAC as well.

There is a separate issue once we get to that profile about scope.   I don't know many RS that do a 1 to 1 mapping of scope at the AS.  Not that they couldn't.
I just don't want to start the access token profiling assuming a one to one mapping of scopes is the only way to do it.

John B.
On 2013-02-28, at 11:12 AM, Justin Richer <[email-masked]> wrote:

> Brian, I think you're conflating two things (and John might be, too). On the one hand, we've got the JWT document, which talks about what goes into the token itself. This can be used as an assertion, as an access token, as a floor wax / dessert topping. JWT doesn't really care, and this is really only in the OAuth WG thanks to IETF politics. Then we have the assertion profiles which say how to use things like JWT to do specific things in OAuth, and these are what Brian's talking about below.
> 
> Ultimately, this conversation is about the former and not the latter. That said, since an OAuth access token is a valid (and common) use of JWT, I think that having a common way to put things like "scope" and "client_id" and other OAuthy things into a JWT makes a whole heck of a lot of sense. Whether or not that is inside of the base JWT draft (since it's supposed to be for many use cases), I don't particularly care, and I can see the arguments from both sides.
> 
>  -- Justin
>

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Feb 2013 11:59:08 -0800

Yes that may be the best place for it.

John B.
On 2013-02-28, at 11:39 AM, Justin Richer <[email-masked]> wrote:

> It doesn't belong in the assertion drafts, but maybe it can be combined with the token introspection piece I've started (but isn't an item yet)? I think that would address the other thread that Hannes was talking about as well. We'd essentially be defining one set of token metadata (including scopes, client_id, subject, audience, expiration and a few others) and two methods to get at it: either by making an introspection call, or by packing it into the token directly. And the two could even work together if you wanted to.
> 
>  -- Justin
> 
>> I do agree that a WG profile of a JWT-structured access token could lend itself to interoperability and ultimately be a useful thing. But you are right that there already are many implementations out there in the wild (heck, I've written one myself) and that might make it difficult to standardize on something.
>> 
>> Because of that, and many other reasons, I don't want to try and add that to existing assertion drafts.
>> 
>> 
>> On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 <[email-masked]> wrote:
>> Hi Brian, a few thoughts from somebody outside of the WG …
>> 
>>  
>> As a newcomer to OAuth last year, I was initially confused by the titles.  It was confusing because we have SAML bearer *assertions* and JWT bearer *tokens* … and as John just (begrudgingly) stated in this thread, the JWT is being used as an assertion in this profile (and in OIDC).  I think it will be difficult to find a good name for these profiles since they do two entirely different things (e.g. define a new grant type and define a new method of client authentication).  One could argue that as long as                       the WG is at it, then why not add a third section to the JWT profile, which talks about usage of JWT-structured bearer access tokens: it would not be any less related than the other two focuses of the doc.  Then the document could be called something simple like “profiles of JWT usage in OAuth” or something like that. 
>> 
>>  
>> On one hand, it is probably naïve to think that an access token can be standardized in a profile given how many have already been released into the wild, but on the other hand, a WG profile of a JWT-structured access token could lend itself to interoperability, where AS implementations can advertise conformance to the profile and who knows … maybe the RS’s of the future will be good with this. 
>> 
>>  
>> adam
>> 
>>

---

From: prateek mishra <[email-masked]>
Date: Thu, 28 Feb 2013 15:43:57 -0500

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 28 Feb 2013 12:51:42 -0800

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
[email-masked]

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?
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Feb 2013 13:59:48 -0700

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
<[email-masked]>wrote:

>> are not access tokens.
>>  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.
>>  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
>>  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
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 28 Feb 2013 22:13:31 +0000

Hmmm, I'm not so sure.  It depends where we all think OAuth is on its trajectory.  On one hand, OAuth has already seen an insanely massive amount of deployment.  On the other hand, RESTful APIs see no sign of slowing down.   Now I'm not going to go so far as Craig B. and say that everything and everyone will be API enabled in the future, but it sure is going to be a lot.  That being said, one could argue that even with all the OAuth implementation we've seen, that this is just the infancy of it.  Obviously a WG profile of a JWT-structured AT could not deprecate other forms (unstructured, SAML, etc.) but going forward new developers may choose to embrace this, and in fact this could even be the guidance.   I agree with previous comments that Justin's introspection draft might be a good place to explore this.

adam

From: Brian Campbell [mailto:[email-masked]]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; [email-masked] WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

On Thu, Feb 28, 2013 at 12:13 PM, Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian, a few thoughts from somebody outside of the WG ...

adam

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: [email-masked]<mailto:[email-masked]> WG

A JWT is:

John B.

Sorry. Couldn't resist.

Phil

Sent from my phone.

John B.

Phil

Sent from my phone.

John B.

Phil

Sent from my phone.

---

From: Mike Jones <[email-masked]>
Date: Thu, 28 Feb 2013 22:53:53 +0000

+1

________________________________
From: Brian Campbell
Sent: 2/28/2013 1:00 PM
To: prateek mishra
Cc: oauth
Subject: Re: [OAUTH-WG] JWT - scope claim missing

On Thu, Feb 28, 2013 at 1:43 PM, prateek mishra <[email-masked]<mailto:[email-masked]>> 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>

- prateek

A JWT is:

John B.

Sorry. Couldn't resist.

Phil

Sent from my phone.

John B.

Phil

Sent from my phone.

John B.

Phil

Sent from my phone.