STIR R. Avasarala Internet-Draft Nokia Intended status: Standards Track A. B. Nataraju Expires: 28 April 2027 Acharya Institute of Technology B. S. Pillai Axyom.Core 25 October 2026 PASSporT Device Information Extension for Enhanced Caller Authentication and Fraud Resilience draft-avasarala-stir-passport-device-info-00 Abstract This document defines a PASSporT extension and a new claim, "dinfo", for carrying authenticated, privacy-minimized information about the endpoint associated with the origination of a call. The claim conveys coarse-grained device characteristics and an optional, non- correlatable device reference. The information is intended for use as an additional input to fraud analysis, policy enforcement, and operational diagnostics. It is not an assertion that the endpoint, caller, or call is trustworthy. This document specifies claim syntax, creation and verification procedures, privacy requirements, and IANA registrations. 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. Avasarala, et al. Expires 28 April 2027 [Page 1] Internet-Draft PASSporT Device Info October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Scope and Design Principles . . . . . . . . . . . . . . . . . 3 4. The "dinfo" PASSporT Claim . . . . . . . . . . . . . . . . . 4 4.1. Claim Syntax . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Claim Members . . . . . . . . . . . . . . . . . . . . . . 4 5. PASSporT Extension Processing . . . . . . . . . . . . . . . . 5 5.1. Creation . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Verification . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Relationship to Rich Call Data . . . . . . . . . . . . . 6 6. Use by Verification and Analytics Functions . . . . . . . . . 6 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Operational and Deployment Considerations . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 12. Informative References . . . . . . . . . . . . . . . . . . . 8 Appendix A. Example Full-Form PASSporT Payload . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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. Avasarala, et al. Expires 28 April 2027 [Page 2] Internet-Draft PASSporT Device Info October 2026 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. Avasarala, et al. Expires 28 April 2027 [Page 3] Internet-Draft PASSporT Device Info October 2026 This document does not define device-attestation protocols, inventory procedures, user-interface behavior, or a universal device trust score. 4. The "dinfo" PASSporT Claim 4.1. Claim Syntax The "dinfo" claim value is a JSON object. Implementations MUST reject the claim as malformed if the value is not an object or if a member has a type different from the type specified below. { "dinfo": { "cat": "desk-phone", "mgmt": "enterprise-managed", "ctx": ["contact-center"], "src": "authenticated-registration", "ref": "urn:example:device-ref:4f7c2a9d", "refexp": 1792890000 } } 4.2. Claim Members cat OPTIONAL string identifying a coarse endpoint category. Initial values are "mobile", "desk-phone", "soft-client", "gateway", "application", and "unknown". A signer MUST use "unknown" rather than guessing. mgmt OPTIONAL string describing the management context. Initial values are "enterprise-managed", "provider-managed", "user-managed", and "unknown". ctx OPTIONAL array of context strings. Initial values are "contact- center", "branch", "remote-work", "service-platform", and "other". The array MUST contain no more than four values; each string MUST contain no more than 32 Unicode code points. src REQUIRED string identifying the class of evidence. Initial values are "authenticated-registration", "provisioning", "enterprise- inventory", "endpoint-attestation", and "other". Avasarala, et al. Expires 28 April 2027 [Page 4] Internet-Draft PASSporT Device Info October 2026 ref OPTIONAL URI carrying an opaque, scoped device reference. It MUST NOT contain a serial number, MAC address, IMEI, IP address, or another stable identifier in clear text. refexp REQUIRED when "ref" is present. It is a NumericDate [RFC7519] after which the verifier MUST NOT use "ref" for correlation. It MUST be later than the PASSporT "iat" value. A "dinfo" object MUST contain "src" and at least one of "cat", "mgmt", "ctx", or "ref". Unknown members MUST be ignored after successful PASSporT signature validation unless local policy requires rejection. 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]. 5.1. Creation Before adding "dinfo", the DIS MUST authenticate the source, be authorized to disclose every attribute, minimize the claim, accurately represent the available evidence, apply a short validity period to any device reference, and sign the resulting PASSporT using an applicable STIR credential. A DIS MUST NOT copy an unauthenticated SIP User-Agent field into "dinfo" and represent it as verified device information. 5.2. Verification A DIV MUST validate the PASSporT according to [RFC8225] and, for SIP use, [RFC8224] before using "dinfo". If validation fails, the DIV MUST treat all "dinfo" values as unverified. After successful validation, the DIV MUST apply local authorization and retention policy and MUST NOT use "ref" after "refexp". Unsupported members or values MUST NOT cause SIP call failure. Avasarala, et al. Expires 28 April 2027 [Page 5] Internet-Draft PASSporT Device Info October 2026 5.3. Relationship to Rich Call Data The "dinfo" claim is separate from the "rcd" and "rcdi" claims defined in [RFC9795]. An issuer MAY use RCD and "dinfo" in the same call, subject to the rules for each extension and the applicable token-carriage mechanism. Implementations MUST NOT insert "dinfo" as an unregistered jCard property and assume that it is covered by RCD integrity rules. 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. Avasarala, et al. Expires 28 April 2027 [Page 6] Internet-Draft PASSporT Device Info October 2026 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. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Avasarala, et al. Expires 28 April 2027 [Page 7] Internet-Draft PASSporT Device Info October 2026 [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, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . 12. Informative References [RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT) Extension for Rich Call Data", RFC 9795, DOI 10.17487/RFC9795, July 2025, . [DEVICE-INFO-PAPER] Nataraju, A. B., Avasarala, R., and B. S. Pillai, "Enhancing SIP Rich Call Data with Device-Info for Improved Caller Authentication and Fraud Resilience", Proceedings 2026 International Conference on Networks, Computers and Communications (ICNCCOM), DOI 10.1109/ICNCCom69117.2026.11736272, 2026, . 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" } Avasarala, et al. Expires 28 April 2027 [Page 8] Internet-Draft PASSporT Device Info October 2026 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 Ranjit Avasarala Nokia Naperville, IL United States of America Email: ranjitkav@gmail.com A. B. Nataraju Acharya Institute of Technology Bangalore Karnataka India Email: nataraju.ab@gmail.com Binu Sudhakaran Pillai Axyom.Core Irving, TX United States of America Email: binu.sudhakaran@gmail.com Avasarala, et al. Expires 28 April 2027 [Page 9]