> > Hi Arndt, Flemming, > > Following this thread with interest, since it overlaps with work I've been > doing on client instance identity in OAuth 2.0 Client Instance Assertion > <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/> > . > > That draft addresses the same underlying situation as point 1: one > registered client_id with many concurrent runtime instances, each holding > its own workload identity. It keeps client_id as the logical client, > conveys the instance's identity to the token endpoint, and represents which > instance authenticated in the issued token (act/sub). It also has a > SPIFFE compatibility section that consumes the SPIFFE client auth draft's > spiffe_id matching rule, so I've worked through the same interop > questions from the consuming side. > > Two observations: > > *1)* Good to see #43 tracked. One refinement on "the other sections > already accommodate this explicitly": they permit one-to-many, but they > don't specify it. > > The validation rules accept a SPIFFE ID that either matches a client > identifier or "is associated with" one, but that association is only > defined in one of the three registration models Section 5 allows: > > - CIMD: defined (sub matches the spiffe_id metadata per 5.1) > - RFC 7591 dynamic registration: undefined > - Out-of-band registration: undefined > > What binds a workload identity space to a client registration, and how the > AS validates it, is the actual interop surface here. However #43 resolves > the 1:1 request rule, the association is what ends up carrying the weight, > so it may be worth specifying as part of the same fix. Defining exactly > that binding turned out to be most of the work in my draft. > > A related gap/opportunity: when the SVID names an instance rather than the > client, the instance identity is discarded after authentication. Nothing > standard carries it into the issued token, so resource servers still see > only client_id. > > If the WG wants that identity to survive into issued tokens (audit, > per-instance policy and revocation), that's the layer the client instance > assertion draft defines, and the two compose cleanly: the SPIFFE client > auth draft authenticates the workload, client instance assertion represents > it downstream. > > *3a)* No strong opinion on the field shape, but two data points from > consuming the current rule (the client instance assertion draft's > instance_issuers descriptor imported the same spiffe_id member, and with > it the same overload): > > - A wildcard-form value isn't itself a valid SPIFFE ID (path segments > permit only [a-zA-Z0-9.-_]), so a consumer has to detect the trailing > /* before knowing which comparison to run. > - The prefix rule today is defined only against the JWT-SVID sub, so > X509-SVID deployments have no scoped-many-instances option at all. This may > be relevant to "prefix-only may not cut it". > > I'll align my descriptor member with whatever shape lands there. > > Thanks, > > Karl >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
