In meinem letzten EBICS-Blog habe ich über die Schmerzen geschrieben, die EBICS-Neukunden bei der Initialisierung haben (und wie man sie lindern könnte). Es kommt erschwerend hinzu, dass Neukunden diesen Schmerz nicht nur ein Mal haben – das gleiche Prozedere wird für jeden einzelnen Teilnehmer von EBICS wiederholt.
Muss das sein? Wie wäre es, wenn man dem ersten angemeldeten EBICS-Nutzer, sozusagen dem User 0, das Recht einräumt, weitere Teilnehmer anzulegen – und sie dabei auch gleich zu authentifizieren? Wie würde so etwas aussehen?
Stellen wir uns also eine neue administrative EBICS-Auftragsart vor, der wir z. B. mal den Namen HUC (EBICS User Create) geben. HUC wäre ein Upload, die enthaltene EBICS-Nachricht würde die notwendigen Stammdaten des neuen EBICS-Nutzers sowie seine drei Zertifikate enthalten. Unterschrieben wird die Nachricht vom User 0. Mit den Daten und der Unterschrift kann der EBICS-Server den Teilnehmer unmittelbar einrichten, es entfallen INI- und HIA-Auftrag, Briefe und Wartezeiten. Wir bekommen ohne jeden Initialisierungsschmerz einen weiteren gebrauchsfertigen Teilnehmer. Indizien für ein kundenseitiges Bedürfnis nach einem solchen „EBICS-Self-Service“ sind vorhanden: Immerhin gibt es mit EBAM Bemühungen, einen ganz ähnlichen Dienst für Konten voranzubringen.
Wenn es so einfach wäre, hätte man das doch vermutlich schon längst gemacht. Zwei Fragen springen einem förmlich ins Gesicht:
1. Wie kontrolliere ich einen so mächtigen EBICS-Teilnehmer wie den User 0?
2. Was sind eigentlich die notwendigen Stammdaten?
Die erste Frage ist überraschend einfach zu beantworten: Denn wenn EBICS in einer Sache wirklich gut ist, dann im Prüfen von Berechtigungen. Um einen übermächtigen User 0 zu verhindern, richtet man ganz am Anfang dann doch noch einen User 1 ein, und legt fest, dass ein HUC-Auftrag mehrere Unterschriften benötigt. Und schon hat man ein Vier-Augen-Prinzip und kann durch die bekannten Mechanismen der E-, A- und B-Unterschriften sehr feingranular konfigurieren, wer mit wem zusammen weitere Mitarbeiter einrichten darf.
Die weitaus schwierige Frage ist: Was sind die notwendigen Stammdaten? Die meisten werden sich darauf einigen können, dass ein Name wohl notwendig ist, aber dann wird es schon schwierig. Will ich Adresse, Telefonnummer und die E-Mail des Benutzers wissen? Brauche ich die womöglich sogar zwingend? Oder möchte ich mich aufgrund der DSGVO lieber gar nicht mit unnötigen persönlichen Daten belasten? Bislang kann das jede Bank für sich entscheiden, aber HUC würde da einen Standard für alle setzen. Und niemandem ist damit geholfen, wenn ein Standard im Wesentlichen aus einer Unmenge an optionalen Feldern besteht. Hier wären die Banken gefordert, sich auf einen sinnvollen Satz an Daten verbindlich zu einigen.
Wie schwer das sein kann, kann man in EBICS selber sehen – an den Auftragsarten HKD und HDT. Dafür gedacht, dass ein Kundensystem sich bei der Bank Informationen zum Kunden, seinen Teilnehmern und deren Berechtigungen abholen kann, führen diese beiden Auftragsarten ein Schattendasein, weil es nicht möglich war, die historisch gewachsen Berechtigungsmodelle der verschiedenen Banken unter einen Hut zu bringen. Viele Banken verstehen sogar ganz im Gegenteil ihre besonderen Freiheitsgrade bei der Rechtevergabe als ein Alleinstellungsmerkmal. Das verträgt sich nicht mit einer Standardisierung.
Darum scheint es auch so, als wären die uneinheitlichen Rechtemodelle der vorzeitige und sichere Tod eines EBCIS-Self-Service. Es scheint aber eben nur so. In Wirklichkeit braucht die Bank die vielen Möglichkeiten der Rechtevergabe, um allen ihren Kunden gerecht zu werden, der einzelne Kunde braucht sie eher nicht, oder zumindest nicht alle gleichzeitig: Wie viele Rollen gibt es schon bei einem typischen Firmenkunden? Da gibt es diejenigen, die Aufträge einreichen, aber nicht autorisieren dürfen, diejenigen mit beschränkter oder umfangreicher Zeichnungsvollmacht für dieses oder jenes Konto und dann noch die, die neue Teilnehmer einrichten dürfen. In Summe etwa eine Handvoll Rollen, die man beim Aufsetzen der EBICS-Vereinbarung gleich mit anlegt und bei denen man sich mit dem kompletten Arsenal der Berechtigungskonfiguration der Bank austoben kann. Die Rolle bekommt dann einen Namen, mit der der Kunde etwas anfangen kann (z. B. Prokurist) und die er dann in seinem HUC-Request für den neuen Prokuristen einfach angeben kann.
So ein Rollenmodell hat noch mehr Vorteile. Man kann die Rolle den neuen Gegebenheiten der Firma (ein Konto ist dazugekommen) anpassen, ohne die Berechtigungen aller Teilnehmer anschauen zu müssen. Man kann die Rollen auch neu verteilen. Und man bekommt leichter einen Überblick, wer eigentlich welche Rolle und damit welche Berechtigung hat.
Während die Definition der Rollen zwangsläufig Handarbeit bleiben wird, kann die Zuordnung der Rollen im EBICS-Self-Service erfolgen. Für den fehlt neben der Neuanlange dann noch die Möglichkeit zum Lesen, Ändern und Löschen des Teilnehmers, also das R, das U und das D aus CRUD. Die zugehörigen Auftragsarten könnte man dann ja HUR, HUU und HUD nennen. Dann hätte man einen schönen ersten Wurf für den EBICS-Self-Service.
Und der Initialisierungsschmerz löst sich fast vollständig in Luft auf.
Autor: Curd Reinert
