Online-Vollmachten - Spezifikation

Transkript

1 Online-Vollmachten - Spezifikation Konvention mis Ergebnis der AG Kurzbeschreibung Dieses Dokument spezifiziert die Schnittstelle zwischen Anmeldeapplikation (z.b. MOA-ID) und dem Online-Vollmachten Service (Mandate Issue Service), das eine on-the-fly Erstellung von elektronischen Vollmachten auf Basis von aufrechten Stellvertretungsverhältnissen in Bestandsregistern ermöglicht. In Folge dessen müssen Vollmachten nicht mehr permanent in der Bürgerkarte der Vertreterin bzw. des Vertreters gespeichert werden müssen. Das Online-Vollmachten Konzept erlaubt somit eine bürgerkartenunabhängige Verwendung von elektronischen Vollmachten. Autor(en): Arne Tauber Projektteam / Arbeitsgruppe Beiträge von: Herbert Leitold Reinhard Posch AG-II Version : TT.MM.JJJJ Abgelehnt von: Fristablauf: TT.MM.JJJJ (Länderangabe bei ablehnender Stellungnahme) Unter-Version : TT.MM.JJJJ Fristablauf: TT.MM.JJJJ (Länderangabe bei ablehnender Stellungnahme) Detail-Version : TT.MM.JJJJ Freigabe: TT.MM.JJJJ (Detailangaben zur Freigabe)

2 Seite 2 / 22 Historie Version Datum Kommentar Autor Finale Spezifikation der ersten Version. Arne Tauber FriendlyName für Online Applikationen ReferenceValue für Signaturbinding Arne Tauber

3 Seite 3 / 22 Begriffsdefinition In Anlehnung an die Begriffsdefinition des ABGB werden in dieser Spezifikation folgende Begriffe festgelegt. Machtgeber oder Vertretene: der Machtgeber ist jene Person in deren Namen eine Handlung gesetzt wird bzw. in deren Namen eingeschritten wird. Der Machtgeber ist im ursprünglichen Besitz der Rechte bzw. Rollen. Machthaber oder Vertreter (Bevollmächtigte): der Bevollmächtigte bzw. Machthaber ist jene Person die in Namen des Machtgebers tätig wird. Auf sie wurden die Rechte bzw. Rollen des Machtgebers per Vollmacht übertragen. Mit dem Übertragen von Rechten bzw. Rollen werden den bisherigen Personen, die Rechte ausüben konnten bzw. im Besitz von Rollen waren diese nicht verändert. Dritte: jene Personen bzw. Organisationen bei denen der Bevollmächtigte in Namen des Machtgebers tätig wird. Dritten wird die Vollmacht zur Prüfung der Berechtigung des Bevollmächtigten vorgelegt. Schlüsselwörter Dieses Dokument verwendet die Schlüsselwörter MUSS, DARF NICHT, ERFORDERLICH, SOLLTE, SOLLTE NICHT, EMPFOHLEN, DARF, und OPTIONAL zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, und OPTIONAL zu handhaben, deren Interpretation in [KEYWORDS] festgelegt ist.

4 Seite 4 / 22 Abkürzungen In diesem Dokument werden die folgenden Abkürzungen verwendet APP BKU E-GovG ERnP ERsB FB MIS MOA-ID MOA-VV SZR SZRB USP ZVR Applikation Bürgerkartenumgebung E-Government Gesetz Ergänzungsregister für natürliche Personen Ergänzungsregister für sonstige Betroffene Firmenbuch Mandate Issue Service Module für Online Applikationen ID Module für Online Applikationen Vollmachten und Vertretungsregelung Stammzahlenregister Stammzahlenregisterbehörde Unternehmensserviceportal Zentrales Vereinsregister

