Nokia

Naperville IL United States of America ranjitkav@gmail.com

Acharya Institute of Technology

Bangalore Karnataka India nataraju.ab@gmail.com

Axyom.Core

Irving TX US binu.sudhakaran@gmail.com

Applications and Real-Time Area STIR PASSporT STIR SHAKEN RCD SIP device information 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.

Introduction PASSporT provides a signed token for assertions about the originating identity of a personal communication. The STIR procedures defined by convey such assertions in SIP. Rich Call Data (RCD) 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.

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 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.

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.

The "dinfo" PASSporT Claim

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 } }

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".

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 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.

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 . When transported using SIP, it is carried according to .

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.

Verification A DIV MUST validate the PASSporT according to and, for SIP use, 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.

Relationship to Rich Call Data The "dinfo" claim is separate from the "rcd" and "rcdi" claims defined in . 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.

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.

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.

Security Considerations The security considerations of , , and, when RCD is also used, 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.

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 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.

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 .

Normative References Informative References

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.