Standards
This page describes polyjose 0.1.0 as designed. The library is in development and not published yet.
polyjose 0.1.0 is designed to implement the JOSE specifications below. Algorithm and parameter names follow the IANA JOSE registries, and the Algorithms page lists every algorithm with its RFC section.
| RFC | Title | What polyjose implements |
|---|---|---|
| RFC 7515 | JSON Web Signature (JWS) | Compact, flattened JSON and general JSON serializations, multiple signatures, detached payloads and crit. Verification takes an explicit algorithm allow-list. |
| RFC 7516 | JSON Web Encryption (JWE) | Compact, flattened JSON and general JSON serializations, multiple recipients and additional authenticated data. Decryption takes explicit alg and enc allow-lists. zip (DEF) is available in Rust with the deflate feature. |
| RFC 7517 | JSON Web Key (JWK) | JWKs and JWK Sets with key types oct, RSA (public keys only), EC and OKP, and the use, key_ops, alg and kid members. x5c and x5t are carried but not validated as X.509. |
| RFC 7518 | JSON Web Algorithms (JWA) | Every algorithm marked Required, and the others listed on the Algorithms page, with the exceptions stated there. Updated by RFC 9864. |
| RFC 7519 | JSON Web Token (JWT) | Issuing and validating signed JWTs (exp, nbf, iat, iss, sub, aud, jti), and nested JWTs that are signed and then encrypted. |
| RFC 7520 | Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) | Its examples are test vectors for the algorithms polyjose implements. |
| RFC 7638 | JSON Web Key (JWK) Thumbprint | Thumbprints with SHA-256, SHA-384 or SHA-512. SHA-1 is not offered. |
| RFC 7797 | JSON Web Signature (JWS) Unencoded Payload Option | b64: false, which must be listed in crit. JWTs never use it. |
| RFC 8037 | CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) | The OKP key type with Ed25519 signatures (EdDSA) and X25519 key agreement (ECDH-ES). Ed448 and X448 are not offered. Updated by RFC 9864. |
| RFC 8725 | JSON Web Token Best Current Practices | The default validation policy: explicit allow-lists, no none, keys bound to their algorithm, exp required, audience and type checks. |
| RFC 8812 | CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms | Its JOSE registrations: the ES256K algorithm and the secp256k1 curve. |
| RFC 9068 | JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens | The at+jwt type and an access-token validation profile. |
| RFC 9278 | JWK Thumbprint URI | urn:ietf:params:oauth:jwk-thumbprint URIs. |
| RFC 9864 | Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) | The Ed25519 algorithm, recommended for new tokens. EdDSA, which it deprecates, stays supported for existing tokens. |
Updates by RFC 9864
Section titled “Updates by RFC 9864”RFC 7518 and RFC 8037 are updated by RFC 9864. It registers fully-specified algorithm names, such as Ed25519, and sets the older EdDSA identifier to Deprecated. polyjose supports both: use Ed25519 for new tokens, and EdDSA for tokens and peers that already use it.
Erratum 8060 on RFC 7519
Section titled “Erratum 8060 on RFC 7519”Erratum 8060 on RFC 7519 §7.2 has the status Verified. Step 5 of JWT validation checks the header by the JWS or JWE rules, so header parameters that are not understood are ignored unless crit lists them. polyjose follows the corrected text.
Duplicate member names
Section titled “Duplicate member names”RFC 7515 §4 and RFC 7519 §4 let a parser either reject JSON with duplicate member names or keep only the last one. polyjose always rejects duplicates, in headers, claims, JWKs and every other JSON it reads, with InvalidJson. Two parsers that keep different duplicates could otherwise read the same token differently.