5 Seite 5 / 22 (1) Einleitung Das Konzept elektronischer Vollmachten stellt wesentlich auf die Bindung der Vollmacht an die Bürgerkarte und die Beibringung der Vollmachten durch die VertreterIn ab. Dies ist eine wesentliche Basis und auch im E-Government Gesetz festgelegt 1. Die Konzept der Online- Vollmachten nimmt dies als Grundlage, bringt dabei zusätzlich die Erfahrungen aus der Online- BKU ein, dass nur minimale Voraussetzungen am Client notwendig sind, Dialoge dann auch angepasst an die Anforderungen der eigentlichen Anwendung Server-seitig erstellt werden können. So wird ein Zustelldienst im Benutzerdialog spezifischer auf die Vollmacht hinweisen können, als der allgemeine BKU-Dialog. Prinzipiell baut das Konzept der Online-Vollmachten auf einer on-the-fly Ausstellung elektronischer Vollmachten auf. Das heißt gem. E-GovG beantragt die bzw. der Vertretene unmittelbar bevor die elektronische Vollmacht zur Anwendung gebracht werden soll, deren Eintragung in ihre bzw. seine Bürgerkarte. Voraussetzung dafür ist ein Bestandsnachweis über das aufrechte Bestehen des Stellvertretungsverhältnisses, welcher zuvor der Stammzahlenregisterbehörde (SZRB) vorliegen muss. Aus dieser Perspektive betrachtet entspricht die on-the-fly Ausstellung von elektronischen Vollmachten exakt der bisherigen Praxis der lokalen Verspeicherung der Vollmacht in der BKU. Der einzige Unterschied ist die Zeitdimension, da nunmehr die Ausstellung der Vollmacht sowie deren Anwendung unmittelbar aufeinander folgen. Das E-Government Gesetz sieht zudem die Eintragung der Vollmacht in die Bürgerkarte der Vertreterin bzw. des Vertreters vor, ohne jedoch explizit auf eine permanente Speicherung festzulegen. Daher wird anstelle der persistenten Speicherung der Vollmacht diese durch die Bürgerin bzw. den Bürger unmittelbar nach deren Anwendung verworfen. Dies geschieht implizit durch die Bürgerkartenumgebung sofort oder spätestens nach deren Beendigung (bis zur Beendigung der BKU könnte die Vollmacht sogar im Rahmen der BKU sogar zwischengespeichert bleiben, was bei mehrfacher Verwendung am selben Tag nützlich sein könnte; da die BKU als Teil der Bürgerkarte gesehen werden kann, verletzt dies den gegebenen Rechtsrahmen nicht). 1 Neben der Definition zur Bürgerkarte vor allem in 5(1) E-GovG als Soll die Bürgerkarte für vertretungsweises Handeln verwendet werden, muss auf der Bürgerkarte des Vertreters ein Hinweis auf die Zulässigkeit der Vertretung eingetragen sein. Dies geschieht, indem die Stammzahlenregisterbehörde bei Nachweis eines aufrechten Vollmachtsverhältnisses bzw. Vorliegen gesetzlicher Stellvertretung auf Antrag des Vertreters die Stammzahl des Vertretenen und das Bestehen eines Vollmachtsverhältnisses mit allfälligen inhaltlichen und zeitlichen Beschränkungen auf der Bürgerkarte des Vertreters einträgt. [ ]

6 Seite 6 / 22 (2) Architektur und Prozesse Dieser Abschnitt beschreibt die Architektur und die Prozesse des Online-Vollmachten Service, in weiterer Folge auch Mandate Issue Service genannt. Abbildung 1: Architektur und Prozessablauf des Konzepts Online-Vollmachten Abbildung 1 skizziert das Grundprinzip der on-the-fly Ausstellung. Es wird sowohl der Prozess aus Sicht der/des Vertretenen als auch aus Sicht der Vertreterin bzw. des Vertreters dargestellt. Vorbedingung für jegliche Ausstellung einer elektronischen Vollmacht ist der zuvor hinterlegte und der SZRB (bzw. dem in deren Auftrag agierenden Dienstleister) vorliegende/zugängliche Bestandsnachweis (d.i. der Nachweis über den aufrechten Bestand des Stellvertretungsverhältnisses). Dieser Nachweis kann vorbereitend entweder durch den Vollmachtgeber bzw. Vollmachtgeberin selbst eingebracht worden oder über Einträge in bestehende Register gegeben sein (die Entscheidung über die Akzeptanz von Bestandsquellen liegt bei der SZRB). Bereits heute wird im Falle bilateraler Vollmachten der Bestandsnachweis durch die Vertretene bzw. dem Vertretenen vor Ausstellung der elektronischen Vollmacht beim Service der SZRB hinterlegt.

