hidekazu-konishi.com

JWT and JOSE Standards History and Timeline - JWS, JWE, JWK, JWA, JWT, and How the Algorithm Registry Has Changed

First Published: 2026-10-06
Last Updated: 2026-10-06

On 2026-09-25, the IETF's JOSE Working Group's draft draft-ietf-jose-deprecate-none-rsa15 entered IETF Last Call. The deadline is 2026-10-09. This draft proposes marking the alg values none for JWS and RSA1_5 for JWE as Deprecated in the IANA registry. The day before, on 2026-09-24, the IESG approved draft-ietf-jose-hpke-encrypt, which utilizes HPKE in JWE. On 2026-09-29, IANA added the HPKE values defined in this draft to the registry. This draft has not yet been published as an RFC. On 2026-08-24, the IESG also approved draft-ietf-oauth-rfc8725bis, intended to replace RFC 8725 (February 2020), the Best Current Practice for JWT. However, the none and RSA1_5 draft that this draft normatively references has not yet reached the RFC Editor, so the revision is held in the RFC Editor's queue.

There is no single date on which JOSE and JWT became standards. For JWT, an individual draft was posted to the IETF on 2010-12-28. It became a draft in the IETF's OAuth Working Group on 2012-05-23, entered IETF Last Call on 2014-08-20, and received IESG approval on 2015-01-13 (UTC). It was published as RFC 7519 in May 2015. The status of the alg values is maintained not in the body of the RFCs themselves, but in the IANA registry, and IANA sometimes moves without waiting for RFC publication. EdDSA was marked as Deprecated in the IANA registry on 2025-05-12, when the IESG approved the draft for RFC 9864. RFC 9864 was published in October 2025.

This article is a timeline, listing dates from the initial draft of JWT (2010-12-28) through the IETF Last Call (2026-09-25 to 2026-10-09) of the draft that would make none and RSA1_5 Deprecated. The timeline is organized by dates from the IETF Datatracker, RFC Editor, and IANA records. The second half presents two tables summarizing the status of the main alg values. Furthermore, it examines how the dates from the three records differ and what the revised JWT BCP (Best Current Practice) is waiting for. All information was verified as of 2026-10-05.

Background and Method of Creating the JWT and JOSE Standards Timeline

JOSE (JSON Object Signing and Encryption) is a set of specifications for signing and encrypting data using JSON. It comprises JWS (RFC 7515) for signing, JWE (RFC 7516) for encryption, JWK (RFC 7517) for key representation, and JWA (RFC 7518) for algorithm definition. JWT (RFC 7519) defines the format for claims that are included in JWS or JWE. The value of the alg parameter in the header indicates which algorithm was used for signing (JWS) or for key management (JWE). However, RFC 8725 §3.1 requires libraries to let the caller specify the set of algorithms that may be used and not to use any other algorithms. The value in the header does not decide this. RFC 7518 was the first RFC to define the permissible values for alg and their implementation requirements, and these values are now managed by an IANA registry. The purpose of this article is to list when, and in which record, these documents and the status of alg values changed, based solely on the descriptions in the original source materials.

Sources Used in This Article

The timeline entries are primarily drawn from the following sources.

• IETF Datatracker — Dates such as the draft version, the date the document became a Working Group (WG) document, the IETF Last Call, IESG approval, and the start and end dates of the WG were taken from the Datatracker JSON API (records of document events and WG events). Datatracker records timestamps in UTC. The dates this article takes from Datatracker are UTC dates. ⚠ The Datatracker history page displays dates in US Pacific Time. Therefore, for four rows in the timeline, the history page shows a date one day earlier than this article. They are the IESG approval of the JWT draft (this article: 2015-01-13, page: 2015-01-12), -00 of the fully specified identifiers draft (this article: 2024-01-26, page: 2024-01-25), -00 of the none and RSA1_5 draft (this article: 2024-11-04, page: 2024-11-03), and the publication request for the none and RSA1_5 draft (this article: 2026-09-07, page: 2026-09-06).
• RFC Editor — Includes the full text of the RFCs, as well as metadata for each RFC (the publication month, status, and updates in /rfc/rfcNNNN.json). The dates for the RFCs are given to the month. The RFC Editor queue was verified using https://www.rfc-editor.org/queue2.xml. This address is being redirected to https://queue.rfc-editor.org/api/v1/queue.xml.
• IANA JOSE Registry — Located at https://www.iana.org/assignments/jose/jose.xml. As of the verification date, the Last Updated date was 2026-09-29. The XML records contain date and updated attributes, but these are not displayed in the HTML table. ⚠ The updated field may not change when a reference is updated from a draft to an RFC. For example, the ML-DSA record shows an updated date of 2025-10-24, but the reference now points to RFC 9964. Therefore, this article does not state that a status changed on a date based only on the date attributes. A date is given as the date of a change only for rows where the registry was checked before and after the change, in Internet Archive copies; for the 2026-09-29 row, the copy from 2026-08-12 and the current registry were checked.
• Internet Archive Copies — These are archived HTML versions (jose.xhtml) of the IANA registry. This article examined copies from 2015-04-18, 2016-10-16, 2020-05-20, 2020-05-27, 2020-06-24, 2025-04-22, 2025-04-24, 2025-05-10, 2025-05-15, 2025-10-23, 2025-11-12, and 2026-08-12. ⚠ These are archived copies and not live, primary source material.
• Draft Text — This refers to the text of each version of the IETF drafts, archived in the IETF draft archives. This article also used the Document History sections.

How Stages and Dates Are Written in This Timeline

This timeline uses two columns: Clock and Stage. The Clock column indicates the source from which the date in that row is taken. The possible values are:

• IETF — Records from the IETF Datatracker, including draft versions, IETF Last Call announcements, IESG approvals, and Working Group (WG) events.
• RFC Editor — Refers to the publication of RFCs and the status of documents in the RFC Editor queue.
• IANA — Relates to the addition of values to IANA registries and changes to implementation requirements.

The Stage column describes what occurred on that row, using fixed terms.

• Individual draft — A new version of an individual draft was posted to the IETF.
• WG document — A -00 draft from a Working Group (WG) was released. This indicates that the WG has taken ownership of the document.
• In IETF Last Call — The IESG announced an IETF-wide Last Call. The deadline is also given.
• Publication requested — The WG requested publication from the IESG.
• IESG approved — The IESG approved the document. This does not constitute the publication of an RFC.
• RFC Editor queue — The approved document entered the RFC Editor queue. The status in the queue is also indicated.
• Published as RFC — The document was published as an RFC.
• IANA registered — A value was added to the IANA registry.
• IANA temporary registration — A value was added to the IANA registry as a temporary registration with an expiration date.
• IANA requirement changed — The implementation requirements for a value in the IANA registry were changed.
• WG chartered — The Working Group (WG) began its activities. This also includes cases where a previously concluded WG resumed activities following the approval of a charter.
• WG concluded — The Working Group (WG) concluded its activities.

Dates are given as year, month, and day for IETF and IANA rows, and as year and month for RFC publication in RFC Editor rows. This article avoids using the term "standardized." For each entry, the date indicating the stage of development is provided. The RFC status (Proposed Standard, Best Current Practice, Informational) is listed in the What Happened column. RFC 7519 for JWT is a Proposed Standard, and is not an Internet Standard.

The terms for implementation requirements in the IANA registry are the words listed in RFC 7518 §7.1.1: Required, Recommended, Optional, Deprecated, and Prohibited. These terms may be followed by either a + or a -. RFC 7518 explains + as the requirement strength is likely to be increased in a future version of the specification and - as the requirement strength is likely to be decreased in a future version of the specification. This article will use these terms directly. For Required, Recommended, and Optional, this terminology describes what a JOSE implementation (library) should support. It does not describe what a receiver should accept.

