Digital identity — the standards contest for portable trust across telecom, the web, agents, and supply chains

The narrowest frame for the work in this library is “telephone-number caller authentication.” The widest is “digital identity for real-time communications,” and beyond even that sits the question this page is about: across every industry now trying to make identity verifiable at internet scale — telecom, the web, autonomous agents, media, supply chains — who decides whether the trustworthy version is open?

The organizing claim here is that trust at internet scale is a commons, and a commons is built — or enclosed — through standards. Whether a call you can verify, an identity you can carry between providers, or a provenance signal you can check is open and portable or locked to one vendor is usually settled in a working group years before it is settled in a market. That contest is chronically under-covered because it is slow, procedural, and unglamorous, and it is where the future of digital identity is actually being decided. This page is the wide-angle read of that contest; the rest of the library zooms into the parts of it I work in directly.

The lens: four axes and a privacy test

The same evaluative axis works in every one of these industries, which is part of why treating them as one subject is useful rather than forced. For any identity capability and the standard behind it, ask where it sits on four axes:

• open ↔ proprietary — a multi-vendor spec in a neutral body, implementable without permission, versus one vendor’s closed system.
• interoperable ↔ captured — genuinely portable and forkable versus an open spec steered so that one player controls the surface everyone else must conform to.
• consumer-protective ↔ extractive — protects the person being verified through data minimization, consent, and portability, versus gatekeeping or monetizing them.
• adopted ↔ announced — real implementations and deployments versus a press-release “standard” with no uptake.

Privacy is not a tiebreaker applied after the fact; it is a first-class reason a design is interesting. The concrete test is always the same four questions: what can the verifier learn, what can it link, what must the subject hand over, and what happens to it afterward? A design that makes correlation structurally impossible, discloses only what a given transaction needs, or moves control to the subject earns attention on that merit alone. The recurring shapes that deliver those properties — unlinkability, selective disclosure, ephemeral or pseudonymous identifiers, zero-knowledge proofs, revocation without a phone-home, and subject-held credentials — show up again and again across the domains below. The inverse is equally worth naming: a standard that is open and widely adopted but quietly builds a correlation surface is a worse outcome for the commons than a proprietary one that does not.

A supporting thesis runs underneath all of this: no single identifier framework will be sufficient. Not telephone numbers, not domain names, not decentralized identifiers, not OAuth identities, not the emerging agent identifiers. The interesting and necessary work is the integration architecture that lets multiple identifier ecosystems interoperate while each keeps the trust properties of its native domain — and integration is itself a place where openness is either preserved or quietly enclosed.

Telecom trust

This is the industry the rest of the library covers in depth, and the one furthest along in turning verifiable identity into deployed infrastructure. STIR/SHAKEN established cryptographic caller authentication across North American networks: STIR is the IETF protocol layer (a signed PASSporT carrying the calling number, anchored in a certificate hierarchy), SHAKEN the ATIS operational profile and governance arrangement. On top of it, Rich Call Data (RFC 9795) carries verified name, logo, and call-reason — the identity content a called party actually sees.

The open-versus-captured contest here is live and concrete. Branded calling — the consumer-visible layer where a call arrives with a name and a logo — can be delivered through the open RCD path, carried in the signed PASSporT and anchored in the same certificate governance as the call itself, or through proprietary vendor programs that route around it, each analytics provider presenting its own display to its own customers. Whether verified branding ends up an open, portable capability of the telephone number or a set of proprietary walled displays that do not travel between providers is exactly the kind of contest this page tracks. VESPER pushes in the open direction from another angle, binding telephone-number authority to domain-based, verifiable evidence.