7 Seite 7 / 22 (2.1) Komponenten Das Online-Vollmachten Konzept umfasst das Zusammenspiel mehrerer individueller als auch zusammenhängender Komponenten. Die in Abbildung 1 dargestellten beteiligten und für diese Spezifikation relevanten Komponenten sind wie folgt: APP: dies ist eine (E-Government) Anwendung, an der sich eine Vertreterin oder Vertreter im Namen einer natürlichen oder juristischen Person vertretungsweise anmelden und anschließend agieren kann. Client (MOA-ID): dies ist die Middleware, die die Anmeldung der Vertreterin oder des Vertreters für eine bestimmte Anwendung (APP) durchführt. Dies kann bpsw. MOA-ID sein. SZR: das Stammzahlenregister stellt die Schnittstellen zu ZMR u. ERnP bereit, um auf Anfrage bereichsspezifische Personenkennzeichen (bpk) und Stammzahlen einer natürlichen Person berechnen zu können. Bilateral: die Stammzahlenregisterbehörde stellt ein Vollmachtenservice zur Verfügung, welches die Eintragung von bilateralen Stellvertretungsverhältnissen zwischen natürlichen Personen in eine Bestandsquelle ermöglicht. Derartige Verhältnisse können sowohl von VertreterIn und Vertretener gelöscht bzw. widerrufen werden. USP: das Unternehmensserviceportal fungiert als Bestandsquelle für die Beauskunftung von aufrechten Stellvertretungsverhältnissen für juristische Personen (z.b. Datenbestand aus Firmenbuch). MIS (Mandate Issue Service): dies ist die Kernkomponente, die durch dieses Dokument im Detail spezifiziert wird. Die Hauptaufgaben bestehen im Auffinden von Stellvertretungsverhältnissen einer bestimmten Person in den angebundenen Bestandsregistern (Bilateral, USP), der Auswahlmöglichkeit einer Vollmacht durch die Vertreterin oder den Vertreter, sowie der Signatur der elektronischen Vollmachtsstruktur und Rückgabe an den Client (MOA-ID). (2.2) Prozess Der grundsätzliche Prozess der Hinterlegung eines Bestandsnachweises für on-the-fly ausgestellte Vollmachten lässt sich am Beispiel bilateraler Vollmachten wie folgt darstellen (gem. Nummerierung in Abbildung 1): a) Die Vertretene bzw. der Vertretene hinterlegt über ein Web-Interface einen Nachweis über den Bestand eines Stellvertretungsverhältnisses zwischen natürlichen Personen. Die Vertretene bzw. der Vertreter muss dazu zustimmen, dass die so zum Ausdruck gebrachte Bevollmächtigung im Bestandsregister bis zu einem Widerruf bzw. bis zum expliziten Löschen gespeichert bleibt. Auf Basis des nunmehr gespeicherten Bestandsnachweises kann mehrfach eine elektronische Vollmacht auf Antrag des Vertretenen ausgestellt werden. b) Das Verwaltungsinterface hinterlegt den so eingebrachten Bestandsnachweis in einer Datenbank, die der SZRB als Bestandsquelle für eine automatische on-the-fly Ausstellung von elektronischen Vollmachten dient.

