[Openid-specs-ab] Peer review request: TADR draft

Mon Oct 27 02:44:43 UTC 2025

Hi Rahul,

I’ve reviewed the TADR draft and, while I agree with the premise that automation around trust-anchor rotation is becoming critical, I don’t see a case for introducing a parallel discovery field or schema when JWKS already supports or could be extended to support these functions.

The issues raised are not new — they’ve already been solved in production ecosystems using the existing JWKS and Discovery patterns defined in RFC 7517 and RFC 8414.

Looking at your requirements and what we can do with JWKS:

  *   Discovery and distribution are already covered by jwks_uri. It’s the standard endpoint for publishing verifiable keys and certificates. If there’s a need to distinguish between signing and transport anchors, a profile or attribute could be introduced rather than defining a new endpoint.

  *   Certificate representation is fully supported via x5c, x5t, and x5u. Additional metadata such as subject, issuer, or validity can be derived from the certificate itself or exposed as lightweight extensions (e.g., x5dn in Open Banking Brazil for correlation - (which I still need to get around to registering)).

  *   Integrity is already supported. A JWKS can be distributed as a signed JWS or encapsulated in an OpenID Federation entity statement, providing cryptographic assurance without defining a new format.

  *   Rotation is a solved problem. Multiple JWK entries (each with their own kid) allow overlapping validity and seamless rollover for signing and transport certificates.

  *   Transport certificates are handled the same way. In Brazil, the x5dn extension allows correlation between successive certificates with the same DN. When a server’s leaf certificate expires, it’s simply replaced in the JWKS — clients parse and process it automatically.

  *   Trust-anchor rotation (actual CA changes) can also be represented via x5c — Brazil’s directory publishes the trust list in both PEM and JWKS formats.

The so-called “bootstrap trust” problem exists in every model — including TADR. To fetch any endpoint securely, you already rely on an existing trust list. Introducing a trust_anchor_uri doesn’t solve that dependency as the endpoint is still served over https!

From an implementation standpoint, TADR appears to re-model a certificate as JSON rather than reuse the already defined and deployed mechanism that does exactly this. Everything described in the draft could be achieved today using JWKS and, if desired, additional x5x attributes to enrich the metadata.

In short:

  *   If it’s about signing keys, publish them in the JWKS and rotate as normal.

  *   If it’s about transport (mTLS) certificates, continue to use JWKS with x5c and x5dn.

  *   If it’s about trust anchors, use the same structure — that’s exactly what x5c was designed for.

Given the maturity, extensibility, and interoperability of JWKS across deployed OpenID ecosystems (UK, Brazil, UAE), I’d strongly suggest we extend JWKS or issue implementation guidance rather than create a second, parallel mechanism that risks fragmentation.

Regards,

Ralph Bragg

Ralph Bragg

Chief Technology Officer

M.

+447890130559

T.

+44 20 4583 6770

ralph.bragg at raidiam.com<mailto:ralph.bragg at raidiam.com>

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf of Rahul Khanna via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Date: Monday, 27 October 2025 at 9:39 am
To: openid-specs-ab at lists.openid.net <openid-specs-ab at lists.openid.net>
Cc: Rahul Khanna <rkhanna at propensic.com>
Subject: [Openid-specs-ab] Peer review request: TADR draft

Hello esteemed community,

I would like to propose Draft 00 of the Trust Anchor Distribution & Rotation (TADR) specification for consideration by the OpenID Connect AB Working Group.

Given that issuers already expose `.well-known/openid-configuration` metadata, this registry is a natural place to address the CA/B Forum’s decision to shorten TLS certificate lifetimes to just 47 days by 2029. This industry shift makes manual trust anchor management unsustainable — automation and interoperability are now mission‑critical, particularly for OAuth client apps, OIDC Client Credential Flows, and potential future extensions such as agentic AI authentication/authorization.

What TADR proposes:

  *   A new `trust_anchor_uri` in OIDC Discovery
  *   A standardized JSON schema for trust anchor bundles
  *   Clear client behaviors for fetching, caching, and rotating anchors
  *   Reference implementations (Node.js server + Python client) to prove feasibility

Why it matters:

  *   Prevents outages during certificate rotation
  *   Aligns OIDC ecosystems with the short‑lived certificate era
  *   Strengthens distributed trust and resilience across federated identity

This is just Draft 00 — the beginning of a conversation. I’m excited to collaborate with the OpenID Foundation community, PKI experts, and identity architects to refine and advance this work.

The draft and reference implementations are available in the working group repository branch `propose/connect/openid-tadr-1_0-00<https://github.com/openid/publication/pull/122/commits/8ef96f263a9c791a7b3c4130d022132a1f099dfa>`.

I welcome guidance on the correct submission process and look forward to your feedback.

Thank you!

Cordially,

Rahul Khanna | Sr Principal Consultant
Propensic Solutions, LLC
Call/Text (new): +1-813-330-0677<tel:+1-813-330-0677> (USA East Coast)
Email: rkhanna at propensic.com<mailto:rkhanna at propensic.com>
Want to meet? Schedule a meeting today!<https://calendar.app.google/Z3LJkWBT6v5KM4tL6>
Visit us online: www.propensic.com<http://www.propensic.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251027/a6eacd13/attachment-0001.htm>