Why JWT Came from a Different Working Group

The four RFCs – JWS, JWE, JWK, and JWA – are documents from the IETF's JOSE WG. The official name of the JOSE WG in Datatracker is Javascript Object Signing and Encryption, which differs in its first word from the title of the RFCs, "JSON Object Signing and Encryption." In contrast, the JWT RFC (RFC 7519) is a document from the OAuth WG (officially named Web Authorization Protocol). Several other RFCs related to JWT, including RFC 7523 (which uses JWT for OAuth 2.0 client authentication and authorization grants), RFC 8725 (a Best Current Practice for JWT), RFC 9068 (representing access tokens with JWT), RFC 9449 (DPoP), and RFC 9901 (SD-JWT), are also documents from the OAuth WG.

This difference in origin is reflected in the timeline. The JOSE WG concluded on 2016-08-22, and resumed activity on 2023-01-26. During that period, the development of JWT-related documents continued in the OAuth WG. RFC 8725 (February 2020) and RFC 9068 (October 2021) were published during this time. The 2026 revised JWT Best Current Practice (BCP) is also a document from the OAuth WG, and it normatively references the JOSE WG draft on none and RSA1_5. RFC 9964, which defines ML-DSA for JOSE, is a document from the COSE WG.

What This Article Leaves to Other Articles

NIST's standardization of quantum-resistant cryptography and AWS's support for quantum-resistant cryptography are detailed in Post-Quantum Cryptography Standardization Timeline and Migration on AWS. This article has only the rows for RFC 9964, which uses ML-DSA in JOSE, and for its draft and IANA registration. The definitions of HMAC, RSA, ECDSA, EdDSA, and Ed25519 are covered in Cryptography Glossary for Engineers. The timeline format follows that of SSH and OpenSSH Algorithm History and Timeline, which tracks when algorithms enter and leave the defaults. The phasing out of SHA-1 in TLS certificates is discussed in TLS Certificate Ecosystem History and Timeline. JWT Signing Algorithms on AWS Endpoints details which alg values AWS JWT endpoints accept.

This article does not cover the history of authorization flows for OAuth 2.0 and OpenID Connect. It also does not address specifications from the OpenID Foundation, such as the Shared Signals Framework. RFCs specifically focused on COSE, with the exception of those shared with JOSE, are not included. Furthermore, this article does not provide comparisons of JWT libraries or implementation procedures. Regarding vulnerabilities, it only describes what standards prohibit or modify, without detailing attack methods.

JWT and JOSE Standards Historical Timeline (Updates from December 28, 2010)

The following six tables present the historical timeline. Each table has the following columns. All references were obtained on 2026-10-05.

• Date — The date, as described in the previous section. RFC publication dates are given to the month only.
• Clock — The source from which the date was obtained. This indicates whether the source is IETF, RFC Editor, or IANA.
• Stage — A term as defined in the previous section.
• What Happened — A description of the event. In some cases, excerpts from the source material will be quoted verbatim.
• Source — The document that provides the basis for the entry.

Index:

• 2010–2014 - The period during which individual JWT drafts were published, the JOSE Working Group (WG) was formed, and five specifications entered the IETF Last Call process.
• 2015–2016 - The period during which the IESG approved five specifications, the IANA registry was established, five specifications were published as RFCs, and the JOSE WG concluded its work.
• 2017–2022 - The period during which the RFC for EdDSA was published, the BCP for JWT was published, and the number of JWT profiles increased.
• 2023–2024 - The period during which the JOSE WG resumed activity, the RFC for DPoP was published, and drafts that would lead to developments in 2025 and 2026 were initiated.
• 2025 - The period during which EdDSA was marked as Deprecated by IANA, ML-DSA was temporarily registered, and RFC 9864 and the SD-JWT RFC were published.
• 2026 - The period during which the RFC for ML-DSA was published, the revised JWT BCP and the HPKE draft were approved, and the none and RSA1_5 draft entered the IETF Last Call process.

* You can sort the table by clicking on the column name.

2010–2014 — The First JWT Draft, the JOSE Working Group, and the IETF Last Call

During this period, initial drafts of JWT emerged. Subsequently, the signing portion was separated into a distinct draft, and drafts for keys and encryption also appeared. The JOSE Working Group was formed, and on 2014-08-20, five specifications – JWS, JWE, JWK, JWA, and JWT – entered the IETF Last Call process simultaneously.

Date	Clock	Stage	What Happened	Source
2010-12-28	IETF	Individual draft	The initial JWT draft, draft-jones-json-web-token-00, was posted to the IETF. The summary begins with JSON Web Token (JWT) defines a token format that can encode claims transferred between two parties. It used the term digitally signed when referring to claims. It reserved the following nine values for the alg parameter: HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, and ES512. It did not include none or values like PS256 for RSASSA-PSS. The header was referred to as the JWT Envelope Segment. The document history in later versions describes -00 as Public draft published before November 2010 IIW. This article uses the Datatracker date, which is also the date given in the draft itself.	draft-jones-json-web-token-00 / draft-jones-json-web-token-01
2011-03-28	IETF	Individual draft	The signature portion was separated from the JWT draft, and on the same day, the JWT draft -03 defined none. The change history for JWT draft -03 stated that "-02" included Split signature specification out into separate draft-jones-json-web-signature-00. Regarding "-03," it stated that the draft defined none as a value for alg to represent JWTs without a signature, and it also changed the designation of RSA SHA-256 implementations from MUST to RECOMMENDED.	draft-jones-json-web-token-03 / draft-jones-json-web-signature-00
2011-05-01	IETF	Individual draft	A draft regarding key representation, draft-jones-json-web-key-00, was released.	draft-jones-json-web-key-00
2011-09-07	IETF	Individual draft	A draft regarding encryption, draft-jones-json-web-encryption-00, was released.	draft-jones-json-web-encryption-00
2011-09-21	IETF	WG chartered	The IETF JOSE Working Group was established. Datatracker records Proposed group on 2011-08-18 and Started group on 2011-09-21.	JOSE WG history
2012-01-16	IETF	WG document	JWS, JWE, JWK, and JWA became drafts within the JOSE Working Group. These were draft-ietf-jose-json-web-signature-00, draft-ietf-jose-json-web-encryption-00, draft-ietf-jose-json-web-key-00, and draft-ietf-jose-json-web-algorithms-00.	draft-ietf-jose-json-web-algorithms history
2012-05-23	IETF	WG document	JWT became a draft within the OAuth Working Group. This was draft-ietf-oauth-json-web-token-00. JWS, JWE, JWK, and JWA progressed as documents within the JOSE Working Group, while JWT progressed as a document within the OAuth Working Group.	draft-ietf-oauth-json-web-token history
2014-04	RFC Editor	Published as RFC	RFC 7165 was published, summarizing the use cases and requirements for JOSE. The status was designated as Informational.	RFC 7165: Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
2014-08-20	IETF	In IETF Last Call	JWS, JWE, JWK, JWA, and JWT all entered IETF Last Call on the same day. The deadlines for all five were 2014-09-03. The JOSE Working Group had requested publication of the four from the IESG on 2014-04-12, and the OAuth Working Group had requested publication of JWT on 2014-05-08. The intended status for all five was Proposed Standard.	draft-ietf-oauth-json-web-token history / draft-ietf-jose-json-web-signature history

2015–2016 — IESG Approval, the IANA Registry, the JOSE and JWT RFCs, and the End of the JOSE Working Group

