This specification defines two mechanisms by which a Primary Technical Contact (PTC) for a Trusted Third Party (TPP) may submit a Software Statement Assertion (SSA) to an Account Servicing Payment Services Provider (ASPSP) for the purposes of receiving a client credential enabling access to UK OpenBanking APIs on behalf of ASPSP Customers. The automated mechanism profiles [RFC7591]. The manual mechanism uses web single sign-on for secure access by the PTC to a portal operated by the ASPSP that is based on the original PTC credentials used to generate the SSA.

This specification uses the terms "access token", "authorization code", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "client secret", "grant type", "protected resource", "redirection URI", "refresh token", "resource owner", "resource server", "response type", and "token endpoint" defined by OAuth 2.0 [RFC6749] and uses the term "Claim" defined by JSON Web Token (JWT) [RFC7519].

Account Servicing Payment Services Provider (ASPSP) - An organisation managing customer accounts (and operating banking APIs).

Primary Technical Contact - The person at the TPP who creates an SSA and invokes a registration mechanism. This is an example of an [RFC7591] Client Developer.

OB Organisation ID - The unique identifier for each OpenBanking participant. Both TPPs and ASPSPs have OB Organisation IDs.

OpenBanking Directory - An implementation of a [PSD2] competent authority; acts as an Identity Provider, certificate authority, and registry governing the participants in the UK OpenBanking API scheme.

ASPSP Registration Endpoint - OAuth 2.0 & [RFC7591] compliant endpoint, exact value is discoverable from the [OIDCD] openid-configuration file of the ASPSP.

Software Statement Assertion (SSA) - An implementation of an [RFC7591] software statement, signed by the OpenBanking Directory.

Trusted Third Party (TPP) - An organization working to initiate payments or consume account information with/from an ASPSP.

TPP Client Software - software implementing an OAuth2 client, interacting with an ASPSP registration endpoint.

The SSA is a JSON Web Token (JWT) containing client metadata about an instance of TPP client software. The JWT is issued and signed by the OpenBanking Directory.

A large number of claims that OpenID Connect OPs could support are detailed https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata and should be followed if not explicitly referenced below.

The payload of an OpenBanking SSA MUST be a compliant software statement according to [RFC7591]. The SSA MUST also be a compliant JWT according to [RFC7519]. The following metadata profiles the metadata in [RFC7591] and [RFC7519]:

The following software metadata is additionally defined for this profile:

The following Organisational metadata is defined for this profile:

The SSA header MUST comply with [RFC7519].

The elements defined in the software statement will consist of the following values.

Note that there are inconsistent applications of booleans or "Active" strings in the current data model.

Note that there are inconsistent applications of status flags case sensitivity.

The attributes required to be displayed by ASPSPs

