Ich weiss auch nicht, wir haben jetzt 2013 und das Internet und WWW gibt es schon ein paar Jährchen. Auch eCommerce ist doch inzwischen bei den meisten Menschen in Deutschland angekommen. Dazu haben wir Login und Autorisierungsmechanismen wie SAML, OAuth, OpenID und Konsorten ersonnen. Was aber ist noch wie damals in den Achtzigern? Banking. Okay, es gibt immerhin schon Onlinebanking. Da kann man praktisch alles aus den Achtzigern machen, ohne dass man physikalisch zur Bank rennen muss. Dennoch ist die Brücke zwischen Banking und eCommerce noch nicht richtig geschlagen. Das finde ich persönlich irgendwie blöd. Ansantzweise könne man den Dienst "sofortüberweisung" hier nennen. Allerdings ist dieser Dienst soweit unvernünftig, dass man Benutzernamen, PIN und eine TAN einer fremden Firma überlassen muss. Das wiederum verbieten die meisten (oder alle) Banken in ihren Nutzungsbedingunen fürs Online Banking. Und das ist auch sehr vernünftig so.
Soweit der Ist-Zustand. Nur wie kann man Abhilfe schaffen? Ich hab mir mal etwas aus meinem verlängertem Rückgrat gezaubert und will das nun im folgenden päsentieren (Nicht auszumalen, was sich kluge Köpfe noch ausdenken könnten, wenn sie mal richtig Zeit investieren würden). Der Name ist OBST ML. Online Banking Secure Token Markup Language. Und wie gesagt, das ist sehr rudimentär und soll nur andeuten, wie es funktionieren könnte.
Nehmen wir also an, es gibt einen Kunden K, einen Händler H und die Bank B. K will von H etwas kaufen und es möglichst schnell geliefert bekommen. Die beiden haben sich eigentlich schon auf Vorauskasse geeinigt, nur wie soll H sofort mitbekommen, dass K die Überweisung getätigt hat. Eine Möglichkeit wäre, dass sich H in seinem Onlinebanking Portal einloggt. Dort kann er sich eine One Time URL erzeugen lassen. Unter dieser URL nimmt seine Bank in einem kurzen Zeitraum Überweisungsanfragen entgegen. Diese URL muss K nun per Copy&Paste bei H im Bestellvorgang eintragen. Am Ende der Bestllung schickt wird in K's Browser die URL der Bank mit einem HTTP Post Request aufgerufen und in den Request Body eine Nachricht mit den Zahlungsmodalitäten, wie Zahlungsempfänger und Betrag, und eine URL zum Zurückkehren mitgeschickt. Die Bankdaten von K muss H gar nicht mehr kennen, denn die Bank, kann das Konto von K ja über die Einmal URL zuordnen. Als Antwort auf den Post Request an die Bank bekommt K nun nochmal alle Details der angefragten Transaktion von seiner Bank aufgezeigt. Er kann die Transaktion nun mit einer TAN bestätigen. Wenn die Transaktion bestätigt ist, schickt die Bank wiederum einen HTTP Post Request über K's Browser an den Händler zurück. Dort kommt in den Request Body die Nachricht, dass die Transaktion durchgeführt wurde.
Dieses gesamt Vorgehen ist aus dem SAML Standard bekannt und wird "front-channel" gennant, weil alle Datenübertragungen über den Browser des Clients laufen. Eine weitere Möglichkeit wäre die Kommunikation über einen "back-channel" zu etablieren. Das ganze ist eigentlich ziemlich geschickt und praktisch. Und besonders bei der "front-channel" Übertragung fällt es sogar noch leichter, das ganze datenschutz konform zu gestalten.
Was fehlt also noch? Wir brauchen noch eine DSL (domain specific language), Die das Format regelt, in dem die Daten übertragen werden. Zusätzlich brauchen wir noch einen Standard, der regelt, wie die Daten übertragen werden. Zusätzlich muss noch ein bisschen asymmeteische Kryptographie her, damit die Bank ihre Aussage auch signieren kann. Damit die Validierung der Signatur korrekt erfolgen kann, müssen die Händler und Banken untereinander Metadaten zu ihren Zertifikaten austauschen. Das kann über eine eigene Metadatenverwaltung passieren, oder aber z.B. über Zertifikatsketten.
Klar, es bedarf noch viel Detailarbeit, aber ich schätze, wenn ein grösserer Bankenverbund (Sparkassen oder Volksbanken) mit so etwas hervorpreschen würden, könnten sie schnell einen Quasistandard zementieren.
Von Michael am 21.04.2013 12:17 in Kategorie
Nerdstuff0 Kommentare