Week ending October 2, 2026 — Sector Watch

The IETF’s WIMSE working group adopted the AI agent authentication draft on September 15 as draft-ietf-wimse-aims-00, with authors from Defakto Security, AWS, Zscaler, Ping Identity, OpenAI and Okta. It defines no new protocol. It profiles WIMSE, SPIFFE, OAuth 2.0, OpenID Connect and HTTP Message Signatures into one agent identity model. Two product launches this week sit on the other side of the line. First Orion’s branded calling went live on Vodafone Ireland through a CAMARA network API, and Socure added mobile driver’s license verification from Google Wallet and Samsung Wallet. Neither announcement names the specification that carries the identity claim.

Standards in motion

IETF & ITU-T

The agent identity work moved from an individual draft to a working-group document. The WIMSE working group adopted AI Identity Management System on September 15 as -00, replacing draft-klrc-aiagent-auth, which first appeared in March. The authors are Pieter Kasselman (Defakto Security), Jeff Lombardo (AWS), Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Nick Steele (OpenAI) and Aaron Parecki (Okta). The draft states its scope as best practice for authenticating and authorizing agent interactions by composing existing standards: WIMSE identifiers, with SPIFFE URIs as one deployed form; short-lived credentials in X.509, JWT or WIMSE Workload Identity Token form; OAuth 2.0 grants for user delegation, self-authorization and cross-system access through token exchange and identity chaining; and the OpenID Shared Signals Framework for monitoring. It calls static API keys an antipattern for agent identity and says an LLM must not have access to agent or tool credentials.

Two parts of it connect to work covered in earlier issues. The cross-system access flow is the identity chaining mechanism behind Okta’s Cross App Access, which ran September 25. For sensitive operations the draft uses OpenID CIBA, an out-of-band confirmation sent to the user, which is the same problem iProov’s HAPS, GLEIF’s vLEI proposal and FIDO’s Verifiable User Instructions are each solving separately. AIMS picks an existing mechanism for it and does not define a new one.

The draft requires tamper-evident audit logs recording the agent’s identity, the delegated subject, and the resources accessed. It leaves policy formats, posture-assessment evidence formats and compliance criteria out of scope. On the §1b axis it is open (multi-vendor authors, neutral body, implementable without permission) and interoperable by construction, since every component is a spec someone else already maintains. Adoption read: a -00 working-group draft with no implementation of its own, resting on SPIFFE and OAuth deployments that exist. Whether the group holds to composing existing specs, or starts defining agent-specific tokens, is the thing to watch in the next revisions.

Implementations & adoption

First Orion’s branded calling is live on Vodafone Ireland through a CAMARA API, and the announcement does not say how the displayed identity is vetted or carried. First Orion and Vodafone announced the Ireland launch on September 30, delivering INFORM Branded Calling, which shows enterprise names to Irish subscribers on incoming calls. The release says the launch used Vodafone’s CAMARA-based network API integration, already deployed in Vodafone’s other markets, with no additional development work from First Orion. No subscriber or call-volume figure is given. STIR, SHAKEN and Rich Call Data are not mentioned.

On the open-versus-proprietary axis this is unclassifiable from the public record. CAMARA defines the network API Vodafone exposes. It does not say what a terminating network receives about the caller, who attests to the enterprise’s identity, or whether a signed claim crosses carrier boundaries or stays inside Vodafone’s network. Questions to put to First Orion and Vodafone: is the name shown to the subscriber backed by a signed, third-party-verifiable attestation, and could another vendor’s branded calling product present through the same API?

Socure added mobile driver’s license verification after federal guidance cleared banks to accept them. Socure announced on October 2 that its DocV product accepts U.S. mDLs presented remotely from Google Wallet and Samsung Wallet. The guidance came in September, jointly from FinCEN, the Federal Reserve, the FDIC, the NCUA and the OCC (OCC Bulletin 2026-44). It lets banks and credit unions accept a government-issued digital credential for customer identification if it is unexpired, protected by an activation factor (face, fingerprint or PIN), and digitally signed by its issuer and cryptographically bound to a device. Participation is voluntary. Private-company credentials are treated as non-documentary verification.

Socure verifies that the credential was signed by the issuing state DMV, then adds device, behavioral and identity risk signals to score fraud. The announcement cites 21 states issuing mDLs and more than 8 million active credentials. It does not name ISO 18013-5, ISO 18013-7, OpenID4VP or the W3C Digital Credentials API. The privacy question is what the bank receives and keeps: a signature check can be done with minimal disclosure, but layering device and behavioral signals on top means Socure learns more about the person than the credential presents. Neither the guidance nor the announcement says what is retained.