| Internet-Draft | STIR Agents | November 2026 |
| Peterson | Expires 6 May 2027 | [Page] |
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.¶
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 (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.¶
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] 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].¶
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.¶
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:¶
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].¶
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.¶
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.¶
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.¶
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.¶
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.¶
The use cases above motivate the following requirements:¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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.¶
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:¶
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" }
]
}
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:¶
The format and encoding of the intent object, and whether it is conveyed by value, by reference, or either.¶
Who signs the intent object, and how a relying party resolves the signer's key and evaluates its authority.¶
How the intent object identifies the principal and the agent, including whether it supports the delegation semantics of Section 6.¶
How the intent object is bound to calls, satisfying Section 8.1.¶
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.¶
A canonical human-readable rendering of the intent object, produced deterministically from its contents (see Section 11).¶
Whether, and how, the intent object distinguishes constraints stated by the principal from constraints inferred by an agent or derived from a standing policy.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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:¶
If an "act" claim is present, record that the call is placed by an agent, and the identity of the agent.¶
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.¶
Where "dig" is present, compute the digest of the intent object and compare it with "dig". If they differ, the entry is invalid.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
This document was written with the assistance of an LLM.¶
[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]¶
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.]¶
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.¶
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.¶
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.¶
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.¶