RFC 8225

🎀 RFC 8225: PASSporT (Personal Assertion Token) 🎀

okay bestie, grab your iced matcha because this one is about proving WHO is calling you 📞✨ It's an IETF Standards Track doc (so it's a real, official protocol, not vibes 💅), and it's from February 2018. It was written by C. Wendt of Comcast and J. Peterson of Neustar Inc. 🌸 It doesn't obsolete or update any other RFCs, so it's a clean, fresh start 🦋 and its status is "Standards Track" with ISSN 2070-1721. The copyright is IETF Trust, 2018 💜

Abstract

This doc is literally the blueprint for making a little signed token that proves the originating identity of a call or message. That identity can be a telephone number, a URI, whatever. The token gets cryptographically signed so that the destination can trust the identity info, even if the signature travels over an insecure channel 🔐 It's built for personal communications over IP and other multi-hop setups, where the two parties don't have a direct trusted relationship. Main character energy for sure 👑

Status of This Memo

This is an Internet Standards Track document 🔥 It's a product of the IETF, it represents community consensus, got public review, and was approved by the IESG. If you want more on Internet Standards, check Section 2 of RFC 7841 🌈 Errata and feedback live at https://www.rfc-editor.org/info/rfc8225 ✨

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 💅 This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as of the publication date. Read those carefully, bestie, they spell out your rights 🙈 Any Code Components pulled from this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and come without warranty 🫶

Table of Contents

1. Introduction ....................................................4
2. Terminology .....................................................4
3. PASSporT Overview ...............................................5
4. PASSporT Header .................................................6
   4.1. "typ" (Type) Header Parameter ..............................6
   4.2. "alg" (Algorithm) Header Parameter .........................6
   4.3. "x5u" (X.509 URL) Header Parameter .........................6
   4.4. Example PASSporT Header ....................................7
5. PASSporT Payload ................................................7
   5.1. JWT-Defined Claims .........................................7
        5.1.1. "iat" (Issued At) Claim .............................7
   5.2. PASSporT-Specific Claims ...................................8
        5.2.1. Originating and Destination Identity Claims .........8
        5.2.2. "mky" (Media Key) Claim ............................10
6. PASSporT Signature .............................................11
7. Compact Form of PASSporT .......................................12
   7.1. Example Compact Form of PASSporT ..........................13
8. Extending PASSporT .............................................13
   8.1. "ppt" (PASSporT) Header Parameter .........................13
   8.2. Example Extended PASSporT Header ..........................14
   8.3. Extended PASSporT Claims ..................................14
9. Deterministic JSON Serialization ...............................15
   9.1. Example PASSporT Deterministic JSON Form ..................16
10. Security Considerations .......................................17
   10.1. Avoidance of Replay and Cut-and-Paste Attacks ............17
   10.2. Solution Considerations ..................................18
11. IANA Considerations ...........................................18
   11.1. Media Type Registration ..................................18
   11.2. Registrations in "JSON Web Token Claims" .................19
   11.3. Registration in "JSON Web Signature and
         Encryption Header Parameters" ............................20
   11.4. PASSporT Extensions Registry .............................20
12. References ....................................................20
   12.1. Normative References .....................................20
   12.2. Informative References ...................................22
Appendix A. Example ES256-Based PASSporT JWS Serialization and
            Signature .............................................23
  A.1. X.509 Private Key in PKCS #8 Format for ES256 Example ......24
  A.2. X.509 Public Key for ES256 Example .........................25
Acknowledgments ...................................................25
Authors' Addresses ................................................25

---

1. Introduction 🌸

Okay, so in today's IP-powered phone world, people are lowkey worried about whether they can trust incoming calls, video, voice, and messages [RFC7340] 😭 Phone networks let anyone fake the calling party's number, and sometimes that's for legit reasons like network features, but bad actors absolutely abuse it to trick people into thinking someone is someone they're not 💀 And this problem is spreading to all kinds of personal communications.

This doc defines a method for creating and validating a token that cryptographically verifies an originating identity (or more generally, a URI or telephone number representing the originator) 🦋 Through the extensions in Section 8, you can add other relevant info to the token too ✨ The big goal of PASSporT is a common framework for signing originating-identity info in an extensible way 💜 It's also independent of any specific call logic, so it works for end-to-end apps needing different signaling protocols or gateways between systems 🧚 Guidance specific to each signaling protocol will come in other docs about how to use and transport PASSporTs, but that is intentionally out of scope here 🙈

