Consumer Data Right FAPI 1.0 Advanced: Transition to Phase 3
This article provides an overview of SecureAuth configurations to comply with the Consumer Data Right (CDR) FAPI 1.0 Advanced Phase 3 profile requirements.
CDR FAPI 1.0 Advanced Alignment
The OIDF Financial-grade API (FAPI) security profile specifies security requirements for high risk API resources protected by the OAuth 2.0 Authorization Framework. CDR is adoptiong the FAPI specification to ensure the data holders and data recipients exchange data in the most secure way with appropriate consumer consents.
At a highlevel, below recommendations for Phase 3 transition by CDR regime and the Phase 3 transition requirements are extracted and interpreted from the documents and discussion notes here.
SecureAuth Configuration Updates
Client Registration
New clients registered in CDR workspaces will now be subject to the following additional constraints: | Type of Client | Required Fields| Conditional Fields | | --------- | ----------- | --------- | | Hybrid Flow |
Type of Client | Required Fields | Conditional Fields |
|---|---|---|
Hybrid Flow |
| |
Authorization Code Flow |
|
|
No configuration is needed to enforce this change.
OIDC Hybrid Flow
The retirement of hybrid flow has been delayed until Phase 4. Id token encryption for this flow is now mandatory in contrast to Phase 2. This will automatically be enforced for new clients during the registration process.
Preexisting Clients
Hybrid clients without id token encryption settings will need to re-register to enforce this change.
Authorization Code Flow
This flow is mandatory in Phase 3 with the following stipulations:
the registered client must have valid JARM configuration settings
response_mode must be
jwt
The JARM response mode can be enforced with the Disallow code response type without JARM flag under Auth Settings > Advanced
 |
ID Token Encryption
This is optional for authorization code flow and will be determined solely by the client's configuration. In Phase 4 id token encryption will be removed completely.
Removal of Non Standard Claims
SecureAuth, by default, returns the sharing_expires_at and refresh_token_expires_at claims. These claims were marked for deprecation in Phase 2 and are required to be removed in Phase 3.
SecureAuth will continue to support the exp claim for refresh token expiry in refresh token introspection endpoint as specified in Security Endpoints. The exp claim is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z to the UTC expiry time.
Configuration transition Highlights for Phase 3
Feature | SecureAuth Phase 3 configuration |
|---|---|
Mandatory ID Token Encryption for Hybrid Flow | Supported & enforced by Client Registration |
Mandatory JARM for Authorization Code Flow | Supported & enforced by Client Registration and Advanced OAuth Settings |