8 Seite 8 / 22 Wird anstelle derart manuell hinterlegter Bestandsnachweise ein für die SZRB zur Ausstellung von Vollmachten akzeptiertes Register als Quelle für Bestandsnachweise herangezogen z.b. Firmenbuch (via Unternehmenserviceportal - USP), Vereinsregister, etc. so wird die Verwaltung (Eintragung, Löschung etc.) durch das betreffende Basisregister selbst bewerkstelligt. Zudem ist bei diesen Registern das Speichern der Bestandsnachweise kein neuer Umstand. Auf Basis derart hinterlegter Bestandsnachweise für Stellvertretungsverhältnisse kann die onthe-fly Ausstellung von elektronischen Vollmachten wie folgt erfolgen (gem. Nummerierung in Abbildung 1): (1) Die Vertreterin oder der Vertreter greift mit ihrer Bürgerkarte auf eine E-Government Anwendung (APP) zu und wird zum Anmeldeservice weitergeleitet. Im abgebildeten Beispiel entspricht dies bspw. MOA-ID. Im Zuge der Anmeldung gibt sie per Checkbox an, dass sie unter Anwendung eines Stellvertretungsverhältnisses das E-Government Verfahren/Applikation nutzen möchte. Im Zuge der Anmeldung wird in einem ersten Schritt die Personenbindung und das Signaturzertifikat ausgelesen. In einem zweiten Schritt wird anschließend die Signatur durch den Vertreter erstellt. Der zu signierende Text is generisch und die Vertreterin bzw. der Vetreter bestätigt im Auftrag des/der Vertretenen zu handeln. Im Zuge dieser Signatur wird ein sog. Referenz-Wert mitsigniert, der eine eindeutige Bindung der Sigantur mit der später ausgewählten Vollmacht herstellen soll. (2) MOA-ID kontaktiert das Mandate Issuing Service (MIS) über eine Webservice (WS) API. Das MIS-Service wird durch die SZRB (oder einen ihrer Dienstleister) betrieben und ist zur Ausstellung von elektronischen Vollmachten auf Antrag der Vertreterin bzw. des Vertreters zuständig. Im Rahmen dieser Anfrage über MOA-ID die folgenden Parameter: o o o o Personenbindung der Vertreterin bzw. des Vertreters: anhand dieser Daten kann die Vetreterin bzw. der Vertreter eindeutig identifiziert werden und es kann gezielt für diese Person in Bestandsregistern nach aufrechten Stellvertretungsverhältnissen gesucht werden. Signaturzertifikat (optional): anhand des Signaturzertifikats kann das MIS- Service feststellen, ob die Vertreterin oder der Vertreter einer bestimmten Berufsgruppe zugehörig ist (z.b. Anwalt, Notar, Ziviltechniker) oder ob es sich um einen Organwalter handelt. In diesen Fälle muss das MIS-Service zusätzliche Möglichkeiten der Vetretung bei der Vollmachtsauswahl zur Verfügung stellen. Redirect-URL: MOA-ID gibt eine URL mit, damit das MIS-Service die Vertreterin bzw. den Vertreter nach erfolgter Vollmachtsauswahl an eine bestimmte URL (z.b. MOA-ID Servlet) weiterleiten kann. Referenz-Wert: dieser Wert stellt eine eindeutige Bindung zwischen dem Anmeldevorgang des Vertreters und der ausgewählten Vollmacht dar. Der Vertreter muss daher in Zuge der Anmeldung diesen Referenzwert unterzeichnen. o Filter: MOA-ID kann nach bestimmten Vollmachten filter, d.h. es stehen der Vertreterin bzw. dem Vertreter ausschließlich Zustellvollmachten zur Auswahl. (3) Das MIS-Service versucht einen adäquaten Bestandsnachweis für das behauptete Stellvertretungsverhältnis zu finden. Dazu je nach konkreter Konfiguration bedient

