Hi, I support removing the client_id equals SPIFFE ID requirement from the X509-SVID method (Section 3.2 of -02).
Raidiam operates OpenID Federation and directory based ecosystems in production with several thousand registered clients whose client_id is an https entity identifier resolved through a trust chain. Client IDs there cannot change, so under the current 3.2 text these deployments can never use this method. The JWT-SVID path already has the right model (3.1 step 5: "matches or is associated with a recognized client identifier"). 3.2 also appears to contradict itself: the request rule mandates that client_id equal the URI SAN, yet validation step 5 accepts a SPIFFE ID that "is associated with a registered client identifier", a branch the request rule makes unreachable. RFC 8705 Section 2.1.2 solved this for certificates: the expected identity (tls_client_auth_san_uri) is registered metadata and client_id remains the registration identifier. The draft already has the equivalent in spiffe_id (Section 5.1, IANA Section 9.1). Proposed replacement for the 3.2 request rule: "The request MUST include the client_id parameter identifying the client. The authorization server MUST verify that the SPIFFE ID in the URI SAN of the presented X509-SVID matches, or is covered by, the spiffe_id metadata registered for or otherwise associated with that client." Section 5.1's wildcard prose would then need to cover the URI SAN as well as the JWT sub claim. Deployments that use the SPIFFE ID as their client_id are unaffected, since the association check degenerates to equality. Ralph Bragg Chief Technology Officer M. +447890130559 T. +44 20 4583 6770 [email protected]<mailto:[email protected]> [https://storage.letsignit.com/icons/designer/socials/Linkedin--circle--black.png]<https://cloud.letsignit.com/collect/bc/652d0421e161c54081b81962?p=TMTQYP7uhVuEibYQ91RsC3IoNUOt5RBT8PxKu46ijB200WFOdFgfuybDSNA7VsIsDfVuTvGEfkoMzngn2LEx6sZgJoSeY6SRq4DADGvENbcrCp3R8bPY3ukqcgnAE1QBOE1aeRl-_3D7UXCGJdZ1M7e1qUDa1Q4HzoARy0RaSJE=> [https://storage.letsignit.com/5fd527570105a500075428f0/generated/effects_08e3e03b4f71b6a89cf4bd9f429daac0a7f6dd1ccb38a410fc760991.png] The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
