Créativité à l’enrôlement aux API PSD2

La PSD2 prévoit que la relation entre les ASPSP et les TPP ne soit pas contractuelle, néanmoins pour des raisons pratiques nous avons accepté à ce qu’un enrôlement technique soit opéré sur les plateformes d’API des différentes banques. Sous condition qu’il soit lui-même fluide. Budget Insight est d’ailleurs à l’origine de l’introduction du RFC 7591 « OAuth2: Dynamic Client Registration » au standard STET.

Car il ne faut pas perdre de vue que nous comme nos confrères établissons la connectivité vers des centaines d’établissements, et Budget Insight a la particularité de le faire en tant que prestataire technique pour de nombreux autres TPP et agents. Il est donc nécessaire d’enrôler chacun d’eux sur l’ensemble des plateformes bancaires.

Si plusieurs établissements ont implémenté ce RFC, nous avons pu constater que les banques ne manquent pas de créativité pour proposer une DX (Developer Experience) défiant la raison. Florilège.

Création d’un Client Application par caisse

La plupart des API bancaire implémentent OAuth 2 et donc le concept de « Client Application » est présent au moment de l’enrôlement. Certaines banques ont décidé que les TPP devaient créer un « Client Application » par caisse. Tout cela sans pouvoir se passer de l’interface web.

Enrôlement par mail+SMS

Beaucoup de banques n’ont pas jugé utile d’investir sur une plateforme moderne d’API Gateway, mais requiert tout de même un enrôlement des TPP qui doit se faire à la main.

La procédure est simple, il suffit d’envoyer un mail, et après quelques échanges informels, on obtient un client_id et un client_secret. Par « mesure de sécurité », ce dernier est parfois envoyé par… SMS.

Enrôlement papier

C’est le cas d’au moins une banque, qui requiert la signature (papier) d’un mandataire social du TPP. Probablement plus sécurisé que de présenter un certificat eIDAS.

Les certificats eIDAS

Au sujet desdits certificats eIDAS, techniquement ils sont autoportants, comme n’importe quel certificat : dès lors qu’en tant qu’ASPSP on a intégré les certificats des Autorités de Certifications (dont la liste est publiée sur le site de la Commission Européenne) et qu’on s’interface avec les registres des NCA (celui de PRETA ou de l’EBA), la validation de l’identité et des autorisations peut être faite à la volée lors des requêtes à l’API.

Malgré tout, bon nombre de banques demandent d’envoyer le certificat utilisé, voire même de répondre à un challenge utilisant le certificat. 

Une banque a même poussé le vice jusqu’à requérir l’utilisation du certificat pour l’accès à la documentation…

Fenêtre de tir pour la production

Une banque française n’active le bouton pour l’enregistrement de l’accès en production que sur une fenêtre de tir d’une demi-heure, à convenir préalablement par téléphone. Attention toutefois à ne pas se louper, lorsqu’on a tenté un vendredi matin, on s’est trompé sur la valeur d’un champ : tant pis, prochaine fenêtre de tir au lundi matin.

 

En conclusion, si nous avons prévu de scraper les portails d’API ne proposant pas d’implémentation du RFC 7591 sur l’enregistrement dynamique, cela ne sera malgré tout pas possible pour bon nombre de banques qui incluent des actions manuelles inutiles.