Est-ce nécessaire ? Que se passerait-il si le premier utilisateur EBICS connecté, pour ainsi dire l'utilisateur 0, avait le droit de créer d'autres participants – et de les authentifier immédiatement ? Comment cela fonctionnerait-il ?
Imaginons un nouveau type d'ordre EBICS administratif que l'on appellerait HUC (EBICS User Create) par exemple. HUC serait un type d’ordre upload, le message EBICS contenu contiendrait les données de base du nouvel utilisateur EBICS ainsi que ses trois certificats. Le message est signé par l'utilisateur 0. Grâce à ces données et à la signature, le serveur EBICS peut immédiatement configurer le participant, les ordres INI et HIA, les lettres et les délais d'attente sont supprimés. Sans aucun problème d'initialisation, un autre utilisateur est configuré et prêt à travailler. Il existe des indicateurs pour la nécessité d'un tel « libre-service EBICS » côté client : après tout, avec EBAM tout est mis en œuvre pour permettre un service très similaire pour les comptes.
Si cela était aussi simple, on l'aurait probablement déjà fait. Deux questions sont inévitables :
1. Comment contrôler un participant EBICS aussi puissant que l'utilisateur 0 ?
2. Quelles sont les données de base nécessaires ?
La première question est facile à répondre : si EBICS est vraiment expert dans un domaine, c'est le contrôle des autorisations. Afin d'éviter qu'un utilisateur 0 ne devienne trop puissant, on crée un utilisateur 1 dès le début et on spécifie qu'un ordre HUC requière plusieurs signatures. De cette façon on obtient un principe de double contrôle et on peut configurer de manière très détaillée qui est autorisé à créer d'autres employés, en utilisant les mécanismes connus des signatures E, A ou B.
La question beaucoup plus délicate est celle des données de base nécessaires. La plupart des personnes impliquées reconnaissent qu'un nom est probablement nécessaire, mais pour le reste, c’est plus difficile. Voulons-nous connaître l'adresse, le numéro de téléphone et l'adresse e-mail de l'utilisateur ? Ces informations peuvent-elles même être obligatoires ? Ou préférons-nous ne pas nous encombrer de données personnelles inutiles à cause du Règlement général sur la protection des données ? Jusqu'à présent, chaque institution financière pouvait prendre la décision elle-même, mais HUC définirait un standard pour toutes les banques. Après tout, il n'est pas utile qu'un standard se compose essentiellement d'un grand nombre de champs facultatifs. Dans ce cas, les institutions financières auront à se mettre d'accord sur un ensemble cohérent de données obligatoires.
La difficulté de ce processus est visible dans EBICS même dans les types d'ordre HKD et HDT. Concus pour permettre à un système client de collecter des informations sur les clients, ses utilisateurs EBICS et leurs autorisations, ces deux types d'ordre restent vagues, car il n'a pas été possible de concilier les modèles d'autorisation développés originaux des différentes banques. Au contraire, de nombreuses institutions financières considèrent leur degré de liberté dans la distribution des droits comme un argument clé de vente. Cela n'est pas compatible avec la normalisation.
C'est pourquoi il semble que les modèles de droits incohérents soient la fin prématurée et certaine d'un libre-service EBICS. Mais il se peut que ce ne soit pas le cas. En réalité la banque nécessite de nombreuses possibilités de distribution de droits pour satisfaire tous ses clients, le client individuel n'en a pas forcément besoin, ou du moins pas tous en même temps. Mais combien de rôles existe-t-il pour une entreprise typique ? Il y a ceux qui peuvent soumettre des ordres mais qui ne peuvent pas les autoriser, ceux qui ont un pouvoir de signature limité ou étendu pour tel ou tel compte, et puis il y a ceux qui sont autorisés à créer des nouveaux utilisateurs. Au total, il une poignée de rôles sont créés lors de la mise en place de l'accord EBICS, parmi lesquels un seul a accès à l’intégralité de la configuration d'autorisations de l'institution financière. Le rôle est ensuite doté d'un nom que le client peut utiliser (par exemple signataire) et qu'il peut ensuite indiquer dans sa requête HUC pour le nouveau représentant.
Un tel modèle de rôle présente encore plus d'avantages. Le rôle peut être adapté aux nouvelles conditions de l'entreprise (un compte a été ajouté) sans devoir consulter les autorisations de tous les participants. Les rôles peuvent également être redistribués. De plus, il est plus facile d'avoir une vue d'ensemble sur les utilisateurs et leurs rôles et donc l'autorisation associée.
Tandis que la définition des rôles restera inévitablement manuelle, l'affectation des rôles peut être faite dans le libre-service d'EBICS. Pour compléter le libre-service, il manque, outre la création, également la possibilité de lire, modifier et supprimer des utilisateurs, c'est-à-dire le R, U et D de CRUD. Les types d'ordre associés peuvent alors être appelés HUR, HUU et HUD. On aurait alors un premier lancement prometteur pour le libre-service EBICS.
Et les problèmes d'initialisation disparaitraient presque complètement.
Auteur: Curd Reinert
