| Internet-Draft | Authorization-to-Reach Handles | August 2026 |
| Das | Expires 4 March 2027 | [Page] |
Many Internet and telephone communication systems treat possession of a routable identifier as sufficient to attempt contact. A telephone number, SIP URI, messaging handle, relay address, or marketplace contact reference can therefore remain a reusable reachability path after the purpose of disclosure has ended.¶
Existing IETF and industry mechanisms solve related but different problems. STIR and SHAKEN authenticate or attest originating identity. Virtual or masked numbers hide a persistent endpoint but commonly leave a substitute route active while the alias is valid. OAuth can express delegated API authorization. Spam scoring and call screening classify or reject an attempt after some path already exists.¶
This document describes an authorization-to-reach model. A visible communication handle is not, by itself, permission to create a communication effect. A request is held as a candidate until current, purpose-scoped, revocable, and optionally consumable authority is validated. The document is informational. It asks whether the IETF Applications and Real-Time area should define interoperable semantics or an encoding for that authority (for example a PASSporT claim, a SIP header or pre-INVITE check, or a reusable authorization object).¶
This work is not a 3GPP radio, core-network, or IMT-2030 architecture proposal. References to machine-scale or future-network traffic are motivational only. The intended protocol home, if any, is IETF work on SIP, STIR, messaging, and Internet communication identifiers.¶
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 4 March 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.¶
A recurring property of telephone numbers, SIP URIs, and similar handles is that knowing the identifier is usually enough to attempt a call, message, or notification. Networks may later authenticate, score, filter, or block that attempt, but some amount of routing, signaling, gateway work, or recipient notification commonly occurs first.¶
This document separates three things that current systems often collapse:¶
identity (who is speaking);¶
handle knowledge (how the destination is named); and¶
communication authority (whether this sender may create this effect, for this recipient, now, for this purpose, on this channel).¶
STIR answers the first question for originating telephone identity [RFC8224]. This document is about the third.¶
This revision is informational. It does not request IANA actions and does not specify a standards-track protocol.¶
The author is asking DISPATCH, and if appropriate STIR or SIPCORE, for guidance on four points:¶
Is authorization-to-reach (as distinct from origin authentication) an IETF problem, or only a local application, CPaaS, or operator policy feature?¶
If interoperable work is warranted, should the unit of work be (a) a PASSporT or RCD-style claim, (b) a SIP header or pre-INVITE authorization check, (c) a standalone authorization-object profile that SIP and messaging can carry, or (d) none of these?¶
Which existing working group, if any, is the right home: STIR, SIPCORE, ACE, or another ART group?¶
Which existing IETF mechanisms already provide a non-bearer, purpose-scoped, revocable communication-authority property that should be reused instead of defining a new object?¶
The intended next step, if the list agrees the problem is in scope, is a narrow follow-on draft containing only the authorization object and one protocol binding — not a network architecture.¶
This document addresses application-layer and session-layer communication identifiers used on the Internet and in SIP/IMS/CPaaS deployments: telephone numbers used in SIP, SIP URIs, messaging handles, and similar references.¶
This document is not:¶
a 3GPP working-item proposal, radio-interface design, or 5G/6G core-network architecture;¶
an IMT-2030 or ITU-R system description;¶
a replacement for STIR, SHAKEN, SIP identity, OAuth, or number masking;¶
a complete anti-spam, anti-phishing, or lawful-intercept specification;¶
a claim of quantified energy or bandwidth savings.¶
Where future programmable or machine-originated traffic is mentioned, it is only to explain why reusable handles become a larger abuse surface. Any radio, slicing, AI-RAN, or 3GPP service-exposure work belongs in 3GPP or other SDOs. The IETF question is whether two independently implemented SIP, STIR, or messaging systems need a common way to say “this handle does not authorize this contact.”¶
A user searches a map or business directory and taps “contact” on plumber Business B. Today, if the user or platform exposes a telephone number or SIP URI, B can retain that identifier and reuse it outside the enquiry.¶
Desired outcome: B may contact the user only for that enquiry, on an approved channel, for a short window and a small attempt quota. Copying the visible handle into another application does not create a new live route.¶
Actors:¶
U — the user / recipient;¶
D — discovery or marketplace application;¶
B — the business / caller;¶
G — grant or authorization service (may be part of D, a carrier, or a recipient-controlled service);¶
T — terminating enforcement point (SBC, SIP AS, CPaaS, or equivalent).¶
Call flow:¶
U selects Business B inside a search result in D.¶
D requests a grant from G with at least: sender B, recipient U, purpose bound to this enquiry, channel, expiry, and maximum attempts.¶
G returns a grant identifier and associated authorization state. The handle shown to B is not independently a general route to U.¶
B initiates a SIP request or message. Signaling carries or references the grant (see Section 10).¶
T validates that the grant exists, is unexpired and unrevoked, has remaining quota, matches the authenticated origin, and matches purpose and channel. STIR may be used to authenticate the origin; it does not replace this check.¶
On success, T allows ringing, notification, or session setup. On failure, T rejects the request (for example SIP 403) and does not create the communication effect.¶
After expiry or quota consumption, the same visible handle retained by B does not authorize a new effect. A new contact requires a new grant.¶
A buyer contacts a seller about listing 123. G issues authority bound to that listing, channel, and a validity window that ends on sale, cancellation, or timeout. A copy of the visible handle in the seller’s CRM is not a live route for unrelated listings or later marketing.¶
A ride or delivery assigns Driver D authority to reach Passenger P only for ride R, until drop-off plus a short grace period. After the transaction closes, a retained handle does not ring.¶
A user asks an assistant to query three hotels for availability tonight. Each outbound attempt uses a separate grant bound to that hotel, that enquiry, a channel, an expiry, and an attempt quota. Discovery of the hotel’s public handle is not a reusable right to contact it later for another purpose. This case is included because software can initiate contact at machine speed; it is not a request that IETF specify AI-agent architecture.¶
Once a telephone number, virtual number, SIP URI, relay address, messaging handle, or marketplace contact reference is disclosed, it may be retained and reused beyond the original interaction. The recipient can later revoke or block, but the identifier often remains sufficient to initiate some routing or notification while it is valid.¶
A network can correctly authenticate a caller and still lack a standard answer to a different question: is this authenticated entity authorized, at this moment, for this purpose, through this channel, to cause this communication effect toward this recipient?¶
Whether possession of a visible identifier should itself activate a communication path.¶
How a recipient, marketplace, directory, or network can grant contact authority for one purpose without granting reusable future reachability.¶
How that authority can expire, be consumed, or be revoked without replacing the underlying identity.¶
How an authenticated caller can still be denied for lack of current recipient-specific authority.¶
How unauthorized attempts can be rejected before session, notification, or media resources are released, where the deployment can enforce that early.¶
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in [RFC2119] and [RFC8174] when, and only when, they appear in all capitals.¶
Handle — A visible communication reference such as a telephone number, SIP URI, messaging address, or marketplace contact identifier.¶
Communication Authority — Current authorization to cause a particular communication effect under defined constraints.¶
Grant — A bounded authorization object or authoritative policy state representing communication authority. Also called a Capability-Bound Authorization Token (CBAT) when encoded as a token.¶
CVID — Capability-Validated Inbound Descriptor: a handle associated with grant state and not intended to operate as independently reusable reachability authority.¶
Candidate Request — A proposed call, message, notification, or session that has not yet been authorized to become effective.¶
Blocked Path — Ordinary routing reaches an enforcement point that rejects a request lacking a valid grant.¶
Pre-Routing Authorization — Grant validation occurs before full routing or destination resolution.¶
Absent Path — The visible handle alone does not resolve to or activate the effective communication path; a valid grant is required before the path or notification resource is released.¶
Virtual numbers and masking services can hide the recipient’s underlying telephone number and can apply forwarding rules, expiry, and screening. While a substitute number or relay address is active, it commonly remains independently routable to a proxy or gateway. Possession of the alias can still be enough to initiate an attempt unless additional authorization is required.¶
The stronger property discussed here is not hiding the permanent endpoint. It is that the visible handle is not itself communication authority. A virtual number may still be used as a transport-compatible façade if a current grant is required before the protected effect is released.¶
STIR defines mechanisms for securely identifying the originators of SIP requests and verifying authorization to use originating identity information [RFC8224]. PASSporT provides signed identity assertions [RFC8225]. SHAKEN adds attestation and origination information [RFC8588]. Messaging use cases for STIR are described in [RFC9475].¶
That work addresses caller-identity authenticity. It does not by itself represent recipient-issued, purpose-scoped, consumable permission to contact a particular recipient. A STIR-valid caller may still be unwanted, out of purpose, over quota, expired, or revoked for a specific interaction.¶
A destination claim in a PASSporT binds asserted call information. It should not be confused with recipient consent or a recipient-scoped grant to create reachability.¶
Combining masking with STIR/SHAKEN improves callee privacy and origin authenticity at once. The remaining gap is authorization-to-reach. The masked endpoint may remain dialable while active, and a correctly authenticated caller can still lack current permission for this recipient, purpose, channel, or quota.¶
OAuth can express fine-grained authorization. Rich Authorization Requests are defined in [RFC9396]. Sender-constrained access tokens may use mechanisms such as DPoP [RFC9449]. Current OAuth security guidance is in [RFC9700].¶
OAuth can be a building block for a grant. It does not itself define telephone or messaging reachability, recipient-specific contact authority, or a rule that possession of a visible handle creates no effective route until communication authority exists.¶
These controls decide whether an already-present attempt looks legitimate or unwanted. They are often applied after some route, signaling transaction, or recipient-side event exists. Authorization-to-reach asks whether the requester has positive authority to create the effect in the first place.¶
| Approach | Primary Property | What May Remain |
|---|---|---|
| Virtual / masked number | Hides or substitutes the persistent endpoint. | Alias may still be independently routable while active. |
| STIR/SHAKEN | Authenticates or attests origin identity. | Does not by itself establish recipient-specific permission to contact. |
| Virtual number + STIR/SHAKEN | Combines callee privacy with origin authenticity. | Still does not inherently create purpose-scoped, consumable reachability authority. |
| OAuth RAR + DPoP/mTLS | Fine-grained, optionally sender-constrained API authorization. | Telecom contact-authority semantics and path-release rules still need definition. |
| Spam / reputation / screening | Classifies or rejects risk. | Often evaluates after some attempt exists. |
| Temporary alias | Limits exposure duration. | Can remain bearer-like during validity. |
| Authorization-to-reach grant | Separates handle knowledge from current communication authority. | Needs an encoding, an enforcement point, and coverage of alternate paths. |
Identifier possession MUST NOT, by itself, constitute communication authority.¶
A caller, business, application, or automated client may possess a handle while lacking authority to create the protected communication effect. Authority is represented by current policy state or a bounded grant that can be scoped, revoked, expired, consumed, or denied independently of the visible handle.¶
This section is an informative sketch so reviewers can see the intended unit of work. It is not a proposed registry or on-wire format.¶
| Field | Meaning |
|---|---|
| grant_id | Unique identifier of this grant or logical communication act. |
| from | Authorized origin (service, business, or user identity). STIR may independently attest the SIP origin. |
| to | Recipient or recipient class. |
| purpose | Opaque purpose or transaction identifier (for example listing-123). Free-text purpose is not assumed to be mechanically verifiable. |
| channel | Permitted effect class: voice, messaging, notification, or another constrained channel. |
| exp | Expiry time. |
| max_attempts | Quota of logical communication acts. |
| epoch | Revocation or policy generation. |
| jti / nonce | Replay discriminator where single-use or freshness is required. |
| aud | Intended enforcement point or audience. |
Possible encodings, if later specified, include PASSporT claims [RFC8225], a JWT or CWT profile, or OAuth authorization details [RFC9396]. This document does not select an encoding.¶
A copied handle without a current matching grant SHOULD NOT be sufficient to create the communication effect in a deployment that claims this property. A copied grant object SHOULD NOT act as an unconstrained bearer credential; sender binding is a protocol-design issue for any follow-on specification.¶
If DISPATCH concludes that interoperable work is appropriate, the following surfaces appear most relevant. They are listed so the discussion can choose one; this document does not standardize any of them.¶
STIR / PASSporT: an optional claim binding destination and grant identifier to an authenticated origin. This would complement, not replace, existing PASSporT claims. A destination claim alone remains insufficient as recipient permission.¶
SIPCORE: a SIP header, reason code, or pre-INVITE check performed by a proxy, SBC, or application server before ringing or notification.¶
Authorization token profile: a reusable object that SIP, messaging, and HTTP-based CPaaS APIs could carry, possibly using OAuth RAR or ACE patterns rather than a new framework.¶
Some deployments can implement the whole model inside one marketplace or CPaaS. IETF work is justified only where independently implemented systems need common grant semantics, signaling, verification, replay and consumption rules, or inter-provider behavior.¶
A requester prepares an inbound communication using a handle and, where required, a grant reference.¶
The request is treated as a candidate. It is not yet an effective call, message, notification, or media session.¶
The enforcement point evaluates current authority for the requested effect.¶
Validation may consider origin, recipient, purpose identifier, channel, time, quota, freshness, revocation epoch, and audience.¶
If validation fails, the communication effect remains uncreated.¶
If validation succeeds, only the bounded path required for the permitted effect is released.¶
Where quota or single-use applies, state is reserved or consumed so that replay is not a new grant.¶
Later reuse requires still-valid or newly issued authority.¶
A conventional address resolves and signaling reaches an enforcement point such as an SBC, application server, or CPaaS. That point validates the grant and rejects unauthorized attempts before the protected effect proceeds. This profile interworks with legacy routing but does not eliminate all upstream signaling.¶
Authorization occurs before full routing. After a grant is confirmed, a routing token, temporary route, or resolved destination is released. Unauthorized attempts can stop before more expensive downstream processing.¶
The visible handle alone does not resolve to an effective route, gateway destination, media allocation, or notification path. The path is absent until authorization succeeds.¶
Where PSTN, SIP, or legacy infrastructure cannot suppress early signaling, an implementation MUST NOT claim complete absent-path behavior. It may claim blocked-path or pre-routing behavior at the earliest enforceable boundary.¶
Software clients, programmable communication APIs, and automated assistants can generate, retry, and fan out contact attempts faster than human callers. A handle that was tolerable as a reusable human-scale address becomes a high-rate attempt surface.¶
That observation is about traffic shape on SIP and messaging systems the IETF already specifies. It is not a proposal to place this mechanism in a 3GPP radio protocol, an AI-RAN controller, or an IMT-2030 architecture document.¶
If unauthorized attempts are rejected before session or notification resources are created, operators may also see less wasted signaling. That is a possible operational benefit. It is not a quantified energy or “Green 6G” claim, and it is not the justification for IETF work. The justification, if any, is interoperable authorization-to-reach semantics.¶
This document does not specify a millisecond target. Real-time voice and messaging should keep the admission check local to or near the enforcement boundary, cache non-sensitive policy epochs where safe, and avoid a mandatory long-haul round trip for every attempt. Feasibility is a measurement question under realistic setup rates.¶
The model does not require replacement of E.164 numbering, SIP [RFC3261], IMS, SBCs, or application servers. A mediation layer can validate a grant and only then originate conventional signaling toward a legacy endpoint. If the same endpoint remains reachable through an uncontrolled ordinary number, the deployment cannot claim complete absent-path protection for that endpoint.¶
Inter-provider use requires agreement on trust anchors, grant-issuer discovery, freshness, failure semantics, and which network enforces the grant. This version does not mandate a federation model.¶
Replay: quota or single-use grants need atomic consumption or equivalent replay-resistant state. SIP retransmission of the same transaction is not a new act.¶
Revocation and TOCTOU: enforcement should check freshness close to path release.¶
Confused deputy: authority for one recipient or purpose must not widen to another.¶
Authorization-service DoS: unauthenticated requests should trigger bounded work.¶
Alternate paths: absent-path claims fail if another route, API, or identifier reaches the recipient without an equivalent grant.¶
Forking, forwarding, and transfer: deployments must define whether authority follows the recipient identity, a device, or a new participant set.¶
Availability: ordinary protected communications may fail closed. Emergency and legally mandated access paths require separate policy and MUST NOT be disabled by grant-service failure.¶
A privacy objective is to reduce disclosure of persistent contact identifiers. A platform can expose a query-scoped handle without revealing the recipient’s underlying number or long-lived messaging identity.¶
A grant identifier should not become a new global tracking identifier. Handles and grants should be scoped, rotated, or unlinkable where practical. Authorization messages should carry only what the enforcement point needs. Purpose and business-identity metadata can themselves be sensitive.¶
Migration can be incremental: one marketplace for callbacks, one CPaaS class of programmatic calls, or one traffic class at a carrier. Deployments should name the profile they implement (blocked path, pre-routing, or absent path) so a gateway-level check is not described as if it prevented all upstream routing.¶
This document requests no IANA actions. If a later specification defines a SIP parameter, PASSporT claim, media type, OAuth authorization-details type, or other protocol element, that document will request the corresponding registrations.¶
STIR can strengthen origin identity. Masking can hide a persistent endpoint. OAuth can delegate API access. Screening can classify an attempt that already exists. Those tools remain useful.¶
The remaining question is whether possession of a communication handle should itself create reachability. This document says no, describes a grant that can carry the missing authority, and asks the IETF ART area whether that grant needs an interoperable encoding and where that work should live.¶
These questions are written so the model is not mistaken for recipient preference, terms-of-service, or local application policy. Policy can say “do not call after the job.” The architectural claim is that a handle plus a copied alias still MUST NOT create a communication effect unless a current grant is valid at an enforcement point. Several answers therefore talk about SIP transactions, path release, replay, forking, and bypass routes — not about user settings.¶
No. A virtual number primarily substitutes or masks an endpoint. It may have expiry and policy, but while active it commonly remains routable to a proxy or gateway. The grant is the capability. The visible handle is a name. A virtual number can be a transport façade only if separate current authority is required before the protected communication effect is released.¶
STIR/SHAKEN strengthens authenticity of originating identity and authorization to use telephone-number identity information. This model addresses whether that authenticated originator is presently authorized to contact this recipient for this purpose, channel, time, quota, and interaction. The two mechanisms are complementary. STIR can feed the `from` check; it does not issue the grant.¶
The destination claim binds asserted call information to a signed identity assertion. It is not evidence that the recipient granted current, purpose-scoped permission to be reached, and it does not require the destination path to remain absent until such permission exists.¶
That combination can hide the callee's persistent number and authenticate the caller's asserted number. A grant adds a third dimension: current communication authority. A correctly authenticated caller presenting a valid masked destination can still be denied because the interaction is expired, out of purpose, over quota, revoked, or otherwise unauthorized.¶
OAuth is a strong authorization framework and can encode a grant. Rich Authorization Requests can carry fine-grained details, and DPoP or mTLS can sender-constrain tokens. OAuth does not by itself standardize telecom reachability: whether a visible handle can resolve, whether the effective path is withheld until authorization, how a logical call attempt is consumed, and how this composes with SIP/PSTN/IMS routing.¶
No. Existing signatures, MACs, secure channels, PKI, OAuth tokens, DPoP-style proof of possession, HSMs, TEEs, or carrier policy systems may be used. The contribution is communication-authority and path-release semantics, not a new cipher.¶
Possible points include a SIP proxy, SBC, application server, service-exposure gateway, carrier API gateway, directory or resolver, or another component that can prevent the protected effect from proceeding. Placement should be as early as practical while retaining authoritative knowledge of destination policy and current grant state. That placement is a protocol-binding question, not a user-preference toggle.¶
Yes through mediation. A gateway can validate a grant and, only on success, originate conventional PSTN or SIP signaling toward the legacy endpoint. The endpoint need not understand the grant. If the same endpoint remains reachable through an uncontrolled ordinary number, the deployment cannot claim complete absent-path protection.¶
In a blocked path, the address resolves and signaling proceeds until a gateway or service rejects it. In an absent path, the visible handle alone does not create the effective route. Authorization must first release or resolve the route. These are different enforcement timings, not different privacy policies.¶
It can if implemented as a mandatory distant round trip. The preferred design is local or near-local verification, cached policy epochs, compact evidence, and co-location with the routing boundary. No universal millisecond figure is claimed. Operators should benchmark setup latency at expected call rates, including cache misses, roaming, failover, and revocation checks.¶
No. The intended surfaces are SIP, STIR/PASSporT, messaging handles, and an authorization object that Internet communication systems could share. Radio interfaces, 5G/6G core architecture, slicing, and IMT process documents are out of scope. Machine-originated traffic is mentioned only because it increases attempt rate on existing SIP and messaging paths.¶
Possibly, by preventing unauthorized attempts from traversing deeper service chains, allocating media, or waking applications. That is an operational side effect. It is not a quantified energy claim and is not the reason to do IETF work. Net cost must subtract authorization lookup and cryptography and therefore requires measurement.¶
Potentially, but not automatically. Downstream signaling and media for never-authorized attempts can fall. Authorization messages add traffic. Compact local validation can make the trade favorable under high unwanted-attempt rates.¶
Automated clients can initiate, retry, and fan out contact at machine speed using ordinary SIP and messaging APIs. A reusable handle then becomes a programmable reachability capability. The IETF question remains handle-plus-grant semantics, not agent frameworks.¶
The authorization plane should avoid expensive work before basic authenticity and rate limits are established. Deployments can use local verification, issuer-discovery caches, epoch-based revocation, compact signed evidence, and hierarchical policy. Stateful single-use guarantees should be reserved for traffic classes that need them.¶
This is an availability and fail-mode protocol question, not a preference setting. A fail-closed profile preserves the authorization property but can reduce availability. Emergency and legally mandated paths require independent treatment and MUST NOT be disabled by ordinary grant-service failure.¶
A federation needs issuer discovery, trust anchors, freshness semantics, privacy rules, and agreement about which network enforces the grant. Evidence may be verified locally or validated online. This draft does not prescribe one federation model.¶
It should not. Query-scoped or session-scoped handles and grant identifiers should be rotated, minimized, or made unlinkable where practical. A globally stable handle would undermine the privacy goal. Purpose and business-identity metadata can also be sensitive.¶
The resolver should perform bounded work for unauthenticated requests, apply rate limits, cache safe policy data, and avoid expensive remote lookups or public-key operations until basic admission checks pass. The grant mechanism MUST NOT become an amplification vector.¶
Compare baseline and grant-enforcing deployments on the same traffic mix: signaling bytes, CPU time, SBC transactions, fraud-analysis work, application wakeups, media reservations, setup latency, and energy per admitted and rejected attempt, reported by deployment profile.¶
Emergency and legally mandated access paths MUST NOT be subject to ordinary grant authorization and MUST NOT be disabled by grant-service failure. Absent-path and fail-closed profiles apply to protected ordinary communications. Emergency numbering needs its own always-available routing policy.¶
The architecture changes when a path is created, not whether an authorized communication remains observable to lawful intercept once established. Deployments in jurisdictions with intercept obligations need intercept points positioned after path establishment. This document does not define an intercept architecture.¶
A grant can technically enforce constraints that a legal regime already requires. It is not a substitute for legal consent, lawful basis, or retention rules. Law is not the enforcement mechanism; the enforcement mechanism is grant validation at a communication-bearing boundary.¶
This document does not mandate a single issuer. The recipient, a carrier, a marketplace or directory, or a federated authority acting for the recipient may issue grants. The enforcement point MUST be able to establish current authority back to a trust root it recognizes. Issuance hierarchy is a follow-on specification issue.¶
This version does not mandate one denial behavior. Deployments may use a silent drop, a standard rejection such as SIP 403, a redirect to an authorization-request path, or another binding-specific response. Denial MUST NOT leak sensitive grant state.¶
Decide whether authorization-to-reach needs an interoperable object or signaling element in the ART area, and if so whether that element is a PASSporT claim, a SIP header or pre-INVITE check, a reusable token profile, or reuse of an existing mechanism. This version is informational and requests no IANA actions.¶
No. Application policy, IAM, and recipient blocklists can exist and still leave a live route: possession of the handle remains enough to create an attempt. The architectural property is that handle possession is not path-release authority. Enforcement happens at a communication-finality boundary (resolver, SBC, AS, gateway), with fail-closed behavior for ordinary protected communications. That is a protocol and routing property, not a settings page.¶
A marketplace may grant seller-to-buyer authority, a directory may mediate an enquiry, an enterprise directory may authorize contact initiation, a recipient-controlled service may issue authority, or a standardized authorization-request exchange may be used. Requesting a grant MUST NOT itself create an unrestricted communication path.¶
It can if designed poorly. Requesting authority MUST be distinguished from delivering arbitrary content to the recipient. The request path may require sender authentication, rate limits, recipient policy, quotas, reputation, mediation, or proof of an active transaction. Unwanted traffic MUST NOT simply move from INVITE bodies to grant-request bodies.¶
The stronger design SHOULD NOT rely solely on bearer semantics. A copied grant artifact SHOULD NOT automatically give another party the same communication authority. Authority may be bound to an authenticated sender, key, application identity, transaction, recipient, channel, or other protected context. Binding is a protocol-design question for any follow-on specification.¶
If one controlled path requires a grant while another directly routable path remains open, the stronger reachability property has not been achieved. A deployment claiming absent-path semantics MUST identify communication-bearing paths that can reach the protected endpoint and ensure unauthorized paths cannot bypass the check. That may require coordination across SIP, PSTN gateways, messaging services, application relays, notification services, and alternate identifiers. This is why the model is not local app policy: policy on one app cannot close the other paths.¶
Forwarding is an authority-scope question. If sender A is authorized to contact recipient B and B forwards to C, the binding must define whether authority applies only to B, whether designated forwarding is a recipient-controlled consequence, or whether C needs independent policy. Sender authority and recipient-controlled routing MUST be distinguished.¶
Transfer and conferencing may create relationships not present in the original grant. A binding should define whether the grant permits transfer, conferencing, added participants, media redirection, or delegation. Where those actions expand scope, additional authorization may be required.¶
Retransmission MUST NOT automatically consume a new grant. SIP retransmits because of loss or transport behavior. Grant semantics need a stable transaction identifier so retransmission of the same attempt is distinct from a new logical communication act.¶
SIP can fork one request toward multiple registered contacts. The model must define whether authority applies to the recipient identity, one device, all registered devices, the first answered branch, or a specified set. Consumption MUST NOT treat protocol-level forks as multiple independent authorized communications unless policy says so.¶
A grant SHOULD NOT remain indefinitely reusable unless policy explicitly allows reuse. Replay resistance may use expiry, nonces, transaction identifiers, sequence state, single-use state, sender binding, recipient binding, or consumed-state tracking. Online, offline, and hybrid verification have different freshness trade-offs.¶
Single-use refers to one logical communication act, not one packet. One authorized call may involve retransmissions, provisional responses, multiple signaling messages, and media setup. The protocol binding MUST define the logical act to which the grant is bound.¶
Revocation may occur when permission is withdrawn, a transaction ends, abuse is detected, an account is disabled, or policy changes. Implementations may use short-lived grants, online validation, revocation lists, epoch state, or provider-maintained grant state. Latency versus rapid revocation is a protocol-design trade-off.¶
The stronger model should say whether final enforcement evaluates only the issued grant or also current policy state. For revocable or higher-risk contexts, the final boundary may re-validate freshness or epoch before allowing the effect.¶
Yes, if a grant is approved, relevant state changes, and the effect is later created from stale approval. Mitigations include short validity windows, transaction binding, policy epochs, final-boundary revalidation, or atomic authorization and effectuation. An authorization decision MUST NOT become detached from the concrete communication act.¶
Declared purpose such as “plumbing enquiry” is not always observable on the wire. The model distinguishes policy-declared purpose from mechanically enforceable attributes: sender, recipient, transaction identifier, channel, validity, attempt quota, and service context. Arbitrary semantic purpose is not assumed to be technically verifiable.¶
A leak may expose a number, SIP URI, or messaging handle. Under conventional reachability, possession of that data is enough to attempt contact. Under this model, compromise of the identifier does not by itself compromise communication authority. The architecture does not prevent the breach; it reduces the value of stolen identifiers as reusable routing credentials.¶
No. It may reduce unauthorized origination that depends only on knowing a handle. Phishing by an authorized sender, account compromise, and malicious content remain separate problems.¶
Yes, if centralized or logged carelessly. A grant service may learn who attempted to contact whom. Designs should minimize retained metadata, stable correlation identifiers, unnecessary purpose disclosure, and cross-service linkability. A global central authority is not required.¶
Yes. A grant need not be single-use. It may permit one message, two attempts, one transaction, a session window, business hours, or a renewable relationship. Permitted scope is explicit rather than unlimited because an identifier is known.¶
Possible elements include grant semantics, an object format, SIP header or body usage, a challenge or pre-INVITE check, grant discovery, replay and consumption rules, revocation signaling, and capability negotiation. IETF work is relevant where independently implemented systems need those common semantics. If an existing mechanism already provides the required property, it should be reused.¶
Not necessarily. A SIP extension is one possible binding. Alternatives include a PASSporT claim, an existing authorization framework, an HTTP grant exchange, or provider-to-provider signaling. Use cases and requirements should be fixed before selecting the binding.¶
Knowledge or possession of a communication identifier is not, by itself, sufficient authority to create the communication effect. A candidate request additionally requires a current grant tied to sender, recipient, context, channel, validity, and other enforceable constraints. That property is what distinguishes this model from recipient policy that only acts after the attempt already exists.¶