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

From: Nat Sakimura <[email-masked]>
Date: Mon, 11 Mar 2013 13:17:36 +0900

So, it is soooo late in the game: I have been completely underwater to even
read the OAuth mails for about a month and slowly catching up now.

Here is an I-D that I have created partly in response to the RS-AS
interaction piece that was talked about at IETF 85.
It does not have 'scope' and has 'claims' instead as it was based on OpenID
Connect, but it is easy to add, provided that the scopes are to be
understood as that of the 'aud'.

http://tools.ietf.org/id/draft-sakimura-oidc-structured-token-01.txt

Best,

Nat

2013/3/1 Lewis Adam-CAL022 <[email-masked]>

>  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****
>
>  ** **
>
> 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****
>
>  ****
>
> 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:*
> ***
>
> 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 <[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).****
>
>  ****
>
> 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 <[email-masked]> 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 <[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]>
> 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]> 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 <[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]>
> 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
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
>  ****
>
>   ****
>
>   ****
>
>  ****
>
> ** **
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Phil Hunt <[email-masked]>
Date: Mon, 11 Mar 2013 07:24:56 -0700

One thing that concerns me is that scope is very different from a claim. An claim is an assertion provided that may have some level of dispute/quality etc.

A scope defines what is request or what has been authorized.  It's an absolute thing. Therefore it is not a claim. Audience...maybe. 

This is why I think scope deserves special attention/discussion in authorization assertions and in access tokens.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-03-10, at 9:17 PM, Nat Sakimura wrote:

> So, it is soooo late in the game: I have been completely underwater to even read the OAuth mails for about a month and slowly catching up now. 
> 
> Here is an I-D that I have created partly in response to the RS-AS interaction piece that was talked about at IETF 85. 
> It does not have 'scope' and has 'claims' instead as it was based on OpenID Connect, but it is easy to add, provided that the scopes are to be understood as that of the 'aud'. 
> 
> 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
> 
>  
> 
> 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
> 
>  
> 
> 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:
> 
> 
> 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.
> 
>  
> 
> 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.
> 
>  
> 
>  
> 
> On 2013-02-28, at 10:12 AM, Phil Hunt <[email-masked]> wrote:
> 
>  
> 
> 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).
> 
>  
> 
> 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
> 
>  
> 
>  
>  
> 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:
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> 
>  
> 
> 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.
> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig <[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 authorized is indeed what the client is asking for.
> >>
> >> Ciao
> >> Hannes
> >>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 11 Mar 2013 14:36:29 +0000

I would not even want to confuse audience with scope.  Maybe in the simplest of cases, where there is a one-to-one mapping between scope and audience, but in reality the RS could expose multiple APIs at the same endpoint.  Granted the RS could extract the audience field based on a fully qualified scope, but it just seems that claims, scopes, and audiences are each unique and should be kept that way.

adam

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, March 11, 2013 9:25 AM
To: Nat Sakimura
Cc: Lewis Adam-CAL022; [email-masked] WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

Best,

Nat

2013/3/1 Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>>
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]<mailto:[email-masked]>]
Sent: Thursday, February 28, 2013 1:36 PM
To: Lewis Adam-CAL022
Cc: John Bradley; [email-masked]<mailto:[email-masked]> WG

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

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
Sent: Thursday, February 28, 2013 1:03 PM
To: John Bradley
Cc: [email-masked]<mailto:[email-masked]> WG

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:

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

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

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 11 Mar 2013 10:47:17 -0400

I agree. Many have been suggesting audience. But my gut feeling matches yours.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Mar 2013 10:08:31 -0500

Some thing that scopes are a  stupidly vague bucket of stuff inferring something about a permission for an action against a resource.

If people want to send the scopes that were sent from the the client to the authorization server to the RS that is fine.

Scopes are intended for Client to AS communication and the scopes granted are returned outside the token and a client should never be snooping into the access token.

I would object to requiring that Scopes be the only or even preferred mechanism for communicating authorization for resources to the RS.

Audience principal and other members of the JWT provide much richer opportunities to communicate permissions to the RS.

Al top level members of the JWT are called claims so if you add a scopes claim with a string containing the space separated scope strings if you like but it is a claim like the others.

JWT is extensible and you can add that,  It doesn't need to be in the core set of JWT claims.

Other than that I have no opinion:)

John B.

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 11 Mar 2013 16:10:46 +0000

"Many people don't want a separate RS to AS communication channel. So the token should give the RS everything it needs.  So if scope was intended to be defined in terms of what the RS understands, then of course, the RS needs to know what was authorized."

