DE102020134933A1

DE102020134933A1 - Verfahren zum Erstellen einer qualifizierten elektronischen Signatur

Info

Publication number: DE102020134933A1
Application number: DE102020134933.5A
Authority: DE
Inventors: Ludwig Schulte
Original assignee: Klarna Bank AB
Current assignee: Klarna Bank AB
Priority date: 2020-12-24
Filing date: 2020-12-24
Publication date: 2022-06-30

Abstract

Offenbart ist ein Verfahren zum Initiieren des Erstellens einer qualifizierten elektronischen Signatur (10) über das Internet (6), umfassend die Schritte Aufnehmen (S1) von personenbezogenen Nutzerdaten durch Nutzereingabe zum Erstellen eines nutzerspezifischen Datensatzes (8), Erhalten (S2) eines Zugangs zu einem Nutzerkonto durch Eingabe von Zugangsdaten durch den Nutzer, Erfassen (S3) von Kontoinformation des Nutzers durch Ausführen eines Kontozugriffs unter Verwendung der eingegebenen Zugangsdaten, Auslösen (S4) eines Überweisungsvorgangs vom Nutzerkonto auf ein vorbestimmtes Konto unter Verwendung einer zwei-Faktor-Authentifizierung, Bestätigen (S5) der aufgenommenen Nutzerdaten, wenn der Überweisungsvorgang erfolgreich durchgeführt worden ist, und bei erfolgreicher Bestätigung und Initiieren (S6) des Erstellens der qualifizierten elektronischen Signatur (10) basierend auf dem nutzerspezifischen Datensatz (8).

Description