[RFC8224] covers how PASSporT is used inside SIP [RFC3261] to sign and verify telephone numbers and SIP URIs 📞

2. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖

3. PASSporT Overview 🦋

"JSON Web Token (JWT)" [RFC7519], "JSON Web Signature (JWS)" [RFC7515], and other related specs define a standard token format for wrapping claimed or asserted info with a digital signature using X.509-based certificates 🔏 JWT gives you JSON claims that fit originating-identity info nicely and are super easy to extend 💅 JWS gives you a way to update the methods and crypto algorithms used for the signatures 🌈

JWS defines JSON data structures in a specified canonical format for signing the JOSE Header, JWS Payload, and JWS Signature 🧩 JWT defines a set of claims as specified JSON objects that can be extended with custom keys for specific apps ✨ The next sections define the header and claims that MUST be minimally used with JWT and JWS for PASSporT 💖

PASSporT uses this token format and defines claims that carry the identity of the origination and destination of personal communications 📞 The main value asserted is the originating identity, meaning the calling party or the initiator of the session 👑 The signer of a PASSporT may or may not be the originating identity 🙃 For a given application, the PASSporT is created by an entity that's authoritative to assert the caller's identity, and that authority shows up in the certificate credentials and the signature 🔐 The PASSporT gets created and sent to the destination(s) based on the application's choice of authoritative points in the network 🌐 For example, it could be made at a device that has authenticated with a user, or at a network entity with an authenticated trust relationship with that device and user 🫶 Destination identities are the intended destination of the call, i.e., the identities being called 📱 The destination point(s) need the capability to verify the PASSporT and its signature, and the PASSporT-associated certificate is used to validate the signer's authority, generally through a certificate chain to the application's trust anchor 🦋

4. PASSporT Header 🌷

The JWS token header is a JOSE Header ([RFC7515], Section 4) that defines the type and encryption algorithm used in the token 🧁

The PASSporT header SHOULD include, at a minimum, the Header Parameters defined in the next three subsections ✨

4.1. "typ" (Type) Header Parameter

The "typ" (Type) Header Parameter is defined in JWS ([RFC7515], Section 4.1.9) to declare the media type of the complete JWS 🎀

For the PASSporT, the typ header MUST be the string "passport" 💜 This signals that the encoded token is a JWT of type "passport" 🦋

---

Part 1 of 4. Keep an eye out for Part 2, bestie, we're just getting started 🫶

4.2. "alg" (Algorithm) Header Parameter ✨

okay so the alg header parameter is borrowed straight from JWS ([RFC7515], Section 4.1.1) 💅 it's the thing that lets you say which cryptographic algorithm is doing the signing for the signature part of the JWS. the list of legit alg values lives in a registry set up by JSON Web Algorithms (JWA) ([RFC7518], Section 3.1) 🦋

now the important bit 👑 for making and checking PASSporTs and their digital signatures, implementations MUST support ES256 as defined in JWA ([RFC7518], Section 3.4). no skipping it, bestie!! 😭 other algorithms from the "JSON Web Signature and Encryption Algorithms" registry created by [RFC7518] are allowed too (implementations MAY support them) 🌸 and that registry can change later, depending on how strong crypto needs to be according to current security best practices 🔥 the must-support algorithm for PASSporTs can also get updated in future versions of this document, so keep an eye out 👀

if you're doing PASSporT signatures with ES256 like we just said, you SHOULD use the deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) if or when it's supported, for the reasons explained in [RFC6979] 🧚 this one is lowkey a strong recommendation, not a must, but it's giving "do it if you can" energy ✨

4.3. "x5u" (X.509 URL) Header Parameter 🎀

so the x5u header parameter is also from JWS ([RFC7515], Section 4.1.5) 💖 it's a URI [RFC3986] pointing at the resource with the X.509 public key certificate (or certificate chain) [RFC5280] that matches the key used to sign the JWS. generally, the definition in JWS ([RFC7515], Section 4.1.5) says this would be an HTTPS or DNSSEC resource using integrity protection 🔒 main character energy for security, periodt 💅

