Should this be recommended or required for FAPI 2?
This came up on today’s call, in particular that lack of DCR and in particular the client management endpoint made it harder to perform some of the migrations necessary for OPs to move from the OpenBanking UK security profile over to FAPI - for example, it was hard at some banks to change a client from using RS256 to using PS256, or to move from client_secret_basic to private_key_jwt, and in particular to easily allow the change to be made at a time of the RPs choosing, and without registering a whole new client (which would invalidate existing refresh tokens/access tokens).
I consider such a migration a deployment/scheme specific exercise. I don’t think it requires a standardized client management API. Moreover, client management is an experimental RFC for good reasons. There is a lack of implementation experience.
I would also consider this deployment-specific. FAPI will be used in many environments where DCR is not applicable.
I think it’s reasonable to not mandate DCR in FAPI 2 but a recommendation with existing experiences might be useful?
I agree this is deployment specific. Although, for those deployments that require it, some recommendations, guidelines or even optional part of the specification would be helpful.
Alternatively, every jurisdiction will do it their way which potentially creates additional threat vectors.
Hi support this proposal. As far as I remember we had started a discussion re client management practices when Dima and Stuart joined the WG. @Dima Postnikov haven’t you started a document to compare approaches back then?
wonder if we should start a “FAPI Best Practices” document.
We have an ‘implementation and deployment advice’ document, so I think this could potentially go in there.