When the OP receives an incoming dynamic client registration request, the current spec does not say much about the request processing and validation steps the OP needs to do in order for the Federation trust to be valid.
Obviously this step needs to allow deployment specific additions, but the spec should add a set of minimum requirements, for the trust chain to be complete between the registered client and the OP through the chain of MS-s from the federation.
I'd suggest following the pattern of OpenID Core spec, and add a section of request validation after each section describing the request.
My proposal would be that the spec includes statements like this:
- The OP should ignore all other values from the registration request than: metadata_statement, metadata_statement_uri and redirect_uri
- The first level of metadata statements needs to be self signed iss=sub
- The unsigned redirect_uri value MUST match the one from the flattened metadata statement.