Brian, I think you're conflating two things (and John might be, too). On
the one hand, we've got the JWT document, which talks about what goes
into the token itself. This can be used as an assertion, as an access
token, as a floor wax / dessert topping. JWT doesn't really care, and
this is really only in the OAuth WG thanks to IETF politics. Then we
have the assertion profiles which say how to use things like JWT to do
specific things in OAuth, and these are what Brian's talking about below.
Ultimately, this conversation is about the former and not the latter.
That said, since an OAuth access token is a valid (and common) use of
JWT, I think that having a common way to put things like "scope" and
"client_id" and other OAuthy things into a JWT makes a whole heck of a
lot of sense. Whether or not that is inside of the base JWT draft (since
it's supposed to be for many use cases), I don't particularly care, and
I can see the arguments from both sides.
-- Justin
On 02/28/2013 02:03 PM, Brian Campbell 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 <[email protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected] <mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> 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 protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
