Background

In order to achieve full FAPI compliance, ASPSPs are required to run the PS256 algorithm for encryption of signatures. To date, the OB test and Production ecosystems run the RS256 algorithm. Waivers (Waiver 3 and Waiver 4) have been issued by the OBIE extending the deadline for conversion to PS256 to 13th March 2019, and the entire ecosystem needs to have migrated across to PS256 by this date. The extent to which there can be parallel running depends on individual participant plans.

Therefore there is the potential for breaking changes - messages issued to ASPSPs/OBIE using RS256 shall not be accepted once the recipients have converted to PS256.

The headline dates for PS256 are indicated in the 'Key Milestone Dates for Release 3' plan on a page - /wiki/spaces/QT/pages/978157770/wiki/spaces/QT/pages/978157770. They include:

Date	Key milestone date
13th February 2019	Sandbox migration from RS256 to PS256
13th March 2019	Production directory on PS256
13th March 2019	All ASPSPs support PS256

Latest communications and News

New Functionality in OB DIrectory

The PS256 issues that have previously caused difficulties have now been resolved. In addition new functionality is now available on the OB Directory - the following summary (from the OB Directory Usage Page) may be helpful:

Using the Open Banking Directory APIs

Functionality that was previously only available via the DFI can now be accessed via Open Banking APIs:

manage organisation contacts (CRU)
manage software statements (CRU)
generate software statement assertions
upload/manage signing keys
upload/manage encryption keys
generate/manage OB non-ETSI certs
generate OBWAC/OBSeal certs
upload eIDAS QWAC/QSeal certs

The above require the generation of an organisational OAuth client. Until the Dynamic Client Registration (DCR) service is made available, please submit a Service Desk ticket requesting an organisational OAuth client.

To understand how to use the API, please read the Directory API Swagger specification. This is an attachment to the Directory 2.0 Technical Overview DRAFT 1.

OB Comms Email Regarding Directory Upgrade

(Please note that this email, sent on 8th March is primarily around eIDAS - but it is also regarded as the key date for PS256. This information is provided just for information)

'Dear Participant,

OBIE would like to update the previous communication regarding the planned release next week to support eIDAS.

NB: The JWKS Keystore will not have an outage.

This is a major release, and will bring Production into line with the Directory Sandbox (which has had ETSI certificate capability since January 2019).

Some of the work OBIE intends to carry out next week will require a service outage to the Directory, and this will also include work to the JWKS (JSON Web Key Set) store to migrate certificates to the new format during part of the release.

OBIE would therefore like to notify the following maintenance windows:

Monday 11th March: 1800 to 2200 - Preparatory work with no expected service impact.

Tuesday 12th March: 1800 to 0600 (Wednesday) - Directory outage.

Wednesday 13th March: 1800 to 0600 (Thursday) - Directory outage.

The JWKS and OCSP responder will not be impacted by this release.

As ever, if you have any questions relating to this, please do not hesitate to contact the Service Desk at servicedesk@openbanking.org.uk or on 0203 217 8188

Kind regards,

The Open Banking Team'

In a separate note, Head of Directory Mike Mayfield also pointed out that:

'The keystore (and indeed the SCIM end points) will be available at all times but there is a period when it will be in read only (i.e. you won't be able to mint certs)'

Daily RS256 Availability Notification

The following email has been sent to all participants (15th February)

'We would like to remind you that as previously advised, the Directory Sandbox will revert from the recently implemented PS256 signing algorithm to the older RS256 algorithm from 0900 to 1000 (UK time) every weekday (Mon-Fri), starting today, until further notice.

During this daily 1 hour period, a message will be displayed on the Directory login page,

RS256 and PS256 Support in Production Directory

The following message was provided by Ralph Bragg, OB Architect.

‘We support Participants retrieving Access Tokens from OB Using the PS and RS algorithms.

We support Participants asking for OB to issue them ID_Tokens using PS and RS algorithms however we sign with RS by default. Participants will need to contact service desk and raise a case for us to migrate their clients to PS ID Token Issuance.’

The following (anonymised) information was extracted from a Jira ticket

'Query - ASPSP is requesting that the OBIE Directory continues to issue RS256 tokens (for SSO) on a 24/7 basis until the 3rd May 2019.

We would also like to confirm that the OBIE Directory will continue to accept RS256 signed jwt assertions.

