JOSE

JOSE is the family of IETF specifications behind every signed or encrypted JSON token in the API economy. Most people meet it as a JWT in an Authorization header, but the JWT is only the most visible piece of a framework for protecting JSON with signatures and encryption, and for describing the keys and algorithms that do it.

• JWS (RFC 7515) - Integrity-protected content: a signature or MAC over a payload, so the receiver can tell it hasn’t been altered.
• JWE (RFC 7516) - Encrypted content, readable only by the intended recipient.
• JWK (RFC 7517) - A JSON representation of the keys themselves, which is what a jwks_uri publishes.
• JWA (RFC 7518) - The registry of algorithms the others reference, from RS256 to ES256 to the encryption algorithms.
• JWT (RFC 7519) - Compact claims, carried as a JWS or a JWE.
• Instructions travel with the data - A JOSE object has a protected header that says how it was built (which algorithm, which key, what type), next to the payload that carries the content. Security profiles like FAPI 2.0 work largely by constraining those instructions — allowing only certain algorithms — rather than the data.

That split between instructions and content is the thing API descriptions struggle with. A JSON Schema can validate the claims inside a token, but it can’t say which algorithm signed it or how to verify it. The OpenAPI community is working through how to describe JOSE content properly, treating it as a media type with its own handling, the way multipart and form data already are. With the IETF working group active again on JSON Web Proofs and post-quantum algorithms, the family is still moving, and describing it well in our API contracts matters more as agents start presenting and verifying credentials on our behalf.

Industry: Security