9 Seite 9 / 22 sich das Service verschiedener Bestandsquellen (z.b. bilaterales Bestandsregister der SZRB oder Firmenbuch im USP). In der Praxis ist es vorstellbar, dass bspw. aufgrund der Angabe der Vertreterin bzw. des Vertreters alle für sie/ihn im Firmenbuch (Unternehmensregister) vorhandenen Vertretungsverhältnisse retourniert werden (Identifikation der Antragsstellerin als potentielle Vertreterin kann bspw. über bpk erfolgen). Das selbe Prozedere ist auch für andere bzw. alle Bestandsregister/-quellen vorstellbar. (4) Nach Feststellung des Bestands der Stellvertretungsverhältnisses erzeugt das Mandate Issuing Service für jedes Stellvertretungsverhältnis eine elektronische Vollmacht. Das Mandate Issuing Service nimmt dazu Dienste des Stammzahlenregisters in Anspruch, um bspw. die Stammzahl der/des Vertretenen (Anmerkung: dies nur in dem Fall, wenn der/die Vertretene eine natürliche Person ist: die Stammzahl der/des Vertretenen wird im Falle natürlicher Personen nicht mit einem Bestandsnachweis abgelegt) oder die bpk von Mittlern im Falle einer Substitution zu ermitteln. Da das MIS-Service ohnehin im Verantwortlichkeitsbereich der SZRB betrieben wird, ist diese Anforderung leicht umsetzbar. (5) Die so erstellten Vollmachten werden temporär vom MIS-Service in einem sog. Session-Objekt, welches an eine eindeutige Session-ID gebunden ist, verspeichert. Diese Session-ID wird an MOA-ID retourniert. (6) MOA-ID leitet die Vertreterin bzw. den Vertreter zusammen mit dieser Session-ID an das Auswahl-GUI des MIS-Services weiter. Dieses holt das zur Session-ID gehörende Session-Objekt aus dem temporären Speicher und bietet die hinterlegten Stellvertretungsverhältnisse der Vertreterin bzw. dem Vertreter zur Auswahl an. Diese/r kann somit gezielt eine Stellvertretungsverhältniss für die Anmeldung an der Applikation auswählen. Das MIS-Service leitet den Vertreter anschließend wieder zu MOA-ID zurück (an die im ersten MOA-ID Request übermittelte Redirect-URL). (7) MOA-ID kontaktiert erneut das MIS-Service mit der zuvor übermittelten Session-ID. Das MIS-Service konvertiert das von der Vertreterin bzw. dem Vertreter ausgewählte Stellvertretungsverhältnis in ein elektronische Vollmachtsstruktur gemäß [MD], signiert diese elektronisch und retourniert sie an MOA-ID. (8) MOA-ID prüft optional die Vollmacht (falls notwendig, z.b. weil generisch) und setzt den gewohnten Anmeldevorgang fort. Nach erfolgreicher Anmeldung wird die Vollmacht zusammen mit allen anderen Attributen der Anmeldung (bpk, Personenbindung, etc.) an die Applikation übermittelt. Dieses Prinzip ist bei allen Stellvertretungsverhältnissen identisch. Unterschiedlich ist jeweils die Quelle des Bestandsnachweises in Schritt 3. Die folgende Abbildung zeigt den erfolgreichen Anmeldeprozess mittels Vollmacht bei Verwendung von MOA-ID und dem MIS-Service (Stellvertretungverhältnis wird im Beispiel aus dem USP bezogen).

10 Seite 10 / 22 Abbildung 2: Ablaufdiagramm für eine erfolgreiche Anmeldung mittels MOA-ID und dem MIS- Service

11 Seite 11 / 22 (3) Allgemeine Anforderungen Dieser Abschnitt beschreibt allgemeine Anforderungen an das MIS-Service, die nicht in direktem Zusammenhang mit der Webservice oder GUI Schnittstelle für die Vollmachtsauswahl stehen. (3.1) Session-ID und Session-Objekt Die Session-ID, die ein Session-Objekt einer Client Abfrage zuordnet, muss mit einem sicheren Zufallsalgorithmus erzeugt werden, um eine gezielte Berechnung im Rahmen einer Attacke zu verhindern. Ein einer Client-Abfrage zugeordnetes Session-Objekt darf eine maximale Gültigkeit von 5 Minuten besitzen. D.h. in dieser Zeit muss die Vertreterin bzw. der Vertreter eine Vollmacht auswählen und der Client (MOA-ID) diese vom MIS-Service abholen. Ist ein Session-Objekt älter, so werden sämtliche darauf bezogene Informationen aus dem temporären Speicher (Session-Store) des MIS-Service gelöscht. Ein Session-Objekt muss an das SSL Zertifikat des Clients gebunden werden. Eine Abfrage für eine Session-ID und eine darauffolgende Abfrage der ausgewählten Vollmacht darf ausschließlich von ein und demselben Client durchgeführt werden. Damit soll verhindert werden, dass durch eine mittels einer Attacke abgefangene Session-ID zur Abfrage der Vollmacht missbraucht werden kann. Nach erfolgreicher Abfrage der ausgewählten Vollmacht durch den Client muss das Session- Objekt aus dem temporären Speicher gelöscht werden.