Gebiet der Erfindung
Die Erfindung bezieht sich auf ein Verfahren zum Initiieren des Erstellens einer qualifizierten elektronischen Signatur sowie eine zugehörige Servereinrichtung. Ferner betrifft das Verfahren und die zugehörige Vorrichtung auch die für die Initiierung notwendige Identifizierung des Nutzers.
Stand der Technik
Aus der europäischen Patentanmeldung 1 209 579 A1 ist ein System zur automatisierten Abwicklung von Transaktionen durch aktives Identitätsmanagement bekannt.
Beschreibung
Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Initiieren des Erstellens einer qualifizierten elektronischen Signatur. Diese kann über das Internet oder ein anderes Netzwerk, wie ein Weitverkehrsnetz (WAN) erfolgen. Eine qualifizierte elektronische Signatur kann zum Signieren von Dokumenten, welche der Schriftform bedürfen, verwendet werden, insbesondere anstatt einer manuellen (herkömmlichen) Signatur.
Alle im Folgenden in der Beschreibung erklärten Schritte des Verfahrens können in der hier verwendeten Reihenfolge ausgeführt werden. Das Verfahren ist jedoch nicht als auf diese Reihenfolge beschränkt zu verstehen. Auch eine passende, alternative Reihenfolge zum Ausführen des Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur ist von den Ansprüchen umfasst.
Ein weiterer Aspekt der Erfindung betrifft ein System zum Ausführen eines Verfahrens gemäß einer Ausführungsform zum Initiieren des Erstellens einer qualifizierten elektronischen Signatur insbesondere über das Internet. Das System kann eine Servereinrichtung aufweisen, welche eingerichtet sein kann, das Verfahren zum Erstellen der qualifizierten elektronischen Signatur über das Internet auszuführen.
Das vorgenannte Verfahren weist einen Schritt des Aufnehmens von personenbezogenen Nutzerdaten durch Nutzereingabe zum Erstellen eines nutzerspezifischen Datensatzes auf. Personenbezogene Nutzerdaten können zumindest eines sein von Anrede, Vorname, Nachname, Geburtstag, Telefonnummer, E-Mail-Adresse und IBAN. Die Nutzereingabe kann manuell, beispielsweise von einem Nutzer über ein mobiles Endgerät, wie ein Handy, erfolgen oder die Nutzereingabe kann automatisiert, beispielsweise über einen Passwortmanager oder eine andere Datenerfassung, erfolgen. Der nutzerspezifische Datensatz kann in Abhängigkeit der aufgenommenen personenbezogenen Nutzerdaten erstellt werden. Zu einem späteren Zeitpunkt während des Verfahrens können weitere Daten dem nutzerspezifischen Datensatz hinzugefügt werden, beispielsweise durch den Nutzer, die Servereinrichtung oder eine andere Einrichtung. Die Servereinrichtung kann eingerichtet sein, personenbezogenen Nutzerdaten zu erhalten und basierend darauf den nutzerspezifischen Datensatz zu erstellen. Alternativ kann die Servereinrichtung lediglich den nutzerspezifischen Datensatz erhalten. Die Kommunikation zwischen Servereinrichtung und mobilem Endgerät kann beispielsweise über das Internet erfolgen.
Das Verfahren weist ferner einen Schritt des Erhaltens eines Zugangs zu einem Nutzerkonto durch Eingabe von Zugangsdaten durch den Nutzer auf. Das Konto kann ein Bankkonto bei einer Bank oder einem anderen Kreditinstitut oder Bankinstitut sein. Die Eingabe von Zugangsdaten kann manuell und/oder automatisiert per Applikation über das Endgerät des Nutzers eingegeben werden. Die Zugangsdaten können Onlinebanking-Zugangsdaten sein. Das Erhalten des Zugangs kann ein Erhalten einer Zugangsberechtigung zu dem Nutzerkonto sein. Beispielsweise kann die Servereinrichtung einen Zugang zum Nutzerkonto durch Erhalten einer Zugangsberechtigung erhalten.
Das Verfahren weist ferner einen Schritt des Auslösens eines Überweisungsvorgangs vom Nutzerkonto auf ein vorbestimmtes Konto unter Verwendung einer zwei-Faktor-Authentifizierung auf. Der Überweisungsvorgang kann eine Onlinebanküberweisung sein. In einer hiervon umfassten Ausführungsform kann im Schritt des Ausführens des Kontozugriffs die zwei-Faktor-Authentifizierung erfolgen, so dass im Schritt des Auslösens eines Überweisungsvorgangs diese zwei-Faktor-Authentifizierung nicht notwendig ist. Die Servereinrichtung kann eingerichtet sein, sowohl den Überweisungsvorgang auszulösen wie auch auf das vorbestimmte Konto zuzugreifen oder zumindest Information bezüglich des Kontostands und/oder der Umsätze des vorbestimmten Kontos zu erhalten.
Das Verfahren weist einen Schritt des Bestätigens der aufgenommenen Nutzerdaten, wenn der Überweisungsvorgang erfolgreich durchgeführt worden ist, auf. Der Überweisungsvorgang kann als erfolgreich durchgeführt angesehen werden, wenn der gewünschte Betrag vom Nutzerkonto auf das vorbestimmte Konto überwiesen worden ist. In diesem Fall kann die Bestätigung als erfolgreich angesehen werden. Ein Überweisungsvorgang kann als erfolgreich bewertet werden, wenn die Überweisung durch eine Schnittstelle einer das Nutzerkonto führenden Bank bestätigt wird. Ferner kann jedoch auch die Servereinrichtung Umsätze am vorbestimmten Konto auf das Vorhandensein des zuvor erwähnten Überweisungsvorgangs prüfen und bei Übereinstimmung die aufgenommenen Nutzerdaten bestätigen.
Das Verfahren weist ferner einen Schritt des Initiierens des Erstellens der qualifizierten elektronischen Signatur basierend auf dem nutzerspezifischen Datensatz auf, wenn eine erfolgreiche Bestätigung vorliegt. Mittels der sodann erstellten qualifizierten elektronischen Signatur kann ein Dokument signiert werden.
Vorteilhafterweise ist es somit möglich, personenbezogene Nutzerdaten aufzunehmen, zu bestätigen und für einen davon abhängigen nutzerspezifischen Datensatz eine qualifizierte elektronische Signatur zu erstellen, ohne die Notwendigkeit einer menschlichen Überprüfung der aufgenommenen personenbezogenen Nutzerdaten. Dadurch ist dieses Verfahren zum Erstellen einer qualifizierten elektronischen Signatur im Vergleich zu herkömmlichen Verfahren zum Erstellen von Signaturen orts- und zeitunabhängig und insbesondere skalierbar hinsichtlich zu erstellender qualifizierter elektronischer Signaturen, da es keiner manuellen Bestätigung der aufgenommenen Nutzerdaten durch einen Menschen bedarf. Das Verfahren kann beispielsweise vollkommen automatisiert durch die Servereinrichtung ausgeführt werden.
Gemäß einer Ausführungsform kann die Kontoinformation zumindest eines von Kontoinhabername, Payment Service User, PSU, und IBAN umfassen. Gemäß einer Ausführungsform können Kontoinhabername und PSU identisch sein. Im Fall von Gemeinschaftskonten oder Vollmachten für Konten kann der Kontoinhabername ein anderer sein als der PSU. Gemäß einer Ausführungsform kann die Kontoinformation auch Salden und/oder Umsatzdaten des Nutzerkontos umfassen.
Vorteilhafterweise kann somit beispielsweise der Schritt des Auslösens lediglich in den Fällen ausgeführt werden, in denen Kontoinhabername und PSU übereinstimmen. Es kann somit ein weiteren Überprüfungsschritt des Überprüfens des PSU vorgesehen sein. Dies kann die Sicherheit des Verfahrens erhöhen, da dann sichergestellt werden kann, dass der ausführende Nutzer auch derjenige ist, für den die Signatur erstellt werden soll.
Das Verfahren kann ferner einen Schritt des Erfassens von Kontoinformation des Nutzers durch Ausführen eines Kontozugriffs unter Verwendung der eingegebenen Zugangsdaten aufweisen. Der Kontozugriff kann manuell, beispielsweise durch den Nutzer, oder automatisiert, beispielsweise durch die Servereinrichtung, erfolgen. Auch das Erfassen von Kontoinformation kann durch die Servereinrichtung erfolgen.
Gemäß einer Ausführungsform kann der Schritt des Erfassens von zumindest einem Teil der Kontoinformation des Nutzers mittels einer Schnittstelle, insbesondere mittels eines Payment Initiation Services, PIS, und/oder eines Account Information Services, AIS, erfolgen. Eine Schnittstelle kann hier eine Applikationsprogrammierschnittstelle, API, sein. Diese Schnittstellen können von einer das Nutzerkonto führenden Bank bereitgestellt werden. Der Schritt des Erfassens kann einen Schritt des Sendens einer Anfrage bezüglich der Kontoinformation und einen Schritt des Empfangens der Kontoinformation an und von der Schnittstelle umfassen. Mittels Verwendung der Schnittstelle kann im Schritt des Erfassens von Kontoinformation vorteilhafterweise eine Trennung zwischen der das Verfahren zum Erstellen einer qualifizierten elektronischen Signatur ausführenden Servereinrichtung und der die Kontoinformation des Nutzers speichernden Bank sichergestellt werden. Dies stellt sich für potentielle Nutzer als vorteilhaft dar, da verschiedene Banken mit verschiedenen, das Verfahren ausführende Unternehmen so leicht zusammenarbeiten können und Schnittstellen dazwischen klar definiert sind.
Gemäß einer weiteren Ausführungsform kann der Schritt des Erfassens von Kontoinhabername und IBAN mittels einer Schnittstelle, insbesondere mittels PIS und/oder AIS erfolgen. Gemäß einer Ausführungsform können Kontoinhabername und IBAN lediglich über diese Schnittstelle erfasst werden. Vorteilhafterweise ist somit ein möglicher Datenmissbrauch unterbunden, da lediglich über diese definierten Schnittstellen Datenaustausch bezüglich der genannten Informationen erfolgt.
Gemäß einer Ausführungsform der Erfindung kann der Schritt des Erfassens von zumindest einem Teil der Kontoinformation des Nutzers mittels Direct Access bzw. Scraping erfolgen.
Direct Access bzw. Scraping bedienen sich, im Gegensatz zu den oben definierten APIs PIS und AIS, keiner klar von einer Bank definierten Schnittstellen, sondern greifen vielmehr ohne die weitere Einwilligung der Bank auf Daten der Bank zu und können diese unter Umständen manipulieren, beispielsweise eine Überweisung vornehmen. Vorteilhafterweise kann durch die Verwendung von Direct Access eine sichere Verbindung zwischen der Servereinrichtung zum Ausführen des Verfahrens und einem das Nutzerkonto bereitstellenden Bankservers hergestellt werden. Per Scraping können sodann Daten in und/oder von einem Interface der Bank an/von der Servereinrichtung übertragen werden. Es kann zumindest ein Teil oder es kann die gesamte Kontoinformation des Nutzers mittels Direct Access bzw. Scraping erfasst werden. Vorteilhafterweise ist somit ein Verfahren beschrieben, welches unabhängig von extern bereitgestellten APIs notwendige Kontoinformationen mittels Direct Access bzw. Scraping erfassen kann.
Gemäß einer Ausführungsform der Erfindung kann der Schritt des Erfassens des PSU mittels Direct Access bzw. Scraping erfolgen. In einem Hybridmodell kann der Schritt des Erfassens von Kontoinhabername und IBAN mittels einer Schnittstelle, wie einer API, insbesondere mittels PIS und/oder AIS, und der Schritt des Erfassens des PSU mittels Direct Access bzw. Scraping erfolgen.
Gemäß einer Ausführungsform der Erfindung kann im Schritt des Erfassens der Kontozugriff mittels Schnittstelle, insbesondere mittels AIS oder PIS, oder mittels Direct Access bzw. Scraping erfolgen. Hierin kann beispielsweise eine Direct-Access-Verbindung zwischen der Servereinrichtung und dem Bankserver, oder alternativ zwischen dem Nutzerendgerät und dem Bankserver eingerichtet werden.
Gemäß einer Ausführungsform kann der Schritt des Erfassens des PSU mittels einer Schnittstelle, insbesondere mittels des PIS und/oder AIS, erfolgen, und es kann im oder vor dem Schritt des Auslösens des Überweisungsvorgangs ein neuer Consent erstellt werden. Der Consent könnte hier eine Zustimmung zu Funktionalitäten darstellen, d.h. eine erlaubte Verwendung dieser Funktionalitäten darstellen. Die Funktionalitäten können hierbei zumindest eine von Zahlungsauslösefunktionalitäten, insbesondere PIS, oder Kontoinformationsfunktionalitäten, insbesondere AIS sein. Der Consent kann die Zustimmung des Nutzers zu diesen Funktionalitäten darstellen. Der Consent könnte gespeichert sein, beispielsweise in einem Consentmanager (in) der Servereinrichtung. Der Consent kann mit einem Zeitstempel versehen sein, so dass neuer und alter Consent unterschieden werden können, wobei neuer Consent einen Zeitstempel aus der nahen Vergangenheit und alter Consent einen Zeitstempel aus der ferneren Vergangenheit aufweisen kann. Insbesondere kann es in einer Ausführungsform notwendig sein, dass, falls der Schritt des Erfassens des PSU mittels einer Schnittstelle, insbesondere einer API, besonders insbesondere mittels des PIS und/oder AIS erfolgt, zwingend ein neuer Consent erstellt werden muss, um mit dem Verfahren zum Erstellen einer qualifizierten elektronischen Signatur fortfahren zu können.
In einer weiteren Ausführungsform kann der Schritt des Erfassens des PSU mittels Direct Access bzw. Scraping erfolgen und im Schritt des Auslösens des Überweisungsvorgangs kann ein bestehender Consent verwendet werden. Der bestehende Consent kann hier sodann etwa ein wie zuvor definierter, alter Consent, gegebenenfalls gespeichert am Consentmanager, sein. Vorteilhafterweise kann durch die Verwendung eines bestehenden Consent der Schritt des Auslösens des Überweisungsvorgangs beschleunigt werden, da es unabhängig von weiterer Information vom Nutzer wäre. Gleichzeitig kann durch Verwenden des Consent, welcher auch ursprünglich lediglich per zwei-Faktor-Authentifizierung erstellt werden konnte, die Sicherheit des Verfahrens gewährleistet sein.
Gemäß einer weiteren Ausführungsform kann der Schritt des Auslösens des Überweisungsvorgangs mittels Zahlungsauthorisierung durch den Nutzer oder mittels einem zuvor erstellten Consent freigegeben werden. Zahlungsauthorisierung kann hier beispielsweise mittels einer TAN oder mittels biometrischer Daten erfolgen. Die Zahlungsauthorisierung kann somit eine zwei-Faktor-Authentisierung vervollständigen. Wird der Überweisungsvorgang beispielsweise nicht mittels Zahlungsauthorisierung oder zuvor erstelltem Consent freigegeben, so kann eventuell der Schritt des Auslösens vom Verfahren nicht ausgeführt werden. So kann beispielsweise im Fall des Hybridmodells sichergestellt werden, dass eine für den Kontozugriff notwendige TAN bereits in einem vorherigen Schritt vom Nutzer eingegeben worden ist und damit eine zwei-Faktor-Authorisierung vorliegt.
Gemäß einer weiteren Ausführungsform kann der Schritt des Auslösens des Überweisungsvorgangs mittels einer Schnittstelle, insbesondere des PIS, erfolgen. Beispielsweise kann in einer Ausführungsform gemäß einem sogenannten Embedded Flow der Schritt des Erfassens von Kontoinhabername und IBAN mittels einer Schnittstelle, beispielsweise PIS und/oder AIS, erfolgen, der Schritt des Erfassens des PSU mittels Direct Access bzw. Scraping erfolgen und der Schritt des Auslösens des Überweisungsvorgangs mittels einer Schnittstelle, insbesondere des PIS, erfolgen.
Gemäß einer weiteren Ausführungsform kann im Schritt des Auslösens des Überweisungsvorgangs eine PIS-Session erstellt werden, der Nutzer auf eine Website der Bank weitergeleitet werden, sich mittels Eingabe von Zugangsdaten einloggen und den Überweisungsvorgang auslösen. Eine Ausführungsform dieses Verfahrens kann als Redirect Flow bezeichnet werden. Gemäß einer Ausführungsform kann der Schritt des Erfassens des PSU mittels Direct Access bzw, Scraping erfolgen und der Schritt des Erfassens von Kontoinhabername und IBAN mittels API erfolgen. Somit wird ein Verfahren bereitgestellt, welches vorteilhafterweise unabhängig von zahlungsauslösenden Schnittstellen seitens der Banken arbeiten kann.
Gemäß einer weiteren Ausführungsform können im Schritt des Bestätigens der aufgenommenen Nutzerdaten diese mit der erfassten Kontoinformation verglichen werden und der Schritt des Initiierens bei Übereinstimmen von zumindest Kontoinhabername und IBAN, insbesondere auch PSU, ausgeführt werden. So kann vorteilhafterweise sichergestellt werden, dass nur von einem kontozugangsberechtigten Nutzer aufgenommene Nutzerdaten bestätigt werden. Insbesondere kann durch Übereinstimmung des aufgenommenen Nutzernamens mit der erfassten PSU sichergestellt werden, dass eindeutig dieser Nutzer das Verfahren verwendet. Eine personenspezifische qualifizierte elektronische Signatur kann somit vorteilhafterweise bereitgestellt werden.
Gemäß einer weiteren Ausführungsform kann das Verfahren ferner einen Schritt des Überprüfens einer Zugehörigkeit der aufgenommenen Nutzerdaten, insbesondere des Kontoinhabernamens und der IBAN, zueinander durch Vergleich mittels Daten aus einer Auskunftei aufweisen. Die Auskunftei kann hierbei beispielsweise die Schufa sein. Der Schritt des Überprüfens kann beispielsweise nach dem Schritt des Aufnehmens und vor dem Schritt des Erhaltens des Zugangs zum Nutzerkonto erfolgen. Der Schritt kann jedoch alternativ auch noch zu einem anderen Zeitpunkt während des Ausführens des Verfahrens ausgeführt werden, insbesondere zu jedem Zeitpunkt vor dem Schritt des Bestätigens der aufgenommenen Nutzerdaten. In einer weiteren Ausführungsform kann die IBAN auch erst im Schritt des Erhaltens des Zugangs zu dem Nutzerkonto durch Eingabe von Zugangsdaten durch den Nutzer erhalten werden. Somit würde in einer solchen Ausführungsform der Schritt des Überprüfens der Zugehörigkeit der aufgenommen Nutzerdaten frühestens mit oder ab diesem Schritt erfolgen. Somit kann beispielsweise mittels einem in der Auskunftei abgespeicherten Tupel aus Kontoinhabername und IBAN, welche hier miteinander abgeprüft verbunden vorliegen, und den aufgenommenen Nutzerdaten, d.h. Kontoinhabername und IBAN, dieses Tupel überprüft werden.
Gemäß einer weiteren Ausführungsform kann das Verfahren ferner einen Schritt des Bestätigens der aufgenommenen Nutzerdaten durch Überprüfen auf eine vorhandene, bereits erfolgte Bestätigung der Nutzerdaten aufweisen, welche insbesondere in einer Auskunftei abgespeichert sein kann. Die Auskunftei kann auch hierbei die Schufa sein. Der Schritt des Bestätigens kann beispielsweise nach dem Schritt des Aufnehmens von personenbezogenen Nutzerdaten und vor dem Schritt des Erhaltens eines Zugangs erfolgen. Der Schritt kann alternativ auch zu jedem anderen Zeitpunkt vor dem Schritt des Bestätigens der aufgenommene Nutzerdaten ausgeführt werden. Die bereits erfolgte Bestätigung der Nutzerdaten kann beispielsweise eine vor dem Ausführen des Verfahrens erfolgte Identitätsüberprüfung durch einen Menschen per Gesichtskontrolle mit dem Ausweis des Nutzers sein. Dieser Schritt des Bestätigens kann als ausweisgeprüfte Identität bekannt sein.
Gemäß einer weiteren Ausführungsform kann das Verfahren ferner einen Schritt des Sendens zumindest eines Teils des nutzerspezifischen Datensatzes aufweisen, insbesondere eines Session Tokens und einer Telefonnummer, zur zwei-Faktor-Authentifizierung an einen Signaturdienstanbieter, insbesondere eine Zertifizierungsstelle, und insbesondere ferner einen Schritt des Sendens eines Dokuments an den Signaturdienstanbieter aufweisen. Das Dokument kann das zu signierende Dokument sein. Der Signaturdienstanbieter kann ein serverbasierter Signaturdienstanbieter sein. Der Session Token kann hier ein zufallsgenerierter Token sein, und dabei entweder vom mobilen Endgerät des Nutzers und/oder von der Servereinrichtung bereitgestellt sein. Ferner kann der Name des Nutzers an den Signaturdienstanbieter gesendet werden. Beispielsweise kann die Servereinrichtung den Session Token erzeugen, per Schnittstelle dem Signaturdienstanbieter bereitstellen und der (weitere) nutzerspezifische Datensatz, beispielsweise der Name und die Telefonnummer, kann direkt vom mobilen Endgerät des Nutzers, beispielsweise über das Internet, an den Signaturdienstanbieter gesendet werden. Dabei kann ein erfolgreiches Senden beispielsweise innerhalb eines Zeitfensters, welches dem Session Token inhärent innewohnen kann, erfolgreich sein, wenn der Nutzer, der den Session Token auch von der Servereinrichtung erhalten kann, diesen dem Signaturdienstanbieter bestätigt. Durch Identifikation über die Telefonnummer des mobilen Endgeräts kann eine korrekte Zuordnung der an den Signaturdienstanbieter zu sendenden Daten durch den Signaturdienstanbieter erfolgen. Somit kann vorteilhafterweise auch in diesem Schritt eine zwei-Faktor-Authentisierung erfolgen.
Gemäß einer weiteren Ausführungsform kann das Verfahren ferner einen Schritt des Erstellens der qualifizierten elektronischen Signatur und einen Schritt des Signierens des Dokuments aufweisen, insbesondere nach dem Schritt des Initiierens des Erstellens der qualifizierten elektronischen Signatur und basierend auf dem nutzerspezifischen Datensatz.
Gemäß einer weiteren Ausführungsform kann für den Schritt des Erstellens der Signatur und den Schritt des Signierens der externe Signaturdienstanbieter in Anspruch genommen werden. Vorteilhafterweise kann somit in verschiedenen Einrichtungen, wie hier der Servereinrichtung und dem Signaturdienstanbieter, das Überprüfen der Daten bezüglich des Nutzers und das eigentliche Erstellen der Signatur und Signieren des Dokuments mit der erstellten Signatur getrennt werden.
Gemäß einer weiteren Ausführungsform kann der Schritt des Erstellens der elektronischen Signatur einen Schritt des Verifizierens des Nutzers mittels zwei-Faktor-Authentifizierung umfassen, insbesondere mittels Versendens einer Nachricht an den Nutzer und/oder Verwenden eines Session Tokens, und die erstellte elektronische Signatur kann als ein privater Schlüssel in einem Hardware-Sicherheitsmodul, HSM, gespeichert werden. Das Hardware-Sicherheitsmodul kann Teil des Signaturdienstanbieters sein oder zumindest mit diesem verbunden sein. Der private Schlüssel kann Teil eines asymmetrischen Schlüsselpaars sein.
Gemäß einer weiteren Ausführungsform kann im Schritt des Signierens der private Schlüssel, gespeichert auf dem HSM, verwendet werden und der Signaturdienstanbieter kann damit das Dokument signieren. Es kann auch der öffentliche Schlüssel des Schlüsselpaars mit dem privaten Schlüssel auf dem HSM gespeichert sein. Der private Schlüssel, und gegebenenfalls auch der öffentliche Schlüssel, des Nutzers können nach einer bestimmbaren Zeit vom HSM gelöscht werden. Bis zum Löschen des Schlüsselpaars kann für weitere Schritte des Signierens für das gleiche und/oder für weitere Dokumente des Nutzers das Schlüsselpaar verwendet werden, gegebenenfalls mit dann weiterer (notwendiger) zwei-Faktor-Authentifizierung.
Gemäß einer weiteren Ausführungsform kann das Verfahren ferner einen Schritt des Sendens oder Bereitstellens zum Download des signierten Dokuments, insbesondere an eine vorbestimmte Adresse, aufweisen. Die vorbestimmte Adresse kann beispielsweise das Endgerät des Nutzers sein und die Adresse kann beispielsweise als Teil des nutzerspezifischen Datensatzes vorliegen und von dem Signaturdienstanbieter zugreifbar sein. Die vorbestimmte Adresse kann beispielsweise die Servereinrichtung sein. Die vorbestimmte Adresse kann auch beispielsweise durch den Nutzer aktiv eingegeben und damit beeinflusst werden. Im Schritt des Sendens des signierten Dokuments kann beispielsweise der Signaturdienstanbieter die Nachricht einmal mit dem privaten Schlüssel verschlüsseln und der Signatur Informationen bezüglich des öffentlichen Schlüssels beifügen. Die Nachricht kann das Dokument einmal, mit dem privaten Schlüssel verschlüsselt, und einmal unverschlüsselt aufweisen. Damit kann ein Authentisierungsschritt durch einen Dritten durch Anwenden des öffentlichen Schlüssels auf den privat verschlüsselten Teil der Nachricht und Vergleichens des sodann entschlüsselten privaten Teils mit dem öffentlichen Teil der Nachricht erfolgen. Bei Übereinstimmen kann eine für den Dritten erkennbares erfolgreich vom Nutzer signiertes Dokument vorliegen.
Gemäß einer weiteren Ausführungsform kann das Verfahren ferner einen Schritt des Zurücküberweisens von dem vorbestimmten Konto auf das Nutzerkonto aufweisen, wobei insbesondere der gleiche Betrag zurücküberwiesen werden kann, wie zuvor im Schritt des Auslösens des Überweisungsvorgangs überwiesen worden ist.
Ein weiterer Aspekt der Erfindung betrifft ein System, welches aus der Servereinrichtung besteht, welche eingerichtet ist, das Verfahren nach einer der Ausführungsformen, wie oben beschrieben, auszuführen. Ferner kann das System einen Signaturdienstanbieter, insbesondere mit einem HSM, aufweisen. Ferner kann das System zusätzlich oder alternativ eine Bank, insbesondere mit einem Bankserver, auf welchem Kontoinformationen von potenziellen Nutzern gespeichert sein können, aufweisen. Weiter kann das System eine Auskunftei aufweisen. Weiter kann das System auch ein Nutzerendgerät des Nutzers aufweisen. Einrichtungen des Systems können über das Internet verbunden sein.
Figurenliste

