It sounds like the SPIRE server is the AS. Which means that it must already have the clients registered and house their public keys or else the client signing doesn't work.
Does SPIRE somehow not have this information already? On Thu, Feb 13, 2025, 01:25 Dmitry Telegin <dmitryt= 40backbase....@dmarc.ietf.org> wrote: > (Background: exploring the possibility of using SPIFFE as client > authentication mechanism at the Transaction Token service.) > > JWT-SVIDs, defined in SPIFFE, are regular JWTs, though with some > peculiarities: > * the "sub", "aud" and "exp" claims are mandatory; > * the "iss" claim is optional (but would be normally added by SPIRE); > * the "sub" claim must be set to the workload's SPIFFE ID; > * the issuer of the JWT-SVID is the SPIRE server and not the workload; the > workload only controls the acquisition and presentation aspects. > > Question 1. Is the use of JWT-SVIDs for client authentication (as a > client_assertion) compliant with RFC7523(bis)? > > Question 2. If so, what would be the best approach to registering such > clients with the AS (TTS)? Static registration doesn't work very well > because of the SPIFFE's dynamic nature. DCR could be problematic because > for JWT-based client auth mechanisms we only have "private_key_jwt" and > "client_secret_jwt" (and JWT-SVIDs are neither). Should the AS/TTS perform > some sort of automatic client registration when it first encounters a > JWT-SVID signed by a trusted issuer? > > Thanks, > Dmitry > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
