IETF · May 2015
RFC 7519
M. Jones, J. Bradley, N. Sakimura
Every modern agent-auth proposal — AAuth (aa-agent+jwt, aa-auth+jwt), WIMSE WIT, RFC 9068 access tokens, ID-JAG, transaction tokens — is a JWT profile. If you cannot validate iss, aud, typ, and cnf, you cannot implement the landscape.
At a glance
Actors
01
RFC 7519 is a container: header, claims, optional signature or encryption. It does not decide whether you are looking at identity, authorization, or a workload credential. Agent stacks fail when they treat 'it is a JWT' as a complete protocol.
Every modern agent-auth proposal — AAuth (aa-agent+jwt, aa-auth+jwt), WIMSE WIT (wit+jwt), RFC 9068 access tokens (at+jwt), ID Tokens, ID-JAG, transaction tokens, DPoP proofs — is a JWT profile. If you cannot validate iss, aud, typ, alg, exp, and cnf, you cannot implement the landscape.
02
The issuer's signing key is the trust anchor. The audience is who may accept the token. The subject is who the token is about — which might be a user, a client, or a workload, depending on the profile. Never let the presenter choose iss/aud for you.
03
JWS compact serialization is what almost all OAuth/OIDC profiles use. Validate signature against an allow-listed alg (never none, never confuse alg with the payload). Check typ where the profile defines one (RFC 8725). Check exp, nbf, iat, iss, aud as the profile requires. Nested JWTs (JWE, or assertions inside assertions) need explicit policy — see 7523bis work.
04
Flow 1
Parse compact JWS. Reject unencrypted tokens if the profile required JWE (rare in this cluster).
Check typ and alg against the profile allow-list.
Verify signature with keys for that issuer (JWKS, trust anchors — profile says which, and some profiles forbid fetching JWKS from iss alone).
Check exp/nbf, iss, aud, and profile claims (client_id, cnf, wth, …).
Only then apply authorization policy.
05
A container. An ID Token is identity; a JWT access token is authorization; a WIT or AAuth agent token is identity bound to a key. The profile, not RFC 7519, decides the layer.
06
RFC 9068 profiles 7519 as typ at+jwt with mandatory aud.
ID Token is a 7519 JWT with OIDC validation rules (nonce, at_hash, aud=client_id).
Multiple typed JWTs (aa-*). typ is load-bearing.
WIT is typ wit+jwt with cnf.jwk; must not be used as bearer.
Often inputs and outputs JWTs; act is a 7519 claim defined by 8693.
07
Follow RFC 8725 (and 8725bis in the RFC Editor queue in 2026). Allow-list algorithms.
Accepting a token because the signature is valid is how MCP servers get calendar tokens. Check aud.
If typ is absent, do not guess. Cross-profile confusion (ID Token as access token, person token as auth token) is the recurring agent bug.
08
RFC 7519, May 2015. Stable format. Profiles and RFC 8725 JWT BCP are what you actually implement. https://www.rfc-editor.org/rfc/rfc7519.html
Never treat an unprofiled JWT as an access token. Follow RFC 8725 JWT BCP (and the 2026 rfc8725bis work in the RFC Editor queue). Check typ, alg allow-lists, and audience.