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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian
Campbell
Sent: Thursday, February 28, 2013 11:25 AM
To: John Bradley
Cc: oauth@ietf.org 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
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> 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.
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
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> 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
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> 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
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> 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
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> 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
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> 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
<bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> 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
<phil.h...@oracle.com<mailto:phil.h...@oracle.com>> 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
<ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>> 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
> <hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> 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
>> OAuth@ietf.org<mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
