Proposal for FAPI DCR/DCM (Dynamic Client Registration/Management) profile

[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

‌

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

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)

‌

The hope would be that by creating a generic spec, the ecosystem specific profiles for future ecosystems can be smaller, and it may enable the creation of generic FAPI DCR/DCM certification tests and avoid fragmentation.

‌

[Joseph Heenan]

Chris Michael mentioned on the 12th Jan call that there may be different cases:

1. Ecosystems that have a directory
2. Ecosystems that have multiple directories
3. Ecosystems that don’t use a directory

Bahrain and Europe have examples of case '3'.

For the sake of an initial draft, Joseph suggested we focus on '1' at least initially.

‌

[Nat Sakimura]

Joseph is going to create an initial pre-WD

[Freddi Gyara]

I think the biggest inherent weakness is the management specs is that it forces the use of the registration_access_token rather than allowing the stronger client authentication mechanisms that are otherwise mandated by FAPI. This should be one of the things to plug here. I totally agree with your suggestion around strengthening that.

As a special case of the “ecosystems that dont use a directory”, we should define the software statement expected for situations where ecosystems have:

• one or more trusted CAs (e.g. EIDAS QTSPs in the EU)
• one or more trusted IDPs that issue id_tokens (could an id_token be used as a software statement in that special case ?)

‌

[gffletch]

For mobile apps, I think leveraging the OS provided app attestation capabilities can also help with securing the registration endpoint. It is a form of client authentication

‌

Also, doesn’t time limiting software statements just mean that there is some other API that deployed apps have to call to obtain the software statement and then we have to figure out how to secure that API? Maybe I’m missing something.

[Nat Sakimura]

To be discussed on 2023-06-14 call.