In January 2015, the IESG approved five specifications, and the IANA registry received its initial entries. The corresponding RFCs were published in May 2015. In 2016, a draft specifying the use of EdDSA within JOSE was approved, and the JOSE Working Group concluded on the same day.

Date	Clock	Stage	What Happened	Source
2015-01-13	IETF	IESG approved	The IESG approved the draft (draft-ietf-oauth-json-web-token) for JWT. The version approved was -32. The Datatracker history page shows the date as 2015-01-12 (US Pacific Time).	draft-ietf-oauth-json-web-token history
2015-01-15	IETF	IESG approved	The IESG approved the drafts for JWA and JWE. The record for the JWA draft indicates that IANA work (IANA Action) began on the same day, and on 2015-01-24 (UTC; the history page shows 2015-01-23), IANA notified the RFC Editor that the work was complete (Waiting on RFC Editor).	draft-ietf-jose-json-web-algorithms history
2015-01-16	IETF	IESG approved	The IESG approved the drafts for JWS and JWK.	draft-ietf-jose-json-web-signature history
2015-01-23	IANA	IANA registered	In the IANA registry, the records for the values in RFC 7518 carry this date (the date attribute). This date is four months before the RFC was published. The implementation requirements state that HS256 is Required, RS256 is Recommended, ES256 is Recommended+, and none is Optional. For JWE, RSA1_5 is Recommended-, and RSA-OAEP is Recommended+. A copy from 2015-04-18 shows the registry creation date (Created) as 2015-01-23, and lists these values with a reference that has no RFC number, RFC-ietf-jose-json-web-algorithms-40.	IANA: JSON Web Signature and Encryption Algorithms / Internet Archive copy (2015-04-18)
2015-05	RFC Editor	Published as RFC	RFC 7515 (JWS), RFC 7516 (JWE), RFC 7517 (JWK), and RFC 7518 (JWA) were published. All four are Proposed Standards and are documents from the JOSE WG. RFC 7518 §3.6 states about none, Implementations MUST NOT accept Unsecured JWSs by default. In the same month, RFC 7520 (Informational), which provides examples for JOSE, was also published.	RFC 7518: JSON Web Algorithms (JWA) / RFC 7515: JSON Web Signature (JWS)
2015-05	RFC Editor	Published as RFC	RFC 7519 (JWT) was published. It was designated as a Proposed Standard and is a document from the OAuth Working Group. In the same month, RFC 7523 (Proposed Standard) was published, defining how JWT can be used for client authentication and authorization grants in OAuth 2.0. For client authentication, a single JWT is included as the value of the client_assertion parameter.	RFC 7519: JSON Web Token (JWT) / RFC 7523
2015-09	RFC Editor	Published as RFC	RFC 7638 defined the method for calculating the thumbprint (hash value) of a JWK. It was designated as a Proposed Standard. Later, DPoP (RFC 9449) uses this thumbprint to associate access tokens with a key.	RFC 7638: JSON Web Key (JWK) Thumbprint
2016-02	RFC Editor	Published as RFC	RFC 7797 defined a way to leave the JWS payload unencoded (the b64 header) and updated RFC 7519. It was designated as a Proposed Standard. The update states that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.	RFC 7797: JSON Web Signature (JWS) Unencoded Payload Option
2016-04	RFC Editor	Published as RFC	RFC 7800 defined the cnf (confirmation) claim for JWTs. This claim allows the receiver to cryptographically verify that the presenter of the JWT possesses a specific key. It was designated as a Proposed Standard and is a document from the OAuth Working Group.	RFC 7800: Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
2016-08-22	IETF	IESG approved	The IESG approved a draft (draft-ietf-jose-cfrg-curves) that defines the use of Ed25519 and Ed448 signatures, and X25519 and X448 key exchange within JOSE. This draft later became RFC 8037.	draft-ietf-jose-cfrg-curves history
2016-08-22	IANA	IANA registered	In the IANA JOSE registries, records for the alg value EdDSA (Optional), key type OKP, and curve names Ed25519, Ed448, X25519, and X448 are associated with this date (the date attribute). Note that Ed25519 here refers to the curve name used in the crv field of a JWK, and is not a value for alg. In a copy from 2016-10-16, EdDSA is listed with a reference that has no RFC number, RFC-ietf-jose-cfrg-curves-06. The registry's Last Updated on that copy is 2016-08-23.	IANA: JSON Object Signing and Encryption (JOSE) / Internet Archive copy (2016-10-16)
2016-08-22	IETF	WG concluded	The JOSE Working Group concluded its work. According to Datatracker records, a request to conclude the group was made on 2016-08-18, and the status was changed to Concluded on 2016-08-22.	JOSE WG history

2017–2022 — EdDSA in an RFC, the JWT Best Current Practices, and New JWT Profiles

While the JOSE WG was closed, JWT documents continued in the OAuth WG and other groups. RFC 8725, outlining JWT Best Current Practices, was published, and ES256K was added to the IANA registry.

Date	Clock	Stage	What Happened	Source
2017-01	RFC Editor	Published as RFC	RFC 8037 defined the alg value EdDSA and the key type OKP. The status is Proposed Standard. Whether to use Ed25519 or Ed448 is determined by the key, not the alg value. RFC 8037 states, The EdDSA variant used is determined by the subtype of the key (Ed25519 for "Ed25519" and Ed448 for "Ed448").	RFC 8037: CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)
2017-07-27	IETF	WG document	The BCP for JWT became a draft within the OAuth Working Group. It is designated as draft-ietf-oauth-jwt-bcp-00.	draft-ietf-oauth-jwt-bcp history
2018-07	RFC Editor	Published as RFC	RFC 8417 defined the Security Event Token (SET). The status is Proposed Standard. SET is a JWT and includes events that occurred to a subject within the events claim. When the type is given in typ, the value secevent+jwt is recommended. If there is a possibility of confusion with other types of JWT, specifying the type is mandatory.	RFC 8417: Security Event Token (SET)
2019-03-25	IETF	In IETF Last Call	The draft for the JWT BCP entered the IETF Last Call process. The deadline is 2019-04-08.	draft-ietf-oauth-jwt-bcp history
2019-10-21	IETF	IESG approved	The IESG approved the draft for the JWT BCP.	draft-ietf-oauth-jwt-bcp history
2020-02	RFC Editor	Published as RFC	RFC 8725 (BCP 225) was published, updating RFC 7519. Its status is Best Current Practice. Section 3.1 states that Libraries MUST enable the caller to specify a supported set of algorithms and MUST NOT use any other algorithms when performing cryptographic operations. Section 3.2 states that using none can be perfectly acceptable when JWTs are cryptographically protected end-to-end by a transport layer such as TLS, and that libraries SHOULD NOT create or accept JWTs with none unless explicitly specified by the caller. It also recommends avoiding the use of RSA-PKCS1 v1.5 encryption.	RFC 8725: JSON Web Token Best Current Practices
2020-05-26	IANA	IANA registered	ES256K (ECDSA using secp256k1) was added to the IANA registry. A copy from 2020-05-27 lists a "Last Updated" date of 2020-05-26, with the reference for ES256K being draft-ietf-cose-webauthn-algorithms-06. ES256K is not in a copy from 2020-05-20. The IESG approved this draft on 2020-06-16, and the IANA registration occurred prior to that date. A copy from 2020-06-24 shows the reference changed to RFC-ietf-cose-webauthn-algorithms-08.	Internet Archive copy (2020-05-20) / Internet Archive copy (2020-05-27) / Internet Archive copy (2020-06-24) / draft-ietf-cose-webauthn-algorithms history
2020-08	RFC Editor	Published as RFC	RFC 8812 was published. Its status is Proposed Standard, and it is a document from the COSE Working Group. It registers COSE algorithms used by WebAuthn and registers ES256K and the secp256k1 curve within JOSE.	RFC 8812
2021-10	RFC Editor	Published as RFC	RFC 9068 defined a profile for representing OAuth 2.0 access tokens using JWT. Its status is Proposed Standard. It registers the media type application/at+jwt and uses at+jwt in the typ parameter.	RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
2022-08-16	IETF	WG document	A draft on using post-quantum signatures with JOSE and COSE became a draft within the COSE Working Group. It is draft-ietf-cose-post-quantum-signatures-00, titled JOSE and COSE Encoding for Post-Quantum Signatures. On 2023-03-12, this draft was replaced by draft-ietf-cose-dilithium-00 (titled JOSE and COSE Encoding for Dilithium), which later became RFC 9964.	draft-ietf-cose-post-quantum-signatures history / draft-ietf-cose-dilithium history
2022-08-25	IETF	WG document	SD-JWT (Selective Disclosure for JWTs) became a draft within the OAuth Working Group. The draft is draft-ietf-oauth-selective-disclosure-jwt-00.	draft-ietf-oauth-selective-disclosure-jwt history

