Subject: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

From: Mike Jones <[email-masked]>
Date: Tue, 4 Jul 2017 19:43:51 +0000

The JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs.  This is accomplished by including an explicit type for the JWT in the "typ" header parameter.  For instance, the Security Event Token (SET) specification<http://self-issued.info/?p=1709> now uses the "application/secevent+jwt" content type to explicitly type SETs.

The specification is available at:

  *   https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1714 and as @selfissued<https://twitter.com/selfissued>.

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 4 Jul 2017 12:58:05 -0700

+1

Thanks Mike. 

Phil

> On Jul 4, 2017, at 12:43 PM, Mike Jones <[email-masked]> wrote:
> 
> The JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs.  This is accomplished by including an explicit type for the JWT in the “typ” header parameter.  For instance, the Security Event Token (SET) specification now uses the “application/secevent+jwt” content type to explicitly type SETs.
>  
> https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01
>  
> http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html
>  
>                                                        -- Mike
>  
> P.S.  This notice was also posted at http://self-issued.info/?p=1714 and as @selfissued.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 17 Jul 2017 11:53:06 +0200

Could some more guidance be provided around how to use the explicit typing
with nested JWTs?

I'd imagine that the "typ" header should be in the header of the JWT that
is integrity protected by the issuer?

On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> The JWT BCP draft has been updated to describe the use of explicit typing
> of JWTs as one of the ways to prevent confusion among different kinds of
> JWTs.  This is accomplished by including an explicit type for the JWT in
> the “typ” header parameter.  For instance, the Security Event Token (SET)
> specification <http://self-issued.info/?p=1709> now uses the “
> application/secevent+jwt” content type to explicitly type SETs.
>
>
>
>    - https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01
>
>
>
>    - http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html
>
>
>
>                                                        -- Mike
>
>
>
> P.S.  This notice was also posted at http://self-issued.info/?p=1714 and
> as @selfissued <https://twitter.com/selfissued>.
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Mike Jones <[email-masked]>
Date: Mon, 17 Jul 2017 09:55:18 +0000

Good point.  I’d had that thought as well at one point but failed to express it in the draft.  Will do.

                                                       -- Mike

From: Brian Campbell [mailto:[email-masked]]
Sent: Monday, July 17, 2017 11:53 AM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

Could some more guidance be provided around how to use the explicit typing with nested JWTs?
I'd imagine that the "typ" header should be in the header of the JWT that is integrity protected by the issuer?

On Tue, Jul 4, 2017 at 9:58 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
+1

Thanks Mike.

Phil

On Jul 4, 2017, at 12:43 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
The JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs.  This is accomplished by including an explicit type for the JWT in the “typ” header parameter.  For instance, the Security Event Token (SET) specification<http://self-issued.info/?p=1709> now uses the “application/secevent+jwt” content type to explicitly type SETs.

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1714 and as @selfissued<https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Justin Richer <[email-masked]>
Date: Tue, 18 Jul 2017 12:33:54 -0400

Mike et al,

Overall, this document has some really great advice for people who have chosen to use JWT in various situations. It’s a needed draft and I’d like to see it go forward. I have some suggestions on how it can be improved.

In this draft, I’d like to see some more discussion about privacy and security issues around choosing JWTs to begin with. Namely, putting things like subject identifiers and scope/permission information into the JWT structure could potentially leak information about the end user to the client, if the JWT isn’t encrypted, and to multiple RS’s, if the JWT is encrypted with a shared key. It basically amounts to “anyone who can read the JWT can see what’s in it”, which on the one hand is obvious, but on the other hand it’s not always considered by implementers. Since the audience of an access token JWT is the RS and not the client, and the token is opaque to the client, it’s easy to assume that the client *won’t* read the token. However, that doesn’t mean that it *can’t* read the token. It’s a tradeoff in design space with other solutions.

I’d also like to see a discussion on expiration and revocation of self-contained JWT access tokens. Again, this is targeting the decision space of whether or not a self-contained token is an appropriate solution in the first place. If I’m issuing JWTs that are completely self-contained, I can’t revoke them once they’re on the wire. Yes, that’s an acceptable risk to many and that’s fine — but I would like this document to encourage that thought and discussion. 

Thanks,
 — Justin

> On Jul 4, 2017, at 3:43 PM, Mike Jones <[email-masked]> wrote:
> 
> The JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs.  This is accomplished by including an explicit type for the JWT in the “typ” header parameter.  For instance, the Security Event Token (SET) specification <http://self-issued.info/?p=1709> now uses the “application/secevent+jwt” content type to explicitly type SETs.
>  
> https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01 <https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01>
>  
> http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html <http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-01.html>
>  
>                                                        -- Mike
>  
> P.S.  This notice was also posted at http://self-issued.info/?p=1714 <http://self-issued.info/?p=1714> and as @selfissued <https://twitter.com/selfissued>.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Jul 2017 10:52:55 +0000

Thanks for the feedback Justin. Do you have any specific wording?

On Tue, Jul 18, 2017 at 6:34 PM Justin Richer <[email-masked]> wrote:

> Mike et al,
>
> Overall, this document has some really great advice for people who have
> chosen to use JWT in various situations. It’s a needed draft and I’d like
> to see it go forward. I have some suggestions on how it can be improved.
>
> In this draft, I’d like to see some more discussion about privacy and
> security issues around choosing JWTs to begin with. Namely, putting things
> like subject identifiers and scope/permission information into the JWT
> structure could potentially leak information about the end user to the
> client, if the JWT isn’t encrypted, and to multiple RS’s, if the JWT is
> encrypted with a shared key. It basically amounts to “anyone who can read
> the JWT can see what’s in it”, which on the one hand is obvious, but on the
> other hand it’s not always considered by implementers. Since the audience
> of an access token JWT is the RS and not the client, and the token is
> opaque to the client, it’s easy to assume that the client *won’t* read the
> token. However, that doesn’t mean that it *can’t* read the token. It’s a
> tradeoff in design space with other solutions.
>
> I’d also like to see a discussion on expiration and revocation of
> self-contained JWT access tokens. Again, this is targeting the decision
> space of whether or not a self-contained token is an appropriate solution
> in the first place. If I’m issuing JWTs that are completely self-contained,
> I can’t revoke them once they’re on the wire. Yes, that’s an acceptable
> risk to many and that’s fine — but I would like this document to encourage
> that thought and discussion.
>
> Thanks,
>  — Justin
>
-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!