12 Seite 12 / 22 (4) Webservice Komponente (WS-API) Dieser Abschnitt beschreibt die Schnittstelle zur Kommunikation zwischen Client-Applikation und Webservice Komponente des MIS-Service. (4.1) Sicherheit und Authentifizierung Die Kommunikation der Webservice Schnittstelle mit dem Client darf ausschließlich über eine hochsichere Verbindung getätigt werden. Es dürfen ausschließlich TLS (Transport Layer Security) [TLS] oder SSLv3 Verbindungen mit dem Stand der Technik sicheren Cipher Suites zugelassen werden. Webservice Clients müssen sich mittels SSL Clientzertifikat gegenüber dem Webservice authentifizieren. Um eine vertrauenswürdige Herkunft des Clients zu garantieren, muss das Zertifikat entweder die Verwaltungs- oder Dienstleistereigenschaft besitzen (siehe [OID]). Das MIS-Service muss eine Webservice Schnittstelle zur Abfrage durch Clients zur Verfügung stellen. Dieses Webservice muss den SOAP 1.1 (über HTTPs) [SOAP] Standard unterstützen und eine WSDL [WSDL] Datei zur vereinfachten Clientabfrage zur Verfügung stellen. Die Angaben, über welche URI das Webservice bzw. die WSDL abgerufen werden können, müssen über die Seiten des Betreibers öffentlich bereitgestellt werden. (4.2) Anfrage Abbildung 3: XML Struktur des Requests für eine Abfrage am MIS-Service Abbildung 3 zeigt die XML Struktur eines Request für die Abfrage am Mandate Issue Service. Dieser Request muss als SOAP Body in der Anfrage enthalten sein. In den folgenden Abschnitten werden nun die zwei unterschiedlichen Anfragemodi beschrieben. Wie im Prozessablauf beschrieben, kann ein Client zunächst eine Session-ID für die Auswahl von Vollmachten beantragen. In einer weiteren Anfrage kann mittels dieser Session-ID die von der Vertreterin bzw. dem Vertreter ausgewählte Vollmacht abgeholt werden.

13 Seite 13 / 22 Session-ID Abfrage Mittels eines Session-ID Requests kann eine Client eine Session-ID beantragen, mit welcher der Client die Vertreterin bzw. den Vertreter an das MIS-Service zur weiteren Vollmachtsauswahl weiterleiten kann. In einem weiteren Schritt kann mittels dieser Session-ID die von der Vertreterin bzw. dem Vertreter ausgewählte und signierte Vollmacht am MIS- Service abgerufen werden. Folgende Kindelemente sind in diesem Fall für das Element MandateIssueRequest definiert: IdentityLink: dies ist ein verpflichtendes Element und muss die Personenbindung der Vertreterin bzw. des Vertreters in Base64 [BASE64] Kodierung enthalten. X509SignatureCertificate: dies ist ein optionales Element. Falls es vorhanden ist, muss es das qualifizierte Signaturzertifikat der Vertreterin bzw. des Vertreters in Base64 Kodierung enthalten. Um die Auswahl einer Vollmacht durch einen Organwalter oder berufsmäßigen Parteienvertreter zu ermöglichen, muss dieses Element vorhanden sein. OAFriendlyName: dies ist ein optionales Element und definiert den Namen der Applikation, der dem Vertreter bei der Auswahl der Vollmacht angezeigt wird. RedirectURL: dies ist ein verpflichtendes Element und muss jene URL enthalten, an welche die Vertreterin bzw. der Vertreter weitergeleitet werden soll, nachdem dieser die Vollmacht am MIS-Service ausgewählt hat. Dies kann bspw. eine Servlet sein, das den Anmeldeprozess nach der Vollmachstauswahl fortsetzt. ReferenceValue: dies ist ein verpflichtenes Element und enthält einen Wert (xs:token) zwischen 10 und 100 Zeichen (Buchstaben bzw. Ziffern), der die Signatur des Vertreters mit der Vollmachtenauswahl verkettet, d.h. der Vertreter muss diesen Wert auf Applikationsseite signieren. Filters: dies ist ein optionales Element. Falls es vorhanden ist, kann über eine (multiple) Angabe von MandateIdentifier Elementen eine Vorauswahl (Selektion) von Vollmachten aktiviert werden. Das MIS-Service sucht somit in den Bestandsregistern ausschließlich nach Vollmachten mit den angegebenen Filterkriterien. Abfrage der vom Vetreter ausgewählten Vollmachten Dieser Request erlaubt die Abfrage der vom Vertreter am GUI des MIS-Service ausgewählten Vollmacht. Folgende Kindelemente sind in diesem Fall für das Element MandateIssueRequest definiert: SessionID: dies ist ein verpflichtendes Element und muss die Session-ID enthalten, die im Session-ID Request im ersten Schritt vom MIS-Service retourniert wurde. (4.3) Antwort

