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

[Mike Jones]

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>.

[Phil Hunt (IDM)]

+1

Thanks Mike.

Phil

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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

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?

Post by Phil Hunt (IDM)
+1
Thanks Mike.
Phil
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Mike Jones]

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:***@pingidentity.com]
Sent: Monday, July 17, 2017 11:53 AM
To: Phil Hunt (IDM) <***@oracle.com>
Cc: Mike Jones <***@microsoft.com>; ***@ietf.org
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) <***@oracle.com<mailto:***@oracle.com>> wrote:
+1

Thanks Mike.

Phil

On Jul 4, 2017, at 12:43 PM, Mike Jones <***@microsoft.com<mailto:***@microsoft.com>> 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.

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>.
_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
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.

[Justin Richer]

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

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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[Dick Hardt]

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

Post by Justin Richer
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
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
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth