appliedbits
DISPATCH  ·  Sector Watch PUBLISHED
PUBLISHED 2026-09-15

Week ending September 11, 2026

The OpenID Foundation’s members closed a vote that ran August 24 to September 7 and approved OpenID Connect Key Binding 1.0 as a first Implementer’s Draft. The specification binds an ID Token to a public key the client holds, using the same DPoP proof-of-possession mechanism (RFC 9449) that already protects OAuth access tokens: a token stolen from a browser, a log, or a proxy can’t be replayed without also holding the private key. It profiles OpenID Connect and DPoP rather than adding new endpoints — a relying party adds a bound_key scope and a dpop_jkt parameter to the authentication request, and the provider returns the bound key in the ID Token’s cnf claim (RFC 7800). Implementer’s Draft status follows a member vote: working-group members build and review a spec before they’ll approve it at that level.

Standards in motion

OpenID Connect Key Binding clears its first Implementer’s Draft vote. The OpenID Foundation’s Connect working group approved OpenID Connect Key Binding 1.0 as a first Implementer’s Draft, closing a member vote that followed a 45-day public review. The specification, authored by Dick Hardt of Hellō and Ethan Heilman of Cloudflare, binds an ID Token to a client-held public key using DPoP — the same proof-of-possession mechanism already protecting OAuth access tokens — so a stolen or leaked ID Token can’t be replayed without the private key. Adoption read: Implementer’s Draft status is the OpenID Foundation’s signal that working-group members have built and reviewed the spec at that level; the next gate is Final Specification.

STIR’s recharter clears the objection that held it since August. The IETF STIR working group charter picked up a new revision this week — charter-ietf-stir-02-02 — and the blocking IESG position that held the recharter since late August, over deliverables that named no intended publication status, was withdrawn. Other IESG positions on the charter remain open; the recharter has not fully cleared. Whether it does decides whether STIR’s next round of deliverables lands as Standards Track, which other implementers have to interoperate against, or as Informational guidance they can ignore.

EMAILCORE’s applicability statement clears two DISCUSS positions. draft-ietf-emailcore-as, the IETF EMAILCORE working group’s applicability statement for the 5321bis/5322bis core email protocol revisions, revised its SMTP confidentiality-requirements language in revision 30; two blocking DISCUSS positions at the IESG were withdrawn in response this week. The document is not yet approved — other positions may still be open. Adoption read: an applicability statement doesn’t ship code; it tells implementers which of the underlying SMTP/email specs apply and how, which is the layer SPF, DKIM, and DMARC sit on top of.

DKIM2’s best-practices draft reaches its first working-group revision. draft-ietf-dkim-dkim2-bcp — guidance for deploying DKIM2, the IETF DKIM working group’s rechartered signing mechanism that runs alongside legacy DKIM rather than replacing it outright — was revised to -01 this week. DKIM2 itself is specified in a separate document plus a motivation draft; the BCP is aimed at implementers deciding how to run both mechanisms at once. Adoption read: no implementer has committed publicly yet; DKIM2 is still spec-stage.

Capital & motivation

KPMG takes a stake in a deepfake-detection vendor, not a provenance one. KPMG LLP acquired a minority stake in Reality Defender, backing a hiring push at the company, which sells forensic detection of AI-generated video, voice, and images after the fact. That is a different technology from C2PA’s approach of signing content at the moment of capture: detection catches a fake after it’s already circulating, provenance stops an unsigned or altered file from passing as authentic in the first place. Reality Defender does not state whether its output ties to any provenance standard. Adoption read: an accounting firm the size of KPMG paying for detection tooling is a vote that the market doesn’t consider capture-time provenance standards deployed widely enough yet to rely on.