...
It's important to remember that the client registration payload has most of its attributes as non-mandatory, and that assigned values that conflict with those in the software statement assertion will be overridden by the values of the software statement assertion issued by the Directory of Participants. Not all metadata a client wishes to provide may be contained in a software statement, e.g alternative Metadata Languages and Script values. There are some cases where the client metadata are subset of the existing values in the SSA, such as redirect_URIs.
...
shall advertise its presence in the Open Finance Brasil ecosystem by being listed on the Directory of Participants;
shall advertise all Open Finance Brasil REST API resources protected by the OpenID Provider on the Directory of Participants;
shall advertise support for all signing, encryption, authentication mechanisms and standards required to support Open Finance Brasil Financial API;
shall advertise support for OpenID Dynamic Client Registration;
may advertise mtls_endpoint_aliases as per clause 5 RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens the token_endpoint, registration_endpoint, userinfo_endpoint and push_authorization_request_endpoint;
if supporting Financial API - Client Initiated Back Channel Authentication shall advertise through OIDD mtls_endpoint_aliases the backchannel_authentication_endpoint;
shall not rotate the registration_access_token.
6.2. Client
The Client shall support OpenID Connect Discovery as required by Financial-grade API Security Profile 1.0 - Part 1: Baseline
...
7. Open Finance Brasil OpenID Connect Registration Provisions
7.1. Authorization server
The Authorization Server shall support the RFC RFCs Dynamic Client Registration (DCR) RFC7591, Dynamic Client Management (DCM) RFC7592 and OpenID Registration
...
The following table describes the regulatory roles for Open Finance and the related OAuth 2.0 scopes mapping. If the scopes are omitted during the DCR process, the authorization server shall grant the complete set of potential scopes based on the registering bank's regulatory roles, as described in the Server Defaults section.
Regulatory Role | Description | Allowed Scopes | Target Phase |
DADOS | Instituição transmissora ou receptora de dados (AISP) | openid accounts credit-cards-accounts consents customers invoice-financings financings loans unarranged-accounts-overdraft resources credit-fixed-incomes exchanges bank-fixed-incomes variable-incomes treasure-titles funds | Phase 2 and Phase 4 |
PAGTO | Instituição prestadora de serviço de iniciação de pagamentos (PISP) | openid payments recurringPayments | Phase 3 |
CONTA | Instituição detentora de conta (ASPSP) | openid | Phase 3 |
CCORR | Correspondente de crédito | openid | Phase 3* |
It is requiread that the active roles in the application's software_statement are validated. The field _software_statement_roles shall be used for validation and currently listed roles shall be active.
...