4.4. Example PASSporT Header 🌈

here's what a header looks like 🍓 it's got the passport type, the ES256 algorithm, and a URI for the network location of the certificate you need to validate the PASSporT signature 🫶

{
  "typ":"passport",
  "alg":"ES256",
  "x5u":"https://cert.example.org/passport.cer"
}

5. PASSporT Payload 💜

the token claims are the info that needs to be verified at the destination party 🦋 these claims follow the definition of a JWT claim ([RFC7519], Section 4) and get encoded the way the JWS Payload says ([RFC7515], Section 3) ✨

PASSporT uses a standard JWT-defined claim plus custom claims for the two parties in personal communications: the originator and the destination, which we'll get into below 👑

for PASSporT, any claim names MUST use the ASCII character set 😭 claim values, though, can have characters outside the ASCII range, as long as they follow the rules for creating a JWT Claims Set in [RFC7519], Section 7.1 🌸

5.1. JWT-Defined Claims 🎀

5.1.1. "iat" (Issued At) Claim 🕰️

the JSON claim MUST include the "iat" (Issued At) claim ([RFC7519], Section 4.1.6) 💅 so the "iat" claim SHOULD be set to the date and time the JWT was issued, and it MUST indicate the date and time the personal communications originated 🔥 the time value should be in the NumericDate format from [RFC7519], Section 2 ✨ this is there to protect the token against replay and cut-and-paste attacks, which Section 10 ("Security Considerations") explains further 🙈 seriously, read that section, it's giving "spicy" 🌶️

5.2. PASSporT-Specific Claims 🦋

5.2.1. Originating and Destination Identity Claims 💖

the originating identity and destination identity each get a claim, and both are REQUIRED for PASSporT: the "orig" and "dest" claims 🫶 wait, I can't use those words in caps unless the original does, so let me say it properly: both "orig" and "dest" MUST contain claim values that are identity claim JSON objects. the child claim name is the identity type, and the claim value is the identity string (more on those in the subsections) 💜 right now, identities can be telephone numbers or Uniform Resource Indicators (URIs) 📞

the "orig" claim is a JSON object named "orig", and its value is a JSON object for the asserted identity of the originator of the personal-communications signaling. the type is currently either "tn" or "uri" 🌸 there MUST be exactly one "orig" claim with exactly one identity claim object in a PASSporT object 👑

Note: As explained in Section 3, the originating identity represents the calling party and may or may not correspond to the authoritative signer of the token. 🙈

the "dest" claim is a JSON object named "dest" and MUST have at least one identity claim object 🔥 its value is an array with one or more identity claim JSON objects for the destination identities, currently "tn" or "uri" 🧚 if the "dest" array has both "tn" and "uri" names, the JSON object SHOULD list the "tn" array first and the "uri" array second 🍓 inside the "tn" and "uri" arrays, the identity strings SHOULD be in lexicographical order, including the scheme-specific portion of the URI characters ✨

Note: As explained in Section 3, the destination identity represents the called party and may or may not correspond to the authoritative party verifying the token signature. 💀

5.2.1.1. "tn" (Telephone Number) Identity 📞

if the originating or destination identity is a telephone number, the claim name for it MUST be "tn" 💅

the "tn" claim value is the telephone number, and it MUST be canonicalized according to the procedures in [RFC8224], Section 8.3 🌈

5.2.1.2. "uri" (URI) Identity 🌐

if any originating or destination identity is a URI as defined in [RFC3986], the claim name for it MUST be "uri", and the claim value is the URI form of the identity 🦋

5.2.1.3. Future Identity Forms 🔮

we know there may be other standard ways to represent identities later 👀 "orig" and "dest" currently support "tn" and "uri", but they could be extended to other identity types with new IANA-registered unique types ✨

5.2.1.4. Examples 🎀

here's a single originator with telephone number identity +12155551212, going to a single destination with URI identity "sip:alice@example.com" 💖

{
  "dest":{"uri":["sip:alice@example.com"]},
  "iat":1443208345,
  "orig":{"tn":"12155551212"}
}

and here's a single originator with telephone number identity +12155551212, going to multiple destination identities: telephone number identity +12125551212 plus two URI identities, "sip:alice@example.com" and "sip:bob@example.com" 🫶

