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

Mon Oct 27 09:30:44 UTC 2025

Hi Rahul,

Thanks for the proposal. After reviewing it, I agree with Ralph's comments.
We currently do basically what Ralph outlines to rotate certificates in
production systems with JWKS, and this is a very common approach in use in
many ecosystems.

I am not in principle opposed to introducing a JWKS profile/attribute
specifically for transport anchors, but being a non-expert on this specific
topic I am not convinced it is necessary.
Is there a need for distinguishing transport anchors specifically?

Cheers,
*Frederik Krogsdal Jacobsen*
Staff Software Engineer, Identity Standards

+45 31 33 45 10
frederik.krogsdal at criipto.com

Criipto

On Mon, 27 Oct 2025 at 03:44, Ralph Bragg via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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
>
> 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 (USA East Coast)
> Email: rkhanna at propensic.com
> Want to meet? Schedule a meeting today!
> <https://calendar.app.google/Z3LJkWBT6v5KM4tL6>
> Visit us online: www.propensic.com
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20251027/4b14bb81/attachment-0001.htm>