Version Control

Introduction

This document is based on the OpenID Foundation's Financial-grade API Read+Write specification FAPI-RW, which in turn is based on the Read only specification document FAPI. In addition, the Financial-grade API: Client Initiated Backchannel Authentication Profile FAPI-CB has been incorporated, to support a decoupled authentication flow. The Security Profile will further shape these profiles in some cases tightening restrictions and in others loosening requirements using keywords. Please see the introduction to FAPI-RW for a general introduction to the aims of this document.

The Security Profile outlines the differences between the FAPI-RW and FAPI-CB with clauses and provisions necessary to reduce delivery risk for API Providers.

Security Architecture

OAuth 2.0

OAuth 2.0 will be the foundational framework for API Security for the in-scope API standards. OAuth 2.0 itself is a framework which can be deployed in many ways, some of them completely incompatible with financial models. In order to securely use the OAuth 2.0 framework, a profile must exist by which both Third Parties and API Providers are certified to have correctly configured their clients and servers.

OIDC Core

The OpenID Connect Request object uses exactly the same claims object for specifying claim names, priorities, and values as OAuth 2.0. However if the Request object is used, the Claims object becomes a member in an assertion that can be signed and encrypted, allowing the API Provider to authenticate the request from the Third Party and ensure it hasn't been tampered with. The OpenID Connect Request object can either be passed as a query string parameter, or can be referenced at an endpoint that could theoretically be protected by MATLS. The use of JWT Request objects by reference is not supported due a number of delivery risks and remaining security concerns.

In addition to specifying a ticket, the Third Party can optionally require a minimum strength of authentication context or request to know how long ago the user was actually authenticated. Multiple tickets could be passed if necessary. Everything is fully specified. Vendors who implement this feature are not creating a one-off proprietary feature, they are simply supporting the OpenID Connect standard.

Full accountability is available as required by all participants. Not only can the API Provider prove that they received the original request from the Third Party, but the Third Party can prove that the access token that comes back was the token that was intended to be affiliated to this specific ConsentId.

OIDC Client Initiated Backchannel Authentication

The OIDC Client Initiated Backchannel Authentication (CIBA) profile enables a Client (Third Party) to initiate the authentication of the end-user (Customer) with the OpenID Provider (API Provider) in an out of band mechanism. This direct out of band mechanism between the Third Party and API Provider means that the Customer is not redirected to authenticate through the Customer's browser (or consumption device).

FAPI

The Financial API working group in the OpenID Foundation has created a draft standard for configuration of Financial-grade API security regimes. If any FAPI-compliant vendor can participate in the Open Data API ecosystem, it means that vendors can work to the standard and reach many customers, rather than having to create different solutions for different banking platforms. The FAPI profiles apply to both OIDC Core and OIDC CIBA profiles.

Scope

This part of the document specifies the method of

• Applications to obtain the OAuth tokens in an appropriately secure manner for financial data access;

• Applications to use OpenID flows to identify the Customer; and

• Using tokens to interact with the REST endpoints that provides financial data;

This document is applicable to higher risk use cases which includes commercial and investment banking.

Normative References

The following referenced documents are strongly recommended to be used in conjunction with this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

• [FAPI] - FAPI ReadOnly profile [FAPI]: http://openid.net/specs/openid-financial-api-part-1.html

• [FAPI-RW] - FAPI Read+Write profile [FAPI-RW]: http://openid.net/specs/openid-financial-api-part-2.html

• [OIDC] - OpenID Connect Core 1.0 incorporating errata set 1 [OIDC]: http://openid.net/specs/openid-connect-core-1_0.html

• [MTLS] - Mutual TLS Profile for OAuth 2.0 [MTLS]: https://datatracker.ietf.org/doc/rfc8705/

• [CIBA] - OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-02 [CIBA]: https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html

• [FAPI-CB] - Financial-grade API: Client Initiated Backchannel Authentication Profile [FAPI-CB]: https://openid.net/specs/openid-financial-api-ciba-ID1.html

• [OAUTH-CLIENT-AUTH] - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [OAUTH-CLIENT-AUTH]: https://tools.ietf.org/html/rfc7521

• [JARM] - OpenID FAPI JWT-Secured Authorization Response Mode: https://openid.net/specs/openid-financial-api-jarm.html

