Security Layer 2.0

Der Austausch von Informationen bei der Signaturerstellung erfolgt, gemäß dem Security Layer 2.0 Protokoll, auf Basis des RFC 7159 JavaScript Object Notation (JSON) Data Interchange Formats. Der Austausch von Informationen, welche durch den E-ID Inhaber signiert werden, erfolgt auf Basis der RFC 7515 JSON Web Signature (JWS) Spezifikation.

Nachfolgend befindet sich eine Darstellung der Architektur und Teilnehmer des Security Layer 2.0 Systems.

Abbildung 1: Architektur und Teilnehmer des Security Layer 2.0

Wie in Abbildung 1 dargestellt kommen beim Security Layer 2.0 System mehrere Kommunikationsschnittstellen zum Einsatz.

  • Routingschnittstelle: Dies ist eine generische Schnittstelle, die Basisanforderungen und allgemeine Funktionen spezifiziert, welche von allen Teilnehmern unterstützt werden.
  • Anwendungsschnittstelle: Jene Schnittstelle, mit der ein Service Provider mit dem VDA kommuniziert um Funktionen, welche der VDA zur Verfügung stellt, zu verwenden.
  • Authentifizierungsschnittstelle: Jene Schnittstelle, übert welche ein VDA die Authentifizierung eines Benutzers durchführt.
  • Service Provider-Schnittstelle: Eine Schnittstelle, über welche eine Anwendungssoftware mit einem Service Provider kommuniziert.
  • Benutzer-Schnittstelle:Jene Schnittstelle, über welche der Benutzer mit dem von ihm verwendeten Endgerät installierten Anwendungssoftware, um Funktionen des Service Providers zu verwenden und sich am VDA zu authentifizieren.


Das Security Layer 2.0 Protokoll definiert generische Transportcontainer, welche zur Übertragung von Kommandos der Kommunikationsschnittstellen verwendet werden. Nachfolgend befindet sich ein Beispiel (Abbildung 2) für einen Security Layer 2.0 Transportcontainer (zur besseren Lesbarkeit wurden die Anführungszeichen [„] für String-Werte entfernt):

1) Service 1 -> Service 2: {v=10, reqID=1234545abcedf, payload={name=qualifiedSig, params={……..}}}
2) Service 2 -> Service 1: {v=10, respID=975814zctrb, inResponseTo=1234545abcedf, payload={name=createCADES, result={……..}}}

Abbildung 2: Beispiel Verwendung SL2.0 ohne Redirect zwischen Teilnehmern

Diese Transportcontainer ermöglichen eine Verschachtelung von Kommandos und damit ein komplexes Routing per Redirects zwischen mehreren Teilnehmern. Die nachfolgende Grafik stellt ein komplexeres Beispiel, welches die Möglichkeiten des Routings von Kommandos mithilfe von Verschachtelungen der Kommandos der Routingschnittstelle der Kommunikationsschnittstellen widerspiegelt. Unter diesem Link ist eine genaue Beschreibung des Prozessflusses für die Kommunikation mit Redirect zwischen den Teilnehmern dargestellt: Prozessfluss für die Erstellung einer qualifizierten Signatur (App mit Backend)

Abbildung 3: Beispiel Verwendung SL2.0 mit Redirect

Abbildung 4 stellt ein Beispiel dar, das die Möglichkeiten von Routing-Befehlen widerspiegelt, wenn sowohl das Backend als auch der Client in einer eigenständigen App implementiert sind. Unter diesem Link ist eine genaue Beschreibung des Prozessflusses für die Kommunikation mit Redirect bei einer Standalone App: Prozessfluss für die Erstellung einer qualifizierten Signatur (Standalone App)

Abbildung 4: Routing bei Standalone App