Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
Extracted elements (13)
The compact form of PASSporT is explicitly not specified for use in SHAKEN, as noted in the overview. This constrains implementations to the full-form PASSporT to ensure all claim fields are present and verifiable.
Three attestation levels (A, B, C) were defined to bridge the transition period where the telephone network contains both VoIP and TDM/SS7 traffic. Gateway attestation (C) accommodates calls from gateways that do not support PASSporT or STI, enabling incremental deployment.
The 'shaken' PASSporT type is intended for use within an RFC 3324 trust domain, and SHAKEN PASSporTs are expected to be stripped before calls exit that trust domain. This limits exposure of the 'origid' and attestation information beyond the originating SP's network.
The use of 'shaken' PASSporT type and the 'attest' and 'origid' claims for SIP is formally defined in ATIS-1000074 using the SIP Identity header field from RFC 8224. RFC 8588 specifies only the JWT claim definitions, deferring SIP-layer usage rules to ATIS-1000074.
Claim keys in the PASSporT payload MUST follow the lexicographic ordering rules of Section 9 of RFC 8225. In a 'shaken' PASSporT, the required order is: attest, dest, iat, orig, origid.
Implementations are RECOMMENDED to generate a unique 'origid' value per call so that only the generator can correlate two values to the same or different network elements. Reusing a common 'origid' across calls risks exposing correlation patterns, potentially revealing geographic location or device-level information to recipients or analytics systems.
The 'attest' claim indicates the service provider's level of confidence in the calling identity. It MUST be one of three string values: 'A' (Full Attestation), 'B' (Partial Attestation), or 'C' (Gateway Attestation), as defined in ATIS-1000074.
The 'origid' claim is a UUID (as defined in RFC 4122) generated by the originating telephone service provider to uniquely identify the network element or origin point of a call. It supports traceback for enforcement against illegitimate calls.
The 'shaken' PASSporT extension defines two new JWT claims: 'attest' (attestation level) and 'origid' (originating identifier). These extend the base PASSporT claims to convey service provider attestation and call origin information within the SHAKEN framework.
IANA added a new entry 'shaken' to the 'Personal Assertion Token (PASSporT) Extensions' registry, designating RFC 8588 as the specification document.
IANA added two new claims to the 'JSON Web Token Claims' registry: 'attest' (Attestation level as defined in SHAKEN framework) and 'origid' (Originating Identifier as defined in SHAKEN framework), both with IESG as change controller.
The 'attest' and 'origid' claims are not validated against SIP message fields (unlike 'dest', 'orig', and 'iat'). They carry additional information from signer to consumer and share the same integrity protection and non-repudiation properties as the base PASSporT claims.
The 'shaken' PASSporT uses a JWS Protected Header with fields 'alg' (e.g., 'ES256'), 'typ' ('passport'), 'ppt' ('shaken'), and 'x5u' (certificate URL). The payload contains 'attest', 'dest', 'iat', 'orig', and 'origid' in lexicographic order.