1 zeigt einen schematischen Ablauf eines Verfahrens zum Erstellen einer elektronischen Signatur gemäß einem Aspekt der vorliegenden Erfindung
2 zeigt ein System zum Ausführen eines Verfahrens zum Erstellen einer elektronischen Signatur gemäß einem Aspekt der vorliegenden Erfindung

Detaillierte Beschreibung der Ausführungsformen
Ein schematisches Ablaufdiagramm, gezeigt in 1, beschreibt einen Ablauf eines Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur 10 gemäß einer Ausführungsform. Wenngleich das schematische Ablaufdiagramm von 1 eine mögliche Abfolge von Schritten des Verfahrens zeigt, so können einzelne Schritte oder alle Schritte in einer anderen möglichen Reihenfolge nacheinander im Laufe des Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur 10 ausgeführt werden. Beispielhafte Ausführungsformen solcher anderen Abläufe werden mitunter im Folgenden beschrieben.
Gezeigt in 2 ist ein System zum Ausführen des Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur 10 gemäß einer Ausführungsform. Manche Ausführungsformen des Systems können lediglich Teile des in 2 gezeigten Systems zum Ausführen des Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur 10 gemäß einer Ausführungsform aufweisen.
Das System weist eine Servereinrichtung 2 zum Ausführen des Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur 10 auf. Die Servereinrichtung 2 ist über ein Netzwerk, beispielsweise das Internet 6, mit anderen Einrichtungen verbunden. Zunächst führt die Servereinrichtung 2 einen Schritt des Aufnehmens S1 von personenbezogenen Nutzerdaten durch Nutzereingabe zum Erstellen eines nutzerspezifischen Datensatzes 8 aus. Die Nutzereingabe kann durch ein Endgerät 4, beispielsweise ein Smartphone, durch den Nutzer erfolgen. Das Endgerät 4 des Nutzers ist über das Internet 6 mit der Servereinrichtung 2 verbunden. Die Servereinrichtung 2 kann somit eingegebene personenbezogene Nutzerdaten über das Netzwerk 6 erhalten. So kann der nutzerspezifische Datensatz 8 basierend auf den aufgenommenen personenbezogenen Nutzerdaten durch und insbesondere in der Servereinrichtung 2 erstellt werden. Alternativ kann im mobilen Endgerät 4 oder in einem nicht gezeigten Teil des Internets 6 der nutzerspezifische Datensatz 8 basierend auf den aufgenommenen personenbezogenen Nutzerdaten erzeugt werden und ferner an die Servereinrichtung 2 geschickt werden.
Im Schritt S2 erhält die Servereinrichtung 2 einen Zugang zu einem Nutzerkonto durch Eingabe von Zugangsdaten durch den Nutzer. Hierbei kann der Nutzer bevorzugterweise seine Zugangsdaten zu seinem Nutzerkonto bei einer Bank 14 in das mobile Endgerät 4 eingeben. Die Eingabe von Zugangsdaten durch den Nutzer kann hierbei entweder auf Seiten der Servereinrichtung 2 oder auf Seiten der Bank 14 erfolgen.
Gemäß einer Ausführungsform weist das Verfahren, welches in 1 schematisch dargestellt ist, einen Schritt des Bestätigens S8 der aufgenommenen Nutzerdaten durch Überprüfen auf eine vorhandene, bereits erfolgte Bestätigung der Nutzerdaten auf. Hierbei kann beispielsweise die Servereinrichtung 2 Informationen bezüglich der aufgenommenen Nutzerdaten von einer Auskunftei 16 abfragen. Die Auskunftei 16 ist hierbei mit der Servereinrichtung 2 über das Netzwerk 6 verbunden. Vor dem Ausführen des Verfahrens zum Erstellen einer qualifizierten elektronischen Signatur 10 kann beispielsweise bereits eine ausweisgeprüfte Identität des Nutzers in der Auskunftei 16 vorliegen. Diese kann sodann in dem Schritt S8 von der Servereinrichtung 2 abgefragt werden. Somit kann beispielsweise gemäß einer Ausführungsform der Erfindung das Ausführen des Schritts S2 des Erhaltens eines Zugangs zu einem Nutzerkonto abhängig sein von dem (erfolgreichen) Schritt S8 des Bestätigens der aufgenommenen Nutzerdaten durch Überprüfen bei der Auskunftei 16. In anderen Ausführungsformen kann der Schritt S8 des Überprüfens einer ausweisgeprüften Identität auch zu einem späteren Zeitpunkt und insbesondere zwischen zwei anderen notwendigen Schritten des Verfahrens, wo sinnvoll, ausgeführt werden. Insbesondere kann der Schritt S8 zu einem beliebigen Zeitpunkt vor dem (erfolgreichen Beenden) des Schritts S5 beziehungsweise vor dem Start des Schritts S6 sein, welche weiter unten detailliert beschrieben werden.
Ferner weist das Verfahren einen Schritt S3 des Erfassens von Kontoinformation des Nutzers durch Ausführen eines Kontozugriffs unter Verwendung der eingegebenen Zugangsdaten aus. Der Schritt des Erfassens S3 wird hierbei durch die Servereinrichtung 2 ausgeführt. In einer Ausführungsform weist die Bank 14, welche mit den anderen Einrichtungen des Systems über das Internet 6 verbunden ist, eine Schnittstelle 12 auf. Insbesondere kann die Schnittstelle 12 ein Payment Initiation Service, PIS, und/oder ein Account Information Service, AIS, sein. So kann die Servereinrichtung 2 im Schritt S3 beispielsweise über den AIS Kontoinformationen, wie Kontoinhabername, IBAN und/oder den Payment Service User, PSU, über die Schnittstelle 12 von der Bank 14 erhalten. Der zuvor notwendige Kontozugriff kann dabei beispielsweise auch mittels der zuvor eingegebenen und erhaltenen Zugangsdaten durch die Servereinrichtung 2 erfolgen. Dieser Kontozugriff kann beispielsweise per Screen Scraping, Direct Access oder mittels Schnittstelle, wie beispielsweise einer API, erfolgen.
Gemäß einer Ausführungsform weist das Verfahren ferner einen Schritt des Überprüfens S7 einer Zugehörigkeit der aufgenommenen Nutzerdaten, insbesondere des Kontoinhabernamens und der IBAN, zueinander auf. Der Schritt S7 ist dabei in Ausführungsformen des Verfahrens notwendig und bedingt weitere Schritte. In anderen Ausführungsformen kann der Schritt S7 des Überprüfens der Zugehörigkeit optional sein und nicht notwendig zum Ausführen weiterer Schritte, insbesondere des Schritts S2 und darauf aufbauender Schritte. Im Schritt S7 überprüft die Servereinrichtung 2 die aufgenommenen Nutzerdaten, insbesondere Kontoinhabername und IBAN, mit Daten aus der Auskunftei 16. So kann das Überprüfen beispielsweise erfolgreich sein, wenn dieses Tupel bestehend aus Kontoinhabername und IBAN identisch ist zwischen den aufgenommenen Nutzerdaten und den Daten aus der Auskunftei 16. Ähnlich wie Schritt S8 kann Schritt S7 zumindest vor dem Start von Schritt S6 in manchen Ausführungsformen der Erfindung notwendig sein.
Ferner weist das Verfahren einen Schritt des Auslösens S4 eines Überweisungsvorgangs vom Nutzerkonto auf ein vorbestimmtes Konto unter Verwendung einer zwei-Faktor-Authentifizierung auf. Der Schritt des Auslösens S4 wird hierbei durch die Servereinrichtung 2 ausgeführt. Der Schritt des Auslösens S4 kann dabei mittels Direct Access bzw. Screen Scraping von der Servereinrichtung 2 über das Internet 6 an die Bank 14 erfolgen. Alternativ kann eine Schnittstelle 12, beispielsweise die PIS der Bank 14, von der Steuereinrichtung 2 zum Auslösen S4 des Überweisungsvorgangs verwendet werden.
Das Verfahren weist ferner einen Schritt des Bestätigens S5 der aufgenommenen Nutzerdaten auf. Der Schritt S5 wird dabei auch durch die Servereinrichtung 2 ausgeführt. Gemäß einer Ausführungsform können die aufgenommenen Nutzerdaten durch die Servereinrichtung 2 bestätigt werden, wenn der Überweisungsvorgang erfolgreich durchgeführt worden ist. Erfolgreiches Durchführen des Überweisungsvorgangs liegt beispielsweise vor, wenn ein bestimmbarer Betrag auf einem von der Servereinrichtung 2 zugriffbaren (hier nicht gezeigten) Konto erhalten worden ist. In einer alternativen Ausführungsform greift die Servereinrichtung 2 mittels der Schnittstelle 12, insbesondere mittels der AIS, auf Kontoinformationen des Nutzerkontos zu, und überprüft zumindest eine Information von dem Kontostand und den Überweisungsvorgängen. Beispielsweise kann hier der Schritt S3 auch zeitgleich mit oder (unmittelbar) vor dem Schritt S5 erfolgen. So kann in einer alternativen Ausführungsform der Schritt S3 des Erfassens von Kontoinformation zeitgleich mit oder direkt nach dem Schritt S4 des Auslösens des Überweisungsvorgangs erfolgen. Liegt eine Abbuchung entsprechend des ausgelösten Überweisungsvorgangs vor, d.h. an das vorbestimmte Konto, so kann der Überweisungsvorgang als erfolgreich durchgeführt angesehen werden. In einer Ausführungsform der Erfindung kann ein erfolgreiches Bestätigen S5 der aufgenommenen Nutzerdaten auch abhängig sein von einem erfolgreichen Vergleichen der erfassten Kontoinformation mit den aufgenommenen Nutzerdaten. So kann es beispielsweise notwendig sein, dass Informationen bezüglich des das Endgerät 4 benutzenden Nutzers und des PSU übereinstimmen müssen, so dass der Schritt des Bestätigens S5 erfolgreich ist.
Gemäß einer Ausführungsform weist das Verfahren einen Schritt S12 des Zurücküberweisens von dem vorbestimmten Konto auf das Nutzerkonto auf. Insbesondere kann hier nach erfolgreicher Bestätigung S5 der aufgenommenen Nutzerdaten der gleiche Betrag zurücküberwiesen werden. Dies kann beispielsweise durch die Servereinrichtung 2 von einem von der Servereinrichtung 2 zugreifbaren vorbestimmten Konto, insbesondere vom gleichen vorbestimmten Konto wie zuvor, auf ein Nutzerkonto erfolgen. Der Schritt S12 des Zurücküberweisens kann unmittelbar zeitlich nach dem Schritt S5 des Bestätigens der aufgenommenen Nutzerdaten erfolgen oder zeitlich später, parallel zu oder nach weiteren Schritten des Verfahrens.
Das Verfahren weist ferner einen Schritt des Initiierens S6 des Erstellens der qualifizierten elektronischen Signatur 10 basierend auf dem nutzerspezifischen Datensatz 8 auf. Der Schritt des Initiierens S6 wird hierbei gemäß einer Ausführungsform durch die Servereinrichtung 2 ausgeführt. Der Schritt des Initiierens S6 ist hierbei abhängig von der erfolgreichen Bestätigung im Schritt S5. Der Schritt des Initiierens S6 ist dabei notwendig, so dass die Servereinrichtung 2 oder eine andere Einrichtung die qualifizierte elektronische Signatur 10 erstellen kann und dazu berechtigt ist. Gemäß einer Ausführungsform erstellt die Servereinrichtung 2 die qualifizierte elektronische Signatur 10 basierend auf dem nutzerspezifischen Datensatz 8 selbst. Im Folgenden wird eine alternative Ausführungsform näher beschrieben, welche eine weitere Einrichtung aufweist, welche die qualifizierte elektronische Signatur 10 basierend auf dem nutzerspezifischen Datensatz 8 erstellt, wobei dieses Erstellen durch den Schritt des Initiierens S6 durch die Servereinrichtung 2 getriggert wird.
Das Verfahren gemäß einer Ausführungsform weist ferner einen Schritt des Sendens S9.1 zumindest eines Teils des nutzerspezifischen Datensatzes 8 auf. Insbesondere kann hierbei ein Session Token und/oder eine Telefonnummer gesendet werden. Beispielsweise kann hier die Servereinrichtung 2 im Schritt des Sendens S9.1 zumindest einen Teil des nutzerspezifischen Datensatzes 8 an einen Signaturdienstanbieter 18 senden. Dieser Schritt des Sendens S9.2 kann zur zwei-Faktor-Authentifizierung dienen. Ferner sendet die Servereinrichtung 2 in einem Schritt S9.2 ein Dokument 20 an den Signaturdienstanbieter 18. Das Dokument 20 kann hierbei in einem vorherigen Schritt, beispielsweise während eines der zuvor beschriebenen Schritte des Verfahrens, von dem Nutzer von dem mobilen Endgerät 4 über das Internet 6 an die Servereinrichtung 2 geschickt worden sein. Alternativ kann die Servereinrichtung 2 das direkte Senden von dem mobilen Endgerät 4 über das Internet 6 an den Signaturdienstanbieter 18 triggern. Der zu verwendende Session Token kann beispielsweise auch an das mobile Endgerät 4 des Nutzers gesendet werden, und die Telefonnummer kann die Telefonnummer des mobilen Endgeräts 4 des Nutzers sein, so dass der Signaturdienstanbieter 18 basierend auf dem erhaltenen Session Token und der erhaltenen Telefonnummer von der Servereinrichtung 2 eine zwei-Faktor-Authentifizierung des Nutzers mit dem mobilen Endgerät 4 durchführen kann.
Gemäß einer weiteren Ausführungsform weist das Verfahren ferner einen Schritt des Erstellens S10 der qualifizierten elektronischen Signatur 10 auf. Hierbei kann der Schritt S10 des Erstellens durch den Signaturdienstanbieter 18 erfolgen. Insbesondere kann in einem Schritt des Verifizierens S10.1 der Nutzer mittels zwei-Faktor-Authentifizierung durch den Signaturdienstanbieter 18 authentifiziert werden. Beispielsweise kann hier ein weiterer Schritt des Versendens S10.2 einer Nachricht an den Nutzer und/oder Verwenden eines Session Tokens zur zwei-Faktor-Authentifizierung des Nutzers durch den Signaturdienstanbieter 18 verwendet werden. Der Signaturdienstanbieter 18 kann hierbei die qualifizierte elektronische Signatur 10 erstellen. Beispielsweise kann die qualifizierte elektronische Signatur 10 mit einem Teil eines asymmetrischen Schlüsselpaares erzeugt werden, insbesondere mit einem privaten Schlüssel 22. Hierbei kann der Signaturdienstanbieter 18 eingerichtet sein, das asymmetrische Schlüsselpaar und insbesondere den privaten Schlüssel 22 zu erzeugen. Der Signaturdienstanbieter 18 kann ein Hardware-Sicherheitsmodul 24 aufweisen, oder zumindest mit einem verbunden sein, und den privaten Schlüssel 22 in dem Hardware-Sicherheitsmodul 24 speichern. Der Signaturdienstanbieter 18 kann eingerichtet sein, nach einer vorbestimmbaren Zeit den auf dem Hardware-Sicherheitsmodul 24 gespeicherten privaten Schlüssel 22 zu löschen. Insbesondere kann der Signaturdienstanbieter 18 eingerichtet sein, bis zum Löschen des privaten Schlüssels 22 auf diesen auf dem Hardware-Sicherheitsmodul 24 zugreifen zu können, gegebenenfalls unter Verwendung einer weiteren zwei-Faktor-Authentifizierung.
Das Verfahren gemäß einer Ausführungsform weist in einem Schritt das Signieren S11 des Dokuments 20 auf. Hierbei wird der Schritt S11 des Signierens von dem Signaturdienstanbieter 18 ausgeführt. Hierzu kann die Servereinrichtung 2 das Dokument 20 entweder direkt von dem mobilen Endgerät 4 an den Signaturdienstanbieter 18 senden lassen, oder ein zuvor auf der Servereinrichtung 2 gespeichertes Dokument 20 an den Signaturdienstanbieter 18 senden. Zum Signieren des Dokuments 20 greift der Signaturdienstanbieter 18 auf den privaten Schlüssel 22 zu. Somit kann der Signaturdienstanbieter 18 mittels des privaten Schlüssels 22 und des Dokuments 20 die elektronische Signatur 10 erstellen und damit das Dokument 20 signieren und somit ein signiertes Dokument 20.1 erstellen. Das signierte Dokument 20.1 kann sodann an weitere Einrichtungen des Systems über das Internet 6 ohne Verzug versendet werden, oder es kann für einen vorbestimmbaren Zeitraum auf einer (nicht weiter gezeigten) Speichereinrichtung und/oder auf dem HSM des Signaturdienstanbieters 18 zwischengespeichert werden.
Das Verfahren weist ferner einen Schritt des Sendens S13 des signierten Dokuments 20.1 auf. Hierbei kann der Signaturdienstanbieter 18 das signierte Dokument 20.1 über das Netzwerk 6 an das mobile Endgerät 4 senden bzw. dieses dem mobilen Endgerät zum Download bereitstellen. Alternativ kann zur Verifikation der erfolgreich erstellten qualifizierten elektronischen Signatur 10 und des erfolgreich signierten Dokuments 20.1 eine Bestätigung an die Servereinrichtung 2 gesendet werden.
Bezugszeichenliste

