Week ending August 7, 2026

The most useful thing this week is that two of the most widely selected specifications in digital identity finally got a test attached to them. The OpenID Foundation completed the conformance test suites for OpenID4VP and OpenID4VCI under the High Assurance Interoperability Profile and opened them for self-certification. By the Foundation’s own count, more than thirty jurisdictions have already selected these protocols, and each will write its own profile and its own conformance requirements on top of them. A free, open-source test suite published before those national regimes are written gives them a common base to build over. That is what happened with the FAPI profile, which started as voluntary certification and is now a condition of participation in Brazilian open banking.

Standards in motion

A conformance target for the wallet protocols, and it is free. 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. Certification is per role rather than per company: wallet or verifier under OpenID4VP, issuer or wallet provider under OpenID4VCI, each with its own test profile. The tests themselves are free and can be run on the Foundation’s infrastructure or on the implementer’s own; the fee applies only to publishing a certification. The Digital Credentials Protocols Working Group confirmed the suites ready in July, after interop rounds the Foundation reports at over 90% pass for OpenID4VP and 87% for OpenID4VCI.

The tests cover protocol conformance including failure scenarios. That matters for the privacy properties these specifications are chosen for, which are protocol properties rather than product features: proving you are over eighteen without handing over a date of birth, and an issuer that gains no visibility into where its credentials are later presented. Both depend on each end implementing the protocol as written, and a test suite is what checks that. Adoption read: adopted on paper, unproven in practice. No implementation is certified yet — the Foundation is calling for first movers. The competing dynamic is not a rival specification but the jurisdictional profiles being written on top of this one. The Foundation says it is in active dialogue with the EU Digital Identity Wallet ecosystem about using its open-source tests inside local requirements; whether EUDI and the other selecting jurisdictions name this suite in their own conformance rules is what to watch before the wallet deadlines.

DID Resolution reached Candidate Recommendation, with an exit bar that excludes single-vendor methods. The W3C Decentralized Identifier Working Group published DID Resolution v1 as a Candidate Recommendation Snapshot on August 6 and is asking for experimental implementations. Resolution is the step where a verifier fetches a DID document from somewhere, so the resolution binding determines what the party being contacted learns — a question the core DID specification leaves to this layer. The exit criteria are worth reading directly: two independent interoperable implementations of every feature, verified against open test suites, and each implementation must support at least two DID methods whose specifications are freely available and freely implementable and which more than one independent implementation has built interoperably. A proprietary DID method cannot count toward exiting the phase. Adoption read: early. There is a published implementation report still to fill in, and the comment window runs 28 days, closing September 3, with feedback in the working group’s repository.

RATS published a measurement format that documents its own tracking risk. RFC 10013 was published July 30 from the IETF RATS working group, defining a measured-component format for the Measurement claim in the Entity Attestation Token. The gap it fills is specific: the only previously specified measurement format was CoSWID, which assumes measurements anchored to a file system and so does not cover early-boot firmware, a CPU register, or a run-time integrity check. The document separates an information model from the JSON and CBOR data models, so the semantics can be reused in serialisations that do not exist yet. Authors sit at Arm, Linaro, the University of the Bundeswehr Munich, and Fraunhofer SIT, and an implementation already exists in the veraison/eat package. The document’s own Privacy Considerations state that component name and version can reveal what is running on a device, and that the requirement for the name to stay stable across releases — the property that makes appraisal work — may enable tracking. The specification names the risk; what the EAT profiles put in the field will determine whether it is realised.

STIR’s charter goes in front of the IESG on August 20. The IETF STIR charter sits in internal steering-group review and is scheduled for the August 20 telechat, where the question before the IESG is whether to send the proposed text out for external review. The rechartering was opened on the working group list in December, with the chairs noting the current charter is out of date and the area director asking for concrete deliverables before new work is taken up; VESPER use cases and requirements were named as the example of work waiting on it. Nothing is settled and the text can still change. External review is the window in which the wider IETF community and other standards bodies comment on scope, and August 20 is when it is decided whether that window opens.

Implementations & adoption

Sixteen implementers tested, none certified yet. The Foundation says sixteen unique entities took part in the OpenID4VP and OpenID4VCI interoperability programme that validated the suites. The ones that put their names to statements are Google’s Android identity and payments team, SpruceID, Authlete, Meeco, Fikua, and Turing Space. Google’s stated interest is in making sure app and wallet developers on Android implement the specifications correctly, which is a position on a distribution surface rather than a product — platform-level conformance determines whether a credential issued in one jurisdiction can be presented in another on hardware people already own. Authlete supplied testing infrastructure for the HAIP OpenID4VCI suite, meaning a vendor built part of the harness its own implementation will be measured against; the CAEP Interoperability Profile noted last week has the same structure, with its authors at the two largest deployers. Adoption read: interop-tested is not certified. The numbers to watch are how many of the sixteen convert into published certifications, and whether any EU member-state wallet appears on the list, which would be direct evidence that the jurisdictional profiles are being built over the common base.

Capital & motivation

Okta bought the thing that generates the signals. Okta signed a definitive agreement on July 30 to acquire Permiso Security, a cloud-native identity threat detection platform covering human, non-human, and agentic identities. Okta’s release describes more than 2,500 research-driven signals drawn across 70-plus identity partners, and expects to close in its fiscal third quarter, August to October. Terms are not disclosed in the release; press reports put the price just under $200 million. Detection is signal generation. The open specification for signal transport is the Shared Signals Framework and its Continuous Access Evaluation Profile, whose Interoperability Profile entered final review the week before with authors at Okta and CrowdStrike. Those are two documented facts, not a stated plan. The question they raise for anyone choosing what to build against: will Permiso’s detections be emitted over the SSF interface Okta helped define, so a relying party that is not an Okta customer can consume the same event, or only within Okta’s own platform?