{
  "dest":{
    "tn":["12125551212"],
    "uri":["sip:alice@example.com",
      "sip:bob@example.net"]
  },
  "iat":1443208345,
  "orig":{"tn":"12155551212"}
}

5.2.2. "mky" (Media Key) Claim 🔐

some protocols that use PASSporT might also want to protect media security keys delivered within their signaling, so they can bind those keys to the identities in the signaling layers 💜 the "mky" claim is an optional PASSporT claim for asserting media key fingerprints carried in the Session Description Protocol (SDP) [RFC4566] via the "a=fingerprint" attribute ([RFC4572], Section 5) 🦋 it can support a single fingerprint or multiple fingerprints in one SDP body, covering one or more media streams offered as defined in [RFC8122] ✨

the "mky" claim MUST be formatted as a JSON object with an array that includes the "alg" and "dig" claims, with the matching algorithm and hexadecimal values 👑 if there's more than one fingerprint value tied to different media streams in SDP, the fingerprint values MUST be built as a JSON array in square brackets ("[" and "]") 🌸 for the "dig" claim, the claim value MUST be the hash of the hexadecimal value without any colons 🔥

the "mky" claim is a JSON object named "mky", and its value is a JSON array in brackets. the "mky" claim value array MUST be built like this 🧚

1. take each "a=fingerprint" line carried in the SDP 🍓
2. sort the lines based on the UTF-8 [RFC3629] encoding of the concatenation of the "alg" and "dig" claim value strings 🌈
3. encode the array in the order of the sorted lines, where each "mky" array element is a JSON object with two elements for "alg" and "dig", with "alg" first and "dig" second 💖

here's an example. for an SDP offer with these fingerprint values 💅

a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:
5D:49:6B:19:E5:7C:AB:3E:4B:65:2E:7D:46:3F:54:42:CD:54:F1
a=fingerprint:sha-256 02:1A:CC:54:27:AB:EB:9C:53:3F:3E:4B:65
:2E:7D:46:3F:54:42:CD:54:F1:7A:03:A2:7D:F9:B0:7F:46:19:B2

the PASSporT Payload object would be 🫶

{
  "dest":{"uri":["sip:alice@example.com"]},
  "iat":1443208345,
  "mky":[
    {
      "alg":"sha-256",
      "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
        F17A03A27DF9B07F4619B2"
    },
    {
      "alg":"sha-256",
      "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
        AB3E4B652E7D463F5442CD54F1"
    }
  ],
  "orig":{"tn":"12155551212"}
}

6. PASSporT Signature 🔏

the signature is created the way JWS says ([RFC7515], Section 5.1, Steps 1 through 6) ✨ PASSporT MUST use the JWS Protected Header 💅 for the JWS Payload and the JWS Protected Header, the lexicographic ordering and whitespace rules in Sections 4 and 5 of this document, plus the JSON serialization rules in Section 9 of this document, MUST be followed 😭

Appendix A of this document has a detailed example of how to follow the steps to create the JWS Signature 📖

Step 7 of the JSON serialization procedure in [RFC7515], Section 5.1 is not supported for PASSporT 🚫

[RFC7515], Section 5.1, Step 8 describes how to create the final JWS Compact Serialization form of the PASSporT 🦋

7. Compact Form of PASSporT ✨

okay bestie, this is the glow-up version 💅 For a using protocol of PASSporT, the claims and the header can carry info that's redundant or just default, stuff the destination could rebuild from the signaling protocol that already carried it. So why send the same bytes twice? 🙈 A more compact form saves the bytes needed to represent the header and claims.

This spec defines that compact form, in the spirit of the one in [RFC7515], Appendix F 🦋 You drop the header and claim objects, leave two periods ("..") as placeholders, then add the PASSporT signature from Section 6. The destination then has to rebuild the header and claim objects so it can verify the signature.

To build the compact form of the PASSporT string, you MUST follow the procedure in Section 6, with one exception: [RFC7515], Section 5.1, Step 8. That step gets replaced by this construction of the compact form: ".." || BASE64URL(JWS Signature) ✨

The using protocol of the compact form of PASSporT MUST be accompanied by a specification for how the header and claims objects can be reconstructed from information in the signaling protocol being used. This is the key 🔑 without it, nobody can rebuild the missing pieces.