2: Servereinrichtung
4: (mobiles) Endgerät
6: Internet/Netzwerk
8: nutzerspezifischer Datensatz
10: qualifizierte elektronische Signatur
12: Schnittstelle (der Bank)
14: Bank (-server)
16: Auskunftei (-server)
18: Signaturdienstanbieter
20: Dokument
20.1: signiertes Dokument
22: privater Schlüssel (eines asymmetrischen Schlüsselpaares)
24: Hardware-Sicherheitsmodul
S1: (Schritt) Aufnehmen von personenspezifischen Nutzerdaten
S2: (Schritt) erhalten eines Zugangs zu einem Nutzerkonto
S3: (Schritt) Erfassen von Kontoinformation des Nutzers
S4: (Schritt) Auslösen eines Überweisungsvorgangs
S5: (Schritt) Bestätigen der aufgenommenen Nutzerdaten
S6: (Schritt) Initiieren des Erstellens der qualifizierten elektronischen Signatur
S7: (Schritt) Überprüfen einer Zugehörigkeit der aufgenommen Nutzerdaten zu der erfassten Kontoinformation
S8: (Schritt)Bestätigen der aufgenommenen Nutzerdaten durch Überprüfen auf eine vorhandene Bestätigung der Nutzerdaten
S9.1: (Schritt) Senden zumindest eines Teils des nutzerspezifischen Datensatzes
S9.2: (Schritt) Senden zumindest eines Dokuments
S10: (Schritt) Erstellen der qualifizierten elektronischen Signatur
S11: (Schritt) Signieren des Dokuments
S12: (Schritt) Zurücküberweisen auf das Nutzerkonto
S13: (Schritt) Senden des signierten Dokuments

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

