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

[Nat Sakimura <[e-mail]>]

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 <[e-mail]>

>  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:[e-mail]]
> *Sent:* Thursday, February 28, 2013 1:36 PM
> *To:* Lewis Adam-CAL022
> *Cc:* John Bradley; [e-mail] 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 <
> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Brian Campbell
> *Sent:* Thursday, February 28, 2013 1:03 PM
> *To:* John Bradley
> *Cc:* [e-mail] 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 <[e-mail]> wrote:*
> ***
>
> Yes the title likely adds to the confusion given that the bearer tokens
> are not access tokens.****
>
>  ****
>
> Things as separate from OAuth as the Firefox browerID spec use JWS signed
> JWTs.  ****
>
>  ****
>
> The bearer token profiles for OAuth 2 are for OAuth2.****
>
>  ****
>
> The JSON Web Token (JWT)<http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06> spec
> did not start in OAuth and is not OAuth specific.****
>
>  ****
>
> A JWT is:****
>
> JSON Web Token (JWT)  A string representing a set of claims as a JSON****
>
>       object that is encoded in a JWS or JWE, enabling the claims to be****
>
>       digitally signed or MACed and/or encrypted.****
>
>   ****
>
> So OAuth or other profiles may define claims to go in a JWT, but the JWT
> needs to itself only define the claims necessary for security processing.
> ****
>
>  ****
>
> John B.****
>
> PS that was a soft ball If you hadn't responded I would have been
> disappointed.  I din't pick the title for the bearer token profiles.****
>
>  ****
>
>  ****
>
> On 2013-02-28, at 10:12 AM, Phil Hunt <[e-mail]> wrote:****
>
> ** **
>  JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0****
>
>
> Note the title says "for OAuth2"****
>
>  ****
>
> Sorry. Couldn't resist. ****
>
>  ****
>
> Phil****
>
>  ****
>
> Sent from my phone.****
>
>
> On 2013-02-28, at 9:40, John Bradley <[e-mail]> wrote:****
>
> JWT is an assertion( I am probably going to regret using that word).****
>
>  ****
>
> It is used in openID connect for id_tokens, it is used in OAuth for
> Assertion grant types and authentication of the client to the token
> endpoint.****
>
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04****
>
>  ****
>
>  ****
>
>  ****
>
> JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0****
>
>  ****
>
> Dosen't define JWT's use for access tokens for the RS.   ****
>
>  ****
>
> Bottom line JWT is for more than access tokens.****
>
>  ****
>
> John B.****
>
>  ****
>
> On 2013-02-28, at 9:28 AM, Phil Hunt <[e-mail]> wrote:****
>
> ** **
>
> Are you saying jwt is not an access token type?
>
> Phil****
>
>  ****
>
> Sent from my phone.****
>
>
> On 2013-02-28, at 8:58, John Bradley <[e-mail]> wrote:****
>
> Yes, defining scope in JWT is the wrong place.   JWT needs to stick to the
> security claims needed to process JWT.****
>
>  ****
>
> I also don't know how far you get requiring a specific authorization
> format for JWT, some AS will wan to use a opaque reference, some might want
> to use a user claim or role claim, others may use scopes,  combining scopes
> and claims is also possible.****
>
>  ****
>
> Right now it is up to a AS RS pair to agree on how to communicate
> authorization.   I don't want MAC to be more restrictive than bearer when
> it comes to authorization between AS and RS.****
>
>  ****
>
> Hannes wanted to know why JWT didn't define scope.  The simple answer is
> that it is out of scope for JWT itself.   It might be defined in a OAuth
> access token profile for JWT but it should not be specific to MAC.****
>
>  ****
>
> John B.****
>
> On 2013-02-28, at 8:44 AM, Brian Campbell <[e-mail]>
> wrote:****
>
> ** **
>
> I think John's point was more that scope is something rather specific to
> an OAuth access token and, while JWT is can be used to represent an access
> token, it's not the only application of JWT. The 'standard' claims in JWT
> are those that are believed (right or wrong) to be widely applicable across
> different applications of JWT. One could argue about it but scope is
> probably not one of those.****
>
> It would probably make sense to try and build a profile of JWT
> specifically for OAuth access tokens (though I suspect there are some
> turtles and dragons in there), which might be the appropriate place to
> define/register a scope claim.****
>
>  ****
>
> On Thu, Feb 28, 2013 at 9:24 AM, Phil Hunt <[e-mail]> wrote:**
> **
>
> Are you advocating TWO systems? That seems like a bad choice.
>
> I would rather fix scope than go to a two system approach.
>
> Phil
>
> Sent from my phone.
>
> On 2013-02-28, at 8:17, John Bradley <[e-mail]> wrote:
>
> > While scope is one method that a AS could communicate authorization to a
> RS, it is not the only or perhaps even the most likely one.
> > Using scope requires a relatively tight binding between the RS and AS,
>  UMA uses a different mechanism that describes finer grained operations.
> > The AS may include roles, user, or other more abstract claims that the
> the client may (god help them) pass on to EXCML for processing.
> >
> > While having a scopes claim is possible, like any other claim it is not
> part of the JWT core security processing claims, and needs to be defined by
> extension.
> >
> > John B.
> > On 2013-02-28, at 2:29 AM, Hannes Tschofenig <[e-mail]>
> wrote:
> >
> >> Hi Mike,
> >>
> >> when I worked on the MAC specification I noticed that the JWT does not
> have a claim for the scope. I believe that this would be needed to allow
> the resource server to verify whether the scope the authorization server
> authorized is indeed what the client is asking for.
> >>
> >> Ciao
> >> Hannes
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
>  ****
>
>   ****
>
>   ****
>
>  ****
>
> ** **
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


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