Response - OB Directory will only change SSO tokens to PS256 on request. So ASPSP can rest assured that they will continue to receive RS256 signed tokens for SSO.

OBIE is now accepting both RS256 and PS256 signed jwt assertions.'

ForgeRock and Ozone PS256 Support

Ozone supports PS256
ForgeRock now supports PS256, as of 11th March. A release note is here.

General Guidance

Impact Summary

Eco-system participants switching over to PS256 simultaneously is unlikely, as is the method of switch-over. Some shall conduct a hard transfer, whilst others shall provide dual running of both protocols for a period.

An existing SSA can continue to be used provided the 'alg' field in the header matches whatever target the ASPSP supports. ASPSPs should advertise the algorithm they support both via their Dev portal and dedicated OB ASPSP pages, including the ASPSP Calendar Detail pages
Transactions not requiring the inclusion of an SSA (e.g. account information) are not impacted.
Post switch-over, any transactions requiring a new SSA must be done with PS256, if it is supported by the target ASPSP (It is likely some ASPSPs may not meet the target date, especially non-CMA9). This covers payments, onboarding with new ASPSPs, new certificates, or changes in SSA identity values (e.g. name).

Therefore, given the heterogeneous nature of the OB ecosystem, the detail underlying the overall transition may differ across participants.

Guidance for ASPSPs

Work with your OBIE Testing Representative to maintain the information published about your eIDAS approach and delivery timeframes remains current. The anticipation is that ASPSPs shall maintain their own pages, with summary information being collated on the top level page.
All ASPSP pages for entry of information can be found here. Each ASPSP has their own details page accessible from this main page.

Lessons Learned from Jira Tickets

Ticket Number	Question Summary	Resolution Notes
OBSD-6925	When we call SCIM APIs, we need to send a client_assertion JWT. Currently,we send this JWT using RS256 alg. Are there any plans to change that alg to PS256?	As of now the client assertion jwt for scim apis should be RS256. There are plans for an upgrade but that is still work in progress and there are no scheduled dates at this point.
OBSD-6971	Does ozone bank support PS256 and RS256	Yes - Ozone supports both. Confirmed with Freddi
OBSD-6992	The jwt in id_token returned by OB IDP endpoint has RS256. Will this move to PS256	The window that we have is only for SSA signing . The ID Token is used only for SSO. There are plans to upgrade this to PS256 at some point, but there is no agreed delivery date for this.
OBSD-6887	Question regarding PS256 transition period.	the Sandbox will ONLY support RS256 between 9am and 10 am and PS256 the remaining time. As of the 13th March only PS256 will be supported in production and the sandbox
OBSE-6717	Question regarding CSR generation with PS256	CSR needs to be created the standard way as documented in directory usage guide. The PS256 part is for SSA generation only. please check further comments on the ticket
OBSD-7224 and OBSD-7283	ASPSP and Model Banks - it appears are rejecting our PS256 implementation, and suggesting that TPPs must perform a dynamic client reregistration in order to select PS256 for request_objects.	(Email from Freddi Gyara, OB Architect) These are all legitimate concerns and its best raised at TDA to discuss what ASPSPs have put in place for the transition. DCR 3.1 introduced a PUT endpoint that is optional - which will now allow for a client to be modified. However, the ASPSPs were of the opinion that they do not need to implement the PUT endpoint and could provide a service request capability to achieve the same end-result. I believe that the point has been made earlier that such modifications should not lead to revocation of consent and should not impact in-production TPPs. However, I would not be able to confirm when that would be applicable from.

Objects Affected

Thank you to ecosystem participants for providing the below information. This may assist with definition of test cases.

Ref	Object	Signing Party	Verifying Party
1	Software Statement Assertions	OB Directory	ASPSPs
2	Onboarding Request Object	TPPs	ASPSPs
3	Authorisation Request Object	TPPs	ASPSPs
4	ID Tokens	ASPSPs	TPPs
5	Payload Request Signing (e.g. payments)	TPPs	ASPSPs
6	Payload Response Signing	ASPSPs	TPPs
7	JWT Assertions used as Token Auth Method	TPPs	ASPSPs
8	JWT Assertions used as Token Auth Method	ASPSPs & TPPs	OB Directory
9	ID Token (for when OB Directory acts as an SSO provider)	OB Directory	ASPSPs

Browser not supported