Network Working Group J. Peterson Internet-Draft TransUnion Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 Secure Telephone Identity for Agents draft-peterson-stir-agentic-00 Abstract The Secure Telephone Identity Revisited (STIR) framework uses credentials to sign calls in order to prevent identity impersonation in the telephone network, especially by robocallers. Its framework also accounts for certain cases of "legitimate" impersonation of identity. This document expands the scope of STIR to include agents acting on behalf of users and enterprises: how agents might best opt- in to self-identify as agents, and how the intent of the originating user or enterprise in delegating to an agent can best be communicated to relying parties. 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 6 May 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 Peterson Expires 6 May 2027 [Page 1] Internet-Draft STIR Agents November 2026 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Consumer Agent, Commerce . . . . . . . . . . . . . . . . 6 3.2. Consumer Agent, Non-Commerce . . . . . . . . . . . . . . 6 3.3. Enterprise Agent . . . . . . . . . . . . . . . . . . . . 6 3.4. Called Agent . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Unaware Terminating Party . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Overview of Operations . . . . . . . . . . . . . . . . . . . 8 6. Impersonation and Delegation . . . . . . . . . . . . . . . . 9 6.1. The "act" Claim in PASSporT . . . . . . . . . . . . . . . 9 6.2. Disclosure Required by the TN Holder . . . . . . . . . . 11 6.3. Agent Disclosure and Intent in Rich Call Data . . . . . . 11 7. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. The "intent" Claim . . . . . . . . . . . . . . . . . . . 12 7.2. Intent Types . . . . . . . . . . . . . . . . . . . . . . 13 8. Binding Intent and STIR . . . . . . . . . . . . . . . . . . . 13 8.1. Binding the Intent Object to STIR . . . . . . . . . . . . 14 8.2. Binding STIR to the Intent Object . . . . . . . . . . . . 14 9. Connected Identity . . . . . . . . . . . . . . . . . . . . . 15 10. Intent Verification Procedures . . . . . . . . . . . . . . . 15 11. Producing Intent . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . 18 13.2. PASSporT Intent Types Registry . . . . . . . . . . . . . 18 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 16.2. Informative References . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The STIR problem statement [RFC7340] discusses many attacks on the telephone network that are enabled by impersonation, including various forms of robocalling, voicemail hacking, and swatting. One of the most important components of a system to prevent impersonation is the implementation of credentials which identify the parties who control telephone numbers. The STIR certificates [RFC8226] Peterson Expires 6 May 2027 [Page 2] Internet-Draft STIR Agents November 2026 specification describes such credentials, which STIR authentication services [RFC8224] use to sign PASSporT objects [RFC8225] carried in SIP [RFC3261] requests. From its outset, STIR has recognized that not every legitimate party who asserts a calling telephone number (TN) is the party to whom that number is assigned. Call centers place calls on behalf of the enterprises whose numbers they present, doctors place calls that show their office's main number as the calling party, and STIR delegate certificates [RFC9060] allow the holder of a TN to authorize a third party to sign for it. Software agents acting on behalf of users and enterprises are the newest instance of this pattern. An agent might place a call to order a pizza, reschedule a medical appointment, or follow up on a delivery, presenting the TN of the user or enterprise on whose behalf it acts. Equally, an agent might answer calls on behalf of a user or business. Frameworks for agent protocols recognize that an agent may need to reach a human in another administrative domain for whom it has only a telephone number or email address [I-D.rosenberg-agentproto-usecases]. Relying parties have a legitimate interest in knowing when a call is placed or answered by an agent rather than by the party whose number is presented, on whose behalf the agent is acting, and what the agent has been authorized to do. Of course, there is no protocol-level mechanism that can compel agents to reveal themselves as such; an agent identifying themselves or not is a matter of policy for the agent's operator. But this document specifies how agents can opt-in to identify themselves within the STIR framework, and how the intent of the user or enterprise that activated an agent can be conveyed to relying parties in a manner that the agent itself cannot forge. Comparable mechanisms for identifying automated clients are being developed for HTTP [I-D.ietf-webbotauth-httpsig-protocol]. Peterson Expires 6 May 2027 [Page 3] Internet-Draft STIR Agents November 2026 Rich Call Data (RCD) [RFC9795] already specifies a way for parties other than the holder of a TN to provide information about calls from that TN: its third-party profile allows an external authority to sign a PASSporT conveying information about a calling party, identified as the source of that information through the "iss" claim. This document addresses a related but distinct relationship. An agent is not an authority attesting to information about the caller, but a party placing the call on the caller's behalf; as will be specified below, an agent here is identified through the "act" claim ([RFC8693]), which distinguishes the actor from the party on whose behalf it acts. Moreover, the authority that expresses the intent of that party need not be a STIR signer at all: this document allows objects signed under trust anchors outside the STIR ecosystem to be bound to a PASSporT signed by the authentication service, rather than requiring external authorities to sign PASSporTs themselves. STIR has previously provided a means of conveying the purpose of a call: the "call-reason" parameter of [RFC9796], protected by the "crn" claim of [RFC9795], allows the originator of a call to state in human-readable text why it is calling. A call reason is, however, a free-text assertion made by the signer of the PASSporT itself, which cannot be mechanically compared against any action taken. To support a means of conveying user intent, this document specifies a new general way for any object signed under a trust anchor outside the STIR ecosystem, such as an OAuth token or a verifiable credential, to accompany a call. This object internally attests the TN(s) it pertains to under the signature of its issuer, and the PASSporT itself binds the object to the call by signing over its digest. This permits information about a calling party that is authoritatively held elsewhere to reach relying parties without requiring its issuer to sign calls, or STIR credentials to vouch for it. While this document applies these mechanisms to agents and their intent, they may be applicable more generally to use cases in which relying parties benefit from information about an originating enterprise or user, beyond what STIR credentials themselves attest. Information that is stable and properly a property of the signing credential, such as the vetted identity of a delegate, belongs in the credential itself [I-D.wendt-stir-vesper]; the mechanisms here address information scoped to individual calls or tasks. This document does not define new trust relationships for agents. Commerce and identity ecosystems already establish end-to-end trust that agent platforms cannot counterfeit: a payment network can verify that a purchase was authorized by a cardholder, and an OAuth authorization server can attest that a user delegated authority to a client. Further defining the non-STIR trust anchors that sign objects admitted to PASSporTs under this mechanism is outside the scope of this specification. Peterson Expires 6 May 2027 [Page 4] Internet-Draft STIR Agents November 2026 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. This document uses the following terms: Principal: The user or enterprise on whose behalf an agent acts. Typically, though not necessarily, the principal holds the TN presented in a call placed by its agent. In the terms of [RFC8693], the principal is the subject and the agent is the actor. Agent: A service that places or answers calls, or sends or receives messages, on behalf of a principal, typically driven by a non- deterministic decision process such as a large language model. Agentic platform: The system that operates an agent. Intent object: A data object that expresses what a principal has authorized an agent to do, at some level of detail. Intent objects range from coarse to fully specified transaction mandates. Intent type: A registered category of intent object, defining its format, signer, and verification procedures (see Section 7.2). Intent authority: The party that signs an intent object: the principal, or a party authorized to represent the principal, such as an OAuth authorization server or a payment credential provider. Intent verifier: A function that acts on the claims defined in this document in a PASSporT that has been successfully verified by a verification service, by obtaining and verifying intent objects and their bindings. An intent verifier may be co-located with a verification service, or may reside in a downstream system such as a point-of-sale system integrated with the called party's calling platform. 3. Use Cases The following use cases exemplify how STIR and agentic calling might interact. Assume that prior to calling, an agentic calling platform obtains authority from the user's carrier to place calls from the user's TN, for example through a delegate certificate [RFC9060]. Peterson Expires 6 May 2027 [Page 5] Internet-Draft STIR Agents November 2026 3.1. Consumer Agent, Commerce A user asks an agent to order a pizza: one large, half plain and half with green onions and olives, for pickup. The pizza shop has no agent-native ordering interface that the agent knows of; it has a telephone number. Thus the agent uses its telephone calling tool to contact the pizza shop. The agent also obtains a manifest expressing the order, signed by an intent authority within the user's payment ecosystem, after the user confirms the contents of the manifest. The agent calls the pizza shop. The call presents the user's TN, a caller name indicating that the caller is the user's agent, and a call reason derived from the mandate. A person answering the call sees and hears an ordinary order. A point-of-sale system integrated with the shop's telephony can additionally retrieve the mandate and verify it against trust anchors it already holds through its own relationship with a payment network. Before the transaction clears, the order can be compared with the mandate. The agentic platform is trusted by no one in this flow: it carries objects that it cannot forge. 3.2. Consumer Agent, Non-Commerce An agent calls a dentist's office to reschedule an appointment on behalf of a patient. No payment ecosystem is involved, and there may be no relying party capable of verifying a detailed intent object. A coarse expression of intent through call reason (that this is a call to reschedule an appointment) is nevertheless useful to the answering party, whether human or automated, and the disclosure that the caller is an agent is useful regardless. 3.3. Enterprise Agent An enterprise engages a service to launch agentic calls to customers about deliveries, presenting the enterprise's TNs as the calling party number. This is structurally identical to the call center case already contemplated by STIR delegation, except that the enterprise may wish to require that every call placed by the service's agents disclose that they are agents, and to constrain the purposes for which the agent may call. Peterson Expires 6 May 2027 [Page 6] Internet-Draft STIR Agents November 2026 3.4. Called Agent A user calls a business, and the call is answered by an agent operated on the business's behalf. The caller, or the caller's own agent, wishes to know that it has reached an agent, whose agent it is, and what that agent is authorized to do: for example, whether it can modify a reservation or only report on its status. Connected identity [RFC9970] provides a channel for this information in the reverse direction. The identity of the answering agent could, for example, resolve to a description of that agent in an existing format, such as the Agent Card of [A2A], which describes an agent's provider and skills. 3.5. Unaware Terminating Party Any of the calls above may terminate at a party that understands none of the mechanisms in this document. Such a party must receive an ordinary call, with no degradation of service. Where it supports Rich Call Data [RFC9795], it should be able to render a human- readable agent disclosure and call reason without understanding anything further. 4. Requirements The use cases above motivate the following requirements: REQ-1: It must be possible for a call placed by an agent to be distinguished from a call placed directly by the principal whose TN it presents. REQ-2: It must be possible for a principal to require any agent it authorizes to use a TN to disclose that it is an agent. REQ-3: It must be possible to convey the intent of the principal in an object signed by the principal or by an intent authority, and never solely by the agent or by its agentic platform. REQ-4: The mechanism must not require STIR to define trust anchors for intent authorities; it must reuse the trust relationships of existing ecosystems. REQ-5: It must be possible to bind an intent object to the calls for which it is intended, so that it cannot be attached to unrelated calls. REQ-6: The mechanism must accommodate intent at varying levels of detail, and must be extensible to new formats of intent objects without changes to STIR. Peterson Expires 6 May 2027 [Page 7] Internet-Draft STIR Agents November 2026 REQ-7: A terminating party that does not support this mechanism must not be adversely affected by its use. REQ-8: The mechanism must operate in real time. It must not require PASSporTs, or the credentials that sign them, to remain valid after call setup. REQ-9: The mechanism must minimize the disclosure of information about the principal, and should permit selective disclosure to different relying parties. REQ-10: The mechanism must be applicable to called agents as well as calling agents. REQ-11: The mechanism must work with existing STIR credentials, including those bearing Service Provider Codes and delegate certificates bearing TNs. 5. Overview of Operations This mechanism is purely additive on traditional STIR operations. Prior to any call being placed, a principal expresses to an agent a goal it would like the agent to achieve. At that time, an intent authority (typically the principal) signs an intent object of an intent type. The intent object expresses what the principal has authorized: on whose behalf the agent acts, which agent is authorized, for which TNs, and for what purpose. The intent authority is never the agent or its agentic platform. The signing key of the intent authority is presented to relying parties and trusted through whatever means the intent type specifies, for example through OAuth authorization server metadata. Relying parties decide whether to trust an intent authority according to their own policies. The STIR authentication service then signs a PASSporT as usual, using a credential that establishes its authority over the calling TN. The PASSporT carries an indication that the call is placed by an agent, and a reference to, or copy of, the intent object together with a digest of it. By signing over that digest, the authentication service binds the intent object to this call. It does not thereby vouch for the contents of the intent object; it asserts only that this intent object accompanies this call. Peterson Expires 6 May 2027 [Page 8] Internet-Draft STIR Agents November 2026 The intent object is bound to STIR by the TNs and call constraints it contains (Section 8.1), and STIR is bound to the intent object by the PASSporT signature over its digest (Section 8.2). Neither signature alone suffices. A verification service verifies the PASSporT as usual; an intent verifier then verifies the intent object and its bindings. A relying party that does not understand the intent type, or does not trust its intent authority, still has a verified PASSporT and can treat the call as an ordinary call from an agent. 6. Impersonation and Delegation OAuth 2.0 Token Exchange [RFC8693] distinguishes two semantics by which one party may act on behalf of another. Under impersonation, the acting party is indistinguishable from the subject: it receives a token that represents the subject, and relying parties cannot tell that anyone other than the subject is acting. Under delegation, the subject's identity is preserved, but the acting party is separately identified as the "actor," conveyed in the "act" claim. The "act" claim is a JSON object containing claims that identify the actor (typically "sub"), and may itself contain a nested "act" claim representing a prior actor in a chain of delegation. Both semantics already occur in STIR. When a call center places a call presenting an enterprise's TN, signed by a credential issued for that TN, the call is effectively impersonation: nothing in the PASSporT indicates that anyone other than the enterprise is calling. Delegate certificates [RFC9060] make the delegation visible in the certificate chain, but not in the PASSporT itself, and not in a form that identifies the agent. This document adopts the delegation semantics of [RFC8693] for agents. Local policy determines when agents use delegation rather than impersonation, though holders of TNs MAY require it (Section 6.2). Impersonation remains possible, because nothing can compel an agent that does not disclose itself to do so, and because some principals may legitimately prefer it; but an agent that does not disclose itself forgoes the ability to carry an intent object (Section 7), since intent objects identify the agent they authorize. 6.1. The "act" Claim in PASSporT This document extends the PASSporT payload to include the "act" claim of [RFC8693]. When present in a PASSporT, the "act" claim indicates that the call was placed (or, in connected identity, answered) by an agent acting on behalf of the party identified by the "orig" (or connected identity) claim, and identifies that agent. Its value is a JSON object as defined in [RFC8693], Section 4.1, containing claims that identify the actor. This document profiles that object for use Peterson Expires 6 May 2027 [Page 9] Internet-Draft STIR Agents November 2026 in PASSporT as follows: * It MUST contain a "sub" claim, whose value MUST be a URI identifying the agent. Because a URI is globally unique, the "sub" claim does not require an accompanying "iss" claim to give it context, as a "sub" claim otherwise would [RFC7519]. An HTTPS URI that dereferences to a description of the agent, such as an Agent Card [A2A], is RECOMMENDED. The identifier SHOULD be narrow, identifying a specific agent or agent service rather than the agent platform operator generically. An agent that also signs HTTP requests [I-D.ietf-webbotauth-httpsig-protocol] MAY use the same URL that it presents as its signature agent, so that it bears a single identity across both. * It MAY contain an "iss" claim identifying the issuer of the agent's identifier. * It MAY contain a nested "act" claim where an agent acts through a further agent; as in [RFC8693], the outermost "act" claim identifies the current actor, and nested claims identify prior actors. * As in [RFC8693], claims within "act" other than those identifying the actor are not meaningful and MUST be ignored. An agent identifier establishes only which agent claims to be acting. It does not establish who operates the agent, whether the agent is benign, or whether its actions are authorized; those are matters of relying party policy and, for authorization, of the intent objects described in Section 7. An "act" claim may be added to any PASSporT, in the manner that [RFC9795], Section 13, permits RCD claims to be added to PASSporTs of other types. The "act" claim in a PASSporT is asserted by the authentication service, which has no inherent knowledge of the agent's identity. Where an intent object accompanies the call, the intent object also identifies the agent, under the signature of the intent authority. Section 10 describes how the two are reconciled. Peterson Expires 6 May 2027 [Page 10] Internet-Draft STIR Agents November 2026 6.2. Disclosure Required by the TN Holder A holder of a TN that authorizes an agent platform to sign for that TN, for example by issuing a delegate certificate [RFC9060], can require agent disclosure through the JWT Claim Constraints mechanism of [RFC8226] and [RFC9118]. A delegate certificate whose JWT Claim Constraints include "act" in "mustInclude" can only be used to sign PASSporTs that disclose an agent. Constraints on the permitted values of "act" can further restrict which agents may use the delegation. This mechanism moves agent disclosure from a voluntary practice of the agent to a policy of the TN holder: the holder of the number decides whether agents acting under its authority must say so. 6.3. Agent Disclosure and Intent in Rich Call Data The "act" and "intent" claims are intended for machine consumption. Where a display to a human is desired, the authentication service SHOULD also include Rich Call Data [RFC9795] indicating that the caller is an agent, such as a "nam" value of the form "Alice (agent)". Where an intent object accompanies the call, the authentication service MAY also include a "crn" claim conveying the purpose of the call in human-readable form. Rich Call Data reaches terminating parties that support RCD but not this specification, which can render the agent disclosure and call reason without understanding anything further. When an intent object accompanies the call, display information SHOULD be derived from, or be consistent with, the intent object: the "nam" value with the identification of the principal and agent, and the "crn" value with the canonical human-readable rendering of the intent object defined by its intent type (Section 7.2). This ensures that a human answering the call is presented with the same intent that the principal approved, rather than an independent description composed by the agent. 7. Intent This document defines a point of indirection through which the intent of a principal is conveyed: the "intent" claim. From a STIR perspective, the handling of this claim is identical regardless of the kind of intent object it carries: they are delivered to intent verification (see Section 10). Intent objects range in detail from coarse to fully specified transaction mandates. New kinds of intent object are accommodated by registering new intent types, without changes to this specification. Peterson Expires 6 May 2027 [Page 11] Internet-Draft STIR Agents November 2026 7.1. The "intent" Claim The "intent" claim is an array of one or more intent entries. A call MAY carry multiple entries expressing intent at different levels of detail, for example a coarse intent suitable for triage together with a full mandate. An intent verifier uses the entries it understands and ignores the rest. Each intent entry is a JSON object with the following members: typ (required): A string identifying the intent type, from the registry defined in Section 13.2. val (conditional): The intent object, by value. Its encoding is defined by the intent type. uri (conditional): An HTTPS URI from which the intent object can be retrieved by reference. dig (conditional): A digest of the intent object, in the integrity format used by the "rcdi" claim of [RFC9795], computed over the exact octets of the intent object as conveyed or retrieved. Exactly one of "val" or "uri" MUST be present. "dig" MUST be present when "uri" is present, and MUST be present when "val" carries an object whose own signature does not cover the call binding described in Section 8.1. An intent type MAY specify that its objects are conveyed only by value or only by reference. { "orig": { "tn": "12075550100" }, "dest": { "tn": [ "12075550123" ] }, "iat": 1793383200, "act": { "sub": "https://agents.example/a/7f3c" }, "rcd": { "nam": "Alice (agent)" }, "crn": "Order: 1 large pizza, half plain, half green onion and olive, pickup", "intent": [ { "typ": "manifest", "uri": "https://intent.example/i/9c1e4a", "dig": "sha256-0rH5u2bQ3k...Qp8" } ] } Figure 1: Example PASSporT Payload with Agent and Intent Claims Peterson Expires 6 May 2027 [Page 12] Internet-Draft STIR Agents November 2026 7.2. Intent Types An intent type defines a format for intent objects and the procedures for creating and verifying them. A specification registering an intent type MUST define: 1. The format and encoding of the intent object, and whether it is conveyed by value, by reference, or either. 2. Who signs the intent object, and how a relying party resolves the signer's key and evaluates its authority. 3. How the intent object identifies the principal and the agent, including whether it supports the delegation semantics of Section 6. 4. How the intent object is bound to calls, satisfying Section 8.1. 5. The level of assurance the intent object provides; in particular, whether it is signed by an intent authority or merely asserted, so that relying parties do not mistake an asserted category for an authorized intent. 6. A canonical human-readable rendering of the intent object, produced deterministically from its contents (see Section 11). 7. Whether, and how, the intent object distinguishes constraints stated by the principal from constraints inferred by an agent or derived from a standing policy. 8. What information the intent object discloses, to whom, and any support for selective disclosure. This document specifies a base intent type of [TBD]. It is anticipated that specifications developed elsewhere, such as payment mandates (e.g. [AP2], [VI]), will be registered as further intent types; such registrations carry those objects as they are defined, rather than redefining them. 8. Binding Intent and STIR An intent object and a PASSporT are signed by different parties, under different trust anchors. Each must be bound to the other: the intent object to the calls it characterizes, and the call to the intent object it carries. Peterson Expires 6 May 2027 [Page 13] Internet-Draft STIR Agents November 2026 8.1. Binding the Intent Object to STIR An intent object that characterizes calls MUST identify the TNs it applies to under the signature of the intent authority. Each intent type MUST specify how its objects express the originating TNs, and optionally the destination TNs, that they authorize. It MUST also contain sufficient metadata for replay protection. An intent verifier MUST confirm that the "orig" of the PASSporT is among the TNs attested by the intent object, and, where the intent object constrains destinations, that the "dest" of the PASSporT is among them. Without such constraints, a valid intent object could be attached by a dishonest agent platform or authentication service to an unrelated call: a fraudulent call could present the authority of a legitimate principal's mandate. TN constraints prevent this across numbers; validity periods, unique identifiers, and limits on the number of calls an intent object authorizes constrain it in time and quantity. Detecting reuse of an intent object beyond its permitted count requires state at relying parties, and is a matter of local policy. The signing key of an intent object is located by means defined by its intent type. For JWS-based types issued by OAuth authorization servers, the "iss" claim and the "kid" header parameter resolve the key through authorization server metadata [RFC8414], whose "jwks_uri" designates a JWK Set [RFC7517] containing the key. Locating a key does not establish trust in its holder: whether a relying party trusts a given intent authority is a matter of its own policy, typically arising from a relationship it already has within the relevant ecosystem. The TNs within an intent object may equally appear in other objects issued within the same ecosystem, such as a description of the agent, or evidence of the principal's right to use the TN. 8.2. Binding STIR to the Intent Object The STIR authentication service includes the intent object, or a reference to it, together with its digest, in the "intent" claim of the PASSporT, and signs the PASSporT. Its signature binds this call to this intent object: a relying party that retrieves an intent object by reference and finds that its digest matches knows that it is the object that accompanied the call, and not merely some object signed by the same intent authority. The signature of the authentication service over the digest asserts the attachment of the intent object to the call. It does not assert that the contents of the intent object are true, that its intent Peterson Expires 6 May 2027 [Page 14] Internet-Draft STIR Agents November 2026 authority is trustworthy, or that the authentication service has verified it, in the same way that the integrity mechanism of [RFC9795] asserts that third-party content is the content intended to accompany a call. An authentication service MAY verify an intent object before attaching it, and MAY decline to attach intent objects it cannot verify, as a matter of local policy. The external key of the intent authority never signs the PASSporT. STIR credentials continue to establish authority over TNs, as they do today, and intent authorities establish authority over intent. Neither is required to hold or understand the credentials of the other, and existing authentication services can carry intent objects without modification to their credentials. 9. Connected Identity The "act" and "intent" claims may equally appear in a PASSporT conveying connected identity [RFC9970], where they indicate that the call has been answered by an agent on behalf of the party whose identity is connected, identify that agent, and optionally express what the agent is authorized to do. The procedures of this document apply with the roles of the originating and terminating parties reversed. Constraints on the TNs for which an intent object is valid apply to the connected TN. Advertising the capabilities of a called party, such as the agent- native endpoints through which it may also be reached, is outside the scope of this document. 10. Intent Verification Procedures The PASSporT claims specified in this document do not alter the procedures of a STIR verification service. Where a signing credential carries JWT Claim Constraints requiring the "act" claim (Section 6.2), a verification service enforces them as it would any other constraint. An intent verifier processing a PASSporT that has been successfully verified performs the following steps: 1. If an "act" claim is present, record that the call is placed by an agent, and the identity of the agent. 2. For each intent entry whose type it supports, obtain the intent object, by-value or by-reference from "uri". If retrieval fails, the entry is unverified. Peterson Expires 6 May 2027 [Page 15] Internet-Draft STIR Agents November 2026 3. Where "dig" is present, compute the digest of the intent object and compare it with "dig". If they differ, the entry is invalid. 4. Verify the intent object as specified by its intent type, including the signature of the intent authority. If the signature does not verify, the entry is invalid. Whether the intent authority is trusted is determined by local policy; if it is not, the entry is unverified. 5. Confirm the bindings of Section 8.1: that the PASSporT "orig" (and, where constrained, "dest") are among the TNs authorized by the intent object, and that the current time is within its validity period. If not, the entry is invalid. 6. Confirm that the agent identified in the "act" claim of the PASSporT matches the actor authorized by the intent object. If they do not match, or if the PASSporT carries no "act" claim, the entry MUST be treated as invalid. 7. Confirm that any "crn" or Rich Call Data display information in the PASSporT is consistent with the intent object, where the intent type defines such consistency. An intent entry that passes these steps is verified. As in [I-D.ietf-webbotauth-httpsig-protocol], the distinction between an unverified entry and an invalid one matters: an unverified entry (of an unsupported type, whose retrieval failed, or whose intent authority is not trusted) carries no information either way, and the call proceeds as a call from an agent whose intent is unknown. An invalid entry (whose digest, signature, or bindings do not check) indicates either an error or an attempt to present intent that the principal did not authorize, and relying parties MAY treat it as a negative signal under local policy. An intent verifier MUST ignore entries of intent types it does not support. Neither an unverified nor an invalid intent entry has any effect on the verification of the PASSporT itself. An intent verifier that resides downstream of a verification service relies on that verification service having verified the PASSporT. The means by which a verified PASSporT, or the intent objects it references, are conveyed to a downstream intent verifier are outside the scope of this document. An intent verifier that wishes to support later examination of a call, for example for audit or traceback, SHOULD record the outcome of verification at the time of the call, rather than relying on the later availability of PASSporTs, certificates, or intent objects. Peterson Expires 6 May 2027 [Page 16] Internet-Draft STIR Agents November 2026 11. Producing Intent Principals will not, in general, compose intent objects themselves. In the common case, an agentic platform will translate the natural language request of a principal into a structured intent object, typically using a large language model, and the principal will at best confirm the result. This translation is the one step in this architecture that cannot be mechanically verified, and this document does not attempt to verify it. It is however important to state precisely what the signature of an intent authority does and does not establish. The signature of an intent authority attests that the principal approved a rendering of the intent object; it does not attest that the intent object accurately captures what the principal meant. Approval is meaningful only if: * The rendering shown to the principal is produced deterministically from the contents of the intent object, as defined by its intent type, and not composed by a language model. Otherwise, an agent could show the principal one thing while the intent object says another. * The system on which the principal confirms the intent object is operated by a party other than the agent platform that drafted it, such as a wallet, a payment credential provider, or an operating system. Existing work follows this pattern. OAuth Rich Authorization Requests [RFC9396] convey structured authorization details that an authorization server renders to the user for consent. Confirmation protocols for agent actions [I-D.rosenberg-aiproto-cheq] can render a signed description of a proposed action to the user through a confirmation server outside the scope of the agent's language model. An intent authority built on either would satisfy both conditions above. Most of what a principal intends is never stated. An agent that fills in unstated parameters, such as a price ceiling, is effectively authoring part of the intent. Intent types SHOULD therefore permit constraints to be distinguished by their origin: stated by the principal, derived from a standing policy authored by the principal, or inferred by the agent. Renderings SHOULD direct the principal's attention to inferred constraints. Intent objects need not, and cannot, be complete; they SHOULD bound the dimensions in which errors are costly or irreversible, such as amount, quantity, and timing, leaving other errors to the ordinary mechanisms of recourse. Peterson Expires 6 May 2027 [Page 17] Internet-Draft STIR Agents November 2026 With these provisions, an intent object divides the question of whether an agent acted properly into three: whether the agent's actions conformed to the intent object, which can be checked mechanically; whether the principal approved the intent object, which is attested by the intent authority; and whether the intent object captured what the principal meant, which only the record of the principal's original request can inform. The last is a matter for audit mechanisms outside the scope of STIR, such as those contemplated in [I-D.kuehlewind-audit-architecture]. 12. Acknowledgments This document was written with the assistance of an LLM. 13. IANA Considerations 13.1. JSON Web Token Claims [More TBD] This document requests that IANA register the following claim in the "Personal Assertion Token (PASSporT) Extensions" registry: * Claim Name: "intent"; Claim Description: Agent intent; Specification Document: [this document] 13.2. PASSporT Intent Types Registry This document requests that IANA create a new registry, "PASSporT Intent Types," with a registration policy of Specification Required [RFC8126]. Each entry contains a type name, a short description, and a reference to a specification satisfying the requirements of Section 7.2. Designated experts should verify that each registration addresses every item listed in that section. [Editor's note: initial entries, including the base intent type, are TBD.] 14. Privacy Considerations Calls placed by an agent using the TN of a principal disclose that TN to the called party, as any call from the principal would. The "act" claim additionally discloses the identity of the agent, which may reveal which services a principal uses. Unlike mechanisms for identifying automated HTTP clients [I-D.ietf-webbotauth-httpsig-protocol], which are unsuitable for agents tied to individual people, the agents contemplated here typically act for an individual who is identified by the TN itself; this heightens the importance of minimizing what intent objects disclose. Peterson Expires 6 May 2027 [Page 18] Internet-Draft STIR Agents November 2026 Intent objects may contain substantial information about a principal's activities. Intent types SHOULD minimize the information disclosed to the called party, and SHOULD support selective disclosure, for example through SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt], so that a merchant sees an order but not the principal's payment details, and an auditor sees what a dispute requires. Payment credentials and other sensitive data SHOULD NOT be carried in intent objects conveyed through STIR; they are better exchanged through the commerce protocols of the relevant ecosystem. Intent objects retrieved by reference expose the retrieval to the host of the reference. Hosts SHOULD use unguessable URIs, and SHOULD restrict retrieval to the validity period of the intent object. PASSporTs are real-time artifacts and are not intended to serve as durable records of calls; this document does not change that. Intent objects and other records retained for audit are subject to the retention policies of the ecosystems that issue and consume them. 15. Security Considerations The agentic platform is not trusted by this architecture. It conveys intent objects signed by intent authorities and PASSporTs signed by authentication services, and can forge neither. A compromised agent platform holding delegated STIR authority can, however, place calls under that authority, and can attach to them any intent object it possesses; the bindings of Section 8.1 limit the calls to which such objects can be attached. Replay of intent objects onto unrelated calls is addressed by TN constraints, validity periods, unique identifiers, and call limits (Section 8.1). Intent verifiers that do not maintain state about the identifiers of intent objects they have seen cannot detect reuse within the other constraints, and SHOULD NOT treat successful verification as evidence that replay has been prevented. An agent that does not wish to disclose itself can omit the "act" claim, and nothing in this document prevents it except where the TN holder mandates disclosure through certificate constraints (Section 6.2). The absence of an "act" claim does not establish that a call was placed by a human. Display information in Rich Call Data and "crn" values is asserted by the authentication service. A call reason that is inconsistent with the accompanying intent object could mislead a human answering the call; intent verifiers SHOULD perform the consistency check described in Section 10 where the intent type supports it. Peterson Expires 6 May 2027 [Page 19] Internet-Draft STIR Agents November 2026 The signature of an intent authority attests to approval of a rendering, not to the accuracy of the translation from a principal's request to an intent object (Section 11). The security of intent depends on deterministic rendering and on the independence of the confirmation surface from the agent. Locating the key of an intent authority through OAuth metadata establishes only that the key belongs to the issuer named in the object. Relying parties MUST NOT treat a successfully verified intent object as authorized unless they trust its intent authority under their own policy. Intent objects retrieved by reference introduce a network dependency into call processing, and the "uri" member is supplied by the originating side of the call. Intent verifiers SHOULD bound the time they spend retrieving intent objects, and treat retrieval failures as described in Section 10. Because retrieval is triggered by an incoming call, intent verifiers MUST guard against server-side request forgery, following practices such as those of [I-D.ietf-webbotauth-httpsig-protocol]: retrieving only HTTPS URIs, refusing addresses in private or otherwise non-public ranges, limiting or refusing redirects, accepting only successful (200) responses, and capping the size of retrieved objects. 16. References 16.1. 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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Peterson Expires 6 May 2027 [Page 20] Internet-Draft STIR Agents November 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, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, September 2021, . [RFC9118] Housley, R., "Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates", RFC 9118, DOI 10.17487/RFC9118, August 2021, . [RFC9795] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT) Extension for Rich Call Data", RFC 9795, DOI 10.17487/RFC9795, July 2025, . [RFC9970] Peterson, J. and C. Wendt, "Connected Identity for Secure Telephone Identity Revisited (STIR)", RFC 9970, DOI 10.17487/RFC9970, June 2026, . 16.2. Informative References [A2A] Linux Foundation, "Agent2Agent (A2A) Protocol Specification, Version 1.0", 2026, . [AP2] FIDO Alliance, "Agent Payments Protocol (AP2)", 2026, . Peterson Expires 6 May 2027 [Page 21] Internet-Draft STIR Agents November 2026 [I-D.ietf-oauth-selective-disclosure-jwt] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet- Draft, draft-ietf-oauth-selective-disclosure-jwt-22, 29 May 2025, . [I-D.ietf-webbotauth-httpsig-protocol] Meunier, T. and S. Major, "HTTP Message Signatures for automated traffic", Work in Progress, Internet-Draft, draft-ietf-webbotauth-httpsig-protocol-01, 29 October 2026, . [I-D.kuehlewind-audit-architecture] Kühlewind, M. and H. Birkholz, "An Architecture for Auditing Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit- architecture-01, 7 September 2026, . [I-D.rosenberg-agentproto-usecases] Rosenberg, J. and C. F. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-agentproto- usecases-00, 4 July 2026, . [I-D.rosenberg-aiproto-cheq] Rosenberg, J., White, P., and C. F. Jennings, "CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL)", Work in Progress, Internet-Draft, draft- rosenberg-aiproto-cheq-00, 19 October 2025, . [I-D.wendt-stir-vesper] Wendt, C. and R. Śliwa, "VESPER - Verifiable STI Presentation and Evidence for RTU", Work in Progress, Internet-Draft, draft-wendt-stir-vesper-11, 1 November 2026, . Peterson Expires 6 May 2027 [Page 22] Internet-Draft STIR Agents November 2026 [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, July 2002, . [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, September 2014, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9796] Wendt, C. and J. Peterson, "SIP Call-Info Parameters for Rich Call Data", RFC 9796, DOI 10.17487/RFC9796, July 2025, . [VI] Mastercard, "Verifiable Intent", 2026, . Author's Address Jon Peterson TransUnion Email: jon.peterson@transunion.com Peterson Expires 6 May 2027 [Page 23]