FAPI 1.0 Non Normative Examples

[anzbankau]

Description

Review and update of the non-normative examples in line with FAPI 1.0 transition.

Area Affected

Security profile > security end-points

Change Proposed

Proposing for review and update of the non normative examples for the security end points in line with FAPI 1.0 transition phases. More specifically:

1. PAR end point with PKCE. (The following is an industry reference - https://datatracker.ietf.org/doc/html/rfc9126#section-2.1 )
2. Authorize end point with PKCE
3. Authorize end point response with PKCE (including JARM). (The following is an industry reference - https://openid.net/specs/openid-financial-api-part-2-1_0.html#example-jarm-response)

DSB Proposed Solution

The current DSB proposal for this issue is in this comment.

[spikejump]

We note that https://datatracker.ietf.org/doc/html/rfc9126#section-3 is the appropriate section in PAR that describes the use of the request object.

The first paragraph in section 3 indicates that the only permitted parameters outside of the JWT request parameter are 'client_id', 'client_assertion' and 'client_assertion_type'. As the spec says, "Request parameters required by a given client authentication method are included in the "application/x-www-form-urlencoded" request directly and are the only parameters other than "request" in the form body.... All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request.".

The example in section 3 is a continuation of the example from section 2.1.

Section 4, has an example of authorisation request to the authorisation endpoint.

[CDR-API-Stream]

In follow up to this change request, it is intended that the following sections are updated to include FAPI 1.0 compliant non-normative examples:

• OpenID discovery document
• PAR endpoint
• Authorisation endpoint
• Token endpoint
• SSA endpoint
• Add and example of the Authorisation Code Flow to Authentication Flows
• Request Object

This will illustrate support and use of:

• PAR RFC9126
• PKCE RFC7636
• JARM

These examples will be included in addition to the existing non-normative examples with labels to clearly indicate what are pre-FAPI 1.0 of OIDC Hybrid Code Flow examples versus FAPI 1.0 compliant examples using the Authorisation Code Flow.

These non-normative examples will include the Authorisation Server publishing supported metadata parameters via their well known OpenID discovery document, client registration and negotiation as well as authorisation and token endpoint calls.

A sequence diagram illustrating the orchestrated flow is presented below. This will be discussed in the maintenance iteration call held at 2pm AEST 06/04/2022. Non-normative examples will be published after discussion of the flow and additional considerations.

Further considerations

• Do the Client Registration, SSA Definition, Registration Response, and OpenID Provider Configuration End Point sections require any changes to better describe the required OIDD metadata, SSA registration parameters and client authorisation request parameters?
• Are there any non-normative examples other than listed above which also require changes?
• Are there any other sections that require clarification for the use of the Authorisation Code Flow (vs OIDC Hybrid Code Flow)

[CDR-API-Stream]

This issue was discussed in the Maintenance Iteration 11 call. It was agreed to carry this change request into maintenance iteration 11.

[CDR-API-Stream]

Issue #522 has been raised to deal with the registration of required OIDD metadata parameters for JARM, PAR and PKCE.

[CDR-API-Stream]

Based on the discussion in Maintenance Iteration 11 the sequence diagram has been updated. A separate change request will be raised to consider the requirements for response encryption using JARM. An OIDF issue has already been raised in relation to this.

[anzbankau]

We view the below as necessary points to resolve in order to enable FAPI 1 phase 3 implementations:

• DCR metadata introduced in PAR, JAR (used by PAR, specified in FAPI) and JARM not listed in the client registration JWT template
• response_types defined in the CDS enumerations for v1.17 don’t include ‘code’ which is required to implement the authorization code flow
• Sequence diagram indicates that the token response JWT (when using JARM) should be encrypted (step 5.3). This is listed in comments as something that will be resolved in a separate change request, however could this position please be clarified.