2023–2024 — The JOSE Working Group Returns, DPoP, and the Drafts Behind the 2025 and 2026 Changes

The JOSE Working Group resumed its activities. The three drafts that moved in 2025 and 2026 (fully specified identifiers, HPKE, and none and RSA1_5) all became JOSE Working Group drafts in this period.

Date	Clock	Stage	What Happened	Source
2023-01-26	IETF	WG chartered	The JOSE Working Group resumed activity. Datatracker records indicate Charter approved, group active. The record for 2023-12-15 shows that adopting a document registering identifiers for fully specified algorithms, and documents using NIST's ML-DSA and others in JOSE, was added to the milestones from the charter.	JOSE WG history
2023-09	RFC Editor	Published as RFC	RFC 9449 was published, defining DPoP. Its status is Proposed Standard. DPoP binds access tokens, and refresh tokens issued to public clients, to proof of possession of a key at the application layer. The typ of the proof JWT is dpop+jwt. When the access token is a JWT, the jkt within the cnf claim contains the JWK SHA-256 thumbprint (RFC 7638) for the DPoP public key.	RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
2024-01-26	IETF	WG document	A draft defining identifiers for fully specified algorithms became a JOSE Working Group draft. It was draft-ietf-jose-fully-specified-algorithms-00, which later became RFC 9864. The Datatracker history page shows the date as 2024-01-25 (US Pacific Time).	draft-ietf-jose-fully-specified-algorithms history
2024-06-19	IETF	WG document	A draft utilizing HPKE in JWE became a JOSE Working Group draft. It was draft-ietf-jose-hpke-encrypt-00, replacing the individual draft draft-rha-jose-hpke-encrypt.	draft-ietf-jose-hpke-encrypt history
2024-11-04	IETF	WG document	A draft to make none and RSA1_5 Deprecated became a JOSE Working Group draft. It was draft-ietf-jose-deprecate-none-rsa15-00, replacing the individual draft draft-madden-jose-deprecate-none-rsa15. The Datatracker history page shows the date as 2024-11-03 (US Pacific Time).	draft-ietf-jose-deprecate-none-rsa15 history

2025 — EdDSA Becomes Deprecated, ML-DSA Is Registered, and RFC 9864 and SD-JWT Are Published

In 2025, the implementation requirement of EdDSA became Deprecated in the IANA registry, and Ed25519 and Ed448 were added as valid values for the alg parameter. ML-DSA values were added as a temporary registration prior to the IETF Last Call.

Date	Clock	Stage	What Happened	Source
2025-01	RFC Editor	Published as RFC	RFC 9701 defined how OAuth 2.0 token introspection responses can be returned using JWT. The status is Proposed Standard. The JWT typ parameter is token-introspection+jwt.	RFC 9701: JSON Web Token (JWT) Response for OAuth Token Introspection
2025-02-21	IETF	In IETF Last Call	A draft specifying fully specified algorithm identifiers entered IETF Last Call. The deadline is 2025-03-07.	draft-ietf-jose-fully-specified-algorithms history
2025-02-21	IETF	WG document	A draft, intended to update RFC 7523 and related documents, became a draft within the OAuth Working Group. It replaced the individual draft draft-jones-oauth-rfc7523bis and is designated as draft-ietf-oauth-rfc7523bis-00.	draft-ietf-oauth-rfc7523bis history
2025-04-24	IANA	IANA temporary registration	IANA's registry added ML-DSA-44, ML-DSA-65, and ML-DSA-87 as temporary registrations, along with the key type AKP. The copy from 2025-04-24 lists ML-DSA-44 as TEMPORARY - registered 2025-04-24, expires 2026-04-24, with a reference to draft-ietf-cose-dilithium-06. They are not in the copy from 2025-04-22. This occurred prior to the draft's IETF Last Call (2025-07-07).	Internet Archive copy (2025-04-22) / Internet Archive copy (2025-04-24)
2025-05-12	IETF	IESG approved	The IESG approved the draft specifying fully specified algorithm identifiers. The approved version is -13.	draft-ietf-jose-fully-specified-algorithms history
2025-05-12	IANA	IANA requirement changed	In the IANA registry, the implementation requirements for EdDSA changed from Optional to Deprecated, and the alg values Ed25519 and Ed448 (Optional) were added. In a copy from 2025-05-10, EdDSA was listed as Optional, while a copy from 2025-05-15 (Last Updated 2025-05-12) shows it as Deprecated. The reference is to RFC-ietf-jose-fully-specified-algorithms-13, Section 2.2, which has no RFC number.	Internet Archive copy (2025-05-15) / Internet Archive copy (2025-05-10)
2025-05-28	IETF	IESG approved	The IESG approved the draft for SD-JWT. Datatracker also shows a record of approval on 2025-05-29, after -22 was released.	draft-ietf-oauth-selective-disclosure-jwt history
2025-07-07	IETF	In IETF Last Call	A draft utilizing ML-DSA in JOSE and COSE entered the IETF Last Call. The deadline is 2025-07-28.	draft-ietf-cose-dilithium history
2025-08-28	IETF	WG document	The revised JWT BCP became a draft within the OAuth Working Group. It replaces the individual draft draft-sheffer-oauth-rfc8725bis with draft-ietf-oauth-rfc8725bis-00.	draft-ietf-oauth-rfc8725bis history
2025-10-15	IETF	IESG approved	The IESG approved a draft utilizing ML-DSA in JOSE and COSE. The temporary registration label in the IANA registry remained in the copy from 2025-10-23 but was gone in the copy from 2025-11-12, with the reference updated to RFC-ietf-cose-dilithium-10. The updated attribute for the record ML-DSA-44 is dated 2025-10-24.	draft-ietf-cose-dilithium history / Internet Archive copy (2025-10-23) / Internet Archive copy (2025-11-12)
2025-10	RFC Editor	Published as RFC	RFC 9864 was published, updating RFC 7518, RFC 8037, and RFC 9053. It is designated as a Proposed Standard and is a document from the JOSE Working Group. It created fully specified identifiers, which determine the curve and other parameters from the identifier alone, and made polymorphic signature identifiers such as EdDSA Deprecated. In JOSE, EdDSA became Deprecated; polymorphic encryption identifiers such as ECDH-ES did not, because the RFC does not define replacements for them. Section 4.4 notes that the terms Deprecated and Prohibited are currently undefined in the context of JOSE and COSE registration, and it defines these two terms.	RFC 9864: Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
2025-11	RFC Editor	Published as RFC	RFC 9901 defined SD-JWT. It is designated as a Proposed Standard. It introduces a mechanism that allows the holder to select and disclose elements within the JWS payload. The typ parameter for Key Binding JWT, used to associate with the holder's key, is kb+jwt.	RFC 9901: Selective Disclosure for JSON Web Tokens

