DIN 91379 und Zeichenkodierung

Die Kommunikation im Rahmen des Standards XBezahldienste soll konform zur DIN 91379 (String.Latin+ 1.2) sein. Durch Beschluss 2019/53 in der 30. Sitzung des IT-Planungsrats wurde festgeschrieben: Alle IT-Verfahren, die dem Bund-Länder-übergreifenden Datenaustausch oder dem Datenaustausch mit Bürgern und Wirtschaft dienen, müssen spätestens zum 1. November 2024 konform zur DIN 91379 sein.

Validierungsverantwortung

Ab Version 1.2.0 enthält die OpenAPI-Spezifikation keine regulären Ausdrücke mehr für die DIN-Datentypen. Diese waren bis v1.1.0 Bestandteil der Spezifikation, wurden jedoch bewusst entfernt: Eine OpenAPI-Spezifikation ist kein geeigneter Validierungs-Layer, da sie weder eine konforme Client-Implementierung noch eine korrekte Verarbeitung auf Serverseite garantieren kann.

Stattdessen gilt ab v1.2.0 folgendes Prinzip:

• Bezahldienste sind eigenverantwortlich für die Validierung eingehender Daten. Sie dürfen nicht darauf vertrauen, dass ein Client DIN-konforme Daten liefert.
• DIN-widrige Eingaben sollten nicht pauschal abgelehnt, sondern in konforme Zeichen überführt werden. Die DIN 91379 stellt hierfür in Kapitel 5 eine normative Abbildung auf Grundbuchstaben sowie in Anhang D Mappings auf Legacy-Zeichensätze bereit. Diese Transformationsaufgabe liegt bewusst beim Bezahldienst: Nutzerzentrierte Systeme wie Online-Dienste sollen moderne, vollständige Zeichensätze verwenden können, ohne selbst für die Kompatibilität mit nachgelagerten Behördensystemen verantwortlich zu sein. Der Bezahldienst übernimmt diese Rolle als Quality-Gate.
• Der Standard schreibt keine technische Umsetzung der Validierung vor. Wie ein Bezahldienst die DIN-Konformität intern sicherstellt, bleibt der Implementierung überlassen.

DIN 91379 (String.Latin+ 1.2)

Hinweis

Nachfolgend werden die für XBezahldienste relevanten Vorgaben der DIN 91379 zusammengefasst.

Innerhalb des Standards XBezahldienste werden unterschiedliche Datentypen der DIN-Norm genutzt. Jeder Datentyp definiert den zulässigen Zeichensatz für eine bestimmte Klasse von Inhalten. Die nachfolgende Beschreibung der Datentypen enthält jeweils die zugehörigen Felder der Schnittstelle. Felder ohne DIN-Datentyp (z. B. IDs, Beträge, Enum-Werte) sind nicht aufgeführt.

Veraltete Schemas

Felder aus den als deprecated markierten Schemas RequestorLegacy und Address sind nachfolgend mit (veraltet) gekennzeichnet. Sie sollten in neuen Implementierungen nicht mehr verwendet werden.

Datentyp A

Datentyp A definiert den Zeichensatz für Namen natürlicher Personen, wie er in hoheitlichen Dokumenten verwendet wird.

Felder:

• RequestorIndividual.name — Familienname des Bezahlers
• RequestorIndividual.firstName — Vorname(n) des Bezahlers
• RequestorLegacy.name (veraltet) — Familienname des Bezahlers
• RequestorLegacy.firstName (veraltet) — Vorname(n) des Bezahlers

Datentyp B

Datentyp B wurde für sonstige Namen entworfen, insbesondere Orts- und Straßennamen. Er wird für alle Adressfelder verwendet.

Felder:

• PostalAddress.addressLine1 — Straße und Hausnummer oder Postfach
• PostalAddress.addressLine2 — Zusätzliche Adresszeile (optional)
• PostalAddress.addressLine3 — Zusätzliche Adresszeile (optional)
• PostalAddress.city — Ortsname
• PostalAddress.countrySubdivision — Region, Bundesland, Provinz (optional)
• Address.street (veraltet) — Straßenname
• Address.addressLine (veraltet) — Generische Adresszeilen für internationale Adressen
• Address.city (veraltet) — Ortsname

Datentyp C

Datentyp C umfasst alle normativen Schriftzeichen der DIN 91379 — die technische Umsetzung der Vereinbarung „Alle nach DIN 91379 normativen Schriftzeichen". Griechische oder kyrillische Buchstaben sowie erweiterte nicht-normative Zeichen sind unzulässig. Er wird für Freitextfelder verwendet, deren Inhalt eine gewisse Gestaltungsfreiheit aufweist.

Felder:

• PaymentRequest.description — Beschreibung des Payment Requests
• PaymentItem.description — Beschreibung der Positionszeile
• PaymentItem.bookingData (Werte) — Key-Value-Paare für Verbuchungsdaten

Datentyp D

Datentyp D wurde für Namen juristischer Personen und Produktnamen entworfen. Er ergänzt den normativen Zeichenvorrat (Lateinische Buchstaben, N1, N2, N3) um griechische Buchstaben sowie erweiterte Nicht-Buchstaben aus Anhang A der DIN 91379 (z. B. ™, ‰, …). Anders als Datentyp C enthält er keine normativ-ungeeigneten Zeichen der Gruppe N4 (Steuerzeichen, geschütztes Leerzeichen). Er kann nur von IT-Verfahren unterstützt werden, die die Erweiterungen aus Anhang A implementieren.

Felder:

• RequestorOrganization.name — Name der Organisation
• RequestorLegacy.organizationName (veraltet) — Name der Organisation