Online-Vollmachten - Spezifikation
|
|
- Andrea Ackermann
- vor 7 Jahren
- Abrufe
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>
Elektronische Vollmachten
Elektronische Vollmachten E-Government Konferenz 2004 2./3. Juni 2004, Wien Inhalt Problemstellung Vertretung nach 5 (1) EGovG Inhalte einer Vollmacht Prüfung Vertretung nach 5 (3) EGovG Ausblick Problemstellung
MehrOnline-Vollmachten. Konzepte, Technik und Ausblick. Dr. Arne Tauber. Graz,
Online-Vollmachten Konzepte, Technik und Ausblick Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Über EGIZ 2005 als gemeinsame Initiative von
MehrDokumentation zur Nutzung des Online Vollmachten Modus in MOA ID
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Dokumentation zur Nutzung des Online Vollmachten Modus in MOA ID DI Klaus
MehrMOA-ID Vollmachten HowTo
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria MOA-ID Vollmachten HowTo Leitfaden zur Integration und Verwendung von
MehrIdentifikationsmodell der österreichischen Bürgerkarte
Identifikationsmodell der österreichischen Bürgerkarte D-A-CH 2005 15. März 2005, Darmstadt Thomas Rössler Über A-SIT Zentrum für sichere Informationstechnologie Austria Gegründet: 1999 Tätigkeiten: Bestätigungsstellen
MehrStammzahlenregister Gateway
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Stammzahlenregister Gateway Spezifikation Version 2.0.0, 18.02.2010 DI
MehrErweiterung Spezifikation Bürgerkarte Auslesen von Infoboxen im Push-Verfahren
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria 1 Erweiterung Spezifikation Bürgerkarte Graz, am 07. Juni 2006 DI Thomas
MehrIdentität und Datenschutz Ein Widerspruch?
Identität und Datenschutz Ein Widerspruch? Tagung: E-Government konkret 18. 11. 2005, Basel Arno.Hollosi@cio.gv.at Motivation E-Government muss... vertrauenswürdig sein sicher sein effizient sein... deshalb
MehrElektronische Vollmachten - Demonstrator
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten - Demonstrator Version 1.0.0, 09.01.2007 DI
MehrIdentität und Rollen im österreichischen Gesundheitswesen:
Identität und Rollen im österreichischen Gesundheitswesen: ehealth-verzeichnisdienst und GDA-Token Dipl.-Ing. Peter Danner 2. Konferenz der e-health-initiative Österreich 26. Januar 2007 Zentrum für sichere
MehrDas Instrument Elektronische Vollmachten
Das Instrument Elektronische Vollmachten e Gov Day 2005 Wien, 14. März 2005 Thomas Rössler Über A-SIT Zentrum für sichere Informationstechnologie Austria Gegründet: 1999 Tätigkeiten: Bestätigungsstelle
MehrDer Projektfahrplan zum Status quo - Konvergenzen mit E-Government
Der Projektfahrplan zum Status quo - Konvergenzen mit E-Government Alexander Kollmann Programm-Management Wien am Version: Präsentation ELGA-G: Inhalte 111. Bundesgesetz: Elektronische Gesundheitsakte-Gesetz
MehrDuale Zustellung. Standardprofile. Version 1.0.0, 14.08.2007. DI Arne Tauber arne.tauber@egiz.gv.at
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Duale Zustellung Version 1.0.0, 14.08.2007 DI Arne Tauber arne.tauber@egiz.gv.at
MehrRevisionsabfrage im Portalverbund
Revisionsabfrage im Portalverbund Konvention PVP-AuditQuery 1.0.0 Ergebnis der AG Kurzbeschreibung: Autor: Beiträge von: In diesem Dokument wird die Schnittstelle spezifiziert, die laut Portalverbundvereinbarung
MehrErfahrungen aus dem eid Großpilotprojekt STORK als Umsetzungshilfe eidas?
Erfahrungen aus dem eid Großpilotprojekt STORK als Umsetzungshilfe eidas? Herbert.Leitold@a-sit.at VISIT 16 Bern 28. Juni 2016 Secure Information Technology Center Austria Bürgerkarte in Österreich Schon
MehrZiel ist es, Dokumente zwischen Anwendungen verschiedener Behörden bzw. Organisationen gesichert und automatisiert auszutauschen.
Leitfaden für Behörden zur Einrichtung eines Postfaches gem. 33 ZustellG für elektronische Zustellungen und Zusendungen im Auftrag von Privaten (Stand März 2016) 1. ALLGEMEINES... 1 2. NUTZEN FÜR DIE VERWALTUNG...
MehrLeitfaden zur Einrichtung eines Postfaches gem. 33 ZustellG 2008 Seite: 1/8
Leitfaden für Behörden zur Einrichtung eines Postfaches gem. 33 ZustellG für elektronische Zustellungen und Zusendungen im Auftrag von Privaten (Stand April 2016) 1. ALLGEMEINES... 2 2. NUTZEN FÜR DIE
MehrAnbindung externer Webanwendung an PDF- AS-WEB 4.0
Dokumentation Anbindung externer Webanwendung an PDF- AS-WEB 4.0 Anbindung einer externen Webanwendung an PDF-AS-WEB 4.0 Version 0.3, 05.06.2014 Andreas Fitzek andreas.fitzek@egiz.gv.at Christian Maierhofer
MehrKopplung des Elektronischen Rechtsverkehrs der Justiz mit der Elektronischen Zustellung Ablaufbeschreibung
Kopplung des Elektronischen Rechtsverkehrs der Justiz mit der Elektronischen Zustellung Ablaufbeschreibung Verfasser: Harald Winter Abteilung: E-DC-AI Tel.: +43/ (0)1 / 711 23-3470 Projekt: ERV-ZUSE Kopplung
MehrSpezifikationen und Voraussetzung
Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze
MehrSpezifikationen und Voraussetzung
Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze
MehrIdentity management mit Hilfe der Bürgerkarte. Waltraut Kotschy Österr. Datenschutzkommission/ Stammzahlenregisterbehörde
Identity management mit Hilfe der Bürgerkarte Waltraut Kotschy Österr. Datenschutzkommission/ Stammzahlenregisterbehörde Relevante use cases Identity management umfasst sehr unterschiedliche Situationen:
MehrElektronische Zustellung Registrierung als Versender
Leitfaden Elektronische Zustellung Registrierung als Versender Anmeldung und Registrierung von Versendern am behördlichen Zustellkopf Version 1.0, 23.05.2013 Arne Tauber Arne.Tauber@egiz.gv.at Zusammenfassung:
MehrGRUDIS RB3 (Schnittstelle MapViewer)
GRUDIS RB3 (Schnittstelle MapViewer) Datum: 7.09.2005 Version: 1.0 Status: Genehmigt Bearbeiter: Markus Lauber Verteiler: Entwickler Fremd-GIS-System Inhaltsverzeichnis 1 Einleitung... 3 1.1 MapViewer...3
MehrUpdate Spezifikation MOA-ID 1.5. Update Spezifikation Module für Online Applikationen - ID
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Update Spezifikation MOA-ID 1.5 Update Spezifikation Module für Online
MehrPersonenbindungsabfrage
Bundesministerium für öffentliche Leistung und Sport Chief Information Office Austria Operative Unit 1 Personenbindungsabfrage 2 3 Protokoll zur Abfrage der Personenbindung beim ZMR durch einen ZDA 4 Dokumentinformation
MehrGrundlagen der Web-Entwicklung INF3172
Grundlagen der Web-Entwicklung INF3172 Web-Services Thomas Walter 16.01.2014 Version 1.0 aktuelles 2 Webservice weitere grundlegende Architektur im Web: Webservice (Web-Dienst) Zusammenarbeit verschiedener
MehrPOTENTIALE AUS REGISTERN DES BM.I MAG. MARKUS POPOLARI SALZBURG, 9. JUNI 2011
POTENTIALE AUS REGISTERN DES BM.I MAG. MARKUS POPOLARI SALZBURG, 9. JUNI 2011 INHALT Wesentliche zentrale Register des BM.I E-Government Use Case Ausblick ZENTRALE REGISTER DES BM.I ÜBERBLICK ZENTRALE
MehrSpezifikation Layout Amtssignatur
Layout Amtssignatur Best Practice las 1.3.0 Ergebnis der AG Kurzbeschreibung Das Dokument legt das Aussehen der Amtssignatur im Detail fest, um einerseits ein einheitliches Auftreten gegenüber den BürgerInnen
MehrKonzept und Spezifikation MOA-ID 1.5. Update Spezifikation Module für Online Applikationen - ID
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Konzept und Spezifikation MOA-ID 1.5 Update Spezifikation Module für
MehrNonstandard Datenbanken
Prof. Dr. V. Linnemann Nils Höller Universität zu Lübeck Institut für Informationssysteme Lübeck, den 02. Februar 2009 Nonstandard Datenbanken Wintersemester 2008/2009 13. Übungsblatt: Probe-Klausur Hinweise:
MehrEine Untersuchung der Funktionen des Apache Wicket Webframeworks
Eine Untersuchung der Funktionen des Apache Wicket Webframeworks Seminararbeit von Olaf Matticzk 1 15.01.2016 (c) by synaix 2016 synaix...your business as a service. Agenda 1. Einleitung 2. Webanwendungen
MehrE-Government XML Strukturen für Antragsdaten
E-Government XML Strukturen für Antragsdaten Konvention xml-a 1.1.0 Entwurf öffentlich Kurzbeschreibung: Das vorliegende Papier standardisiert Antragsdaten im E- Government. Es wird eine Übersicht über
MehrSignatur-Workshop. Warum neue Signaturformate? Arne Tauber Wien,
Signatur-Workshop Warum neue Signaturformate? Wien, 05.12.2013 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Elektronische Signaturen 2000 2013
MehrERsB Ergänzungsregister für sonstige Betroffene Eine Dienstleistung des Finanzministeriums
Josef Makolm ERsB Ergänzungsregister für sonstige Betroffene Eine Dienstleistung des Finanzministeriums 2006 02 17 IRIS2006 Wien josef.makolm@bmf.gv.at Wozu? nicht natürliche Personen 2 - keine Firmen
MehrPDF-AS 4.0 Hands-On Workshop
PDF-AS 4.0 Hands-On Workshop Wien, 09.12.2014 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz » Signaturformate» Signaturblock» PDF-AS 4.0 Inhalt»
MehrXSD - XML Schema Definition
XSD - XML Schema Definition Definieren von XML-Dokumenten Michael Dienert 15. September 2016 Inhaltsverzeichnis 1 Was sind XSD Dateien und warum soll man das lernen? 1 1.1 XSD Dateien und Anwendungen....................
MehrZUSE Push Protokoll. Spezifikation. Version 1.0.0, 24.01.2008. DI Arne Tauber arne.tauber@egiz.gv.at
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria ZUSE Push Protokoll Spezifikation Version 1.0.0, 24.01.2008 DI Arne Tauber
MehrElektronische Dokumente über Web-GUI beziehen
Eidgenössisches Finanzdepartment EFDt Bundesamt für Informatik und Telekommunkation BITI Lösungszentrum Elektronische Dokumente über Web-GUI beziehen Benutzerhandbuch Projektname: e-dec Version: 0.8 Datum:
MehrWebservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste
Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene
MehrWhitepaper Lucene 2.0
Whitepaper Lucene 2.0 BüroWARE/WEBWARE Pervasive Inhalt Was ist Lucene 2.0?... 2 Systemvoraussetzungen für Lucene 2.0... 2 Aktivierung von Lucene 2.0 nach Update von 5.3/5.4 auf 5.5x.... 3 Allgemeine Einstellungen
Mehr2a) Rekursion (zugeschnitten auf Anfrage) (C) Prof. E. Rahm Universität Leipzig
2a) Rekursion (zugeschnitten auf Anfrage) WITH RECURSIVE Hat-Kugellager-als-UT(T) ( SELECT OTNR FROM STRUKTUR // liefert alle Teile in die Kugellager direkt WHERE UTNR = E // eingehen (im Bsp. also C)
MehrAnleitung zur Fleet & Servicemanagement Evatic Schnittstelle
Anleitung zur Fleet & Servicemanagement Evatic Schnittstelle Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Hinweise zur Verbindungseinrichtung zum Evatic Server... 3 3 Konfiguration der docuform
MehrTechnische Richtlinie
Seite 1 von 18 www.bundesanzeiger.de BSI Technische Richtlinie Bezeichnung: De-Mail BSI Technische Richtlinie Anwendungsbereich: Bezeichnung: Kürzel: De-Mail Identitätsbestätigungsdienst Interoperabilitätsspezifikation
MehrElektronischer Datennachweis
Elektronischer Datennachweis Novelle des 17 Abs. 2 E-GovG Datenbeschaffung durch die Behörde Christian Herwig Krems, April 2011 christian.herwig@bka.gv.at Überblick & Navigation Aktuelles und Allgemeines
MehrAnforderungen Bürgerkarten-Umgebung
Bundesministerium für öffentliche Leistung und Sport Chief Information Office Austria IKT-Stabsstelle des Bundes 1 2 Anforderungen Bürgerkarten-Umgebung 3 4 5 Anforderungen an die Bürgerkarten-Umgebung
Mehr1 von 8. (1) Die Personenbindung für Bürgerkarten wird von der Stammzahlenregisterbehörde vorgenommen.
1 von 8 %81'(6*(6(7=%/$77 )h5',(5(38%/,.g67(55(,&+ -DKUJDQJ $XVJHJHEHQDP0lU] 7HLO,, 9HURUGQXQJ 6WDPP]DKOHQUHJLVWHUYHURUGQXQJ±6W=5HJ9 9HURUGQXQJ GHV %XQGHVNDQ]OHUV PLW GHU 7lWLJNHLWHQ GHU 6WDPP]DKOHQUHJLVWHUEHK
MehrDokumentation der REST- Schnittstelle des Funk- Sensorsystem GesySense. Gesytec GmbH Pascalstr. 6 D Aachen
Dokumentation der REST- Schnittstelle des Funk- Sensorsystem GesySense Gesytec GmbH Pascalstr. 6 D 52076 Aachen Tel. +(49) 24 08 / 9 44-0 FAX +(49) 24 08 / 9 44-100 e-mail: info@gesytec.de www.gesytec.de
MehrXML Schema S 2010/2011 a W _d Seite 1 h
XML Schema Seite 1 XML Schema unique Zeigt an, dass ein Element/Attribut in einem bestimmten Bereich eindeutig sein muss:
MehrCARM-Server. Users Guide. Version 4.65. APIS Informationstechnologien GmbH
CARM-Server Version 4.65 Users Guide APIS Informationstechnologien GmbH Einleitung... 1 Zugriff mit APIS IQ-Software... 1 Zugang konfigurieren... 1 Das CARM-Server-Menü... 1 Administration... 1 Remote-Konfiguration...
MehrHinweise zur Bedienung der Schnittstelle DRK-DLDB in ADSYS Ausbildungsverwaltung
Hinweise zur Bedienung der Schnittstelle DRK-DLDB in ADSYS Ausbildungsverwaltung Bearbeiter : Jens Fürstenberg Datum : 20.05.2015 DSE Software-Entwicklung DSE Software-Entwicklung Tel: 06151 / 373777 Inhaltsverzeichnis
MehrESTOS XMPP Proxy
ESTOS XMPP Proxy 4.1.12.22953 4.1.12.22953 1 Willkommen zum ESTOS XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Diagnose... 6 1.4 Proxy Dienst... 6 1.5 Server-Zertifikat...
MehrESTOS XMPP Proxy
ESTOS XMPP Proxy 4.1.18.27533 4.1.18.27533 1 Willkommen zum ESTOS XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Diagnose... 6 1.4 Proxy Dienst... 6 1.5 Server-Zertifikat...
MehrZeiterfassung für Projekte. SOAP-Schnittstelle. Juli 2013 Version 4.7
Weil Zeit Geld ist Zeiterfassung für Projekte SOAP-Schnittstelle Juli 2013 Version 4.7 provantis IT Solutions GmbH Siemensstr. 1 71254 Ditzingen Tel. +49 (0)7156/43623-0 Fax. +49 (0)7156/43623-11 zep@provantis.de
MehrD#32058 Spezifikation UPOC DM V2
Autor: CodX Software AG Sinserstrasse 47 CH-6330 Cham www.codx.ch Version: 12.5.2011 File: Vertraulich. Alle Rechte vorbehalten. Die Informationen dieses Dokuments oder dieses Dokument selber dürfen nicht
MehrDie Warenkorbfunktion (workbasket)
Beschreibung der Komponente zur integration eines Warenkorbs in die Anwendung Table of contents 1 Allgemein...2 2 Körbe speichern und laden...3 3 Aufgelöstes XML oder beliebige weitere Metadaten im Korb...
MehrJava und XML 2. Java und XML
Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003
MehrHandbuch Xlive FILE ROUTER Intrexx Konfiguration
Handbuch Xlive FILE ROUTER Intrexx Konfiguration Release 2.0.1 Änderungen und Irrtümer vorbehalten 2009 Computer-live ohg Stand: 10.03.2009 1 / 22 Inhaltsverzeichnis 1 Vorbereitung/Anpassung Intrexx-Applikation...
MehrSchnittstellenbeschreibung
Schnittstellenbeschreibung Erstellung von personalisierten PDF-Dokumenten zum Thema Grundlagenwissen zu Finanzinstrumenten Autoren: Jan Zeskowski, Pascal Pakozdi Version: 1.3 Datum: 16. März 2016 fundsware
MehrOracle Fusion Middleware Überwachung mit Oracle BAM
Oracle Fusion Middleware Überwachung mit Oracle BAM Schlüsselworte Monitoring, BAM, Fusion Middleware Einleitung Markus Lohn esentri AG Ettlingen Oracle BAM wird vor allem für das fachliche Überwachen
MehrIT-Sicherheit Kapitel 11 SSL/TLS
IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)
MehrDokumentation. CleverReach Modul für Joomla!
Dokumentation CleverReach Modul für Joomla! CleverReach Modul für Joomla! Version 1.0 Seite 1 von 9 Inhalt Informationen zu diesem Dokument... 2 Änderungsnachweis... 2 Ergänzende Dokumente... 2 Einleitung...
MehrSC-Ware e-rechnung an den Bund
SC-Ware e-rechnung an den Bund Allgemeine Informationen SC-Ware stellt mit dem integrierten Programmmodul Edifact/e-Rechnung ab SC-Line Version 2014.1 die Möglichkeit bereit, Ausgangsrechnungen im Format
MehrInterface Spezifikation exotargets LS
Interface Spezifikation exotargets LS Einführung Inhaltsverzeichnis Inhaltsverzeichnis Inhalt 1. Einführung 3 2. History 3 3. Online-Schnittstelle 3 4. Offline-Schnittstelle 6 5. Implementationshinweise
MehrBeschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Demo-Behörde und Fremd-bPK. Dipl.-Ing.
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Demo-Behörde und Fremd-bPK Dipl.-Ing.
MehrDie österreiche Bürgerkarte Technik aus Sicht der Applikation
Die österreiche Bürgerkarte Technik aus Sicht der Applikation Vortrag im Rahmen des OCG IA Seminars Die Bürgerkarte nur ein e-government-instrument? Wien, 25. 04. 2003 Arno.Hollosi@cio.gv.at inhalt Modell
MehrMag. Wolf-Dieter Auer, Teamleiter E-DC-AI Tel.: 01/ ,
Mag. Wolf-Dieter Auer, Teamleiter E-DC-AI Tel.: 01/71123-882909, wolf-dieter.auer@brz.gv.at DI Christoph Enzinger, E-DC-AI Tel.: 01/71123-882359, christoph.enzinger@brz.gv.at E-DC-AI ist das Team im Unternehmensbereich
MehrXML Schema 2016 S h_da S Seite 1
XML Schema Seite 1 XML/Schema: Strukturen Dokumentinstanz Dokumenttyp Wellformed Valid Dokumentstrukturdefinition mit XML/Schema XML Document Type Definition Seite 2 XML Dokument Instanz XML-Deklaration
MehrWissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider
Wissenschaftliche Vertiefung Web Services Esslingen, 22. Januar 2016 Agenda 1. Einführung 2. Serviceorientierte Architektur 3. SOAP Web Service 4. Standards und Protokolle von SOAP Web Services 5. Bewertung
MehrErläuterungen zu Darstellung des DLQ-Datenportals
Erläuterungen zu Darstellung des DLQ-Datenportals Definition zum Datenportal Das DLQ-Datenportal (DP) definiert fachliche Schnittstellen für den Datenaustausch zwischen verschiedenen Kommunikationspartnern.
MehrBlackBerry Dynamics einrichten - Android
Status Vorname Name Funktion Datum DD-MM-YYYY Erstellt: V. De Riggi Junior Network Engineer 07.09.2017 12:31:16 V. De Riggi Unterschrift Handwritten signature or electronic signature (time (CET) and name)
MehrInhaltsverzeichnis. Open-Xchange Authentication & Sessionhandling
Open-Xchange Authentication & Sessionhandling Version Date Author Changes 1.0 28.08.2006 Stephan Martin Initiale Version 1.1 29.08.2006 Marcus Klein Details Authentication via JSON 1.2 04.09.2006 Stephan
Mehr3. Web Service Security 3.1 WS-Security. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit
XML- und Webservice- Sicherheit 3. Web Service Security 3.1 WS-Security Gliederung 1. SOAP 2. WS-Security: Der SOAP Security Header 3. Security Tokens in WS-Security S 4. XML Signature in WS-Security 5.
MehrTicketing mit ServiceNow Kurzanleitung
Bearbeitungs-Datum: 07.03.2017 Version: 2.1 Dokument-Name: Dokument-Status: Klassifizierung: Ersteller: ServiceNow Benutzerhandbuch.docx Freigegeben Standard DV Bern AG DV Bern AG Nussbaumstrasse 21, 3000
MehrDBLAP2 Kurzbeschreibung
DBLAP2 Kurzbeschreibung Prüfungswesen Funktionalitäten für die Prüfungsorganisation Funktionalitäten für Prüfungsleiter / Kantonsverantwortliche Funktionalitäten für Chefexperten Autor Marc Fuhrer Version
MehrSZR 3.0 Anwendungsdokumentation. private Organisationen. extern
Anwendungsdokumentation für extern vom 31.01.2017 Inhaltsverzeichnis 1 Historie / Versionen dieses Dokumentes... 3 2 Allgemeines... 3 3 Anfrageinformationen... 7 4 bpk-abfrage... 11 5 SOAP-Faultcodes...
MehrXML Schema 2015 S h_da S Seite 1
XML Schema Seite 1 XML/Schema Weiterentwicklung Seit 5. April 2012 gibt es eine Weiterentwicklung von XML Schema: W3C XML Schema Definition Language (XSD) 1.1 Die wichtigsten Neuerungen: Assertions in
MehrPersistenz. Ralf Gitzel
Persistenz Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Grundkonzepte Entity Beans Meine erste Entity Entity-Manager Lernziele Übungsaufgabe 3 Grundkonzepte
MehrVerteilte Systeme: Übung 4
Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist
Mehre-bag Kurzanleitung e-bag Grundfunktionen
BAG-Melk Kurzanleitung Grundfunktionen Autor J. Brandstetter Vertraulich, nur für internen Gebrauch Version 1.1 File: Datum: C:\e-BAG\manual\gundfunktionen\ebag_quick_start.doc 2003-09-17 Grundfunktionen
MehrDokumentation Authentische Strukturdaten
Dokumentation Version 1.1 Version 1.0 Seite 1/18 31.10.2008 Inhaltsverzeichnis 1. Allgemeines...3 1.1 Phasenmodell...3 1.1.1 Phase I...3 1.1.2 Phase II...3 1.1.3 Phase III...3 1.2 Datenaktualität...3 2.
MehrSonstige Assets. Assets über T-SQL Abfragen anlegen
Sonstige Assets Assets über T-SQL Abfragen anlegen TITEL Sonstige Assets AUTOR Docusnap Consulting DATUM 06.10.2017 VERSION 1.0 Die Weitergabe, sowie Vervielfältigung dieser Unterlage, auch von Teilen,
MehrAlwinPro Care Modul Schnittstelle TV-Steuerung
AlwinPro Care Modul Schnittstelle TV-Steuerung Beschreibung AlwinPro Care bietet die Möglichkeit TV für tageweise abzurechnen und stellt für die Freischaltung der Leistung einen Authentifizierungsserver
MehrHIN Client API. Technische Schnittstelle. Version: 1.0 Datum: 01.11.2010 Status: Final
HIN Client API Technische Schnittstelle Version: 1.0 Datum: 01.11.2010 Status: Final Health Info Net AG (HIN) Pflanzschulstrasse 3 8400 Winterthur support@hin.ch www.hin.ch Tel. 0848 830 740 Inhaltsverzeichnis
MehrHTTP- SOAP- Schnittstelle
HTTP- SOAP- Schnittstelle für Brief- und SMS- Versand und Account- Verwaltung Stand: 09. September 2009 Die Nutzung der Schnittstelle unterliegt den Allgemeinen Geschäftsbedingungen der OEKOPOST Deutschland
MehrKurzanleitung zum Handbuch zu RKSV
Kurzanleitung zum Handbuch zu RKSV Initialisierung der manipulationssicheren Registrierkasse Cashhit ab Version 17.1.07.24 RKSV-Schritt-2.docx Seite 1 von 9 Inhaltsverzeichnis 1 Einleitung... 3 2 Vorbereitungen...
MehrWeb-Konzepte für das Internet der Dinge Ein Überblick
Web-Konzepte für das Internet der Dinge Ein Überblick Samuel Wieland sawielan@student.ethz.ch ETH Zürich Seminar Das Internet der Dinge Historisches Tim Berners-Lee Erster Web-Server Bildquelle: Wikimedia
Mehrwww.egiz.gv.at Version MOA-ID ... 1 1.1 1.2 Beschreibung... 1 3.1 3.2 3.3 3.4 3.5 Beispiel
www.egiz.gv.at E-Mail: post@egiz.gv.at t Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 80100 Graz / Austria Automatisiertes MOA-ID Login Beschreibung Version 1.0.0, 01.09.2008
MehrElektronische Vollmachten
www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten Dokumentation Version 0.0.2, 03.10.2007 DI
MehrContainerformat Spezifikation
Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...
MehrÖsterreichische Bürgerkarte Lösungen und Anwendungen
Österreichische Bürgerkarte Lösungen und Anwendungen Herbert Leitold A-SIT Zentrum für Sichere Informationstechnologie Austria ViS!T - 19.-20. Juni 2006 Inhalte Überblick Bürgerkarte(n) Viele Token für
MehrDieser Dialog dient der Anzeige einer empfangenen oder gesendeten Nachricht. Bereich für Nachrichteninhalte und -funktionen
Nachricht anzeigen Dieser Dialog dient der Anzeige einer empfangenen oder gesendeten Nachricht. Der Dialog ist in die drei folgenden Bereiche aufgeteilt: Bereich für Nachrichteninhalte und -funktionen
MehrA-Trust Qualizierte Handy-Signatur REST API
A-Trust Gesellschaft für Sicherheitssysteme im elektronischen Datenverkehr GmbH Landstraÿer Hauptstraÿe 1b The Mall E02 A-1030 Wien https://www.a-trust.at E-Mail: oce@a-trust.at A-Trust Qualizierte Handy-Signatur
MehrAmtliche Mitteilungen EAZW
Eidgenössisches Justiz- und Polizeidepartement EJPD Bundesamt für Justiz BJ Direktionsbereich Privatrecht Eidgenössisches Amt für das Zivilstandswesen EAZW Amtliche Mitteilungen EAZW Antrag auf Eintragung
MehrXML Vorlesung ETHZ SS XML Vorlesung ETHZ, Sommersemester
XML Vorlesung ETHZ, Sommersemester 2006 XML Schema Teil II Erik Wilde 16.5.2006 http://dret.net/lectures/xml-ss06/ 16.5.2006 XML Vorlesung ETHZ SS 2006 1 Übersicht Identity Constraints ID/IDREF in XML
MehrAnleitung Umstieg auf AnA-Web
Anleitung Umstieg auf AnA-Web Dieses Dokument richtet sich ausschließlich an die Nutzer des Angebotsassistenten der e-vergabe (AnA), die bereits vor dem 06.04.2017 registriert waren. Die Anmeldung im neuen
MehrBenutzerhandbuch SaxDVDV
Benutzerhandbuch SaxDVDV Version 5.5.6 Arbeitsgruppe DVDV-Pflegende-Stelle Sachsen Version 5.5.6 vom 05.01.2016 Autor geändert durch Ohle, Maik Telefonnummer 0351/3264-7399 E-Mail saxdvdv@sid.sachsen.de
MehrElektronische Identität und Stellvertretung in Österreich
Elektronische Identität und Stellvertretung in Österreich Arne Tauber, Bernd Zwattendorfer, Klaus Stranacher E-Government Innovationszentrum (EGIZ) {Arne.Tauber, Bernd.Zwattendorfer, Klaus.Stranacher}@egiz.gv.at
MehrDas Unternehmensserviceportal als Identity Provider
Das Unternehmensserviceportal als Identity Provider DI Erich Forsthuber, Bundesministerium für Finanzen ADV egovernment Konferenz 2014, 3. Juni 2014 Zielsetzung des Unternehmensserviceportals Das Unternehmensserviceportal
MehrIUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES Software AG. All rights reserved. For internal use only
IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES 2016 Software AG. All rights reserved. For internal use only DIGITAL BUSINESS APPLICATIONS DRIVE THE DIGITAL BUSINESS Partner Lieferanten Kunden SaaS
Mehr