This is my scenario, to be exact.  Development teams have given me pretty unequivocal feedback that the token they receive, they must be able to validate and process autonomously without having to reach back to the AS.  This is why I am looking to profile (for my use cases) the AT to be a structured JWT since this meets the demands of my developers.

This was actually proving to be difficult (utilizing the standard) since JWT was initially meant to audience restrict the token to the client; but with the new changes it seems I'll be able to use the standard as-is, and include an audience=RS claim.

adam

From: Phil Hunt [mailto:[email-masked]]
Sent: Monday, March 11, 2013 10:45 AM
To: John Bradley
Cc: Lewis Adam-CAL022; "WG <[email-masked]>"@il06exr01.mot.com
Subject: Re: [OAUTH-WG] JWT - scope claim missing

I think we have a different view on what the AS and RS should be doing... see below.

Phil

@independentid

On 2013-03-11, at 11:08 AM, John Bradley wrote:

Sure. I think intent of the WG was that scopes be undefined but that that they would be highly localized to specific resource services.

I don't agree.  Scope was always intended to be a set of rights understandable to  specific narrow scope of resource/apps.  Many people don't want a separate RS to AS communication channel. So the token should give the RS everything it needs.  So if scope was intended to be defined in terms of what the RS understands, then of course, the RS needs to know what was authorized.

That still doesn't preclude an AS taking a complex bearer authorization and enabling the richness you mention.

I believe that the access token should have authorization information (including scope) and identity claims about authorizing user, client, if useful to the resource.  The most important is what the AS has authorized --- including scope.

I don't think richness is the objective. The AS has the richness, but its job is to narrow down richness (complexity) and simplify for the resource server.

John B.

On 2013-03-11, at 9:47 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

adam

