New Document Proposal: FAPI Implementation Guide

[Dave Tonge]

As mentioned previously I think that we should have a new document that provides a set of implementation guidelines for implementers of financial APIs.

This WG has a wealth of knowledge about what to do (and what not to do) when implementation financial APIs. Some of that knowledge doesn't fit in a standard spec but I believe that it should be captured.

I propose that we start a new document to document some of this knowledge, examples could include:

• Payments, why these must be 2-stage and not 1-stage
• Scopes vs lodging intent, the different methods available
• Certificates, issues and best practice

[Dave Tonge]

Adding notes from a previous email relating to EBA requirements around eIDAS:

• QWAC are eIDAS certs that can be used either as client or server certs for TLS
• QSealC are eIDAS certs to be used for message signing
• The EBA doesn't have any requirement for banks to use QWACs as server certs
• The EBA encourages TPPs to use QWACs as client certs for TLS mutual auth
• The EBA also encourages TPPs to use QSealC to sign messages
• The bank is the one who decides which certs the TPP has to use

From a FAPI perspective: - We support the use of QWACs for mutual TLS for both client authentication and proof of possession of access tokens - We support the use of QSealCs for signing JWTs, e.g. Request Object, or private_key_jwt client auth

• by support, I mean that we don't preclude the use of eIDAS certs. The underlying specs for oauth mutual TLS - allow the use of PKI based certs. The underlying specs for request object and private_key_jwt allow the use of keys that are backed by certs rather than just raw keys.

So I think FAPI does support both uses proposed by the EBA. In terms of guidance for implementers I can think of the following: - because an eIDAS cert is "org level" rather than "software level" it is strongly advisable to have a means of the RP communicating to the OP which certs should be associated with it - jwks_uri is a good place for the RP to let the OP know which certs it will use for signing, and allows easy rotation - client registration metadata such as tls_client_auth_subject_dn is a good place for the RP to let the OP know the DN of the certs it will use for client authentication

[Dave Tonge]

This type of document was also discussed on the context of CIBA: https://bitbucket.org/openid/fapi/issues/199/ciba-which-modes-to-support

Specifically with regards to guidance around the best practice UX that should be implemented.

This is the relevant point from Joseph:

I think ping mode should have a big benefit in terms of UX (ie. how fast the authorisation process is performed). As one of the goals of CIBA is to try and ensure the low friction authentication flows (I can't recall the exact phrase currently, hopefully that's close enough) that RTS requires I wonder if we should address that point somehow.

One possible way to address it would be to add a clause something along the lines of:

"shall not reject or return 'slow_down' to clients that are polling at an interval of 100ms or longer (except in exceptional circumstances where unexpected and unprecedented server load is present), this requirement shall not apply if CIBA ping mode is supported"

i.e. I think it's important that the user can essentially instantly proceed as soon as they have completed their part of the CIBA process, and I don't believe the server being allowed to insist on 5 second or longer polling intervals is conducive to that.

[Dave Tonge]

Maybe add these points to the doc that Joseph created. If not, then close

[Nat Sakimura]

Need to add them to the document.