Note that the full form of the PASSporT, containing the entire header, payload, and signature, should also use the lexicographic ordering and whitespace serialization rules. This matters most when some using protocols, or interworking between protocols, need to switch between full and compact forms while keeping the signature intact 🫶

7.1. Example Compact Form of PASSporT

Here's the compact form of the following example token. The line breaks between periods are only there so it's readable 👀

eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
.
eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0
.
rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN
CpTzO3QfPOlckGaS6hEck7w

and it turns into this 💖

..rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1VOgFWSjHBr8Qjpjlk-cpFYpFYsojN
CpTzO3QfPOlckGaS6hEck7w

8. Extending PASSporT 🌈

okay so PASSporT only ships with the bare-minimum set of claims needed to securely assert the originating identity and back up the secure properties covered in the rest of this doc. JWT makes it super easy to add more asserted or signed info, you just add new claims 🧚 So PASSporT can grow past the base set to carry other stuff that needs asserting or validating beyond the originating identity itself, whenever that's needed.

8.1. "ppt" (PASSporT) Header Parameter

Any using protocol can extend the payload of PASSporT with extra JWT claims. JWT claims are managed by the "JSON Web Token Claims" IANA registry, as defined in [RFC7519], Section 10.1. Implementations of PASSporT MUST support the baseline claims defined in Section 5.2 and MAY support extended claims. If an extension needs a relying party to support a particular extended claim, or a set of them, in the PASSporT object, it can say so by specifying a "ppt" element for the PASSporT JOSE Header 🎀 Every value of "ppt" needs to be defined in a specification that ties the new value to its required claims and behaviors. Relying parties MUST fail to validate PASSporT objects containing an unsupported "ppt". No sneaking past it, periodt 🚫

Using protocols MUST explicitly define how they carry each claim, plus the rules for constructing the header and payload objects, on top of the lexicographical and serialization rules in this document.

Using protocols that carry the compact form of PASSporT (Section 7) instead of the full form MUST use only mandatory extensions signaled with "ppt". The reason is that if a using protocol added optional claims to a PASSporT it carried in compact form, relying parties would have no way to rebuild the token 😭 Also, using protocols that support the compact form of PASSporT MUST have some field to signal "ppt" to relying parties, because the compact form leaves out the JOSE Header.

8.2. Example Extended PASSporT Header

Here's an example header with a PASSporT extension type of "foo" 🍓

{
  "alg":"ES256",
  "ppt":"foo",
  "typ":"passport",
  "x5u":"https://tel.example.org/passport.cer"
}

8.3. Extended PASSporT Claims

Specs that define extensions to the PASSporT mechanism MUST explicitly specify which claims they include beyond the base set from this document, the order they appear in, and any other info needed to implement the extension ✨ All extensions MUST include the baseline PASSporT claim elements specified in Section 5. Claims can only be appended to the claims object, never removed or reordered 🙅‍♀️ Specifying new claims follows the baseline JWT procedures ([RFC7519], Section 10.1). Understanding an extension, or the new claims an extension defines, is optional during destination verification of the PASSporT. The creator of a PASSporT object cannot assume that destination systems will understand any given extension. When destination systems that do support an extension verify a PASSporT, that can trigger the right application-level behavior for the extension. Authors of extensions should give application developers extension-specific guidance on this point 💅

Here's an example set of extended claims. It extends the first example in Section 5.2.1.4 with "bar" as the newly defined claim 🌸

{
  "bar":"beyond all recognition"
  "dest":{"uri":["sip:alice@example.com"]},
  "iat":1443208345,
  "orig":{"tn":"12155551212"}
}

9. Deterministic JSON Serialization 🔥

okay so JSON objects can include spaces and line breaks, and key value pairs can show up in any order. That makes it a non-deterministic string format 🙈 To make digital signature verification work deterministically, the JSON representation of the JWS Protected Header object and JWS Payload object MUST be computed as follows. These rules are based on the thumbprint of a JSON Web Key (JWK), as defined in Section 3 Step 1 of [RFC7638].

The JSON object MUST follow these rules:

1. The JSON object MUST contain no whitespace or line breaks before or after any syntactic elements.
2. JSON objects MUST have the keys ordered lexicographically by the Unicode [UNICODE] code points of the member names.
3. JSON value literals MUST be lowercase.
4. JSON numbers are to be encoded as integers unless the field is defined to be encoded otherwise.
5. Encoding rules MUST be applied recursively to member values and array values.

Note: For any PASSporT extension claims, member names within the scope of a JSON object MUST NOT be equal to other member names. If they are, serialization will not be deterministic 😱

9.1. Example PASSporT Deterministic JSON Form

This section shows deterministic JSON serialization for the example PASSporT Payload from Section 5.2.1.4 🧁

Here's the initial JSON object:

{
  "dest":{"uri":["sip:alice@example.com"]},
  "orig":{"tn":"12155551212"}
  "iat":1443208345,
  "mky":[
    {
      "alg":"sha-256",
      "dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD54
        F17A03A27DF9B07F4619B2"
    },
    {
      "alg":"sha-256",
      "dig":"4AADB9B13F82183B540212DF3E5D496B19E57C
        AB3E4B652E7D463F5442CD54F1"
    }
  ],
}

The parent members of the JSON object are:

• "dest"
• "orig"
• "iat"
• "mky"

Their lexicographic order is:

• "dest"
• "iat"
• "mky"
• "orig"

The final deterministic JSON serialization, with whitespace and line breaks removed (line breaks are only there for display), is:

