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.

(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)'

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,

• 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.'

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

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.

1. 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
2. Transactions not requiring the inclusion of an SSA (e.g. account information) are not impacted.
3. 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).

Objects Affected

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