EP 1209579 A1 [0002]

Claims

Verfahren zum Initiieren des Erstellens einer qualifizierten elektronischen Signatur (10), umfassend die Schritte: - Aufnehmen (S1) von personenbezogenen Nutzerdaten durch Nutzereingabe zum Erstellen eines nutzerspezifischen Datensatzes (8), - Erhalten (S2) eines Zugangs zu einem Nutzerkonto, insbesondere einem Bankkonto, durch Eingabe von Zugangsdaten durch den Nutzer, - Auslösen (S4) eines Überweisungsvorgangs vom Nutzerkonto auf ein vorbestimmtes Konto unter Verwendung einer zwei-Faktor-Authentifizierung, - Bestätigen (S5) der aufgenommenen Nutzerdaten, wenn der Überweisungsvorgang erfolgreich durchgeführt worden ist, und bei erfolgreicher Bestätigung - Initiieren (S6) des Erstellens der qualifizierten elektronischen Signatur (10) basierend auf dem nutzerspezifischen Datensatz (8).
Verfahren nach Anspruch 1, wobei die Kontoinformation zumindest eines von Kontoinhabername, Payment Service User, PSU, und IBAN umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner einen Schritt des Erfassens (S3) von Kontoinformation des Nutzers durch Ausführen eines Kontozugriffs unter Verwendung der eingegebenen Zugangsdaten,
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erfassens (S3) von zumindest einem Teil der Kontoinformation des Nutzers mittels einer Schnittstelle (12), insbesondere mittels eines Payment Initiation Services, PIS, und/oder eines Account Information Services, AIS, erfolgt.
Verfahren nach Anspruch 2 und 3 und 4, wobei der Schritt des Erfassens (S3) von Kontoinhabername und IBAN mittels einer Schnittstelle (12), insbesondere mittels PIS und/oder AIS, erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erfassens (S3) von zumindest einem Teil der Kontoinformation des Nutzers mittels Direct Access bzw. Scraping erfolgt.
Verfahren nach Anspruch 5 und 6, wobei der Schritt des Erfassens (S3) des PSU mittels Direct Access bzw. Scraping erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei im Schritt des Erfassens (S3) der Kontozugriff mittels Schnittstelle, insbesondere mittels AIS oder PIS, oder mittels Direct Access bzw. Scraping erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erfassens (S3) des PSU mittels einer Schnittstelle (12), insbesondere mittels des PIS und/oder AIS erfolgt und im oder vor dem Schritt des Auslösens (S4) des Überweisungsvorgangs ein neuer Consent erstellt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Erfassens (S3) des PSU mittels Direct Access bzw. Scraping erfolgt und im Schritt des Auslösens (S4) des Überweisungsvorgangs ein bestehender Consent verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Auslösens (S4) des Überweisungsvorgangs mittels Zahlungsauthorisierung durch den Nutzer oder mittels einem zuvor erstelltem Consent freigegeben wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Auslösens (S4) des Überweisungsvorgangs mittels einer Schnittstelle (12), insbesondere des PIS erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei im Schritt des Auslösens (S4) des Überweisungsvorgangs eine PIS-Session erstellt wird, der Nutzer auf eine Webseite einer Bank (14) weitergeleitet wird, sich mittels Eingabe von Zugangsdaten einloggt und den Überweisungsvorgang auslöst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei im Schritt des Bestätigens (S5) der aufgenommenen Nutzerdaten diese mit der erfassten Kontoinformation verglichen werden und der Schritt des Initiierens (S6) bei Übereinstimmen von zumindest Kontoinhabername und IBAN, insbesondere auch PSU, ausgeführt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner einen Schritt des Überprüfens (S7) einer Zugehörigkeit der aufgenommenen Nutzerdaten, insbesondere des Kontoinhabernamens und der IBAN, zueinander durch Vergleich mittels Daten aus einer Auskunftei (16) aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner einen Schritt des Bestätigens (S8) der aufgenommenen Nutzerdaten durch Überprüfen auf eine vorhandene, bereits erfolgte Bestätigung der Nutzerdaten aufweist, welche insbesondere in einer Auskunftei (16) abgespeichert ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner einen Schritt des Sendens (S9.1) zumindest eines Teils des nutzerspezifischen Datensatzes (8) aufweist, insbesondere eines Session Tokens und einer Telefonnummer, zur zwei-Faktor-Authentifizierung an einen Signaturdienstanbieter, insbesondere eine Zertifizierungsstelle, (18), und insbesondere ferner einen Schritt aufweist des Sendens (S9.2) eines Dokuments (20) an den Signaturdienstanbieter (18).
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner einen Schritt des Erstellens (S10) der qualifizierten elektronischen Signatur (10) und einen Schritt des Signierens (S11) des Dokuments (20) aufweist, insbesondere nach dem Schritt des Initiierens (S6) des Erstellens der qualifizierten elektronischen Signatur (10) und basierend auf dem nutzerspezifischen Datensatz (8).
Verfahren nach Anspruch 18, wobei für den Schritt des Erstellens (S10) der qualifizierten elektronischen Signatur (10) und den Schritt des Signierens (S11) der externe Signaturdienstanbieter (18) in Anspruch genommen wird.
Verfahren nach einem der Ansprüche 16 bis 18, wobei der Schritt des Erstellens (S10) der elektronischen Signatur (10) einen Schritt des Verifizierens (S10.1) des Nutzers mittels zwei-Faktor-Authentifizierung umfasst, insbesondere mittels Versendens (S10.2) einer Nachricht an den Nutzer und/oder Verwenden eines Session Tokens, und die erstellte elektronische Signatur (10) als ein privater Schlüssel (22) in einem Hardware-Sicherheitsmodul (24), HSM, gespeichert wird.
Verfahren nach Anspruch 20, wobei im Schritt des Signierens (S11) der private Schlüssel (22), gespeichert auf dem HSM (24), verwendet wird und der Signaturdienstanbieter (18) damit das Dokument (20) signiert.
Verfahren nach Anspruch 21, wobei das Verfahren ferner einen Schritt des Sendens, insbesondere an eine vorbestimmte Adresse, oder Bereitstellens zum Download (S13) des signierten Dokuments (20.1) aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner einen Schritt des Zurücküberweisens (S12) von dem vorbestimmten Konto auf das Nutzerkonto aufweist, wobei insbesondere der gleiche Betrag zurück überwiesen wird, wie zuvor im Schritt des Auslösens (S4) des Überweisungsvorgangs überwiesen worden ist.
Servereinrichtung, welche eingerichtet ist, das Verfahren zum Initiieren des Erstellens einer qualifizierten elektronischen Signatur nach einem der vorrangehenden Ansprüche auszuführen.