Personal Assertion Token (PASSporT) Extension for Diverted Calls
RFC 8946

Document Type RFC - Proposed Standard (February 2021; No errata)
Updates RFC 8224
Author Jon Peterson 
Last updated 2021-02-12
Replaces draft-peterson-passport-divert
Stream Internent Engineering Task Force (IETF)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Russ Housley
Shepherd write-up Show (last changed 2019-07-12)
IESG IESG state RFC 8946 (Proposed Standard)
Action Holders
Consensus Boilerplate Yes
Telechat date
Responsible AD Murray Kucherawy
Send notices to Russ Housley <>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK
IANA expert review comments PASSporT registrations approved. JWT Claims experts would like the issues described in jwt-reg-review mailing list review resolved before registration.

Internet Engineering Task Force (IETF)                       J. Peterson
Request for Comments: 8946                                       Neustar
Updates: 8224                                              February 2021
Category: Standards Track                                               
ISSN: 2070-1721

    Personal Assertion Token (PASSporT) Extension for Diverted Calls


   The Personal Assertion Token (PASSporT) is specified in RFC 8225 to
   convey cryptographically signed information about the people involved
   in personal communications.  This document extends PASSporT to
   include an indication that a call has been diverted from its original
   destination to a new one.  This information can greatly improve the
   decisions made by verification services in call forwarding scenarios.
   Also specified here is an encapsulation mechanism for nesting a
   PASSporT within another PASSporT that assists relying parties in some
   diversion scenarios.

   This document updates RFC 8224.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  The "div" PASSporT Type and Claim
   4.  Using "div" in SIP
     4.1.  Authentication Service Behavior
     4.2.  Verification Service Behavior
   5.  The "div-o" PASSporT Type
     5.1.  Processing "div-o" PASSporTs
   6.  Definition of "opt"
   7.  "div" and Redirection
   8.  Extending "div" to Work with Service Logic Tracking
   9.  IANA Considerations
     9.1.  JSON Web Token Claims Registrations
       9.1.1.  "div" registration
       9.1.2.  "opt" registration
     9.2.  PASSporT Type Registrations
   10. Privacy Considerations
   11. Security Considerations
   12. References
     12.1.  Normative References
     12.2.  Informative References
   Appendix A.  Keys for Examples
   Author's Address

1.  Introduction

   A Personal Assertion Token (PASSporT) [RFC8225] is a token format
   based on the JSON Web Token (JWT) [RFC7519] for conveying
   cryptographically signed information about the people involved in
   personal communications; it is used by the Secure Telephone Identity
   Revisited (STIR) protocol [RFC8224] to convey a signed assertion of
   the identity of the participants in real-time communications
   established via a protocol like SIP.  This specification extends
   PASSporT to include an indication that a call has been diverted from
   its original destination to a new one.

   Although the STIR problem statement [RFC7340] is focused on
   preventing the impersonation of the caller's identity, which is a
   common enabler for threats such as robocalling and voicemail hacking
   on the telephone network today, it also provides a signature over the
   called number at the time that the authentication service sees it.
   As [RFC8224], Section 12.1 describes, this protection over the
   contents of the To header field is intended to prevent a class of
   cut-and-paste attacks.  If Alice calls Bob, for example, Bob might
   attempt to cut and paste the Identity header field in Alice's INVITE
   into a new INVITE that Bob sends to Carol, and thus be able to fool
   Carol into thinking the call came from Alice and not Bob. With the
   signature over the To header field value, the INVITE Carol sees will
   clearly have been destined originally for Bob, and thus Carol can
   view the INVITE as suspect.

   However, as [RFC8224], Section 12.1.1 points out, it is difficult for
   Carol to confirm or reject these suspicions based on the information
   she receives from the baseline PASSporT object.  The common "call
   forwarding" service serves as a good example of the reality that the
   original called party number is not always the number to which a call
Show full document text