Subject: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Apr 2014 12:59:28 -0600

draft-ietf-oauth-jwt-bearer is only about interactions (client
authentication and JWT as an authorization grant) with the token endpoint
and doesn't define JWT style access tokens.

On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke <[email-masked]> wrote:

> Red Hat Keycloak [1] only supports basic auth for client authentication as
> suggested in the OAuth 2 spec.  But our access tokens are JWS signed JWTs.
>
> Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth [2]?
>  Or is there another document I should be following?  I'd like to see what
> other claims are being discussed related to JWT-based access tokens and may
> have some additional access token claims we've been experimenting with
> others might be interested in.
>
> Also, I'm not sure yet if we'll implement draft-ietf-oauth-jwt-bearer to
> authenticate clients.  A lot of our initial users are more interested in
> public clients and/or the implicit flow as they are writing a lot of pure
> javascript apps served up by simple static web servers.
>
> [1] http://keycloak.org
> [2] http://tools.ietf.org/html/rfc6750
>
>

---

From: Bill Burke <[email-masked]>
Date: Fri, 25 Apr 2014 15:51:27 -0400

Thank you.  Thats what I thought.  Is it just assumed JWT would/might be 
used an access token format for Bearer token auth?  Or is there another 
draft somewhere for that?  Is anybody out there using JWS + JWT as a 
access token format?

On 4/25/2014 2:59 PM, Brian Campbell wrote:
> authentication and JWT as an authorization grant) with the token
> endpoint and doesn't define JWT style access tokens.
>
>
> On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Red Hat Keycloak [1] only supports basic auth for client
>     authentication as suggested in the OAuth 2 spec.  But our access
>     tokens are JWS signed JWTs.
>
>     Does draft-ietf-oauth-jwt-bearer relate to OAuth Bearer token auth
>     [2]?  Or is there another document I should be following?  I'd like
>     to see what other claims are being discussed related to JWT-based
>     access tokens and may have some additional access token claims we've
>     been experimenting with others might be interested in.
>
>     Also, I'm not sure yet if we'll implement
>     draft-ietf-oauth-jwt-bearer to authenticate clients.  A lot of our
>     initial users are more interested in public clients and/or the
>     implicit flow as they are writing a lot of pure javascript apps
>     served up by simple static web servers.
>
>     [1] http://keycloak.org
>     [2] http://tools.ietf.org/html/__rfc6750
>     <http://tools.ietf.org/html/rfc6750>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

---

From: John Bradley <[email-masked]>
Date: Fri, 25 Apr 2014 17:06:07 -0300

The only current draft that describes JWT as access tokens is the PoP draft: http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution

That describes JWT access tokens and how to add PoP information.   I don't think there is anything other than the JWT spec itself describing bearer JWT, though they would be like the PoP JWT without the proof key.

Ping Federate has supported generating JWS access as a option for some time.

John B.

On Apr 25, 2014, at 4:51 PM, Bill Burke <[email-masked]> wrote:

> Thank you.  Thats what I thought.  Is it just assumed JWT would/might be used an access token format for Bearer token auth?  Or is there another draft somewhere for that?  Is anybody out there using JWS + JWT as a access token format?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Apr 2014 14:12:02 -0600

I think it is kind of assumed, yeah. And JWT as it is gives you everything
you need for that as long as the AS and RS can agree on keys, JWE and/or
JWS, and how the claims will look. I suspect that's what most deployments
are doing with JWT access tokens today. We are, or offer JWS + JWT access
tokens as an option in product anyway, and I believe many others are doing
the same.

IHMO getting everyone to agree on the specific claims etc. needed for a
standardized JWT access token is a bit of a rat's nest, which is why
there's not been much progress in that area.

On Fri, Apr 25, 2014 at 1:51 PM, Bill Burke <[email-masked]> wrote:

> draft somewhere for that?  Is anybody out there using JWS + JWT as a access
> token format?
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 25 Apr 2014 20:18:22 +0000

To be clear, access tokens are opaque in OAuth and I don’t see any of us trying to change that in the general case.  Particular authorization servers may use JWTs as an access token format, but that’s their private choice.  I know of other authorization servers that have the access token value be an index into a local database table, which is just as legitimate a choice as using a structured access token.

                                                                -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, April 25, 2014 1:12 PM
To: Bill Burke
Cc: oauth
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

I think it is kind of assumed, yeah. And JWT as it is gives you everything you need for that as long as the AS and RS can agree on keys, JWE and/or JWS, and how the claims will look. I suspect that's what most deployments are doing with JWT access tokens today. We are, or offer JWS + JWT access tokens as an option in product anyway, and I believe many others are doing the same.
IHMO getting everyone to agree on the specific claims etc. needed for a standardized JWT access token is a bit of a rat's nest, which is why there's not been much progress in that area.

On Fri, Apr 25, 2014 at 1:51 PM, Bill Burke <[email-masked]<mailto:[email-masked]>> wrote:
Thank you.  Thats what I thought.  Is it just assumed JWT would/might be used an access token format for Bearer token auth?  Or is there another draft somewhere for that?  Is anybody out there using JWS + JWT as a access token format?

On Fri, Apr 25, 2014 at 12:51 PM, Bill Burke <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    [1] http://keycloak.org

---

From: Bill Burke <[email-masked]>
Date: Fri, 25 Apr 2014 17:04:43 -0400

> there's not been much progress in that area.

I guess any IANA registry submissions for new JWT claims is premature 
until an RFC is out for JWT?  Or are people writing drafts for their own 
personal claims?

Thanks.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Apr 2014 15:25:25 -0600

Well, OpenID Connect has a section register JWT claims so it can't be too
premature: http://openid.net/specs/openid-connect-core-1_0.html#IANA

However, private claims are often good enough for JWTs between a related AS
and RS:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-19#section-4.3

---

From: Mike Jones <[email-masked]>
Date: Fri, 25 Apr 2014 21:45:31 +0000

Yes, IANA can't act upon this until JWT is an RFC.  If you point us to your draft defining new claims, however, I'd be glad review your proposed claims usage, if you're interested in that.

				Best wishes,
				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Bill Burke
Sent: Friday, April 25, 2014 2:05 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] draft-ietf-oauth-jwt-bearer != access tokens (was Re: draft-ietf-oauth-jwt-bearer Shepherd Write-up)

On 4/25/2014 4:12 PM, Brian Campbell wrote:
>
> IHMO getting everyone to agree on the specific claims etc. needed for 
> a standardized JWT access token is a bit of a rat's nest, which is why 

I guess any IANA registry submissions for new JWT claims is premature until an RFC is out for JWT?  Or are people writing drafts for their own personal claims?

Thanks.

---

From: Eve Maler <[email-masked]>
Date: Wed, 30 Apr 2014 11:55:51 -0700

I agree with Mike's point about flexibility. If OpenID Connect expects JWT and specific claim semantics, that makes sense in the context of its use case, but there are lots of other choices that can be made. For example, UMA's MTI token profile* defines a mechanism for conveying JSON-formatted permissions (à la Anil Saldhana's "entitlement" model** vs. "enforcement" for cloud authorization), and other token profiles could be created to convey JWT claims, the results of policy decisions, the applicable policies themselves, etc.

	Eve
* http://tools.ietf.org/html/draft-hardjono-oauth-umacore-09#section-3.3.2
** http://anil-identity.blogspot.com/2013/05/access-control-best-practices.html

>     <http://tools.ietf.org/html/rfc6750>

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl