Week ending September 25, 2026 — Sector Watch

iProov, GLEIF, and FIDO Alliance have each proposed a way to verify that a human approved a specific AI agent action in the past five months: iProov’s HAPS, published to GitHub September 18; GLEIF’s proposal to extend the verifiable Legal Entity Identifier (vLEI), in a September 1 paper by CEO Alexandre Kech; and FIDO’s Verifiable User Instructions work item, opened in April with Google, Mastercard, OpenAI, Amazon and Okta. None of the three has a deployment outside its own publisher. The item this week with an actual, checkable adoption number has nothing to do with agents: the OpenID Foundation reported September 24 that fourteen organizations completed self-certification against its High Assurance Interoperability Profile (HAIP) for verifiable-credential wallets.

Standards in motion

Provenance, wallet & decentralized identity

Three different proposals for verifying human approval of an AI agent’s action, and zero adoption across all of them. iProov published HAPS, the Human Approval and Presence Specification, on GitHub September 18 under an Apache-2.0 license — written by iProov alone, with a partial Rust reference implementation and no co-developer named. GLEIF proposed a different mechanism in a September 1 paper by CEO Alexandre Kech: extend the verifiable Legal Entity Identifier (vLEI) to prove which legal entity authorized an agent and what it was allowed to do. GLEIF’s proposal involves two distinct layers. The LEI itself — the 20-character code GLEIF has overseen since 2014 under ISO 17442 — is a reference number with no cryptography in it. The vLEI wraps that number in a digitally signed credential; GLEIF’s own materials call this layer cryptographic and name GLEIF itself as the system’s “digital root of trust” — a cryptographic signing chain anchored to one organization’s accreditation framework, not to an independent or decentralized one. FIDO Alliance has the most multi-vendor effort of the three: a working group opened in April with Google, Mastercard, OpenAI, Amazon and Okta, under the name Verifiable User Instructions, targeting the identical problem HAPS and GLEIF are each pursuing alone. None of the three — FIDO’s working-group draft, GLEIF’s proposal, or iProov’s open-licensed spec — has a deployment outside its own publisher yet. Adoption read: zero, across all three, as of this week.

Enterprise & web identity

The W3C’s Verifiable Credentials Working Group opened a document specifically to catalogue what can go wrong. The group published a first draft Group Note, Verifiable Credentials Data Model Threat Model v2.1, on September 24, covering security and privacy threats across the issuer-holder-verifier flow the Verifiable Credentials Data Model already defines at Recommendation status. A threat model doesn’t change what the credential format can do; it changes what an implementer has to check before shipping one. It’s a first draft, several revisions from final.

Implementations & adoption

Fourteen implementers are the first to certify against OpenID’s high-assurance wallet profile. The OpenID Foundation announced September 24 that fourteen organizations completed self-certification against the High Assurance Interoperability Profile (HAIP) for OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI), after conformance testing opened in August. HAIP is the profile the government and wallet-provider digital-identity programs in the EU, UK, Switzerland, India and California have been building toward. Adoption read: a published, testable conformance result across fourteen organizations is the wallet ecosystem’s first hard interoperability signal on this profile, not another design document.

Okta’s marketing calls Cross App Access “an open protocol”; the IETF record says something more specific. Aembit announced support September 22 for Okta’s Cross App Access (XAA), brokering it so a user’s existing SSO session can authorize an AI agent or MCP server without a separate OAuth consent step. Neither Aembit’s release nor Okta’s own materials name the IETF documents XAA is built on: OAuth Identity and Authorization Chaining Across Domains, now awaiting publication as an RFC, and Identity Assertion JWT Authorization Grant, still an active OAuth working-group document — both with co-authors from Okta, Ping Identity, Defakto Security, MITRE and the NSA on the author list. Aembit separately describes its broker as implementing the “Model Context Protocol Working Group’s” Enterprise-Managed Authorization pattern, a second, less formal effort converging on the same access-delegation problem from the AI-agent side rather than the enterprise identity-provider side. Adoption read: XAA is closer to a real multi-vendor IETF standard than the vendor copy suggests, and Aembit is the first third-party broker product built on it.