{ "typ": "JWT", "alg": "ES256", "kid": "ABCD1234" } { "iss": "OpenBanking Ltd", "iat": 1492756331, "jti": "id12345685439487678", "software_environment": "production", "software_mode": "live", "software_id": "65d1f27c-4aea-4549-9c21-60e495a7a86f", "software_client_id": "OpenBanking TPP Client Unique ID", "software_client_name": "Amazon Prime Movies", "software_client_description": "Amazon Prime Movies is a moving streaming service", "software_version": "2.2", "software_client_uri": "https://prime.amazon.com", "software_redirect_uris": [ "https://prime.amazon.com/cb", "https://prime.amazon.co.uk/cb" ], "software_roles": [ "PISP", "AISP" ], "organisation_competent_authority_claims": [ { "authority_id": "FMA", // Austrian Financial Market Authority "registration_id": "111111", "status": "Active", "authorisations": [ { "member_state": "GBR", "roles": [ "PISP", "AISP" ] }, { "member_state": "ROI", "roles": [ "PISP" ] } ] } ], "software_logo_uri": "https://prime.amazon.com/logo.png", "org_status": "Active", "org_id": "Amazon TPPID", "org_name": "OpenBanking TPP Registered Name", "org_contacts": [ { "name": "contact name", "email": "contact@contact.com", "phone": "+447890130558" "type": "business" }, { "name": "contact name", "email": "contact@contact.com", "phone": "+447890130558", "type": "technical" } ], "org_jwks_endpoint": "https://jwks.openbanking.org.uk/org_id/org_id.jkws", "org_jwks_revoked_endpoint": "https://jwks.openbanking.org.uk/org_id/revoked/org_id.jkws", "software_jwks_endpoint": "https://jwks.openbanking.org.uk/org_id/software_id.jkws", "software_jwks_revoked_endpoint": "https://jwks.openbanking.org.uk/org_id/revoked/software_id.jkws", "software_policy_uri": "https://tpp.com/policy.html", "software_tos_uri": "https://tpp.com/tos.html", "software_on_behalf_of_org": "https://api.openbanking.org.uk/scim2/OBTrustedPaymentParty/1234567789", "ob_registry_tos": "https://registry.openbanking.org.uk/tos.html" } { Signature }

A TPP MAY use automated client registration to submit an SSA to an ASPSP in exchange for client credentials for use as a client against an OAuth 2.0 Authorization Server. It is RECOMMENDED for ASPSPs to support the automated client registration mechanism.

ASPSPs MUST NOT accept client registration requests that do not contain a valid SSA. Requests that pass validation criteria SHOULD result in the ASPSP populating client security characteristics from the metadata within the SSA and client registration requests issuing a registration response.

To support onboarding through APIs, the ASPSP must provide:

• A service to validate and process the Request JWT and the SSA JWT contained within supporting both PS256 and ES256 alg types

• A service to create and return client credentials based on the security characteristics obtained from the metadata

• Storing the the Software Statement ID from the SSA against the client and validating the TPP, App, and SSID.org_jwks_endpoint

• Provide a discovery specification endpoint that conforms to the OIDC discovery specification advertising supported mechanisms and algorithims available to TPPs. [https://openid.net/specs/openid-connect-discovery-1_0.html]

The TPP must only present the SSA to an ASPSP over a mutually authenticated TLS channel using a certificate issued by the OB. In this case, the combination of possession of the SSA, the possession of private keys referenced in the SSA and ability to present it over a channel that can be validated as belonging to the same TPP organization, is a strong barrier for attackers. Unlike RFC7591 the client registration request will be of type JWT where the registration request itself is a signed jwt.

If an ASPSP supports automated client registration, the ASPSP MUST operate an [RFC7591] compliant registration endpoint. The client registration endpoint MUST be protected by transport-layer security (TLS 1.2 or better) The transport layer MUST be mutually authenticated using certificates chaining to the OpenBanking certificate authority The ASPSP registration endpoint MUST accept HTTP POST messages with request parameters encoded in the entity body using the "application/jwt" content-type. The ASPSP registration endpoint SHOULD accept registration attempts from any mutually authenticated channel whose certificate chains to the OpenBanking certificate authority and is not revoked.

Prior to issuing a client registration response, the ASPSP MUST perform the following checks The ASPSP SHOULD check whether the TPP that initiated the TLS connection is the same TPP as listed in the SSA. In the case where a gateway or other piece of infrastructure pre-terminates the MATLS channel in front of the registration endpoint, the certificate used to initiate the connection or some part of that certificate (such as DN & Issuer) SHOULD be made available to the ASPSP for validation against the claims in the SSA. The registration request MUST be signed with a key contained in the JWKS referenced in the SSA included with the request. This ensures that a holder-of-key proof-of-possession is performed proving that the TPP app was the originally intended recipient of the SSA when the OB issued it. The SSA MUST be validated according to [RFC7519], including validation of the signature and validity window.

JWT signature must be validated, this involves retrieving the jwks keyset for both the OB and the TPP. The OB keystore location will be published as part of the directory specification, The TPP's will be included in the software statement.

• SSA Lifetime

• The SSA's Lifetime will be short, typically less than 10 minutes. TPPs will be able to retrieve SSAs from OB using client_credentials grant so there should be no need for a SSA to be long lived.

Section for the support sections / profile enhancements on RFC7591 e.g OIDC client reg profile, reg profile enhancments for mtls token end point auth

To register as a client at an ASPSP, the TPP sends an HTTP POST to the ASPSP registration endpoint. The request MUST be presented in the format of a [RFC7519] compliant JWT. The request MUST use the HTTP POST method, using the application/jwt method. * The JWT MUST be signed using algorithms specified in [FAPI-RW] Section 8.6.

The client registration request MUST contain the following claims in the JWT payload unless designated as Optional. The TPP MAY add additional claims to the JWT payload. The ASPSP MAY ignore claims not in the chart below. If a claim name matches a specified claim in any of [RFC7519], [RFC7591], or [FAPI], the usage must also match the specification.

The TPP MUST choose one of the following token endpoint authentication methods:

Private Key JWT Authentication A TPP choosing to use the private_key_jwt method to authenticate to the token endpoint MUST set the value of the token_endpoint_auth_method to private_key_jwt as specified by [OIDC] Section 9, and [RFC7523].

Mutual TLS Client Authentication A TPP choosing to register Mutual TLS as the client authentication method MUST set the following client metadata in the registration request:token_endpoint_auth_method MUST be set to tls_client_auth The client metadata parameter tls_client_auth_dn MUST be included in the registration request * The content of the tls_client_auth_dnclaim MUST contain the DN of the certificate that the TPP will present to the ASPSP token endpoint.

HTTP Basic Client Authentication A TPP choosing to use HTTP Basic Authentication method MUST set the token_endpoint_auth_method claim in the registration request to client_secret_basic as per [rfc6749] section 2.3.1.

HTTP POST Client Authentication A TPP choosing to use HTTP Basic Authentication method MUST set the token_endpoint_auth_method claim in the registration request to client_secret_post as per [rfc6749] section 2.3.1.

The TPP MUST specify one or more of the following values in the grant_types claim. Values MUST be encoded as a JSON array. ASPSPs MAY reject anything other than client_credentialsor authorization_code. authorization_code refresh_token * client_credentials