Hi Dmitry Great question. The Transaction Token draft does allow for the use of SPIFFE SVIDs (section 7.6 of [1]) when authenticating clients, so this is definitely functionality we believe should be supported.
JWT-SVID as Client Authentication ----------------------------------------------- The JWT-SVIDs typically has all the claims needed to be used for client authentication (as you point out, even though "iss" is not mandatory, it is commonly included) and you should be able to use it for that purpose (JWT-SVIDs are specifically meant to be used for authentication purposes) JWT-SVID and Client Registration --------------------------------------------- In terms of the client registration, the SPIFFE SVID issuer (e.g. a SPIRE server) is responsible for establishing the workload/client identity through various attestation mechanisms and only issues the JWT-SVID once the attestation requirements are satisfied. To me it seems reasonable that if you trust the SPIRE server, you could accept the JWT-SVVID and register the SPIFFE_ID as the client_id. The TTS/AS could apply additional policy in deciding whether it accepts the JWT-SVID (e.g. filtering on the SPIFFE ID, trust domain etc), but that adds complexity and may not be needed. The simplest is to accept the JWT-SVID when you trust the issuer (e.g. SPIRE server) and then perform registration (perhaps with some default metadata that is configured for JWT-SVIDs from certain issuers) You could use dynamic client registration, and define the JWT-SVID as a new authentication mechanism in that protocol. DCR feels less efficient as you will have an extra roundtrip and the outcome feels the same since you trust the JWT-SVID issuer (e.g. SPIRE). The extra roundtrips will add up - both because of the volume of these clients in these microservices architectures, but also because they can come and go at a very rapid rate, so you may end up registering, and re-registering a lot of them. I think your suggestion to register the client_ids when the JWT-SVID is first presented is a practical way to deal with these highly volatile environments. You can put some registration policies in place such as explicitly parsing of the SPIFFE ID or set time limits for how long you will keep the registration (maybe age it out if you haven't seen a client_id interacting with the TTS/AS in 24 hours). [1] https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/ On Thu, Feb 13, 2025 at 7:25 AM 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
