Week ending October 9, 2026 — Sector Watch

The OpenID Foundation approved OpenID Connect Ephemeral Subject Identifier 1.0 as a Final Specification on October 8. It adds a third subject type to OpenID Connect, next to public and pairwise: the provider issues a new sub value for every authentication, so a relying party cannot link two visits by the same person, and two relying parties cannot link their responses to each other. Pairwise identifiers, the strongest option until now, stop the second kind of linking but give each relying party a stable identifier to build a profile on. The spec’s own examples are over-age, under-age and domicile checks, where a site needs a yes or no and has no reason to recognize the person next time.

Standards in motion

Enterprise & web identity

OpenID Connect now has a standard subject identifier that a relying party cannot correlate. OpenID Connect Ephemeral Subject Identifier 1.0, from the OpenID Connect Working Group, was approved as Final on October 8. A relying party registers ephemeral as its subject_type; a provider that supports it lists ephemeral in subject_types_supported. The sub in the ID Token and UserInfo response then holds for one authentication session and changes on the next. The provider must never reuse a value and must generate values with a guessing probability of 2^-128 or less. The stated target is Unlinkability Level 3A+ under ISO/IEC 27551 for Self-Issued OpenID Provider deployments, and the spec says the subject type is already used in some ecosystems, with standardization meant to reduce the variations between them.

The spec covers the identifier, not the claims released with it. A relying party that receives an email address or a name alongside an ephemeral sub can still link visits by those. The property holds for flows that release only the attribute being checked, which is the age and domicile case the spec names. On the wallet side, OpenID4VP with SD-JWT VC has the same problem in a different place: the issuer’s signature is identical across presentations, and the mitigation is batch issuance of single-use credentials. Ephemeral sub is the federated-login counterpart.

On the §1b axis: open, neutral body, implementable without permission, and consumer-protective by mechanism rather than by policy. Adoption read: Final status gives implementers the Foundation’s IP protections, but the approval names no implementer, and the spec’s claim of existing use names no ecosystem. The signal to look for is identity providers serving age assurance adding ephemeral to their discovery metadata.

W3C is making a public case for Verifiable Credential Barcodes, and California is the only issuer it names. In an October 7 press release, W3C cites September reporting of a dark-web market selling scans of about 160 million US and Canadian driver’s licenses, which initial reports attributed, without confirmation, to a compromised document-verification service. Verifiable Credential Barcodes is a Recommendation-track Working Draft from the Verifiable Credentials Working Group, last revised August 22. It signs the data already printed in a license’s AAMVA PDF417 barcode, or in a QR code or MRZ, with a Data Integrity signature using the ecdsa-xi-2023 cryptosuite, compresses it with CBOR-LD to under 150 bytes, and carries a Bitstring Status List entry so the issuer can revoke one credential. W3C’s argument is that a signature does not stop someone using a copied image of a valid barcode, and revocation does. Because a verifier checks the status list without contacting the issuer, the issuer does not learn where a license is presented.

The working group’s own threat model notes that a static barcode can be captured and works as a persistent identifier. Every verifier that scans a license gets the same signed data, and revocation does not change that. ISO 18013-5 mobile driver’s licenses take the other approach, with device binding and selective disclosure, and the federal guidance on bank acceptance of digital IDs covered last week requires a credential bound to a device. A printed barcode is not. The release says that had the breached licenses carried VC Barcodes, the response would mainly be identifying the affected licenses and revoking them. It does not say how an issuer identifies them when the breached service has not been named.

Adoption read: W3C says the California DMV has issued licenses and ID cards with a VC Barcode since late 2025. The release names no other issuer and no verifier deployment. The spec is edited at Digital Bazaar with one invited expert.

Implementations & adoption

Datavant put ID.me verification in front of patient medical-records requests. Datavant announced on October 5 that its Patient Request Tool now verifies requesters through ID.me instead of manual review. ID.me is approved by the Kantara Initiative as a credential service provider at NIST SP 800-63 IAL2 and AAL2. The companies say about 73% of patients going through the tool already have an ID.me credential. Datavant’s network covers more than 80,000 hospitals and clinics. ID.me announced a similar arrangement with Oracle Health on September 28.

The assurance level is an open, third-party-certified standard. The credential is an ID.me account, reusable wherever ID.me is the identity provider; the companies call it portable in that sense. The announcement names no federation protocol, wallet or credential format. The question to put to Datavant: can a patient verify with a different IAL2 provider, or with a state mobile driver’s license, or is ID.me the only path into the tool?