Voice is the most developed channel, but the same telephone number also carries text, and messaging is beginning to grow its own identity layer along similar lines — earlier and quieter than the voice work, and worth noting here precisely because it belongs to telephone-number trust rather than standing apart from it. The ATIS/SIP Forum IP-NNI Task Force, the same body that authored the SHAKEN specifications, has published a landscape report on unwanted-message mitigation (ATIS-1000101) and taken up follow-on work on security and authentication in text messaging; on the RCS side, RCS Business Messaging verifies brand and sender identity through GSMA’s certification of agents, and the underlying baseline moves with the Universal Profile — GSMA announced Universal Profile 4.1 in August 2026, framed around stronger foundations for secure messaging. A verified identity that travels with a voice call but not with a text from the same number leaves an obvious seam for impersonation, and closing it is part of making the number a trustworthy identifier across every channel it addresses.

Web and enterprise identity

The web solved a different slice of the problem first: how a person proves who they are to a service, and how services pass that assertion around. The load-bearing standards are OAuth 2.0 and OpenID Connect for delegated authorization and authentication, the WebPKI and Certificate Transparency for binding certificates to domains, and increasingly the FIDO Alliance passkey / WebAuthn stack for phishing-resistant login without shared secrets. Passkeys are the clearest recent adoption story in identity — a genuinely open, multi-vendor credential now being pushed into workplace authentication by the major platforms.

The frontier here is portability of the assertion itself. The OpenID Foundation is where much of that work sits: IPSIE (interoperability for secure identity in the enterprise), Shared Signals / CAEP (so that a risk or logout event at one provider propagates to others rather than dying in a silo), and OID4VC (OpenID for Verifiable Credentials, profiling how wallets present credentials over familiar OAuth machinery). Alongside it, the W3C Verifiable Credentials and Decentralized Identifier (DID) specifications define subject-held, cryptographically verifiable claims. The open-versus-captured tension in this domain is subtle: the specs are open, but whoever controls the dominant identity provider, the wallet, or the passkey sync fabric controls the surface everyone conforms to — capture through position rather than through a closed spec.

Two mid-2026 OpenID Foundation items show what maintenance on an open spec looks like, and both sit on the “what can the verifier learn and link” axis. The CAEP Interoperability Profile 1.0 entered a 60-day final-specification review in July 2026 — a conformance profile that pins down which Shared Signals endpoints are required, how OAuth 2.0 authorizes them, and the core event set (session revoked, credential change, device-compliance change) two implementations must both handle before “supports CAEP” means the same thing on each side. It is the boring, load-bearing move that keeps a popular open spec from fragmenting into per-vendor dialects; the thing to watch is whether an interoperability or certification program attaches to it once it is final. Separately, OpenID Connect Ephemeral Subject Identifier 1.0 (also in public review) profiles a sub value that is not reused across authentications, so a relying party can confirm a user is authenticated without receiving a stable handle it could use to link that user’s sessions over time — extending the pairwise pseudonymous identifiers OIDC already supports (which stop one site correlating with another) to also blunt a single site correlating a user with themselves. Both are reviews upstream of deployment rather than shipped defaults, so the signal to watch is whether any large provider commits to emitting them.

Agentic identity

The fastest-moving and least-settled domain is identity for AI agents — software that acts on a person’s or an organization’s behalf. The question “who is this agent, whose authority does it carry, and what is it allowed to do” is now urgent enough that several bodies are working it at once, and it is where the current page most needed updating: the earlier framing around DNS-based agent identifiers (DNS-AID) reads as premature next to where the standards work has actually gone.

The important pattern is that the serious work is profiling existing primitives onto the agent problem rather than inventing a parallel identity stack. At the IETF that means JOSE (JWT/COSE token formats), SPICE (credential formats, SD-JWT), and WIMSE (workload identity for services), with DAWN (Discovery of Agents, Workloads, and Named entities) an early effort at the discovery layer. In the enterprise-identity world the OpenID Foundation is running interop work on securing MCP-based agents with open identity standards, and the Decentralized Identity Foundation has begun framing “first-class identity for digital actors.” The through-line is that agents mostly need OAuth-style delegated authority, verifiable credentials, and attestation — capabilities that already exist — assembled and profiled for a new kind of actor.

The intergovernmental standards machinery has turned toward the same problem. In mid-2026 the ITU chartered a Focus Group on Trust and Identity for Humans and Agentic AI, reporting to ITU-T SG17, to build the terminology, reference architectures, and trust frameworks for establishing who an AI agent is and whether its behavior can be trusted — with agent discovery and interoperability, lifecycle assurance, and continuous security benchmarks on its charter, and first meetings in Paris and Geneva across late 2026 and early 2027. Focus Groups are where the ITU floats an area before committing a study group, so this is early and non-binding; but terminology and reference architectures are exactly where durable definitions get set, and a UN body chartering agent-identity work signals the topic moving from conference panels toward formal specification. Whose reference architecture wins is, again, the open-versus-captured question.

This is the domain where enclosure risk is highest, precisely because it is early. Several vendors are shipping “agent trust” and “agentic AI security” platforms ahead of any settled standard; some will be genuinely open, some will be closed systems that make the open work unnecessary if they arrive first and set the de-facto surface. The honest read on much of it today is unclassifiable — the vendor has not said whether the output is portable — and for anything soliciting commitments from participants, not knowing whether the result will be portable is itself the material fact. This is the space worth watching most closely over the next year.

Workload and supply-chain identity

Underneath both the web and the agent story sits a machine-identity layer that has quietly become critical. SPIFFE/SPIRE (a CNCF project) gives workloads verifiable identities without embedded secrets — the same “who is this actor and what may it do” question as agents, answered for services. Remote attestation, standardized at the IETF’s RATS working group, lets a relying party check that a piece of hardware or software is in the state it claims before extending trust to it. And SCITT (Supply Chain Integrity, Transparency, and Trust) builds an auditable, append-only record of who attested what about a software artifact and when — transparency logs applied to the supply chain rather than to certificates.

Cryptographic transparency about what is inside a system is becoming a regulated requirement here. The Cryptographic Bill of Materials (CBOM) effort — given a hard deadline by Executive Order 14412 (signed June 22, 2026, directing CISA and NIST to publish minimum CBOM elements within 270 days) — pushes toward machine-readable inventories of the cryptography a product uses, which is the precondition for the coming post-quantum (PQC) migration. This domain is less consumer-facing than the others, but it is the foundation the higher layers stand on: an agent or a caller-identity assertion is only as trustworthy as the attestation and provenance of the systems producing it.

Content provenance

Where the other domains verify actors, content provenance verifies artifacts — whether a piece of media is what it claims to be and where it came from, a problem synthetic media has made acute. The open standard here is C2PA (the Coalition for Content Provenance and Authenticity) and its Content Credentials — cryptographically signed provenance manifests bound to an image, audio, or video file. Adoption is the open question: the spec is real and multi-vendor, and conformance programs for validators are appearing, but provenance only works as a commons if capture devices, editing tools, and platforms all carry the manifest through rather than stripping it. This is the media industry’s version of the same contest — an open, portable provenance signal versus per-platform trust badges that do not travel.

Wallets and government identity

Government-issued digital identity is where selective-disclosure privacy technology is being deployed at population scale. The EU Digital Identity Wallet under eIDAS 2.0, mobile driver’s licenses (ISO mDL), and the credential formats behind them (notably SD-JWT for selective disclosure) are the leading edge. The privacy stakes are explicit and the design choices decisive: a wallet can be built so that presenting your age discloses only “over 18” and cannot be correlated across the sites you present it to — or it can be built so that every presentation is loggable and linkable. Same standard family, opposite outcomes for the person holding it, which is exactly why the privacy test above matters more here than anywhere. These wallets are also the most likely near-term carrier of verifiable credentials into ordinary life, which makes their interoperability profiles (how a wallet from one member state is accepted by a verifier in another) a commons question with real consequences.

The integration architecture