2026 — RFC 9964, the Revised JWT BCP, HPKE, and the IETF Last Call for none and RSA1_5

RFC 9964, which specifies the use of ML-DSA in JOSE, was published. The IESG approved both the revised JWT BCP and a draft document detailing the use of HPKE in JWE. Both are held in the RFC Editor queue. The draft for none and RSA1_5 has entered the IETF Last Call process.

Date	Clock	Stage	What Happened	Source
2026-03-27	IETF	In IETF Last Call	A draft aimed at updating RFC 7523 and related specifications entered the IETF Last Call process. The deadline is 2026-04-10.	draft-ietf-oauth-rfc7523bis history
2026-04-30	IETF	IESG approved	The IESG approved a draft (version -11) aimed at updating RFC 7523 and related specifications. According to the summary, the update addresses a security vulnerability found in multiple OAuth 2.0 specifications by revising the handling of audience values in RFC 7521, RFC 7522, RFC 7523, and RFC 9126. As of the verification date, the document is in the second_editor state in the RFC Editor queue and is not blocked waiting for other documents.	draft-ietf-oauth-rfc7523bis history / RFC Editor queue (XML)
2026-05-13	IETF	In IETF Last Call	A draft utilizing HPKE in JWE entered its first IETF Last Call. The deadline is 2026-05-27.	draft-ietf-jose-hpke-encrypt history
2026-05	RFC Editor	Published as RFC	RFC 9964 was published, defining how to use ML-DSA in JOSE and COSE. It is a Proposed Standard and is a document from the COSE Working Group. The alg values are ML-DSA-44, ML-DSA-65, and ML-DSA-87, and the key type is AKP.	RFC 9964: ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)
2026-06-22	IETF	In IETF Last Call	The revised JWT BCP draft entered the IETF Last Call process. The deadline is 2026-07-06.	draft-ietf-oauth-rfc8725bis history
2026-07-13	IETF	In IETF Last Call	The draft utilizing HPKE in JWE entered its second IETF Last Call. The deadline is 2026-08-03. On 2026-07-22, the Datatracker comments state, Document has passed the WGLC and is already in the 2nd IETF Last Call to remove two algorithms. A ballot comment on 2026-09-15 states This second run through the process is to remove HPKE-4-KE and HPKE-6-KE as options in the Key Encryption mode. On the same date, 2026-07-13, the draft-ietf-hpke-hpke draft, which this draft normatively references, also entered IETF Last Call.	draft-ietf-jose-hpke-encrypt history / draft-ietf-hpke-hpke history
2026-08-24	IETF	IESG approved	The IESG approved the draft (-10) of the revised JWT BCP. The draft's header shows that it Obsoletes: 8725 (if approved) and Updates: 7519 (if approved), with the intended status being Best Current Practice.	draft-ietf-oauth-rfc8725bis history
2026-08-25	RFC Editor	RFC Editor queue	The draft of the revised JWT BCP entered the RFC Editor queue and was immediately marked as blocked. The queue shows the normative reference draft-ietf-jose-deprecate-none-rsa15 as NOT-RECEIVED.	RFC Editor queue (XML) / draft-ietf-oauth-rfc8725bis history
2026-09-07	IETF	Publication requested	The JOSE WG requested the IESG to publish the draft for none and RSA1_5. On the same day, the intended status changed from Internet Standard to Proposed Standard. Both records indicate UTC time of 2026-09-07 (the intended status change occurred at 00:33:45Z), while the Datatracker history page displays the date as 2026-09-06 in US Pacific Time.	draft-ietf-jose-deprecate-none-rsa15 history
2026-09-24	IETF	IESG approved	The IESG approved the draft (-22) utilizing HPKE in JWE. This draft updates RFC 7516 (JWE) to allow for Integrated Encryption as a Key Management Mode.	draft-ietf-jose-hpke-encrypt history
2026-09-25	IETF	In IETF Last Call	A draft (-06) to make none and RSA1_5 Deprecated entered the IETF Last Call process. The deadline is 2026-10-09. The intended status is Proposed Standard, and it would update RFC 7518.	draft-ietf-jose-deprecate-none-rsa15 history
2026-09-29	IANA	IANA registered	IANA added HPKE values for the alg parameter to its registry. These include eight values (HPKE-0 through HPKE-7), as well as six additional values: HPKE-0-KE, HPKE-1-KE, HPKE-2-KE, HPKE-3-KE, HPKE-5-KE, and HPKE-7-KE. The implementation requirements for all of these values are marked as Optional. The reference is RFC-ietf-jose-hpke-encrypt-22, which has no RFC number. The values are not in the copy from 2026-08-12.	IANA: JSON Web Signature and Encryption Algorithms / Internet Archive copy (2026-08-12)
2026-09-29	RFC Editor	RFC Editor queue	The draft utilizing HPKE in JWE entered the RFC Editor queue and was marked as blocked. The queue indicates that the normative reference draft-ietf-hpke-hpke is NOT-RECEIVED. As of the verification date, draft-ietf-hpke-hpke has been in IESG Evaluation since 2026-09-26.	RFC Editor queue (XML) / draft-ietf-hpke-hpke history

Current Overview of JWT and JOSE Standards

The most recent RFC listed in this timeline is RFC 9964 (May 2026). As of 2026-10-05, IANA's registry was last updated on 2026-09-29. This section provides two tables summarizing the status of the primary alg values. Furthermore, it examines changes related to EdDSA, none, and RSA1_5, details any discrepancies in dates from IESG, IANA, and the RFC Editor, and outlines what the revised JWT BCP is waiting for.

The alg Status Table

The following two tables summarize the status of key alg values, as taken from the IANA registry as of 2026-10-05. The columns are as follows:

• alg Value — The value to be written in the alg header in JOSE.
• Used For — Indicates whether this value is used for JWS signatures, JWS MACs, or JWE key management. For HPKE, the row names the key management mode (Integrated Encryption or Key Encryption). For none, it is JWS with no signature or MAC.
• Defined In — The document that defines this value, along with the month of the corresponding RFC.
• IANA Requirement — The implementation requirements specified in the IANA registry as of the verification date.
• Status Change — Indicates any changes in status, listing the IANA date and the RFC month separately.

Table Part 1 lists the values used for JWS.

