Greetings
I've taken a closer look at the latest version of the "OAuth SPIFFE Client
Authentication" draft
(https://www.ietf.org/archive/id/draft-ietf-oauth-spiffe-client-auth-02.html)
and I have a few comments for discussion:
1) Section 3.2 states that:
"The request MUST include the client_id parameter containing the SPIFFE-ID
of the client. It MUST match the URI SAN of the presented X509-SVID client
credential."
There is a potential issue here between having a common client_id for multiple
instances of a given client application yet each instance of that client
application may have a unique SPIFFE ID.
2) Section 4 states that:
"Clients MUST support at least one of JWT-SVID, X509-SVID or WIT-SVID. To
guarantee interoperability a client SHOULD support all."
It seems unlikely to me that clients in general will implement all three of the
above. I think we have a better chance of guaranteeing interoperability if the
requirement was put on the AS instead.
3) Section 5.1 defines use of a wildcard in the spiffe_id and some associated
rules.
3a) The way the text is written we end up overloading the term "spiffe_id"
which can lead to issues elsewhere in the document (e.g. what do you actually
put in the client_id) ? I think a cleaner solution would be to define a
separate field for this kind of syntax and associated semantics, e.g.
spiffe_id_prefix. We can discuss further whether spiffe_id and spiffe_id_prefix
should be mutually exclusive.
3b) The prefix-based approach is simple, but it also imposes limitations on the
spiffe_id naming scheme a particular deployment can use. We should discuss
further whether we want something more flexible than a simple prefix (e.g.
regex or somewhere in-between)
The above are my main comments for discussion - I'll create GitHub issues for
them as well but wanted to get them out here first.
I have some additional comments of varying editorial degrees - I'll get those
on GitHub as well
(https://github.com/oauth-wg/oauth-spiffe-client-authentication).
Thanks
-- Flemming
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
