Summary

  • The live IETF Datatracker page describes charter-ietf-stir-02-00 as a proposed recharter in internal IESG/IAB review, with two BLOCK positions and no telechat date.
  • The proposal says STIR can authenticate a call event and authorization to use a telephone number but cannot standardly identify the entity behind that authorization.
  • It would add an entity identifier associated with PASSporT and extend work on certificate transparency, out-of-band discovery and connected identity.
  • The charter deliberately excludes legal vetting policy, regulatory requirements and governance rules for numbering authorities, certification authorities and transparency services.
  • A useful output is therefore a privacy-bounded receipt joining number scope, entity capacity, credential lineage and a current status or correction pointer—without treating any one field as proof of a person, a truthful call or a legal entitlement.

A valid assertion with an unnamed principal

Imagine a business that owns a well-known callback number but routes outbound calls through several providers. One provider presents a signed PASSporT and a valid certificate covering that number. The cryptography can answer whether the signer was authorized to make the number assertion. It may not answer whether the signer represents the business, a contractor, a call centre or another delegate further down the chain.

That is not a hypothetical flaw invented outside the standards process. The proposed STIR charter says operational experience has shown that STIR authenticates the event of a call and authorization to use a number, yet offers no standardized way to identify the entity behind that authorization. Numbers may be used through several services or providers acting on a holder's behalf, and a verifier may not know which entity a delegate certificate represents.

The distinction is easy to lose because everyday speech uses “caller identity” for several different things. A displayed number is an identifier. Authority to use it is a permission claim. The entity exercising that authority is a principal. The human speaking, the brand shown to a recipient and the truthfulness of the message are further claims. A signature can secure one layer without settling the others.

The proposal is still an authority question

At the evidence cutoff, the Datatracker labels the text a proposed recharter, last updated on 30 July 2026. It is in Start Chartering/Rechartering (Internal Steering Group/IAB Review), has two BLOCK positions and has enough positions to pass once those are resolved. No telechat date is listed.

Those details matter because the proposal is not the charter in force. The approved version 02 authorizes work around verifying a calling party's permission to use a number, certificate delegation, out-of-band mechanisms and related telephone-number communications. The new text would explicitly add a means to associate a PASSporT with an identifier for the entity holding the right to use an assigned number. It would also authorize certificate-transparency mechanisms, broader credential discovery and connected identity.

The two BLOCK positions do not prove that the identity idea has been rejected, and “enough positions to pass” does not approve it. The correct public state is proposed scope under review. Any later article must check whether the wording, exclusions and state changed.

Delegation proves scope, not every identity claim

The existing standards explain why the gap exists. RFC 8225 allows the signer of a PASSporT to differ from the originating identity. The signer may be a device or a network entity that has authority to make the assertion. Certificate credentials and the signature establish that authority within a trust model; they do not automatically describe the business relationship behind it.

RFC 9060 handles delegation by requiring a delegate certificate's TN Authorization List to be equal to or narrower than its parent. That is valuable evidence: it prevents a child credential from claiming a wider telephone-number scope than its parent. It also supports real operating patterns in which an enterprise uses several outbound providers.

But TNAuthList is a scope object. RFC 8226 even permits it to carry authority without identifying the certificate owner through a subject name, including for privacy reasons. A verifier can therefore know that a credential covers a number while still lacking a stable, standardized answer to which entity is acting and the capacity in which it acts.

The recharter should not solve this by forcing a legal name or natural-person identity into every call. That would collapse privacy, jurisdiction and disclosure policy into a protocol field. An entity identifier should instead be typed: it should say which identifier scheme is being used, what capacity is asserted, who made the binding, when it was verified and where its current status can be checked.

Transparency makes issuance visible, not self-correcting

The active STI Certificate Transparency draft supplies another part of the evidence chain. It proposes append-only logs for STI certificates, Signed Certificate Timestamps, monitors and auditors. A verification service could require evidence that a certificate was logged, and parties responsible for numbers or provider codes could watch for unexpected issuance.

This is useful because an entity binding is only as trustworthy as its issuance lineage. If duplicate or unauthorized credentials appear, public evidence can make the event detectable. But the draft is also clear about the limit: what parties do after detecting mis-issuance is outside its scope. A log does not revoke a certificate, decide which claimant is correct or tell a terminating provider how to treat a call.

Three states must therefore remain distinct: a credential exists, a credential was publicly logged, and a credential is currently accepted under the relevant policy. Treating an SCT as current authorization would make transparency impersonate governance.

A receipt with public and protected layers

The smallest coherent record would join four components. First is the telephone number or range and the parent/delegate scope. Second is a stable entity identifier plus a narrowly stated capacity such as holder, authorized provider or delegate. Third is the issuer, certificate lineage, validity interval and transparency receipt. Fourth is a current status, revocation or correction pointer naming the institution competent to change the result.

The public or call-carried layer need not reveal contracts, subscriber files, personal names or corporate ownership evidence. It can expose the identifier scheme, capacity, binding authority, dates, credential hash or reference, log proof and status endpoint. Protected systems can retain legal-name evidence, vetting records, service agreements and dispute files.

This division follows the proposed charter's own exclusions. The IETF can define interoperable syntax and proof semantics. Numbering authorities, providers, certification authorities, regulators and courts remain responsible for the policy decisions they actually control. A correction must identify which layer changed: number assignment, entity binding, certificate status, log evidence or call-treatment policy.

The result would not say “this caller is trustworthy.” It would say, more precisely, “this credential covers this number; this identified entity is asserted to act in this capacity; this authority made and logged the binding; this is where its current status and correction history can be checked.” That is a narrower claim—and a more governable one.

Sources

  1. Proposed STIR recharter
  2. Current approved STIR charter
  3. STIR Working Group documents
  4. STI Certificate Transparency Internet-Draft
  5. RFC 8225: PASSporT
  6. RFC 8226: STIR certificates
  7. RFC 9060: STIR certificate delegation
  8. STIR interim agenda, 9 April 2026
  9. Heng Lu, The Policy Mirror