<div dir="ltr">Hi Rahul,<div><br></div><div>Thanks for the proposal. After reviewing it, I agree with Ralph's comments.</div><div>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.</div><div><br></div><div>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.</div><div>Is there a need for distinguishing transport anchors specifically?</div><div><br></div><div>Cheers,</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font color="#000000" face="Menlo"><span style="font-size:12px"><b>Frederik Krogsdal Jacobsen</b></span></font><br style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)"><font color="#000000" face="Menlo"><span style="font-size:12px">Staff Software Engineer, Identity Standards</span></font><br style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)"><br style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)"><span style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)">+45 31 33 45 10</span><br style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)"><a href="mailto:frederik.krogsdal@criipto.com" style="color:rgb(17,85,204);font-family:Menlo;font-size:12px" target="_blank">frederik.krogsdal@criipto.com</a><br style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)"><br style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)"><span style="font-family:Menlo;font-size:12px;color:rgb(0,0,0)">Criipto</span><br></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 27 Oct 2025 at 03:44, Ralph Bragg via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<p dir="ltr" style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Hi Rahul,</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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.</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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.</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Looking at your requirements and what we can do with JWKS:</span></p>
<ul style="text-align:left">
<li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">Discovery and distribution are already covered by jwks_uri. It’s the standard endpoint for publishing verifiable keys and
<b>certificates</b>. 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.</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">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)).</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">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.</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">Rotation is a solved problem. Multiple JWK entries (each with their own kid) allow overlapping validity and seamless rollover for signing and transport certificates.</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">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.</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">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.</p>
</li></ul>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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!</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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.</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">In short:</span></p>
<ul style="text-align:left">
<li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">If it’s about signing keys, publish them in the JWKS and rotate as normal.</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">If it’s about transport (mTLS) certificates, continue to use JWKS with x5c and x5dn.</p>
</li><li style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<p role="presentation">If it’s about trust anchors, use the same structure — that’s exactly what x5c was designed for.</p>
</li></ul>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">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.</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Regards,</span></p>
<p style="text-align:left;text-indent:0px"><span style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">Ralph Bragg</span></p>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_8620700859686564232ms-outlook-mobile-signature" style="color:inherit;background-color:inherit">
<div style="color:inherit;background-color:inherit">
<table cellpadding="0" cellspacing="0" style="height:64.33px;border-collapse:unset;padding:0px">
<tbody>
<tr>
<td align="left" height="16.67" nowrap style="height:16.67px;vertical-align:top;white-space:nowrap;padding:0px 0px 2px;border-collapse:collapse" valign="top">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:14.67px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:11pt;font-weight:bold">Ralph Bragg</span></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:top;white-space:nowrap;padding:0px 0px 5px;border-collapse:collapse" valign="top">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;font-weight:bold">Chief Technology Officer</span></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td align="left" height="15.33" style="height:15.33px;vertical-align:top;padding:0px" valign="top">
<table cellpadding="0" cellspacing="0" style="height:15.33px">
<tbody>
<tr>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:bottom;white-space:nowrap;padding:0px 10px 0px 0px;border-collapse:collapse" valign="bottom">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt">M.</span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt"> </span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt">+447890130559</span></p>
</td>
</tr>
</tbody>
</table>
</td>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:bottom;white-space:nowrap;padding:0px 0px 0px 2.67px;border-collapse:collapse" valign="bottom">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt">T.</span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt"> </span></p>
</td>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt">+44 20 4583 6770</span></p>
</td>
</tr>
</tbody>
</table>
</td>
<td align="left" height="15.33" nowrap style="height:15.33px;vertical-align:bottom;white-space:nowrap;padding:0px 0px 0px 10px;border-collapse:collapse" valign="bottom">
<table style="border-collapse:collapse">
<tbody>
<tr>
<td style="padding:0px">
<p style="line-height:13.33px;margin:0.1pt"><a href="mailto:ralph.bragg@raidiam.com" style="text-decoration:none" target="_blank"><span style="font-family:Tahoma,Verdana,Segoe,sans-serif;font-size:10pt;text-decoration:none">ralph.bragg@raidiam.com</span></a></p>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
<tr>
<td height="10" style="width:470px;height:10px;padding:0px">
<p style="line-height:0;margin:0.1pt;padding:0px;width:100%;height:10px"></p>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<div id="m_8620700859686564232mail-editor-reference-message-container" style="color:inherit;background-color:inherit">
<div dir="ltr"></div>
<div style="text-align:left;padding:3pt 0in 0in;border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;font-family:Aptos;font-size:12pt;color:black">
From: Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> on behalf of Rahul Khanna via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
Date: Monday, 27 October 2025 at 9:39 am<br>
To: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
Cc: Rahul Khanna <<a href="mailto:rkhanna@propensic.com" target="_blank">rkhanna@propensic.com</a>><br>
Subject: [Openid-specs-ab] Peer review request: TADR draft<br>
<br>
</div>
<div dir="ltr">Hello esteemed community,<br>
<br>
I would like to propose Draft 00 of the Trust Anchor Distribution & Rotation (TADR) specification for consideration by the OpenID Connect AB Working Group.<br>
<br>
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.<br>
<br>
What TADR proposes:  </div>
<ul dir="ltr">
<li dir="ltr">A new `trust_anchor_uri` in OIDC Discovery  </li><li dir="ltr">A standardized JSON schema for trust anchor bundles  </li><li dir="ltr">Clear client behaviors for fetching, caching, and rotating anchors  </li><li dir="ltr">Reference implementations (Node.js server + Python client) to prove feasibility  </li></ul>
<div dir="ltr"><br>
Why it matters:  </div>
<ul dir="ltr">
<li dir="ltr">Prevents outages during certificate rotation  </li><li dir="ltr">Aligns OIDC ecosystems with the short‑lived certificate era  </li><li dir="ltr">Strengthens distributed trust and resilience across federated identity  </li></ul>
<div dir="ltr"><br>
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.<br>
<br>
The draft and reference implementations are available in the working group repository branch `<a href="https://github.com/openid/publication/pull/122/commits/8ef96f263a9c791a7b3c4130d022132a1f099dfa" target="_blank">propose/connect/openid-tadr-1_0-00</a>`.<br>
<br>
I welcome guidance on the correct submission process and look forward to your feedback.<br>
<br>
Thank you!</div>
<div dir="ltr"><br>
</div>
<div dir="ltr" class="gmail_signature"><span style="background-color:rgba(255,255,255,0)">Cordially, </span></div>
<div dir="ltr" class="gmail_signature"><span style="background-color:rgba(255,255,255,0)"><br>
</span></div>
<div dir="ltr" class="gmail_signature"><span style="background-color:rgba(255,255,255,0)">Rahul Khanna | Sr Principal Consultant</span></div>
<div dir="ltr" class="gmail_signature"><span style="background-color:rgba(255,255,255,0)">Propensic Solutions, LLC</span></div>
<div dir="ltr" class="gmail_signature"><span style="background-color:rgba(255,255,255,0)">Call/Text
</span><span style="color:rgb(255,153,0);background-color:rgba(255,255,255,0)">(new)</span><span style="background-color:rgba(255,255,255,0)">:
</span><span style="color:rgb(17,85,204);background-color:rgba(255,255,255,0)"><a href="tel:+1-813-330-0677" style="color:rgb(17,85,204)" target="_blank">+1-813-330-0677</a></span><span style="background-color:rgba(255,255,255,0)"> (USA
 East Coast)</span></div>
<div dir="ltr" class="gmail_signature"><span style="background-color:rgba(255,255,255,0)">Email:
</span><span style="color:rgb(17,85,204);background-color:rgba(255,255,255,0)"><a href="mailto:rkhanna@propensic.com" style="color:rgb(17,85,204)" target="_blank">rkhanna@propensic.com</a></span></div>
<div dir="ltr" class="gmail_signature">Want to meet? <a href="https://calendar.app.google/Z3LJkWBT6v5KM4tL6" target="_blank">
Schedule a meeting today!</a></div>
<div dir="ltr" class="gmail_signature">Visit us online: <a href="http://www.propensic.com/" target="_blank">
www.propensic.com</a></div>
<div dir="ltr" class="gmail_signature"><br>
</div>
</div>
</div>

_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>