PASSporT Device Information Extension for Enhanced Caller Authentication and Fraud Resilience

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 April 2027.¶

Copyright Notice

Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

PASSporT [RFC8225] provides a signed token for assertions about the originating identity of a personal communication. The STIR procedures defined by [RFC8224] convey such assertions in SIP. Rich Call Data (RCD) [RFC9795] extends PASSporT with caller- and call-related information that can be integrity protected and rendered to a called party.¶

These mechanisms provide limited standardized information about the endpoint associated with call origination. In some deployments, a coarse endpoint category, management context, or registration-derived assurance indication can be useful as an additional signal for fraud analytics, enterprise policy, audit, and troubleshooting.¶

This document defines the "dinfo" PASSporT claim. It does not carry a hardware serial number, permanent equipment identifier, IP address, or unbounded manufacturer/model fingerprint. A signer includes the claim only when authorized to make the assertion and when the information comes from an authenticated registration, enterprise inventory, endpoint-attestation system, or another policy-approved source.¶

Device information is only one input to a trust decision. A verifier MUST NOT interpret the presence of "dinfo", by itself, as proof that the caller or call is benign.¶

2. Conventions and Terminology

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

Device Information Signer (DIS)

The entity that creates a PASSporT containing the "dinfo" claim.¶

Device Information Verifier (DIV)

The entity that verifies the PASSporT and consumes or forwards verified device information.¶

Device reference

A scoped, short-lived, opaque value that permits an authorized verifier to correlate events within a limited context.¶

Managed endpoint

An endpoint whose configuration or lifecycle is controlled by an enterprise or service provider.¶

3. Scope and Design Principles

The extension has the following design goals:¶

• Bind device information to a signed PASSporT.¶
• Convey categorical rather than fingerprinting-level information.¶
• Support data minimization and policy-based disclosure.¶
• Permit incremental deployment.¶
• Avoid changes to SIP dialog establishment.¶

This document does not define device-attestation protocols, inventory procedures, user-interface behavior, or a universal device trust score.¶

4. The "dinfo" PASSporT Claim

{
  "dinfo": {
    "cat": "desk-phone",
    "mgmt": "enterprise-managed",
    "ctx": ["contact-center"],
    "src": "authenticated-registration",
    "ref": "urn:example:device-ref:4f7c2a9d",
    "refexp": 1792890000
  }
}

5. PASSporT Extension Processing

A PASSporT carrying "dinfo" MUST include the PASSporT extension type "dinfo" in the protected "ppt" header parameter. The token is created and validated according to [RFC8225]. When transported using SIP, it is carried according to [RFC8224].¶

6. Use by Verification and Analytics Functions

A verified "dinfo" claim can be used as one feature among several in a risk or routing decision. A mismatch can trigger further analysis but MUST NOT be treated as conclusive evidence of fraud. Scoring thresholds, user-visible labels, and enforcement actions are local policy.¶

7. Privacy Considerations

Device metadata can facilitate tracking, fingerprinting, and inference about a user's location, employer, work pattern, or network topology. A DIS MUST apply data minimization and purpose limitation. Stable hardware or network identifiers MUST NOT be included. A device reference MUST be scoped and time limited. A DIV MUST limit retention to the stated operational purpose.¶

The claim SHOULD be omitted when the signer cannot establish an authorized purpose for disclosure.¶

8. Security Considerations

The security considerations of [RFC8225], [RFC8224], and, when RCD is also used, [RFC9795] apply.¶

A compromised inventory or registration system can produce false device assertions. Signers SHOULD protect those systems, maintain provenance, and audit changes. A "ref" is not an authorization credential and MUST NOT grant access to a device-management interface or subscriber data.¶

Fine-grained manufacturer, model, and software-version information can help an attacker select an exploit. This extension deliberately excludes those fields. A missing or "unknown" value MUST NOT, by itself, be treated as evidence of fraud.¶

9. Operational and Deployment Considerations

Deployment can be incremental. A verifier that does not understand the extension can ignore it, and SIP call establishment remains unchanged. Operators should monitor token size because certificates, RCD, and device information can increase SIP message size and fragmentation risk.¶

Controlled proof-of-concept work reported in [DEVICE-INFO-PAPER] suggests that device context can improve fraud-analysis confidence and reduce troubleshooting time. Those measurements are deployment-specific and do not define protocol requirements or guaranteed outcomes.¶

10. IANA Considerations

This document requests registration of "dinfo" in the "Personal Assertion Token (PASSporT) Extensions" registry, with this document as its reference.¶

This document also requests registration of "dinfo" in the "JSON Web Token Claims" registry with the description "Authenticated endpoint device information", change controller "IETF", and this document as its reference.¶

This document requests creation of a "PASSporT Device Information Values" registry with Device Category, Management Context, Device Context, and Evidence Source subregistries. The registration policy is Specification Required. Initial values are listed in Section 4.2.¶

Appendix A. Example Full-Form PASSporT Payload

The following non-normative example is shown before encoding and signing:¶

{
  "attest": "A",
  "dest": {"tn": ["13105551212"]},
  "dinfo": {
    "cat": "desk-phone",
    "mgmt": "enterprise-managed",
    "ctx": ["contact-center"],
    "src": "authenticated-registration",
    "ref": "urn:example:device-ref:4f7c2a9d",
    "refexp": 1792890000
  },
  "iat": 1792886400,
  "orig": {"tn": "12155551212"},
  "origid": "123e4567-e89b-12d3-a456-426614174000"
}

The protected header contains "ppt":"dinfo". Example telephone numbers and URI values are illustrative only.¶

Acknowledgements

The authors thank Zaheduzzaman Sarker for his guidance and support to the PASSporT and Rich Call Data work.¶

Authors' Addresses