I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies a protocol whereby an instance of installed software on a node can register itself with an OAuth 2.0 authorization server and in doing so (normally) acquire a secret to be used in subsequent authentications. According to the introduction: "This specification generalizes the registration mechanisms defined by the OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] specification and used by the User Managed Access (UMA) Profile of OAuth 2.0 [I-D.hardjono-oauth-umacore] specification in a way that is compatible with both, while being applicable to a wider set of OAuth 2.0 use cases." I am not an expert on the evolution of OAuth, and I would expect others on Secdir are, so they be more able to evaluate the goodness of the particular design decisions, but this appears to me to be consistent with the way OAuth does related things and the particular attributes that this document specifies as being relevant to the process seem right. The security considerations section of the document is somewhat unorthodox in that it specifies security aspects of the protocol (e.g., that it MUST run over TLS 1.2 and MAY run over other transport-layer mechanisms. In most recent RFCs, the security considerations section is not normative but rather reviews the security aspects of the protocol. I'm not objecting though... this organization seems entirely reasonable. I will throw in one vague concern and one specific issue: 1) This document is all about infrastructure to allow software (as opposed to the end user or service using the software) to authenticate itself. This has been the holy grail of many authorization architectures for a long time, but the technology to accomplish it securely is by and large still not in place. I worry that specifying protocols for doing it might fool people into thinking they are getting more security than they really are. There may be some other document containing the rationale and scenarios for attempting this, but it was not obvious (at least to me) from reading the document. 2) The software_version values are specified as opaque where the only operation to be done on them is comparisons for equality. It's not clear (at least to me) the intended usage of this field, but generally version numbers work best when they have multiple parts (at least major version and minor version and sometimes lower level indicators) and where the different parts can be compared for "greater than" and "less than" in addition to tests for equality. That allows forward compatibility when a new version is released that is intended to be compatible with an existing version while detecting incompatibility in the case where a major version number changes. --Charlie