Adoption records

JOSE signatures and canonical JSON

Version pinned

• RFC 7515, JSON Web Signature, May 2015, Proposed Standard.
• RFC 7517, JSON Web Key, May 2015, Proposed Standard.
• RFC 7518, JSON Web Algorithms, May 2015, Proposed Standard, updated by RFC 9864 (October 2025, Proposed Standard).
• RFC 7638, JSON Web Key (JWK) Thumbprint, September 2015, Proposed Standard.
• RFC 7493, The I-JSON Message Format, March 2015, Proposed Standard.
• RFC 8785, JSON Canonicalization Scheme, June 2020, Informational.
• OpenID Federation 1.0, 17 February 2026, Final: only the JWK parameter exp that its section 8.7.2 registers in the IANA JSON Web Key Parameters registry.

What is taken

• Detached compact JWS (RFC 7515 Appendix F) over UTF-8 RFC 8785 canonical JSON of the object without proof, with ES256 and a kid resolved only against the issuer's trusted key set (A5.4).
• JWK sets for publishing verification keys (A3.3, A5.4, A11.1).
• RFC 7638 SHA-256 thumbprints as key IDs, so a key ID names one key (A5.4, A9), as OpenID Federation 1.0 also recommends for its keys.
• The registered JWK parameter exp, in whole seconds since the epoch, as a published key's retirement time: what the key signed before it still verifies, and anything dated at or after it is rejected (A5.4, A9).
• I-JSON: signed text with a lone surrogate, a noncharacter, a number with more magnitude or precision than binary64 provides, or a repeated member name is rejected before canonicalisation (A5.4).
• RFC 8785 canonicalisation for handle and alias derivation input (A3.2), response hashes (A9) and statement hashes (A7.2).

Why

Signed, canonical objects let a recipient or the person verify what was disclosed offline with standard libraries. AGENTS.md rule 9 forbids hand-rolled cryptography or canonicalisation.

What is extended

The signed object shapes and their protected typ values are Open Personal Context's: autonym-disclosure+jws, autonym-receipt+jws, autonym-purge+jwt, autonym-purge-ack+jws and autonym-export+jws. One spelling is fixed for instants in signed objects (A5.4).

What is replaced or not used

Unencoded-payload mode, alg:none, critical headers, any protected header member other than alg, kid and typ, and key URLs or keys supplied by the object or its header are rejected (A5.4). Only ES256 is accepted. Of the key lifetime parameters OpenID Federation 1.0 registers, only exp is used; a key carrying nbf, iat or revoked is not used to verify, and OpenID Federation's historical keys endpoint and signed JWK set are not used: retired keys stay in the ordinary key set.

Deviations

RFC 8785 is Informational, not standards track; it is adopted because it is the maintained canonicalisation scheme JOSE libraries implement. RFC 9864 updates RFC 7518 with fully specified algorithm identifiers and changes nothing for ES256: it names the JOSE ES256 as already fully specified (P-256 with SHA-256), defines new fully specified identifiers only for COSE ECDSA and for EdDSA, and deprecates only the polymorphic JOSE EdDSA. Its recommendation that a JWK carry alg, so that a key is used with one algorithm, is why each published key carries alg:ES256.

Conformance checks

SIGN-01, LOG-01, LOG-02, KEY-01 and, for the signed purge instruction and acknowledgement, PURGE-01 in the conformance manifest. SIGN-01 has library evidence from the reference verifier's tests. The published test vectors give the RFC 8785 canonical bytes, the detached JWS of each signed object with its keys, and the failures A5.4 rejects; the reference implementation checks them with its own verifier and independently with Python jwcrypto and rfc8785. KEY-01 has integration evidence from the reference implementation's key store, tested against a real database. Runtime evidence for the others is pending.

References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.