14 Seite 14 / 22 Abbildung 4: XML Struktur der Response für eine Abfrage am MIS-Service Abbildung 4 zeigt die XML Struktur der Antwort für die Abfrage am Mandate Issue Service. Die Struktur muss als SOAP Body in der Antwort enthalten sein. In den folgenden Abschnitten werden nun die unterschiedlichen Antwortmöglichkeiten beschrieben. Erfolgreiche Antwort auf eine Session-ID Abfrage Wenn die Prüfung der Abfrageparameter korrekt war und die Bestandsregister erfolgreich abgefragt werden konnten, so wird vom MIS-Service ein Session-Objekt gebunden an eine Session-ID angelegt. Das Session-Objekt enthält alle in den Bestandsregistern (nach Filterkriterien aussortierten) gefundenen Stellvertretungsverhältnisse. Folgende Kindelemente sind in diesem Fall für das Element MandateIssueResponse definiert: SessionID: dies ist ein verpflichtendes Element und enthält die Session-ID des Session-Objekts, das dem Client zugewiesen wird. GuiRedirectURL: dies ist ein verpflichtendes Element und enthält die URL, an die der Client die Vertreterin bzw. den Vertreter zur Vollmachtsauswahl weiterleiten muss. Dies ist ein GUI-Service, das in der Domäne des MIS-Service betrieben wird. Erfolgreiche Antwort auf eine Abfrage der vom Vertreter ausgewählten Vollmacht Falls der Vertreter an der GUI des MIS-Service erfolgreich eine Vollmacht ausgewählt hat, so wird diese signiert und hinterlegt. Diese Vollmacht wird in dieser Response retourniert. Folgende Kindelemente sind in diesem Fall für das Element MandateIssueResponse definiert: Mandates: dies ist ein verpflichtendes Element und enthält eine Liste von weiteren Mandate Elementen. Das Schema sieht vor, dass ein Vertreter potentiell mehrere Vollmachten auswählen könnte (Im Konzept ist momentan nur eine Vollmacht erlaubt). Jedes Mandate Element enthält eine signierte Vollmacht gemäß der Vollmachtenstruktur [MD] in Base64 Kodierung. Das optionale Attribut ProfessionalRepresentative ist im Falle des Einschreitens eines Organwalters oder

15 Seite 15 / 22 Fehlerfall berufsmäßigen Parteienvertreters gesetzt und enthält die OID der Berufsgruppe, d.h. das Attribut das im Signaturzertifikat der Vertreterin bzw. des Vertreters gesetzt ist. Falls bei der Clientabfrage oder bei der Vollmachtsauswahl durch die Vertreterin bzw. den Vertreter ein Fehler auftritt, so wird die entsprechende Fehlermeldung als XML Struktur an den Client retourniert. Folgende Kindelemente sind in diesem Fall für das Element MandateIssueResponse definiert: Error: enthält die Elemente Code und Info. Code gibt die Fehlernummer (Zahl größer 0) und Info enthält ein textuelle Beschreibung des Fehlers. Abschnitt (5) beschreibt die Fehlercodes im Detail.

16 Seite 16 / 22 (5) Fehlercodes Dieser Abschnitt beschreibt die Fehlerklassen des MIS-Service sowie einige klar definierte Fehlercodes. Die Liste erhebt keinen Anspruch auf Vollständigkeit und kann vom implementierenden MIS-Service erweitert werden. Fehlerklasse 2xx 3xx 5xx Beschreibung Fehler in der Abarbeitung des Clientrequests durch das MIS-Service Fehler bei der Vollmachtsauswahl durch den Vertreter Interner Server Fehler Fehlercode Beschreibung 201 Ungültige Base64 Kodierung der Personenbindung 202 Fehler beim Parsen der Personenbindung 203 Personenbindung ungültig 205 SSL Clientzertifikat enthält keine Verwaltungs- oder Dienstleistereigenschaft 206 Ungültiges Format für Redirect-URL 207 Ungültige Session-ID 208 Unerlaubter Zugriff auf Session Daten 209 Keine ausgewählten Vollmachten für diese Session vorhanden 210 Signaturzertifikat passt nicht zu IdentityLink 211 Fehler beim Lesen des Signaturzertifikats 212 Ungültiges Signaturzertifikat 213 Referenzwert fehlt 214 Referenzwert hat ein ungültiges Format 215 Referenzwert wurde bereits verwendet