alg Value	Used For	Defined In	IANA Requirement	Status Change
HS256	JWS MAC (HMAC and SHA-256)	RFC 7518 (2015-05)	Required	No change (IANA record date: 2015-01-23).
HS384, HS512	JWS MAC	RFC 7518 (2015-05)	Optional	No change.
RS256	JWS signature (RSASSA-PKCS1-v1_5 and SHA-256)	RFC 7518 (2015-05)	Recommended	No change. The none and RSA1_5 draft explicitly states that it does not change RS256, RS384, and RS512.
RS384, RS512	JWS signature (RSASSA-PKCS1-v1_5)	RFC 7518 (2015-05)	Optional	No change.
PS256, PS384, PS512	JWS signature (RSASSA-PSS)	RFC 7518 (2015-05)	Optional	No change.
ES256	JWS signature (ECDSA, P-256 and SHA-256)	RFC 7518 (2015-05)	Recommended+	No change. RFC 9864 lists JOSE's ES256 as an example of a fully specified identifier. While COSE's ES256 has become Deprecated as polymorphic, it is distinct from JOSE's ES256.
ES384, ES512	JWS signature (ECDSA)	RFC 7518 (2015-05)	Optional	No change.
ES256K	JWS signature (ECDSA, secp256k1 and SHA-256)	RFC 8812 (2020-08)	Optional	Registered with IANA on 2020-05-26 (referencing the draft), prior to IESG approval (2020-06-16).
EdDSA	JWS signature (Ed25519 and Ed448. Curve is determined by the key.)	RFC 8037 (2017-01)	Deprecated	IANA record date: 2016-08-22 (as Optional). Became Deprecated in IANA on 2025-05-12. RFC 9864, the basis for the change, was published in 2025-10.
Ed25519, Ed448	JWS signature (EdDSA)	RFC 9864 (2025-10)	Optional	Registered with IANA on 2025-05-12.
ML-DSA-44, ML-DSA-65, ML-DSA-87	JWS signature (ML-DSA)	RFC 9964 (2026-05)	Optional	Temporarily registered with IANA on 2025-04-24. The temporary label was gone in the copy from 2025-11-12. RFC 9964 was published in 2026-05.
none	JWS (no signature or MAC)	RFC 7518 (2015-05)	Optional	No change in IANA. As of 2026-10-05, a draft to make it Deprecated is in IETF Last Call (deadline: 2026-10-09).

Table Part 2 lists the key management values for JWE.

alg Value	Used For	Defined In	IANA Requirement	Status Change
RSA1_5	JWE key management (RSAES-PKCS1-v1_5)	RFC 7518 (2015-05)	Recommended-	No change in IANA. As of 2026-10-05, a draft to make it Deprecated is in IETF Last Call (deadline: 2026-10-09).
RSA-OAEP	JWE key management (RSAES OAEP)	RFC 7518 (2015-05)	Recommended+	No change.
RSA-OAEP-256	JWE key management (RSAES OAEP with SHA-256)	RFC 7518 (2015-05)	Optional	No change.
A128KW, A256KW	JWE key management (AES Key Wrap)	RFC 7518 (2015-05)	Recommended	No change.
dir	JWE key management (using a shared symmetric key directly)	RFC 7518 (2015-05)	Recommended	No change.
ECDH-ES	JWE key management (ECDH-ES)	RFC 7518 (2015-05)	Recommended+	No change. RFC 9864 refers to it as "polymorphic," but does not make it Deprecated, because it does not define replacements for it.
ECDH-ES+A128KW, ECDH-ES+A256KW	JWE key management (ECDH-ES with AES Key Wrap)	RFC 7518 (2015-05)	Recommended	No change.
HPKE-0 through HPKE-7	JWE Integrated Encryption (HPKE)	draft-ietf-jose-hpke-encrypt-22 (approved by the IESG, RFC not yet published)	Optional	Registered with IANA on 2026-09-29.
HPKE-0-KE, HPKE-1-KE, HPKE-2-KE, HPKE-3-KE, HPKE-5-KE, HPKE-7-KE	JWE Key Encryption (HPKE)	draft-ietf-jose-hpke-encrypt-22 (approved by the IESG, RFC not yet published)	Optional	Registered with IANA on 2026-09-29.

The values of enc used for encrypting JWE content are not listed in the table. A128CBC-HS256 and A256CBC-HS512 are Required, while A128GCM and A256GCM are Recommended, and these designations have not changed from RFC 7518. Only values used exclusively with JWKs and registered with reference to the W3C Web Cryptography API (such as RS1, HS1, A128CBC, etc.) are marked as Prohibited in this registry, as of the verification date. All values can be verified against the IANA registry listing.

The terms Deprecated and Prohibited were originally introduced in RFC 7518 §7.1.1 in 2015 as terms related to implementation requirements. RFC 7518 specifies that values unsuitable for direct use in JWS or JWE, such as algorithms for unauthenticated encryption, must be registered as Prohibited. RFC 9864 §4.4 notes that these two terms are currently undefined in the context of JOSE and COSE registration, and in 2025 defined them as follows.

Deprecated
   There is a preferred mechanism to achieve functionality similar to
   that referenced by the identifier; this replacement functionality
   SHOULD be utilized in new deployments in preference to the
   deprecated identifier, unless there exist documented operational
   or regulatory requirements that prevent migration away from the
   deprecated identifier.

Prohibited
   The identifier and the functionality that it references MUST NOT
   be used.  (Identifiers may be designated as "Prohibited" due to
   security flaws, for instance.)

What Changed for EdDSA, none, and RSA1_5

EdDSA — RFC 8037 (January 2017) defined EdDSA as an algorithm where the choice between Ed25519 and Ed448 is determined by the crv (curve) of the key, rather than the alg parameter. RFC 9864 refers to algorithms like this, where processing cannot be determined solely by the identifier, as "polymorphic," and states, with EdDSA, it is not known which of the curves Ed25519 and/or Ed448 are supported. This causes problems for protocols that rely on algorithm identifiers to communicate supported algorithms. RFC 9864 adds Ed25519 and Ed448 – which specify the curve – as values for alg, and has made EdDSA Deprecated. This change was registered with IANA on 2025-05-12. Deprecated does not mean that it is no longer usable. According to the definition in RFC 9864, new deployments should prefer alternative identifiers (SHOULD). The revised JWT BCP draft (-10) also states New deployments SHOULD prefer fully-specified algorithm identifiers (for example, "Ed25519" rather than "EdDSA"). This is a recommendation for negotiation and configuration, except when there is a need to support older, polymorphic identifiers for backward compatibility.

none — The initial JWT draft (2010-12-28) did not include none. It was introduced in the JWT draft -03, dated 2011-03-28, as a value representing JWTs without a signature. RFC 7518 (May 2015) made none Optional and stated that it must not be accepted by default (MUST NOT accept Unsecured JWSs by default). RFC 8725 (February 2020) specified that none should only be used when the JWT is cryptographically protected by other means (such as end-to-end protection through a transport layer like TLS) and that libraries SHOULD NOT create or accept none JWTs unless explicitly requested by the caller. The two 2026 drafts strengthen this. The none and RSA1_5 draft (-06) proposes making their IANA implementation requirement Deprecated. This draft states that developers of JOSE libraries SHOULD deprecate support for these algorithms and that application developers MUST disable them by default, although applications with specific needs MAY enable them, but only for the specific objects or operations that need them, not globally. The revised JWT BCP draft (-10) states that JWT libraries MUST NOT create or accept none JWTs unless the caller explicitly requests or allows it. Its §3.2 also states The "none" algorithm is deprecated by [I-D.ietf-jose-deprecate-none-rsa15]. However, as of the verification date, the none entry in the IANA registry remains Optional.

RSA1_5 — RSA1_5 has been Recommended- since its initial registration in 2015. In RFC 7518, - indicates that the requirement strength is likely to be decreased in a future version. RFC 8725 recommended avoiding the RSA-PKCS1 v1.5 encryption scheme (SHOULD). The none and RSA1_5 draft notes that the vulnerabilities associated with this padding scheme have been known since at least 1998, referencing Bleichenbacher's attack, and proposes making RSA1_5 Deprecated. This draft explicitly states that signatures such as RS256 will not be affected.

Note that RSA signatures using PKCS#1 version 1.5 padding ("RS256",
"RS384", and "RS512") are unchanged by this specification and can
still be used.