• [PAR] - OAuth 2.0 Pushed Authorization Requests: https://www.rfc-editor.org/rfc/rfc9126.html

• [JAR] - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR): https://www.rfc-editor.org/rfc/rfc9101.html

• [PKCE] - Proof Key for Code Exchange by OAuth Public Clients: https://www.rfc-editor.org/rfc/rfc7636.html

• [BCP-225] - JSON Web Token Best Current Practices: https://www.rfc-editor.org/rfc/rfc8725

Terms and Definitions

For the purpose of this document, the terms defined in [FAPI ReadOnly profile] FAPI, [FAPI Read+Write profile] FAPI-RW, [OpenID Connect Core] OIDC, [OpenID Connect Client Initiated Backchannel Authentication Flow] CIBA, and [FAPI: Client Initiated Backchannel Authentication Profile] FAPI-CB apply.

Symbols and Abbreviated Terms

• API Provider - provides APIs in a manner that complies with the API Standards (e.g. Account Information and Payment Initiation APIs), and connects those APIs with a Third Party.

• Third Party - the entity that consumes an API in a manner that complies with the API Standards.

• Customer - a natural or legal person that operates banking accounts.

Authorisation Scopes

To access each of the APIs, the API must be called with an access token in the HTTP Authorization header.

The scopes required with these access tokens and the grant type used to get the access token are specified in the specific API documentation.

Consent Authorisation

OAuth 2.0 scopes are coarse grained and the set of available scopes are defined at the point of client registration. There is no standard method for specifying and enforcing fine grained scopes (e.g. a scope to specify that account information should only be provided for certain time periods or to enforce payments of a specified amount on a specified date).

A consent (identified with a ConsentId) is used to define the fine-grained permissions that are granted by the Customer to the Third Party. The API specifications define a variety of consents resources such as account-access-consents and domestic-payment-consents. The act of a Customer providing authorisation of a consent with an API Provider is called consent authorisation.

Two generic consent types are used in the API specification:

• Short lived consents - these are used for one-off access to a protected resource

• Long lived consents - these are used for enduring access to a protected resource

Steps for consent authorisation are:

• The Third Party requests an API Provider to create a consent (with the fine-grained permissions) using a client credentials grant.

• The API Provider creates the consent and responds with a ConsentId.

• The Third Party then initiates an authorisation flow (passing in the ConsentId as a parameter) where the Customer authorises the consent with the API Provider. The supported grant types for the authorisation flow are described below.

• The API Provider issues an access token to the Third Party tied to the authorised consent and the Customer.

Token Expiry

An API Provider may issue an access token and refresh token for a long-lived consent. These tokens may expire before the consent expires. In such a situation, the state of the consent does not change and the API Provider must not modify the state of the consent.

Token Expiry Time

The expiry time for issued access tokens and refresh tokens must be deterministic for the Third Party.

In order to achieve this:

• The API Provider must indicate the lifetime in seconds of the access token in the expires_in field of the JSON object returned by the token endpoint (see https://tools.ietf.org/html/rfc6749#section-4.2.2 ).

• If the API Provider issues a refresh token, the API Provider must support refresh token introspection, as per the Security Profile

• The location of the introspection endpoint is indicated in authorisation server metadata introspection_endpoint.

• If the API Provider issues a refresh token that does not expire, the API Provider must populate refresh token introspection response claim exp with a value representing the number of seconds to 03:14:07 UTC on 19 January 2038 (end of 32-bit UNIX epoch), or a value further in the future.

Supported Grant Types

OAuth2.0 and OIDC provide support for a variety of methods for the Authorization Server to issue an access token to the Client. These methods are called Grants.

Some of these Grant Types only identify the client, but not the resource owner. It is sufficient to provide the client's identity.

On the other hand, other grant types identify the client and resource owner. The resource owner must be authenticated to issue access tokens through such a grant type.

The Security Profile supports a sub-set of these grants as well as the FAPI Profile CIBA grant.

Client Credentials Grant

Some of the APIs can be accessed using an access token issued through a Client Credentials Grant. These APIs are not restricted resources owned by the Customer and do not require Customer consent authorisation. It is sufficient to identify and authenticate the Third Party in order to call these APIs.

The Client Credentials Grant is documented in Section 4.4 of the OAuth 2.0 RFC.

Authorization Code Flow

The Authorization Code Flow (see https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth ), used with PAR, PKCE and JARM is both more secure and offers a better consumer experience than the Hybrid Flow.

The Authorization Code Flow uses Pushed Authorization Requests, aka PAR (with PKCE) to submit an authorization request for validation, before redirecting the customer. Third Parties can then redirect when an authorization request has passed technical validation with the API provider.

The JARM response removes the need for ID token to be exposed via the redirect, and as such prevents leakage of identity information. Because the JARM response is a signed-JWT, there is no requirement for detached signature, code hash or state hash.

ID Token

When an access token is generated through a Authorization Code Flow, an OIDC Authorization Server will also issue an ID Token along with the access token.

The ID Token is a signed JWT that consists of a number of claims that identify the resource owner. In the NZ Open Data API context, the ID Token always identifies the consent (using ConsentId claim) that was authorised and Customer who authorised it (using the sub claim).

As the ID Token is signed by the API Provider and bound to a specific Third Party (through the aud claim), the ID Token could be leveraged to identify the Customer in subsequent authorisation requests. OIDC caters for this by allowing the ID Token to be passed into an authorization code grant request as the id_token_hint query parameter (as documented here).

Error Condition

If the Customer does not complete a successful consent authorisation (e.g. if the Customer is not authenticated successfully), the authorization flow ends with a redirection to the Third Party with an error response as described in section 4.1.1 herehttps://openid.net/specs/openid-financial-api-jarm.html#the-jwt-response-document . The Customer is redirected to the Third Party with an error parameter indicating the error that occurred.

Hybrid Flow

The Hybrid Flow enables access to APIs that require the Customer as well as Third Party to be identified and authenticated.

The Hybrid Flow (see Section 3.3. of the OIDC Specification) provides a redirect based mechanism to redirect a Customer to the API Provider's authorisation pages in order to authenticate the Customer and generate an authorization code. The Third Party can then exchange this authorization code for an access token (and optionally refresh token) by calling the API Provider's token endpoint and authenticating itself.

The Security Profile and FAPI Read & Write API Security Profile specify a more stringent set of requirements that API Providers and Third Parties must adhere to.

ID Token

When an access token is generated through a Hybrid Flow, an OIDC Authorization Server will also issue an ID Token along with the access token.

The ID Token is a signed JWT that consists of a number of claims that identify the resource owner. In the Security Profile API context, the ID Token always identifies the consent (using ConsentId claim) that was authorised and Customer who authorised it (using the sub claim).

As the ID Token is signed by the API Provider and bound to a specific Third Party (through the aud claim), the ID Token could be leveraged to identify the Customer in subsequent authorisation requests. OIDC caters for this by allowing the ID Token to be passed into an authorization code grant request as the id_token_hint query parameter (as documented here).

Error Condition

If the Customer does not complete a successful consent authorisation (e.g. if the Customer is not authenticated successfully), the hybrid flow ends with a redirection to the Third Party with an error response as described in RFC 6749 Section 4.1.2.1. The Customer is redirected to the Third Party with an error parameter indicating the error that occurred.

Decoupled Flow (CIBA)

The CIBA flow is a decoupled authentication flow that enables access to APIs that require the Customer as well as Third Party to be identified and authenticated.

The Client Initiated Back-channel Authentication flow is part of the OpenID specifications. A FAPI Profile of the CIBA specification is available and API Providers that implement the CIBA Flow must adhere to this FAPI profile.

An API Provider must implement the CIBA Flow to allow Customers to authenticate themselves using a decoupled authentication device that may be distinct from the consumption device on which they consume the Third Party application.

The NZ Security Profile specifies a more stringent set of requirements that API Providers and Third Parties must adhere to.

An API Provider:

• must support the id_token_hint as a method of identifying the Customer to be authenticated.

• may support login_hint_token as a method of identifying the Customer to be authenticated.

• must document on their developer portal, the methods of identifying a Customer that the API Provider supports.

A Third Party:

• must pass a method of identifying the Customer in the authorisation request object using either the login_hint_token or id_token_hint (i.e., not both).

• must create a consent with the API Provider prior to creating the CIBA authorisation request.

• must pass the generated ConsentId as a custom claim in the authorisation request object (this allows the access token that is eventually generated to be bound to a specific consent).

If an API Provider does not support a specific method of identifying a Customer, the API Provider must return an error with the error field set to invalid_request as per https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.13 .

ID Token Hint

To identify a Customer through a previously issued ID Token - the Third Party must issue an authorisation request object with an id_token_hint which contains an ID Token from a previously successful authentication event for the Customer. As this is a previously used ID Token, it is valid for a Third Party to use an expired ID Token.

Third Parties must provide either a login_hint_token or id_token_hint (i.e., not both).

Login Hint Token

The login_hint_token is a token in the CIBA authorisation request object that contains a subject_type and corresponding claim that identifies the Customer for whom authentication is being requested.

Third Parties must provide either a login_hint_token or an id_token_hint (i.e., not both).

The Security Profile and related APIs support these login_hint_token identification claims:

• phone

• email

• username

• api_provider_token

• third_party_token

UML Diagram

Open

Data Model

Example

This is an example of a login_hint_token using the phone number as the subject_type:

Changes to Consent Status

A Customer may revoke their consent either through the Third Party or directly through the API Provider. This only applies to long-lived consents.

• When the Customer revokes their consent with the API Provider, the API Provider must update the consent Status as Revoked.

• When the Customer revokes their consent with the Third Party, the Third Party must make a request to DELETE the consent using the ConsentId.

In each of the above cases, the consent states are terminal i.e., the API Provider must not allow any further state changes. The API Provider must not permit any authorisation code grants to be initiated with such a consent.

Consent Re-authorisation

Consent re-authorisation is the scenario where the API Provider requests a long-lived consent to be re-authorised (e.g., because of fraud risk). In this scenario, the Third Party reuses the existing ConsentId, and the API Provider may tailor the re-authorisation flow to be more efficient than the full consent authorisation flow.

A Third Party may request a Customer to re-authorise an existing long-lived consent that is in the Authorised state (using the existing ConsentId) at any point of time. This includes before and after the tokens bound to the consent have expired.

An API Provider must accept a request from a Third Party to re-authorise a long-lived consent (that is in the Authorised state) at any point of time. This includes before and after the tokens bound to the consent have expired.

Once a consent is re-authorised, the Third Party must not use access tokens and refresh tokens that were previously issued for the same consent.

If an API Provider issues a new access token and refresh token as a result of consent re-authorisation, it may invalidate the previously issued access tokens and refresh tokens for the same consent.

Use of Refresh Token

An API Provider may issue a refresh token along with an access token as a result of consent re-authorisation.

When an access token expires, the Third Party may attempt to get a new access and refresh token as defined in Section 6 of the OAuth 2.0 specification.

If the Third Party fails to get an access token using a refresh token, the Third Party must initiate a consent re-authorisation flow.

NZ Read and Write API Security Profile

The NZ Read and Write API Security Profile extends from [FAPI Read+Write profile] FAPI-RW.

This section identifies variations from FAPI-RW and the numbered section references where there is a variation in FAPI-RW.

NZ Client Initiated Backchannel Authentication Profile

The NZ Client Initiated Backchannel Authentication Profile extends from [FAPI: Client Initiated Backchannel Authentication Profile] FAPI-CB.

This section identifies variations from FAPI-CB and the numbered section references where there is a variation in FAPI-CB.

The Client Initiated Backchannel Authentication Flow [CIBA] specifies an alternate method of users granting access to their resources whereby the flow is started from a consumption device, but authorized on an authentication device.

Non-Normative Examples

Hybrid Flow

This section describes parameters that should be used with a hybrid grant flow request so that a ConsentId can be passed from the Third Party to an API Provider for minimum conformance for the NZ Read and Write API Security Profile (extending FAPI-RW). The hybrid flow is used as an optional redirect authorisation flow for the NZ Banking Data and other specified APIs.

Prior to this step, 

1. The Third Party would have already registered a consent with an API Provider. This is achieved by creating a resource with an account information or payment consent APIs.

2. The API Provider would have responded with a ConsentId (this is the unique identifier for the consent resource).

Authorization Request

This section describes the bare minimum set of Authorization Request parameters that an API Provider must support. The definitive reference is specified in OIDC Section 3.3.2.1 (Authentication Request) and OIDC Section 3.1.2.1 (Authentication Request)

All API Providers must support the issuance of OIDC ID Tokens, a Third Party must request that an ID Token is issued. 

This is a non-normative example of the Authorization Request:

Parameters

Request Object

This section describes the Request Object which is used in the request Authorization Request parameter. The definitive reference is specified in OIDC Section 6.1 (Request Object). All standards and guidance MUST be followed as per the OIDC specification. Note that FAPI 1.0 Baseline and FAPI 1.0 Advanced place additional constraints on the Request Object.

As per OIDC - when the Request Object is used, the OpenID Connect Request Object values (in the JWT) supersede those which are passed using the OAuth 2.0 request query parameter syntax. 

The Request Object:

• must contain a "claims" request parameter with the ConsentId in the "id_token" object as an essential claim

• may contain additional "claims" to be requested if the API Provider's Authorization Server support them - these claims must be listed on the OIDC Well Known configuration endpoint.

In OIDC - the "claims" request parameter in the Request Object is used to request that specific Claims be returned in either the ID Token or at the userinfo endpoint. Hence the top level members of the "claims" request parameter are:

• id_token

• userinfo

The userinfo and id_token members of the claims request parameter are JSON objects with the names of the individual Claims being requested as the member names. Within an individual Claims field, the "essential" field is required to indicate whether the Claim being requested is an Essential Claim. If the value is true, this indicates that the claim is an Essential Claim.

For instance, the claim request:

can be used to specify that it is essential to return the ConsentId as a claim in the ID Token.

This is a non-normative example of the Request Object JWS - without Base64 encoding:

Claims

Where appropriate follow the JWT Best Current Practices Guides [BCP-225] https://www.rfc-editor.org/rfc/rfc8725  

Authorisation Response

The following is a non-normative HTTP authorization response, showing code, state and id_token parameters, as required by OIDC Core 1.0, section 3.3.2.5:

ID Token

This is a non-normative example of an ID Token returned - with the sub being populated with a PPID uniquely identifying the Customer to the Third Party.

Decoded ID Token JWT

Claims

Where appropriate please follow the JWT Best Current Practices Guides [BCP-225] https://www.rfc-editor.org/rfc/rfc8725  

Authorization Code Flow

This section describes parameters that should be used with a authorization code flow request so that a ConsentId can be passed from the Third Party to an API Provider for minimum conformance for the NZ Read and Write API Security Profile (extending FAPI-RW). The authorization code flow is used as the redirect authorisation flow for the NZ Banking Data and other specified APIs.

Authorization Code Flow is mandatory in this version of the NZ Security Profile.

Prior to this step;

1. The Third Party would have already registered a consent with an API Provider. This is achieved by creating a resource with an account information or payment consent APIs.

2. The API Provider would have responded with a ConsentId (this is the unique identifier for the consent resource).

Pushed Authorization Requests (PAR) with JWT-Secured Authorization Requests & Proof-Key Code Exchange

Pushed Authorisation Requests (PAR, RFC9126) allow an OAuth 2.0 authorization request to be lodged directly with the authorization server, without the need to redirect the client. This results in better security (the OIDC authentication request object is not exposed to user-agent) and customer experience, since the client is only redirect if the authentication request is considered appropriate to proceed.

FAPI 1.0 requires PAR requests to use JAR (RFC9101) method to submit a request object JWT, which must include PKCE claims.

FAPI 1.0 supports PAR requests with hybrid flow ("response_type": "code id_token"), however this specification requires PAR only for authorization code flow ("response_type": "code").

Proof Key Code Exchange

As per FAPI 1.0, PKCE (RFC 7636) is required for PAR requests and subsequent token requests. Only S256 for code_challenge_method is supported.

Note: Section 7.1 of PKCE specifies the code_verifier should be a minimum of 256 bits, or 32 ASCII characters encoded using URL-safe base64 (total 43 characters).

PKCE code_challenge and code_challenge_method are required in the PAR request object, while the token request includes code_verifier to facilitate verification before issuing tokens.

Authentication

The PAR endpoint requires private_key_jwt for client authentication. The endpoint must use MTLS for secure transport.

PAR Request using JAR

The authentication request object is required to be specified in the request parameter, and request_uri is not supported in PAR request. Only signed JWT tokens (JWS) are supported.

The following is a non-normative PAR request:

Decoded PAR request object JWT body:

PAR Response

The following shows a non-normative example success response. PAR requires HTTP 201 Created for success. Both request_uri and expires_in are required.

The expires_in value is the time-to-live in seconds for the request_uri expected to be short, normally between 5 and 600 seconds and it is the API provider responsibility to set and publish values for this.

The request_uri format is at the discretion of the API provider, but must contain at least some part that is randomly generated in a cryptographically strong manner, consistent with section 10.10 of OAuth 2.0. The authorization server may choose to use the PAR-specified format of urn:ietf:params:oauth:request_uri:<reference-value>. where <reference-value> is the randomly generated part.

Error Response

PAR error responses use the same format as OAuth 2.0 and related extensions.

The following is an non-normative example of and error response:

PAR also defines the following additional error responses in section 2.3 of PAR:

Authorize request with PAR

The following shows a non-normative example of an authorization request, using a request_uri previously issued through a PAR request:

Note that PAR section 4 requires authorization servers should treat request_uri as a single-use value, but may allow for duplicates to allow for user-agent reloading of the URI. An expired request_uri must be rejected as invalid.

OIDC metadata

API provider authorization servers must publish the appropriate metadata for PAR, as required by RFC9126 section 9.1.

JWT-Secured Authorization Response Mode (JARM)

FAPI 1.0

FAPI 1.0 Final specifies in section 5.2.2 the use of JARM ("response_mode":"jwt") in conjunction with "response_type": "code". The use of JARM removes the need for ID token as detached signature in the authorization response.

Signing and encryption

JARM supports both signing and encryption, however this specification requires that only signing is used (similar to ID Token as detached signature). The approved JARM signing algorithms are as per FAPI 1.0.

Example JARM response

The following is a non-normative JARM HTTP success response JWT using the previous PAR request object and subsequent authorization request:

Response Mode "jwt"

FAPI 1.0 requires "response_mode": "jwt" is used with "response_type": "code". JARM specifies response mode "jwt" in this case to be shorthand for "query.jwt", so the response to the authorisation request is in the redirect URI query parameter.

The following shows a non-normative example of the HTTP redirect using the JARM JWT above (line breaks for display only):

The JARM JWT from the response parameter:

Decoded JARM response JWT body:

JARM response claims

The JARM response is to be processed according to JARM section 4.4.

For the NZ Security Profile, the following enhanced definitions of the JARM response claims from [section 4.1.1 of JARM}(https://openid.net/specs/openid-financial-api-jarm.html#response-type-code ) are used:

Error response

JARM error response is a JWT containing the error response claims defined in Oauth 2.0 RFC6749 section 4.1.2.1:

For the NZ Security Profile, the following enhanced definitions of the JARM response claims from section 4.1.1 of JARM are used:

Token request

The following non-normative example shows the token request:

Note that the code_verifier is included so the authorization server can verify the code_challenge PKCE claim supplied in the PAR request.

Decoded client assertion JWT body:

Token response

The client must validate the ID token according to OIDC Core 3.1.3.7

Decoded ID token JWT body:

OIDC metadata

API provider authorization servers must publish the appropriate metadata for supported JARM signing algorithms, as required by JARM Authorisation Server Metadata.

Decoupled Request

This section describes parameters that should be used with a decoupled flow so that a ConsentId can be passed from the Third Party to an API Provider for minimum conformance for the NZ Client Initiated Backchannel Authentication Profile (extending FAPI-CB).

Prior to this step, 

1. The Third Party would have already registered a consent with an API Provider. This is achieved by creating a resource with an account information or payment consent APIs.

2. The API Provider would have responded with a ConsentId (this is the unique identifier for the consent resource).

Authorization Request

This section describes the bare minimum set of Authorization Request parameters that an API Provider must support. The definitive reference is specified in CIBA Section 7.1 (Authentication Request).

As per FAPI-CB 5.2.2.6 the Authorization Requests shall be signed as per CIBA Section 7.1.1

This is a non-normative example of the Authorization Request:

This is the example Request Object - without Base64 encoding:

Claims

Login Hint Token

This is a non-normative example of a Login Hint Token - which is used to identify the Customer.

Claims

The following claims are supported in the login_hint_token. The RFC7519 registered claims may also be included, and are to be treated in according with that specification.

ID Token Hint

This ID Token must be from a previously successful authentication event for the Customer. As this is a previously used ID Token, it is valid for a Third Party to use an expired ID Token.

This is the example Request Object - without Base64 encoding - using the ID Token Hint:

This is the (non-normative) ID Token Hint, after base64 decoding:

Authorization Request Response

The following is a non-normative example of an authentication response:

Claims

Token Request

The following is a non-normative example of a token request using the auth_req_id in the authorisation request response.

Token Request Response

The following is a non-normative example of a successful token response.

Ping Callback

The following is a non-normative example of a Ping callback request. The API Provider calls POST at the Third Party's registered callback endpoint with the client_notification_token in the original Authorisation Request, and the auth_req_id in the body of the request.

ID Token

This is a non-normative example of an ID Token returned - with the sub being populated with a PPID uniquely identifying the Customer to the Third Party.

Claims

Where appropriate please follow the JWT Best Current Practices Guides [BCP-225] https://www.rfc-editor.org/rfc/rfc8725  

Implementation Guide

This provides an implementation perspective of the NZ Security Profile aligned to the accepted NZ Banking Data and other specified APIs for:

• The Hybrid Flow (illustrated with the Payment Initiation APIs)

• The Authorization Code Flow

• The Decoupled Flow (illustrated with the Account Information APIs)

Both the Payment Initiation APIs and the Account Information APIs rely on the same underlying consent flow - so either authorisation flow may be used for both Payment Initiation and Account Information.

JSON schemas for messages associated with the security profile can be found here:

https://github.com/PaymentsNZ/API-Security-Profile

Hybrid Flow

The implementation is based on the following known configurations:

Client Types

• As per the OAuth 2.0 specification, the Confidential Client Type is illustrated

Grant Types

Client Credentials Grant Type

This is with scope payments

• The Client Credentials Grant Type is used when the Third Party requires an Access Token (on behalf of itself) in order to access a consent resource

• Only valid API scopes will be accepted when generating an Access Token (i.e., payments)

• Access tokens generated by a Client Credentials grant may not return any refresh tokens (as per the OAuth 2.0 specification)

Hybrid Flow

This is with response_type "code id_token"

• The Payment Initiation APIs illustrate the use of request_type=code id_token for the OIDC Hybrid Flow implementation

• The API Provider may optionally choose to return Refresh Tokens for the Hybrid Flow when issuing an Access Token

Access Tokens

• For the Payments and Accounts APIs, the Access Token must be obtained within a Secure, Server Side Context between the Third Party and the API Provider

• Access Tokens must be validated by the Third Party as outlined within OIDC

Refresh Tokens

• API Providers may optionally return a Refresh Token when an Authorization Request is successfully processed at the Token endpoint. The Hybrid flow supports the provisioning of Refresh Tokens.

• Refresh Tokens must be validated as outlined in OIDC

ID Tokens

• ID Tokens must be validated by the Third Party as outlined within OIDC

• Third Parties must use the ConsentId claim to populate and retrieve the ConsentId for any required validation

• The full set of claims that can be represented within an ID Token are documented in the Request Object and ID Token sections of the Security Profile

Authorization Codes

• Authorization Codes must be validated by the Third Party as outlined within OIDC

Unspecified Behaviour

The implementation guide does not illustrate the following configurations in this section.

Client Types

• Public clients - as only confidential clients are allowed in the NZ Security Profile

Grant Types

• OIDC Hybrid Flow (response_type=code id_token token)

  • Forces an Access Token to be returned from the API Provider Authorization endpoint (instead of a token endpoint). This is not illustrated in the Payments and Accounts API Specifications

• Client Credentials Grant Type (scope=openid email profile)

  • Requesting OIDC specific scopes or any unspecified scopes when using the Client Credentials grant

Validity Lengths

These are to be managed in the competitive space - so different validity lengths are not illustrated. Each API Provider's Authorization / Resource Server will be configured independently to comply with internal API Provider Security Policies and Guidelines. The Accounts and Payments API Specifications do not mandate validity lengths. 

Authorization Code

•  OAuth 2.0 Specification suggests an Authorization Code should be short lived to a maximum of 10 minutes. Any codes exceeding this limit to be rejected

ID Token

• ID Token claims (exp and iat) determine its validity

• Returned with the Authorization Code when the Hybrid flow (code id_token) is initiated

Access Token

• The expires_in attribute returned by the Authorization Server when an Access Token is generated determines its validity

• Access Tokens are generally short lived, and where they expire, are then exchanged for another using a longer lived Refresh Token

• Refer to Section 16.18 of OIDC - Lifetimes of Access Tokens and Refresh Tokens.

Refresh Token

• Refresh Tokens are generally longer lived in comparison to Access Tokens

• Refer to Section 16.18 of OIDC - Lifetimes of Access Tokens and Refresh Tokens

Success Flows

The sequence diagram below highlights the OAuth 2.0 Client Credentials Grant and OIDC Hybrid flow that are used by the Payments API. 

Open

Payment Initiation with Client Credentials Grant Type and OIDC Hybrid Flows

Client Credentials Grant Type (OAuth 2.0)

This grant type is used by the Third Party in Step 2 to setup a single payment with the API Provider.

1. The Third Party initiates an Authorization request using valid Client Credentials Grant type and scope(s)

2. The API Provider Authorization Server validates the Client Authentication request from the Third Party and generates an Access Token response where the request is valid

3. The Third Party uses the Access Token to create a new Payment resource against the API Provider Resource Server

4. The API Provider Resource server responds with the ConsentId for the resource it has created

5. The Client Credentials Grant may optionally be used by the Third Party in Step 5 to retrieve the status of a consent resource

OIDC Hybrid Flow

• The Hybrid flow is an optional redirect flow for the NZ Security Profile. The Hybrid flow prevents IDP mixup attacks as documented by Nat Sakimura - Cut and Paste OAuth 2.0 Attack

• This is initiated at the end of Step 2 by the Third Party after the ConsentId is generated by the API Provider and returned to the Third Party

• This is used in a redirect across the Customer and API Provider in Step 3 in order for the Customer to authorize consent with the API Provider

• This is used across the Third Party and API Provider in Step 4 by exchanging the Authorization Code for an Access Token in order to create the domestic-payment resource

Non-Normative HTTP Request and Response Examples

Step 1 - Agree Payment Consent

There are no Requests and Responses against the Payments API in this Step for the Customer, Third Party and API Provider.

Step 2 - Setup Payment-Order Consent

1. Third Party obtains an Access Token using a Client Credentials Grant Type. The scope

payments must be used. When an Access Token expires, the Third Party will need to re-request for another Access Token using the same request below. 

1. Third Party uses the Access Token (with 

payments scope) from the API Provider to invoke the payment-order consent API. 

Step 3 - Authorize Consent

1. Third Party receives a ConsentId from the API Provider. The Third Party then creates an Authorization request (using a signed JWT Request containing the ConsentId as a claim) for the Customer to consent to the Payment directly with their API Provider. The request is an OIDC Hybrid flow (requesting for code and id_token)

1. The Customer is then redirected to the Third Party. The Third Party will now possess the Authorization Code and ID Token from the API Provider. Note at this point, there is no Access Token. The Third Party will now introspect the ID Token and use it as a detached signature to check:

• The hash of the Authorization Code to prove it hasn't been tampered with during redirect (comparing the hash value against the c_hash attribute in ID Token)

• The hash of the State to prove it hasn't been tampered with during redirect (comparing the state hash value against the s_hash attribute in the ID Token)

Example: ID Token

Sourced from the NZ Security Profile Request Object section

1. Once the state and code validations have been confirmed as successful by use of the ID Token, the Third Party will proceed to obtain an Access Token from the API Provider using the Authorization Code they now possess. The Third Party will present its Authorization Code together with the private_key_jwt. The Access Token is required by the Third Party in order to submit the Payment on behalf of the Customer. The 

payments scope should already be associated with the Authorization Code generated in the previous step.