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

[prateek mishra <[e-mail]>]

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

> 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] 
> <mailto:[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]
>     <mailto:[e-mail]>]
>     *Sent:* Thursday, February 28, 2013 1:36 PM
>     *To:* Lewis Adam-CAL022
>     *Cc:* John Bradley; [e-mail] <mailto:[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]
>     <mailto:[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]>
>     [mailto:[e-mail] <mailto:[e-mail]>]
>     *On Behalf Of *Brian Campbell
>     *Sent:* Thursday, February 28, 2013 1:03 PM
>     *To:* John Bradley
>     *Cc:* [e-mail] <mailto:[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]
>     <mailto:[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]
>     <mailto:[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]
>     <mailto:[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]
>         <mailto:[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]
>         <mailto:[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]
>             <mailto:[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] <mailto:[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]
>             <mailto:[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]
>             <mailto:[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] <mailto:[e-mail]>
>             >> https://www.ietf.org/mailman/listinfo/oauth
>             >
>             > _______________________________________________
>             > OAuth mailing list
>             > [e-mail] <mailto:[e-mail]>
>             > https://www.ietf.org/mailman/listinfo/oauth
>             _______________________________________________
>             OAuth mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth