[Openid-specs-fapi] Issue #466: Proposal for FAPI DCR/DCM (Dynamic Client Registration/Management) profile (openid/fapi)

[josephheenan]

New issue 466: Proposal for FAPI DCR/DCM (Dynamic Client Registration/Management) profile
https://bitbucket.org/openid/fapi/issues/466/proposal-for-fapi-dcr-dcm-dynamic-client

Joseph Heenan:

As discussed on 1st December call I think we should consider creating a spec for this:

[https://bitbucket.org/openid/fapi/wiki/FAPI\_Meeting\_Notes\_2021-12-01\_Atlantic#rst-header-id17](https://bitbucket.org/openid/fapi/wiki/FAPI_Meeting_Notes_2021-12-01_Atlantic#rst-header-id17)

‌

The scope of the spec would be creating a profile of RFC7591 and RFC7592 that adds extra security.

Brazil have an ecosystem specific spec that is a profile of these specs: [https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1\_ID2.html](https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID2.html#section-)

The items I think might be usefully handled in a generic FAPI spec might be:

### RFC7591

1. Some suggestion about securing the registration endpoint \(Brazil use TLS client certificates primarily\)
2. Some suggestions about the use of software statement assertions \(e.g. limiting the time they are valid for\)
3. Potentially define an extra metadata field with the goal that the SSA can include a full set of redirect uris for the software, but allow the client to register a subset of these fields. \(This is required in the UK / Au / Brazil specs I believe.\)

‌

### RFC7592

1. Some suggestions about securing the registration endpoint \(e.g. binding of `registration_access_token` using OAuth-MTLS or dPOP, or MTLS authentication\)

‌