17 Seite 17 / Abbruch durch den Benutzer 500 Interner Server Fehler

18 Seite 18 / 22 Referenzen ID Titel Verfasser Datum [KEYWORDS] Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment IETF [TLS] The TLS Protocol V.1.0, IETF RFC 2046 IETF [OID] Object Identifier der öffentlichen Verwaltung (Teil 2 Taxative Definition) Thomas Rössler [SOAP] SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) W3C [WSDL] Web Services Description Language (WSDL) 1.1 W3C [BASE64] The Base16, Base32, and Base64 Data Encodings IETF [MD] Elektronische Vollmachten Spezifikation Thomas Rössler

19 Seite 19 / 22 Anhang A Beispielfolge von Requests/Responses Session-ID Abfrage <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Body> <MandateIssueRequest xmlns=" <IdentityLink>PHNhbWw6QXNzZX...w6QXNzZXJ0aW9uPg==</IdentityLink> <RedirectURL> <ReferenceValue> </ReferenceValue> </MandateIssueRequest> </S:Body> </S:Envelope> Erfolgreiche Antwort auf einen Session-ID Abfrage <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Header/> <S:Body> <MandateIssueResponse xmlns=" xmlns:s=" xmlns:xml=" <SessionID>844fca4e2860c867eefc0e49c67b f68</SessionID> <GuiRedirectURL> </MandateIssueResponse> </S:Body> </S:Envelope> Abfrage der vom Vetreter ausgewählten Vollmachten <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Body> <MandateIssueRequest xmlns=" <SessionID>844fca4e2860c867eefc0e49c67b f68</SessionID> </MandateIssueRequest> </S:Body> </S:Envelope> Erfolgreiche Antwort auf eine Abfrage der vom Vertreter ausgewählten Vollmacht <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Header/> <S:Body> <MandateIssueResponse xmlns=" xmlns:s=" xmlns:xml=" <Mandates> <Mandate ProfessionalRepresentative="false">PD94bWwgd...WFuZGF0ZT4=</Mandate> </Mandates> </MandateIssueResponse> </S:Body> </S:Envelope>

20 Seite 20 / 22 Fehlerfall <?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:s=" <S:Body> <MandateIssueResponse xmlns=" <Error> <Code>301</Code> <Text>Operation canceled by citizen</text> </Error> </MandateIssueResponse> </S:Body> </S:Envelope>

21 Seite 21 / 22 Anhang B MIS Schema <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" xmlns=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="mandateissuerequest" type="mandateissuerequesttype"> <xs:annotation> <xs:documentation>request to MIS</xs:documentation> </xs:annotation> </xs:element> <xs:complextype name="mandateissuerequesttype"> <xs:choice> <xs:sequence> <xs:element name="identitylink" type="xs:base64binary"/> <xs:element name="x509signaturecertificate" type="xs:base64binary" minoccurs="0"/> <xs:element name="redirecturl" type="xs:anyuri"/> <xs:element name="filters" minoccurs="0"> <xs:complextype> <xs:sequence> <xs:element name="mandateidentifiers" minoccurs="0"> <xs:complextype> <xs:sequence maxoccurs="unbounded"> <xs:element name="mandateidentifier" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:sequence> <xs:element name="sessionid" type="xs:string"/> </xs:choice> </xs:complextype> <xs:element name="mandateissueresponse" type="mandateissueresponsetype"> <xs:annotation> <xs:documentation>response from MIS</xs:documentation> </xs:annotation> </xs:element> <xs:complextype name="mandateissueresponsetype"> <xs:choice> <xs:sequence> <xs:element name="sessionid" type="xs:string"/> <xs:element name="guiredirecturl" type="xs:anyuri"/> </xs:sequence> <xs:element name="mandates"> <xs:complextype> <xs:sequence> <xs:element name="mandate" maxoccurs="unbounded"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:base64binary"> <xs:attribute name="professionalrepresentative" type="xs:boolean"> <xs:annotation> <xs:documentation>organwalter oder berufsm. Parteienvertreter</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="error"> <xs:complextype> <xs:sequence> <xs:element name="code" type="xs:positiveinteger"/> <xs:element name="text" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> </xs:complextype>

22 Seite 22 / 22 </xs:schema>