Laid side by side, these domains are converging on a shared kit: verifiable credentials, selective disclosure, attestation, transparency logs, and delegated authority keep reappearing under different names. That convergence is what makes “no single identifier will be sufficient” a design program rather than a lament. The real work is the seams — how telephone-number authority (the STIR model) relates to domain authority (WebPKI, and the bridge VESPER builds across it); how an OAuth2 grant can express telephone-number authorization so a service can act for a number without impersonating it; how an agent identifier plugs into existing attestation and credential infrastructure instead of demanding a new root of trust; and how a vCon conversation record carries provenance so that what was said, by whom, and under what authority travels with the artifact.

Each seam is a place where openness is either preserved or lost. An integration that only works if everyone uses one vendor’s broker has enclosed the commons just as effectively as a closed spec would have — it has simply moved the capture from the standard to the plumbing between standards. Keeping the seams open is the specific contribution the telecom-trust vantage brings to the wider identity conversation: STIR/SHAKEN is one of the few places where an open, multi-vendor, cryptographic identity framework has actually been operationalized at national scale under regulatory pressure, and the lessons — certificate governance, delegation, transparency, revocation — are exactly the ones the agent, wallet, and provenance worlds are now working through.

What to watch

The live contests, stated as the open-versus-captured questions they really are: does verified branded calling settle on an open, portable path or fragment into proprietary per-vendor displays; does agent identity get built by profiling open primitives (JOSE, SD-JWT, WIMSE, OAuth) or does a proprietary “agent trust” platform arrive first and become the de-facto surface; do the government wallets ship with genuine unlinkability and selective disclosure or with loggable, correlatable presentations; does content provenance survive the trip through capture devices, editors, and platforms or get stripped along the way; and does the machine-identity and transparency layer (SPIFFE, RATS, SCITT, CBOM) stay open as it becomes a compliance requirement. That layer keeps filling in: the IETF RATS working group published RFC 10013 on July 30, 2026, defining a measured-component format for the Measurement claim in the Entity Attestation Token (RFC 9711). The only measurement format previously specified was CoSWID, which assumes file-system-anchored measurements and so does not cover early-boot firmware, a CPU register or a run-time integrity check. RFC 10013 separates an information model from JSON and CBOR data models, and its own privacy considerations note that a component name held stable across releases — the property that makes appraisal useful — can enable device tracking. The interop artifacts worth tracking are the ones that produce hard adoption evidence rather than announcements — cross-vendor test matrices, conformance programs, and first real deployments.

Two of those artifacts landed in August 2026. The OpenID Foundation announced on August 7 that the conformance test suites for OpenID for Verifiable Presentations and OpenID for Verifiable Credential Issuance, used with the High Assurance Interoperability Profile, are complete and open for self-certification — per role, wallet and verifier for OpenID4VP, issuer and wallet provider for OpenID4VCI. Sixteen entities took part in the interop rounds that validated the suites, and the Foundation reports pass rates above 90% for OpenID4VP and 87% for OpenID4VCI. The tests are free and the fee attaches to certification; no implementation is certified yet, and whether the jurisdictional profiles — EUDI in particular — name this suite in their own conformance rules is open.

The W3C published DID Resolution v1.0 as a Candidate Recommendation Snapshot on August 6 and is calling for experimental implementations, with the comment window closing September 3. Resolution is the layer where a DID stops being a string and becomes a network operation, which makes it where “what does the party being contacted learn” gets answered — the same question the STIR out-of-band work faces. The exit criteria require two independent interoperable implementations of every feature, each supporting at least two DID methods that are freely available, freely implementable and independently implemented, so the CR phase cannot be exited on proprietary methods.

Where this fits

This section sits at the wide end of the library on purpose. The STIR/SHAKEN topic covers the telecom-trust domain in depth; DNS and domain trust covers the WebPKI and encrypted-DNS substrate the web-identity and bridging work depends on; vCon covers conversation provenance; VESPER covers the telephone-number-to- domain bridge. Most of the material here is genuinely under construction — both as content in this library and as standards in the field — and the page will evolve as the contests it describes are settled. The point of holding all of it in one frame is that the same lens, the same recurring primitives, and the same open-versus-captured question apply across every one of these industries, and reading them together is what makes the pattern visible.