From: Phil Hunt [mailto:[email-masked]<http://oracle.com/>]
Sent: Monday, March 11, 2013 9:25 AM
To: Nat Sakimura
Cc: Lewis Adam-CAL022; [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] JWT - scope claim missing

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

Best,

Nat

adam

adam

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: Nat Sakimura <[email-masked]>
Date: Mon, 11 Mar 2013 12:42:05 -0400

No. I am not confusing scope with audience.

There is no standard scope. So, the scope has to be either defined by the
resource or the authorization server.
Just stating scope is too vague that you will not able to find out whose
scope it is.

That is why I wrote that the scope has to be understood in the context of
aud.
Audience is the resource. So what I wrote amounts to be that the scope
expressed in the token is what was defined by the resource and not the
authorization server.

It could be authorization server's scope, but then there would be a
complication that the resource has to be able to resolve that to its own
scope. Expressing the scope as the audience's scope will free us from this
problem.

Nat

=nat via iPhone

Mar 11, 2013 10:38、Lewis Adam-CAL022 <[email-masked]>
のメッセージ:

  I would not even want to confuse audience with scope.  Maybe in the
simplest of cases, where there is a one-to-one mapping between scope and
audience, but in reality the RS could expose multiple APIs at the same
endpoint.  Granted the RS could extract the audience field based on a fully
qualified scope, but it just seems that claims, scopes, and audiences are
each unique and should be kept that way.

adam

*From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
*Sent:* Monday, March 11, 2013 9:25 AM
*To:* Nat Sakimura
*Cc:* Lewis Adam-CAL022; [email-masked] WG
*Subject:* Re: [OAUTH-WG] JWT - scope claim missing

One thing that concerns me is that scope is very different from a claim. An
claim is an assertion provided that may have some level of dispute/quality
etc.

A scope defines what is request or what has been authorized.  It's an
absolute thing. Therefore it is not a claim. Audience...maybe.

This is why I think scope deserves special attention/discussion in
authorization assertions and in access tokens.

Phil

@independentid

www.independentid.com

[email-masked]

 So, it is soooo late in the game: I have been completely underwater to
even read the OAuth mails for about a month and slowly catching up now.

Best,

Nat

to explore this.

adam

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

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:

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.

future will be good with this.

adam

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

could be used for that but that's not what these drafts do.

Yes the title likely adds to the confusion given that the bearer tokens are
not access tokens.

JWTs.

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.

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.

Sorry. Couldn't resist.

Phil

Sent from my phone.

endpoint.

John B.

Phil

Sent from my phone.

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.

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.

Phil

Sent from my phone.

-- 
Nat Sakimura (=nat)

---

From: Phil Hunt <[email-masked]>
Date: Mon, 11 Mar 2013 13:18:07 -0400

+1. I think that is correct characterization. 

Phil

Sent from my phone.

On 2013-03-11, at 12:42, Nat Sakimura <[email-masked]> wrote:

> There is no standard scope. So, the scope has to be either defined by the resource or the authorization server. 
> Just stating scope is too vague that you will not able to find out whose scope it is. 
> 
> That is why I wrote that the scope has to be understood in the context of aud. 
> Audience is the resource. So what I wrote amounts to be that the scope expressed in the token is what was defined by the resource and not the authorization server. 
> 
> It could be authorization server's scope, but then there would be a complication that the resource has to be able to resolve that to its own scope. Expressing the scope as the audience's scope will free us from this problem. 
> 
> Nat
> 
> =nat via iPhone
> 
> Mar 11, 2013 10:38、Lewis Adam-CAL022 <[email-masked]> のメッセージ:
>

---

From: Eve Maler <[email-masked]>
Date: Mon, 11 Mar 2013 10:22:57 -0700

Just a (perennial) reminder from me that scopes are proprietary strings in core OAuth, but the UMA folks have proposed a way to standardize them because we needed to:

http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
(pretty-printed, slightly updated version here: http://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html )

It's possible to treat the data associated with a token as orthogonal to the way it is delivered to the RS. UMA's default token profile chooses to require the RS to ask the AS at run time for that data ("artifact" pattern using Justin's introspection spec), and defines a format that is not JWT-based, but rather conveys permissions/entitlements to the RS. But all kinds of choices are possible:

- Format: JWT attribute-type claims. Conveyance: signed and locally verifiable by RS.
- Format: JWT attribute-type claims. Conveyance: artifact/introspection pattern.
- Format: XACML-type authorization decision. Conveyance: signed and locally verifiable by RS.
etc.

This separation is UMA's preference since it already has a non-JWT-style set of JSON-based authorization data, which has scopes in it but of the interoperable UMA sort, not the hot-mess OAuth sort. :-) The UMA spec even has an extensibility point for defining new token profiles in an interoperable manner.

	Eve

>> >> 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 t…

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 11 Mar 2013 18:22:41 +0000

I agree with Eve that the structure of the data surrounding a token should really be the sam between the artifact/introspection approach and the packed-in-the-token approach. This is why in the latest edition of introspection [1] starts down the road to adopting the JWT claim names where they overlap, which was suggested by Torsten and others.

There is hesitation in adding more claims to base JWT, which makes some sense. But there's also an expressed desire and need to extend the JWT claim set, such as in Nat's draft and in UMA, with useful information.

I propose that we adopt the UMA approach (and at least some of its structure) and define a "token data" kind of construct, and define multiple ways to communicate that information, either inside the token itself (using JWT/JWS/JWE) or by calling an Introspection Endpoint. The interesting thing would be that you could get the same structured information in either means. This would let you keep scopes as a bag-of-strings (which I do find to be very useful, still), but still have a means of communicating those scopes between components.

And I think that we can do this in such a way that higher-level (and arguably higher-purpose ;) ) applications like UMA can easily extend a reusable core set. They've already started to do this with the Introspection draft as it stands now (which isn't surprising, considering that I stole much of the idea from UMA to begin with).

From a practical standpoint, this would mean combining Nat's and my drafts into a single document, stealing many wonderful things from UMA along the way. We're already using token introspection in a few places, and I know there are several vendors who have shipped a version of this concept.

 -- Justin

On Mar 11, 2013, at 1:22 PM, Eve Maler <[email-masked]<mailto:[email-masked]>> wrote:

Eve

On 11 Mar 2013, at 9:42 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

Nat

=nat via iPhone

Mar 11, 2013 10:38、Lewis Adam-CAL022 <[email-masked]<mailto:[email-masked]>> のメッセージ:

adam

Phil

@independentid

Best,

Nat

adam

adam

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: prateek mishra <[email-masked]>
Date: Mon, 11 Mar 2013 16:28:13 -0400

Nat -

I think this kind of document ("JWT profile of the OAuth access token") 
would be very helpful to the community (+1 to Adam's comment).

IMO there may be value in keeping it separate from the introspection 
draft which is a kind of API for validating/querying assertion contents.

My guess is that developers/deployers will use one of these two 
approaches, not both.

- prateek

> It does not have 'scope' and has 'claims' instead as it was based on 
> OpenID Connect, but it is easy to add, provided that the scopes are to 
> be understood as that of the 'aud'.
>
> 2013/3/1 Lewis Adam-CAL022 <[email-masked] 
> <mailto:[email-masked]>>
>
>     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]
>     <mailto:[email-masked]>]
>     *Cc:* John Bradley; [email-masked] <mailto:[email-masked]> WG
>
>
>     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.
>
>     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
>
>
>     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.
>
>     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.
>
>         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.
>
>             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]>
>     [email-masked] <mailto:[email-masked]>