Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
Extracted elements (20)
The nonce/challenge mechanism and the means of communicating the signed nonce are intentionally not specified in this document, because different protocols communicate this information in different ways. Applications are expected to define these interactions.
The symmetric key PoP mechanism is conceptually similar to Kerberos tickets: the issuer embeds an encrypted copy of the symmetric key in the JWT confirmation claim, and the recipient decrypts it to obtain the key used to verify subsequent communications with the presenter.
All confirmation members that are not understood by implementations MUST be ignored, in the absence of application-specific requirements to process them.
At least one of the "sub" and "iss" claims MUST be present in the JWT to identify the presenter.
Confirmation method names registered in the JWT Confirmation Methods registry SHOULD be short, not exceeding eight characters without a compelling reason, and are case sensitive. Names may not match other registered names in a case-insensitive manner unless Designated Experts approve an exception.
If the "jwk" member is used for a symmetric key, the JWT MUST be encrypted so the key is not revealed to unintended parties; if the JWT is not encrypted, the symmetric key MUST be encrypted as a JWE.
The "cnf" claim value MUST represent only a single proof-of-possession key; thus, at most one of the "jwk", "jwe", and "jku" confirmation values may be present.
When using the "jku" member, the protocol used to acquire the JWK Set resource MUST provide integrity protection, the HTTP GET MUST use TLS, and the server identity MUST be validated per RFC 6125 Section 6.
A PoP key can act as a correlation handle if the same key is used with multiple parties. For privacy, it is recommended that different proof-of-possession keys be used when interacting with different parties.
The "cnf" (confirmation) claim is a JWT claim whose value is a JSON object containing members that identify the proof-of-possession key. By including it, the issuer declares that the presenter possesses a particular key that the recipient can cryptographically confirm.
The "jku" confirmation member is a URI pointing to a JWK Set resource containing the PoP public key. If multiple keys exist in the referenced set, a "kid" member MUST also be included identifying which key is the PoP key.
The "jwe" confirmation member holds a symmetric PoP key encrypted to the recipient using JWE Compact Serialization. The UTF-8 encoding of the JWK representing the symmetric key is used as the JWE Plaintext.
The "jwk" confirmation member holds a JSON Web Key representing the asymmetric public key corresponding to the private key held by the presenter. It MUST contain the required key members for that JWK key type and MAY include optional members like "kid".
The "kid" confirmation member identifies the PoP key by a Key ID string instead of conveying the key directly. The recipient must be able to obtain the key using this identifier. Content of "kid" is application specific; a JWK Thumbprint value may be used.
This specification establishes the IANA "JWT Confirmation Methods" registry for JWT "cnf" member values, with initial entries: "jwk" (JSON Web Key Representing Public Key), "jwe" (Encrypted JSON Web Key), "kid" (Key Identifier), and "jku" (JWK Set URL). Registration requires Specification Required review.
This specification registers the "cnf" claim in the IANA "JSON Web Token Claims" registry. Claim description: Confirmation. Specification: Section 3.1 of RFC 7800.
Applications that require the PoP keys in the "cnf" claim to be understood and processed must ensure implementations are present, since a recipient that does not understand "cnf" will not enforce the proof-of-possession requirement.
Applications utilizing proof of possession should also utilize audience restriction (JWT "aud" claim) since they provide complementary protections: PoP rejects messages from unauthorized senders, while audience restriction rejects messages intended for different recipients.
Possessing a PoP key is only valuable if the key is kept secret. Appropriate means must be used to prevent unintended parties from learning private or symmetric key values. JWT integrity and data origin authentication are required for all JWTs carrying PoP information.
Proof of possession via encrypted symmetric secrets is subject to replay attacks. This can be mitigated by using signed nonces or challenges (with a distinct nonce per interaction) or by deriving sub-keys specific to each PoP demonstration instance.