PASSporT: Personal Assertion Token
Extracted elements (27)
Deterministic JSON serialization is required because JSON is inherently non-deterministic (arbitrary key ordering and whitespace). PASSporT adopts rules based on JWK Thumbprint (RFC 7638, Section 3 Step 1) to ensure digital signature verification works consistently across implementations.
PASSporT is intentionally decoupled from any specific signaling protocol (e.g., SIP) so that identity assertion can be implemented flexibly across different application protocols and multi-hop interconnection scenarios. Protocol-specific usage guidance is delegated to separate documents such as RFC 8224.
Using protocols that carry the compact form of PASSporT MUST use only mandatory extensions signaled with "ppt" because optional claims in compact form cannot be reconstructed by relying parties, making the token unverifiable.
A PASSporT object MUST contain exactly one "orig" claim with exactly one identity claim object, and a "dest" claim with at least one identity claim object. Both claims represent identities as either "tn" (telephone number) or "uri" types.
A using protocol that carries the compact form of PASSporT MUST be accompanied by a specification describing how the header and claims objects can be reconstructed from the signaling protocol.
If the "dest" claim value array contains both "tn" and "uri" claim names, the "tn" array MUST be listed first and "uri" second. Within each array, identity strings SHOULD be in lexicographical order.
Implementations MUST support ES256 (ECDSA using P-256 and SHA-256) for creation and verification of PASSporT digital signatures. Implementations MAY support other algorithms from the "JSON Web Signature and Encryption Algorithms" registry.
Implementations of PASSporT digital signatures using ES256 SHOULD use the deterministic ECDSA as defined in RFC 6979 to avoid risks associated with weak random number generation during signing.
PASSporT extension specifications MUST explicitly specify what claims they include beyond the base set, the order they appear, and any further information needed to implement the extension. Claims may only be appended, never removed or reordered.
PASSporT MUST use the JWS Protected Header. The lexicographic ordering, whitespace rules, and deterministic JSON serialization defined in this document MUST be followed for the JWS Payload and JWS Protected Header.
Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt" value. Implementations MUST support the baseline claims defined in Section 5.2 and MAY support extended claims.
The JSON representation of the JWS Protected Header and JWS Payload MUST follow deterministic serialization rules: no whitespace, keys in lexicographic Unicode order, literal values lowercase, numbers encoded as integers, rules applied recursively.
The "mky" claim array MUST be constructed by sorting the SDP fingerprint lines based on UTF-8 encoding of the concatenation of "alg" and "dig" values, then encoding each as a JSON object with "alg" first and "dig" second.
The PASSporT payload MUST include the "iat" (Issued At) JWT claim set to the date and time of origination of the personal communications. This is required for protecting against replay and cut-and-paste attacks.
The "typ" (Type) JOSE Header Parameter in a PASSporT MUST be the string "passport", signifying that the encoded token is a JWT of type passport.
When the originating or destination identity is a telephone number, the claim name MUST be "tn" and the value MUST be canonicalized according to the procedures in RFC 8224, Section 8.3.
PASSporT is a JSON Web Token (JWT) signed as a JSON Web Signature (JWS) that cryptographically asserts the originating and destination identities of a personal communications session. It uses X.509-based certificates for signing authority and is designed to be transported over insecure channels while remaining verifiable at the destination.
The optional "mky" (Media Key) claim binds SDP media security key fingerprints (from "a=fingerprint" attributes) to the PASSporT identity assertions. It is a JSON array of objects each containing "alg" and "dig" fields, where "dig" is the hexadecimal hash value without colons.
The "ppt" (PASSporT) JOSE Header Parameter signals a mandatory PASSporT extension, associating a named extension type with required claims and behaviors. All values of "ppt" must be defined in a specification linking the value to required claims.
The "x5u" JOSE Header Parameter MUST contain a URI referencing the X.509 public key certificate or certificate chain corresponding to the key used to sign the PASSporT. This is typically an HTTPS or DNSSEC resource with integrity protection.
RFC 8225 creates a new "PASSporT Extensions" IANA registry for "ppt" parameter values with Specification Required policy. Each entry must contain the "ppt" value name and the specification in which it is described.
RFC 8225 registers the "application/passport" media type in the IANA Media Types registry. Values are encoded as base64url-encoded values separated by period characters, indicating content is a PASSporT-defined JWT.
RFC 8225 registers the "ppt" header parameter in the "JSON Web Signature and Encryption Header Parameters" IANA registry, with usage location JWS, to serve as the PASSporT extension identifier.
RFC 8225 registers three new JWT claims in the "JSON Web Token Claims" IANA registry: "orig" (Originating Identity String), "dest" (Destination Identity String), and "mky" (Media Key Fingerprint String).
PASSporT alone does not constitute full non-repudiation of the asserted identity. When a service provider signs on behalf of a user, the provider MUST have an authenticated and secure relationship with the end user or device. Verifiers must check that the signer is authoritative via application-specific trust anchors.
PASSporTs SHOULD only be sent with application-level protocol information corresponding to the required token fields. The "iat" claim mitigates replay attacks by binding the token to the origination time, and the "dest" claim restricts reuse to the intended recipient only.
The compact form of PASSporT omits the header and payload, consisting of two periods followed by the BASE64URL-encoded JWS Signature: ".." || BASE64URL(JWS Signature). The receiving party must reconstruct the header and claims from signaling protocol context to verify the signature.