This draft states that two values should be marked as Deprecated rather than Prohibited (specifically, The algorithms identified in this document are to be marked as Deprecated only.). According to the draft, existing specifications and applications that use these algorithms can continue to do so, but are encouraged to adopt alternatives in future updates. New specifications built on top of JOSE MUST NOT allow the use of either value.

Three Clocks: IESG Approval, the IANA Registry, and RFC Publication

Even for the same changes, the dates for IESG approval, IANA registry updates, and RFC publication do not always align. The following table, taken from the timeline in this article, lists these three dates for the addition and modification of alg values, as of 2026-10-05.

Change	IESG Approved	IANA Registry	Published as RFC
First values in RFC 7518	2015-01-15 (JWA)	2015-01-23 (Record date and registry creation date. Confirmed in a copy dated 2015-04-18)	2015-05 (RFC 7518)
Registration of EdDSA	2016-08-22	2016-08-22 (Record date. The Last Updated on the 2016-10-16 copy is 2016-08-23)	2017-01 (RFC 8037)
Registration of ES256K	2020-06-16	2020-05-26 (Confirmed in a copy. The reference was the draft)	2020-08 (RFC 8812)
Registration of ML-DSA	2025-10-15	2025-04-24 (Confirmed in a copy. Temporary registration)	2026-05 (RFC 9964)
Registration of EdDSA as Deprecated, and registration of Ed25519 and Ed448	2025-05-12	2025-05-12 (Confirmed in a copy)	2025-10 (RFC 9864)
Registration of HPKE values	2026-09-24	2026-09-29 (Confirmed in a copy and current registry)	Not yet published
none and RSA1_5 as Deprecated	Not approved (Currently in IETF Last Call. Deadline 2026-10-09)	No change (Optional and Recommended-)	Not yet published

In all six instances where IANA made changes, the IANA registry moved ahead of RFC publication. For ES256K and ML-DSA, the updates occurred before IESG approval. The ML-DSA registration was marked as a temporary registration with an expiration date. This article did not check which procedure was used for this registration. RFC 7518 §7 sets the registration procedure for the registry and allows registration before publication.

However, to allow for the allocation of values
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.

Therefore, even if a value exists in the IANA registry, the corresponding RFC that defines that value may not yet be published. Focusing solely on the publication of RFCs can lead to delays in understanding changes to the registry. For example, with EdDSA and its Deprecated status, there was a period of approximately five months between IANA's change (2025-05-12) and the publication of RFC 9864 (October 2025). Similarly, for the none and RSA1_5 draft, IANA's implementation requirements could change before the draft is published as an RFC, should the IESG approve it. This article does not attempt to predict those dates.

Why the Revised JWT BCP Is Waiting

IESG approval is not the publication of an RFC. Approved documents are placed in the RFC Editor's queue, and remain there if a required normative reference is still outstanding. The following diagram illustrates the relationships between five documents as of the verification date.

• Revised JWT BCP (draft-ietf-oauth-rfc8725bis-10) — Approved by the IESG on 2026-08-24. It is currently in the RFC Editor's queue with a status of blocked, and the normative reference draft-ietf-jose-deprecate-none-rsa15 is NOT-RECEIVED. The eighth change listed in Appendix A of the revised document is that it normatively references this draft, requires an explicit opt-in from the caller to use none JWTs (MUST), and deprecates the RSA-PKCS1 v1.5 algorithms (§3.2 states the target as the RSA-PKCS1 v1.5 encryption algorithms). The draft's header includes the statement Obsoletes: 8725, but as of the verification date, RFC 8725 has not been replaced.
• The none and RSA1_5 draft (draft-ietf-jose-deprecate-none-rsa15-06) — Currently in the IETF Last Call phase, with a deadline of 2026-10-09. The IESG has not yet approved it, and it is not in the RFC Editor's queue.
• Draft using HPKE in JWE (draft-ietf-jose-hpke-encrypt-22) — Approved by the IESG on 2026-09-24, and IANA registered its values on 2026-09-29. It is currently in the RFC Editor's queue with a status of blocked, and the normative reference draft-ietf-hpke-hpke is NOT-RECEIVED. draft-ietf-hpke-hpke has been in IESG Evaluation since 2026-09-26.
• Draft updating RFC 7523, etc. (draft-ietf-oauth-rfc7523bis-11) — Approved by the IESG on 2026-04-30. Its status in the RFC Editor's queue is second_editor, and it is not currently awaiting any other documents.

The revised JWT BCP is an OAuth Working Group document, and the document it waits for is a JOSE Working Group document. The revised version normatively references the none and RSA1_5 draft, and therefore, while that reference stays normative, will not become an RFC before that draft does.

What RFC 8725 Asks the Receiver to Check

RFC 8725 §3 outlines best practices for both JWT creators and receivers, divided into 12 items. The revised draft (version -10) adds three items, bringing the total to 15, and modifies the heading for §3.10. The following table lists these headings. A dash (—) indicates that a particular item is not covered in RFC 8725.

Section	RFC 8725 (2020-02)	draft-ietf-oauth-rfc8725bis-10
3.1	Perform Algorithm Verification	Perform Algorithm Verification
3.2	Use Appropriate Algorithms	Use Appropriate Algorithms
3.3	Validate All Cryptographic Operations	Validate All Cryptographic Operations
3.4	Validate Cryptographic Inputs	Validate Cryptographic Inputs
3.5	Ensure Cryptographic Keys Have Sufficient Entropy	Ensure Cryptographic Keys Have Sufficient Entropy
3.6	Avoid Compression of Encryption Inputs	Avoid Compression of Encryption Inputs
3.7	Use UTF-8	Use UTF-8
3.8	Validate Issuer and Subject	Validate Issuer and Subject
3.9	Use and Validate Audience	Use and Validate Audience
3.10	Do Not Trust Received Claims	Carefully Evaluate Received Claims
3.11	Use Explicit Typing	Use Explicit Typing
3.12	Use Mutually Exclusive Validation Rules for Different Kinds of JWTs	Use Mutually Exclusive Validation Rules for Different Kinds of JWTs
3.13	—	Limit Hash Iteration Count
3.14	—	Check JWT Format Type
3.15	—	Limit JWE Decompression Size

The central point for the receiver is §3.1. The caller, not the token header, determines which algorithms can be used. RFC 8725 states that libraries MUST NOT use algorithms outside of that set, and it requires verifying that the header's alg value matches the actual algorithm being used, as well as ensuring that a single key is used with only one algorithm. Section 6.3 of AWS IAM Outbound Identity Federation - Issuing Short-Lived Tokens from AWS to External Services covers how a verifier of JWTs that AWS issues to external services writes this, as an example in which the verifier passes the algorithm list instead of reading it from the token. Section 3.8 requires that if a JWT includes the iss claim, the receiver must verify that the cryptographic key belongs to the issuer. If the JWT includes the sub claim, the receiver must verify that the subject is correct. Section 3.9 addresses scenarios where a single issuer may issue JWTs to multiple receivers, requiring that the JWT include the aud claim, which the receiver must then verify. In Appendix A, the revised draft lists eight changes: the handling of upper and lower case in alg values, confusion between encryption and signatures, an upper limit on PBES2 iteration counts, JWT format confusion, JWE compression, explicit typing, treating kid, jku, and x5u as input an attacker may control, and the handling of none and RSA-PKCS1 v1.5.

JWT on AWS

This article does not cover which alg values AWS JWT endpoints accept. JWT Signing Algorithms on AWS Endpoints covers AWS endpoints side by side and uses this article's terms for the status of alg values. The relationship between IAM OIDC identity providers and signature algorithms is discussed in Sections 4.2 and 5.5 of AWS IAM Inbound Workload Federation - IAM Roles Anywhere, OIDC, and SPIFFE Converging on One Trust Policy Condition.

