Hello everyone. Very excited to see this draft. It helps tremendously in addressing use cases around oauth client management in machine-to-machine scenarios. Particularly, the PKI authentication method.
In reviewing the document, I noticed that the only supported method for identifying a client using the PKI authentication method is by referencing its distinguished name. This caught me a bit by surprise - many newer projects aimed at automating X.509 issuance in the datacenter utilize SAN extensions rather than distinguished name in order to encode identity. I am further under the impression that the community is, in general, moving away from the subject extension altogether in favor of SAN-based identification. Full disclosure: I am one of the maintainers on a project called SPIFFE, which provides identity specifications for datacenter workload applications. For X.509, SPIFFE encodes identity into a URI SAN extension. A number of projects using SPIFFE do not configure the subject with identifying information (SPIRE and Google Istio being just a couple). I am also hearing of other X.509 automation projects which are moving away from subject/distinguished name (even if they are not using SPIFFE). While I think support for distinguished name is absolutely necessary, I worry that supporting it solely will render it incompatible with some of the more modern PKIX systems and not stand the test of time. I know that I am a little late to this, and for that I apologize... but I feel this is a significant point. I would like to open a discussion on supporting the most commonly used SAN extension types in addition to distinguished name. To accomplish this, amending section 2.1.2 `Client Registration Metadata` with additional parameters seems appropriate. In my experience, the most commonly used SAN extensions are: DNS name, IP address, URI, and email address. Are there significant drawbacks to extending the number of client registration metadata parameters? I would very much like to see this - without it, many existing projects will be unable to use the spec. I am happy to contribute time and text to this, assuming people feel that this is a beneficial addition. Sorry again for the timing -- evan _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