{"dest":{"uri":["sip:alice@example.com"],"iat":1443208345,"mky":
[{"alg":"sha-256","dig":"021ACC5427ABEB9C533F3E4B652E7D463F5442CD5
4F17A03A27DF9B07F4619B2"},{"alg":"sha-256","dig":"4AADB9B13F82183B5
40212DF3E5D496B19E57CAB3E4B652E7D463F5442CD54F1"}],
"orig":{"tn":"12155551212"}}

10. Security Considerations 🛡️

okay this part is seriously important, bestie 💀 Keep it real about these.

10.1. Avoidance of Replay and Cut-and-Paste Attacks

There are a bunch of security considerations around using the token to avoid replay and cut-and-paste attacks 😭 PASSporTs SHOULD only be sent with application-level protocol information (for example, for SIP, an INVITE as defined in [RFC3261]) that matches the required fields in the token. A unique set of token claims and token signature gets built from the originating identity asserted with the "orig" claim, plus these two claims:

• The "iat" claim should match the date and time the message was originated. It should also fall within a relative time that's reasonable for clock drift and transmission time characteristics of the application using the PASSporT. So validation of the token should consider date and time correlation, which could be affected by how the signaling protocol is used and by network time differences ⏰
• The "dest" claim is included to further restrict a valid PASSporT from being replayed as an attack against other destination parties. The verification of the PASSporT at the destination should check that the "dest" claim matches the destination party as the intended recipient of the message 🎯

10.2. Solution Considerations

Using PASSporTs that depend on validating the digital signature and the associated certificate means you have to think about the authentication, authority, or reputation of the signer when it comes to attesting to the identity being asserted 🧐 The following should be recognized when using PASSporT:

• Using this token should not, on its own, be treated as a full solution for absolute non-repudiation of the identity being asserted. Not the whole story, bestie 🙅‍♀️
• In lots of applications, the signer and the end user represented by the asserted identity may not be one and the same. For example, when a service provider signs and validates the token on behalf of the user consuming the service, the provider MUST have an authenticated and secure relationship with the end user or the device initiating and terminating the communications signaling 🔐
• Applications that use PASSporT should ensure that verifying the signature includes a way to check that the signer is authoritative. That means using an application-specific or service-specific set of common trust anchors for the application ✨

11. IANA Considerations 🌷

11.1. Media Type Registration ✨

okay bestie, this bit registers the "application/passport" media type (see [RFC2046] for the definition of "media type") in the "Media Types" registry, following the process in [RFC6838]. It's how the world knows the content is a PASSporT-defined JWT 🎀

• Type name: application
• Subtype name: passport
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: 8bit; application/passport values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period (".") characters.
• Security considerations: See the Security Considerations section of [RFC7515].
• Interoperability considerations: N/A
• Published specification: RFC 8225
• Applications that use this media type: Secure Telephone Identity Revisited (STIR) and other applications that require identity-related assertion
• Fragment identifier considerations: N/A
• Additional information:
  • Magic number(s): N/A
  • File extension(s): N/A
  • Macintosh file type code(s): N/A
• Person & email address to contact for further information: Chris Wendt, chris-ietf@chriswendt.net
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Chris Wendt <chris-ietf@chriswendt.net>
• Change Controller: IESG
• Provisional registration? No

11.2. Registrations in "JSON Web Token Claims" 💜

three new claims get registered in the "JSON Web Token Claims" registry, and they all point back to the right sections 🫶

Claim Name: "orig"
Claim Description: Originating Identity String
Change Controller: IESG
Reference: Section 5.2.1 of RFC 8225

Claim Name: "dest"
Claim Description: Destination Identity String
Change Controller: IESG
Reference: Section 5.2.1 of RFC 8225

Claim Name: "mky"
Claim Description: Media Key Fingerprint String
Change Controller: IESG
Reference: Section 5.2.2 of RFC 8225

11.3. Registration in "JSON Web Signature and Encryption Header Parameters" 🌸

and then there's the header parameter, which gets its own entry in the "JSON Web Signature and Encryption Header Parameters" registry. it's giving organized 🍓

Header Parameter Name: "ppt"
Header Parameter Description: PASSporT extension identifier
Header Parameter Usage Location(s): JWS
Change Controller: IESG
Reference: Section 8.1 of RFC 8225

11.4. PASSporT Extensions Registry 🦋

IANA made a brand new PASSporT Type registry for "ppt" parameter values, so the extension values finally have a home 🏡 The parameter and its values are defined in Section 8.1. New registry entries must contain the name of the "ppt" parameter value and the specification in which the value is described. The policy for this registry is Specification Required [RFC8126]. no cap, this is how you keep the list tidy ✨

---

12. References 📚

12.1. Normative References 🔥

these are the references you need to actually read to implement this, so don't skip them 🙈

[RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
           Extensions (MIME) Part Two: Media Types", RFC 2046,
           DOI 10.17487/RFC2046, November 1996,
           <https://www.rfc-editor.org/info/rfc2046>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3629]  Yergeau, F., "UTF-8, a transformation format of
           ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629,
           November 2003, <https://www.rfc-editor.org/info/rfc3629>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, DOI 10.17487/RFC3986, January 2005,
           <https://www.rfc-editor.org/info/rfc3986>.

[RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
           Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
           July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
           Transport Layer Security (TLS) Protocol in the Session
           Description Protocol (SDP)", RFC 4572,
           DOI 10.17487/RFC4572, July 2006,
           <https://www.rfc-editor.org/info/rfc4572>.

[RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
           Specifications and Registration Procedures", BCP 13,
           RFC 6838, DOI 10.17487/RFC6838, January 2013,
           <https://www.rfc-editor.org/info/rfc6838>.

[RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
           Algorithm (DSA) and Elliptic Curve Digital Signature
           Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979,
           August 2013, <https://www.rfc-editor.org/info/rfc6979>.

[RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
           Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
           May 2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
           DOI 10.17487/RFC7518, May 2015,
           <https://www.rfc-editor.org/info/rfc7518>.

[RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
           (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
           <https://www.rfc-editor.org/info/rfc7519>.

[RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
           Thumbprint", RFC 7638, DOI 10.17487/RFC7638,
           September 2015, <https://www.rfc-editor.org/info/rfc7638>.

[RFC8122]  Lennox, J. and C. Holmberg, "Connection-Oriented Media
           Transport over the Transport Layer Security (TLS) Protocol
           in the Session Description Protocol (SDP)", RFC 8122,
           DOI 10.17487/RFC8122, March 2017,
           <https://www.rfc-editor.org/info/rfc8122>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
           RFC 2119 Key Words", BCP 14, RFC 8174,
           DOI 10.17487/RFC8174, May 2017,
           <https://www.rfc-editor.org/info/rfc8174>.

[RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
           "Authenticated Identity Management in the Session
           Initiation Protocol (SIP)", RFC 8224,
           DOI 10.17487/RFC8224, February 2018,
           <https://www.rfc-editor.org/info/rfc8224>.

[UNICODE]  The Unicode Consortium, "The Unicode Standard",
           <http://www.unicode.org/versions/latest/>.

12.2. Informative References 💅

these ones are the extra reading for when you want the background tea ☕

[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E.
           Schooler, "SIP: Session Initiation Protocol", RFC 3261,
           DOI 10.17487/RFC3261, June 2002,
           <https://www.rfc-editor.org/info/rfc3261>.

[RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
           Housley, R., and W. Polk, "Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
           <https://www.rfc-editor.org/info/rfc5280>.

[RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
           Telephone Identity Problem Statement and Requirements",
           RFC 7340, DOI 10.17487/RFC7340, September 2014,
           <https://www.rfc-editor.org/info/rfc7340>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

---

Appendix A. Example ES256-Based PASSporT JWS Serialization and Signature 🧚

this appendix is the fun part where we actually build a PASSporT step by step 🎀 every PASSporT always has a JWS with these three members:

• "protected", with the value BASE64URL(UTF8(JWS Protected Header))
• "payload", with the value BASE64URL(JWS Payload)
• "signature", with the value BASE64URL(JWS Signature)

we're following Steps 1-6 and 8 from JWS ([RFC7515], Section 5.1), plus the extra serialization bits PASSporT needs 💖

Step 1 is about the JWS Payload. Here's an example PASSporT Payload:

{
  "dest":{"uri":["sip:alice@example.com"]}
  "iat":1471375418,
  "orig":{"tn":"12155551212"}
}

it gets serialized into this form (the line break is just for display, not part of the value):

{"dest":{"uri":["sip:alice@example.com"]},"iat":1471375418,
"orig":{"tn":"12155551212"}}

Step 2 computes the BASE64URL(JWS Payload), which gives us this (again, the line break is just for display):

eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19

For Step 3, here's an example PASSporT Protected Header built as a JOSE Header:

{
  "alg":"ES256",
  "typ":"passport",
  "x5u":"https://cert.example.org/passport.cer"
}

serialized, it looks like this (line break for display only):

{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org
  /passport.cer"}

Step 4 does the BASE64URL(UTF8(JWS Protected Header)) operation and encoding, producing this value (line break for display only):

eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9

Steps 5 and 6 are where the signing happens 🔐 We compute the digital signature over the PASSporT Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || "." || BASE64URL(JWS Payload)), using ES256 as the algorithm, and that gives us the BASE64URL(JWS Signature):

VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb
a7UWYRM47ZbNFdOJquE35cw

Step 8 is the final assembly. You put the values together in the order Header.Payload.Signature, joined with period (".") characters. For the example values above, that gives (the line breaks between periods are only there for readability):

eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j
ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9
.
eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
6MTQ3MTM3NTQxOCwib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyIn19
.
VLBCIVDCaeK6M4hLJb6SHQvacAQVvoiiEOWQ_iUkqk79UD81fHQ0E1b3_GluIkb
a7UWYRM47ZbNFdOJquE35cw

A.1. X.509 Private Key in PKCS #8 Format for ES256 Example 🗝️

-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY-----

A.2. X.509 Public Key for ES256 Example 🔑

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8HNbQd/TmvCKwPKHkMF9fScavGeH
78YTU8qLS8I5HLHSSmlATLcslQMhNC/OhlWBYC626nIlo7XeebYS7Sb37g==
-----END PUBLIC KEY-----

---

Acknowledgments 🫶

huge thanks to members of the ATIS and SIP Forum NNI Task Group, including Jim McEachern, Martin Dolly, Richard Shockey, John Barnhill, Christer Holmberg, Victor Pascual Avila, Mary Barnes, and Eric Burger, for their review, ideas, and contributions 👑 Thanks also to Henning Schulzrinne, Russ Housley, Alan Johnston, Richard Barnes, Mark Miller, Ted Hardie, Dave Crocker, Robert Sparks, and Jim Schaad for the valuable feedback on the technical and security aspects of the document 🌈 And additional thanks to Harsha Bellur for helping code the example tokens ✨

Authors' Addresses 🦋

Chris Wendt
Comcast
One Comcast Center
Philadelphia, PA  19103
United States of America

Email: chris-ietf@chriswendt.net


Jon Peterson
Neustar Inc.
1800 Sutter St. Suite 570
Concord, CA  94520
United States of America

Email: jon.peterson@neustar.biz