Subject: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

From: Mike Jones <[email-masked]>
Date: Wed, 19 Feb 2020 23:07:15 +0000

The OAuth 2.0 Token Exchange specification  is now RFC 8725<https://www.rfc-editor.org/rfc/rfc8725.html> and BCP 225<https://www.rfc-editor.org/info/bcp225>.  The abstract of the specification is:

JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.

The JSON Web Token (JWT) specification [RFC 7519<https://tools.ietf.org/html/rfc7519>] was approved in May 2015<https://self-issued.info/?p=1387>, almost five years ago, and has been in production use since at least 2013.  This Best Current Practices<https://tools.ietf.org/html/rfc1818> specification contains a compendium of lessons learned from real JWT deployments and implementations over that period.  It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise.  Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others.  For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party's authorization to use a particular telephone number for an incoming call, providing verified Caller ID<https://self-issued.info/?p=2045> to help combat fraudulent and unwanted telephone calls.  The advice in the BCP can be used by new JWT profiles and applications to take advantage of what's been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

                                                       -- Mike

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

---

From: Dick Hardt <[email-masked]>
Date: Wed, 19 Feb 2020 16:43:26 -0800

I think Mike meant to write "JSON Web Token Best Current Practices" rather
than "The OAuth 2.0 Token Exchange specification"

On Wed, Feb 19, 2020 at 3:07 PM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> The OAuth 2.0 Token Exchange specification  is now RFC 8725
> <https://www.rfc-editor.org/rfc/rfc8725.html> and BCP 225
> <https://www.rfc-editor.org/info/bcp225>.  The abstract of the
> specification is:
>
>
>
> JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security
> tokens that contain a set of claims that can be signed and/or encrypted.
> JWTs are being widely used and deployed as a simple security token format
> in numerous protocols and applications, both in the area of digital
> identity and in other application areas. This Best Current Practices
> document updates RFC 7519 to provide actionable guidance leading to secure
> implementation and deployment of JWTs.
>
>
>
> The JSON Web Token (JWT) specification [RFC 7519
> <https://tools.ietf.org/html/rfc7519>] was approved in May 2015
> <https://self-issued.info/?p=1387>, almost five years ago, and has been
> in production use since at least 2013.  This Best Current Practices
> <https://tools.ietf.org/html/rfc1818> specification contains a compendium
> of lessons learned from real JWT deployments and implementations over that
> period.  It describes pitfalls and how to avoid them as well as new
> recommended practices that enable proactively avoiding problems that could
> otherwise arise.  Importantly, the BCP introduces no breaking changes to
> the JWT specification and does not require changes to existing deployments.
>
>
>
> The BCP came about as JWTs were starting to be used in new families of
> protocols and applications, both in the IETF and by others.  For instance,
> JWTs are being used by the IETF STIR working group to enable verification
> of the calling party's authorization to use a particular telephone number
> for an incoming call, providing verified Caller ID
> <https://self-issued.info/?p=2045> to help combat fraudulent and unwanted
> telephone calls.  The advice in the BCP can be used by new JWT profiles and
> applications to take advantage of what’s been learned since we created the
> JSON Web Token (JWT) specification over a half decade ago.
>
>
>
>                                                        -- Mike
>
>
>
> P.S.  This notice was also posted at https://self-issued.info/?p=2052 and
> as @selfissued <https://twitter.com/selfissued>.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 20 Feb 2020 00:49:22 +0000

Oops – cut and paste error!  I’ve fixed this in the blog post at https://self-issued.info/?p=2052.

From: Dick Hardt <[email-masked]>
Sent: Wednesday, February 19, 2020 4:43 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] JSON Web Token Best Current Practices is now RFC 8725 and BCP 225

I think Mike meant to write "JSON Web Token Best Current Practices" rather than "The OAuth 2.0 Token Exchange specification"

On Wed, Feb 19, 2020 at 3:07 PM Mike Jones <Michael.Jones=40microsoft.com@dmarc..ietf.org<mailto:[email-masked]>> wrote:
The OAuth 2.0 Token Exchange specification  is now RFC 8725<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8725.html&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427068187&sdata=SDXzEELzAAyT8LjYMHMz%2BSxBjq2g3dQNzvfEYUpiajQ%3D&reserved=0> and BCP 225<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Fbcp225&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427068187&sdata=Qo6r%2B0qvKQZ%2BhsR8osFvfwliHMxp2ZPMLTFGBVe2xWU%3D&reserved=0>.  The abstract of the specification is:

The JSON Web Token (JWT) specification [RFC 7519<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7519&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427078185&sdata=hjXIAe55kT6R6WzZcAv7dSQGe6Ncw7XlYFf6xhx%2BqmU%3D&reserved=0>] was approved in May 2015<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fself-issued.info%2F%3Fp%3D1387&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427078185&sdata=KXqM0JQplPzJ6FKwMz29N3V0PAzj8WmiL1ea1mDTDN4%3D&reserved=0>, almost five years ago, and has been in production use since at least 2013.  This Best Current Practices<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc1818&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427088179&sdata=qz4XoYOO8Y7gT07%2FQzru%2BLpWoO4XJ6ryKssFP3O284k%3D&reserved=0> specification contains a compendium of lessons learned from real JWT deployments and implementations over that period.  It describes pitfalls and how to avoid them as well as new recommended practices that enable proactively avoiding problems that could otherwise arise.  Importantly, the BCP introduces no breaking changes to the JWT specification and does not require changes to existing deployments.

The BCP came about as JWTs were starting to be used in new families of protocols and applications, both in the IETF and by others.  For instance, JWTs are being used by the IETF STIR working group to enable verification of the calling party's authorization to use a particular telephone number for an incoming call, providing verified Caller ID<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fself-issued.info%2F%3Fp%3D2045&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427088179&sdata=I%2Fsfexe57mSKoPWAMa5fd140whs4Gl4YVV5OdmpqLwI%3D&reserved=0> to help combat fraudulent and unwanted telephone calls.  The advice in the BCP can be used by new JWT profiles and applications to take advantage of what’s been learned since we created the JSON Web Token (JWT) specification over a half decade ago.

                                                       -- Mike

P.S.  This notice was also posted at https://self-issued.info/?p=2052<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fself-issued.info%2F%3Fp%3D2052&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427098175&sdata=2dMlphAcFQpgBaRyWlGsl%2B7FA%2FERb3Koyfwlc%2FHIs7A%3D&reserved=0> and as @selfissued<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fselfissued&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427098175&sdata=UViLMGp7FHUc1BCGfJQ9ZX50OLYHXP6Av58alZPSajM%3D&reserved=0>.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C9f80ca2177654f8d065108d7b59dfa4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637177562427098175&sdata=WXFFpdhTwp9IuhoIChsma7skosJy%2FEyyIAtBQA9Feas%3D&reserved=0>