To view the alg value of your token, you can display the header using the JWT Decoder Tool. This tool displays the header and payload but does not verify the signature.

Frequently Asked Questions about JWT and JOSE Standards History

This section answers common questions about the JWT and JOSE standards, drawing on the information presented in this article. The information provided is current as of 2026-10-05.

Is the none algorithm deprecated?

As of 2026-10-05, the none algorithm is not yet Deprecated. The IANA registry's implementation requirements for none are currently marked as Optional. The draft specification draft-ietf-jose-deprecate-none-rsa15 (-06), which proposes making none Deprecated, entered the IETF Last Call phase on 2026-09-25, with a deadline of 2026-10-09. However, the IESG has not yet approved it. The revised JWT BCP draft (-10), which the IESG approved on 2026-08-24, already says in §3.2 that none is deprecated by draft-ietf-jose-deprecate-none-rsa15, but the revised BCP is not yet an RFC, and the IANA entry has not changed. Nevertheless, the requirement to not accept JWTs using the none algorithm by default has been in place since 2015. RFC 7518 §3.6 states Implementations MUST NOT accept Unsecured JWSs by default., and RFC 8725 states that JWT libraries SHOULD NOT accept JWTs using the none algorithm unless explicitly requested by the caller. If draft-ietf-jose-deprecate-none-rsa15 is approved, the IANA implementation requirements could change before a corresponding RFC is published.

Should I write EdDSA or Ed25519 in the alg header?

For new deployments, use Ed25519 or Ed448. According to the IANA registry, EdDSA has been marked as Deprecated since 2025-05-12, while Ed25519 and Ed448 are listed as Optional. RFC 9864 defines that new deployments should use alternative identifiers (SHOULD). The revised JWT BCP draft (-10) also recommends (SHOULD) using Ed25519 over EdDSA when negotiating and configuring algorithms, except when there is a need for the older identifier for backward compatibility. Being marked as Deprecated does not prohibit its use. The definition in RFC 9864 allows for exceptions to this recommendation in cases where migration is not possible due to documented operational or regulatory requirements. Note that Ed25519, when used in the crv field of a JWK, has been in a registry as a curve name since 2016 (IANA record date: 2016-08-22). It is in a different registry from the alg value Ed25519.

Does deprecating RSA1_5 affect RS256?

Deprecating RSA1_5 does not affect RS256. RSA1_5 is a key management value for JWE, while RS256 is a signature value for JWS. The none and RSA1_5 draft explicitly states that RSA signatures using PKCS#1 version 1.5 padding (including RS256, RS384, and RS512) are unchanged by the draft and can still be used. Furthermore, IANA's registry still lists RS256 as Recommended.

Has RFC 8725 been replaced?

As of 2026-10-05, it has not been replaced. The IESG approved a revised version, draft-ietf-oauth-rfc8725bis (-10), on 2026-08-24. However, it is currently marked as blocked in the RFC Editor's queue, and the normative reference draft-ietf-jose-deprecate-none-rsa15 has not yet been received. The phrase Obsoletes: 8725 appears in the draft's header, but until an RFC is published, RFC 8725 (BCP 225) remains the current BCP.

Why does the IANA registry list algorithm values whose RFC has not been published?

The IANA JOSE registry allows the registration of values even before the corresponding RFC is published. RFC 7518 §7 states to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. In the examples this article checked, ES256K was registered by referencing a draft prior to IESG approval. ML-DSA was added as a temporary registration with an expiration date, before the IETF Last Call process (this article did not check which procedure was used for this registration). EdDSA was marked as Deprecated on the same day the IESG approved the RFC 9864 draft, and the values for HPKE were registered five days after the IESG approved the HPKE draft. As of 2026-10-05, the reference for the HPKE values points to RFC-ietf-jose-hpke-encrypt-22, which does not yet have an RFC number.

When did JWT become a standard?

The dates vary depending on the stage. The initial individual draft was dated 2010-12-28; it became an OAuth Working Group draft on 2012-05-23; the IETF Last Call began on 2014-08-20; IESG approval occurred on 2015-01-13 (UTC – Datatracker's history page lists 2015-01-12); and RFC 7519 was published in May 2015. RFC 7519 has a status of "Proposed Standard" and is not an "Internet Standard." The related RFCs 7515 through 7518, covering JWS, JWE, JWK, and JWA, were also published in May 2015 as "Proposed Standards."

Summary

This article lists dates from the initial JWT draft (2010-12-28) through the IETF Last Call (2026-09-25 to 2026-10-09) of the draft that would make none and RSA1_5 Deprecated, based on records from the IETF Datatracker, RFC Editor, and IANA.

There is not one date on which a standard came into being. JWT's development spanned nearly four and a half years, from the individual draft to RFC 7519. During that time, it went through stages including Working Group drafts, the IETF Last Call, and IESG approval. The timeline states, row by row, which stage each date belongs to.

The status of values for the alg parameter is managed by the IANA registry, and IANA sometimes moves without waiting for RFC publication. In the examples this article checked, the IANA registry consistently moved ahead of RFC publication. For ES256K and ML-DSA (which had a time-limited temporary registration), the registry updated before IESG approval, and EdDSA became Deprecated on the day the IESG approved the RFC 9864 draft. RFC 7518 §7 allows Designated Experts to approve registration before publication (this article did not check which procedure was used for the ML-DSA registration).

EdDSA is Deprecated, and its replacements are Ed25519 and Ed448. The IANA registry made this change on 2025-05-12, and the corresponding RFC 9864 was published in October 2025. Being Deprecated does not mean that usage is prohibited; rather, it indicates that new deployments should use alternative identifiers.

none and RSA1_5 are not yet Deprecated as of the verification date. In the IANA registry, they are still listed as Optional and Recommended-, while the draft that would designate them as Deprecated is currently undergoing the IETF Last Call. Signatures like RS256 are not the target of this draft. The approved revised JWT BCP draft (-10) already says in §3.2 that none is deprecated by the none and RSA1_5 draft.

The revised JWT BCP has been approved, but has not yet been published as an RFC. Although the IESG approved it on 2026-08-24, it is held in the RFC Editor queue, waiting for the normatively referenced none and RSA1_5 draft. A draft utilizing HPKE in JWE is also waiting for draft-ietf-hpke-hpke.

⚠ Things will move after the verification date. The IETF Last Call for the none and RSA1_5 draft will close on 2026-10-09. The IESG's subsequent decision may change the state of the IANA registry and the RFC Editor queue. All information is current as of 2026-10-05.

This timeline will be updated as the JWT and JOSE standards continue to evolve.

In addition, there are related history-and-timeline articles on this site, so please have a look if you are interested.

• Post-Quantum Cryptography Standardization Timeline and Migration on AWS - From Algorithm Selection to Service Support
• SSH and OpenSSH Algorithm History and Timeline - From SSH-1 to Post-Quantum Key Exchange, and How Algorithms Enter and Leave the Defaults
• TLS Certificate Ecosystem History and Timeline - Certificate Authorities, Automation, and Shrinking Certificate Lifetimes
• Major Security Vulnerabilities History and Timeline - Disclosure, Impact, and the Response Practices They Changed
• Email Authentication History and Timeline - SPF, DKIM, DMARC, and BIMI
• Cryptography Glossary for Engineers - AES, RSA, ECDSA, HKDF, Envelope Encryption, and TLS Explained

References:
Tech Blog with curated related content