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

[Justin Richer <[e-mail]>]

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 
> <[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]
> https://www.ietf.org/mailman/listinfo/oauth