Ausgangslage OSCI(2) Fokussiert auf Transport, keine Annahmen zum transportierten Inhalt Spezifiziert nur das Protokoll zwischen zwei OSCI-Gateways Lässt das Interface zu nutzenden Endpunkten offen Gegenstand konkreter Implementierung – z.B. Starter Kit „Service Exploration“ (Capabilities/Reqirements): Setzt auf WSDL Endpunkt als generisches Konzept Adresse muss bekannt sein Out of Scope: Endpoint Discovery / Exploration mittels DVDV / S.A.F.E AS, LDAP….. XTA/EU-“Convergence“: OSCI Erweiterungen/Anpassungen 10.Mai 2012 Jörg Apitzsch

XTA „Convenience-Interface“ zu Endpunkten / FV, kapselt Authentisierung, Service Exploration, letztlich auch Transport selbst Leicht zu handhabende generische Konstrukte für EP-Identifiern (logische Adressierung) Transport Reports / Quittungen EP Authentisierung Struktur Payload (letztlich gebunden an Szenario) XTA-WS setzt entspr. Attribute entspr. Transportprotkoll XTA/EU-“Convergence“: OSCI Erweiterungen/Anpassungen 10.Mai 2012 Name

Déjà vue? OSCI2, Rolle „Dispatcher“ Entry Point (z.B. MsgBox) Dispatcher OSCI OSCI EP EP OSCI Entry Point (z.B. MsgBox) OSCI Dispatcher  WS-Strecke   WS-Strecke   WS-Strecke  Kettungen von unabhängigen WS-Szenarien Muss nicht OSCI sein XTA/EU-“Convergence“: OSCI Erweiterungen/Anpassungen 10.Mai 2012 Name

EU-Projekte - Konvergenz verwandter Ansätze Interconnect Protocol TS 102 640 „REM“ SOAP Binding ebMS 3.0 BusDoX CEN BII

EU-LSPs: eDelivery Eigebettet in Ziele des eGoverment Action Plans: Errichtung einer „Connect Europe Facility“ Ähnliche Problematik bei interoperabler Verbindung bestehender Transport-Infrastrukturen über Gateways Generische Konstrukte Logische Adressen („Participant Identifier“) Transport Reports / Quittungen EP Authentisierung Struktur Payload / Message Packaging – gebunden an Profil des jeweiligen Szenarios Gateway konvertiert jeweils zum/vom Interop-Format auf die nationalen Lösungen Bisher nur asynchrone Austauschmuster eCODEX u. geplantes BSCC haben auch „eInteraction“ (synchron) auf der Agenda XTA/EU-“Convergence“: OSCI Erweiterungen/Anpassungen 10.Mai 2012 Name

SPOCS eDelivery, Design Essentials, Solutions connected Interop framework interconnects national solutions of different technologies and security features Requires absolutely minimal changes for existing solutions Gateway (GW) approach chosen Common exchange Protocol, no Service! ….Slovenia, Portugal, Romania, De-Mail, Sweden? … Protocol: ETSI TS 102 640 (REM) SOAP Binding Profile

„Interconnect“ Protocol SOAP(1.2) / WS-* profiling WS-Bricks needed at minimum, as supported by standard frameworks Standard body structures for mapping/carrying payload and related metadata „normalized“ Msg; to some extend XML structuring of RFC 5233 eMail format Cross realm end entity authentication via SAML „sender vouches“ Ready to use PEPS (STORK) issued token in the future Other distributed eIDM systems may be used, if federated (cross-border) trust established Open to connect to PEPPOL‘s BusDox concept „Universal Identifier Scheme“ Addressing („Participant Identifier“); other keywords may be defined / agreed on (eg. DocumentID, ProcessID) Adoption of ETSI TS 102 640 (REM evidences) Traceability/ receipting of delivery, provability of communication Approved 06/11 as: ETSI TS 102 640 REM-MD SOAP Binding Profile

Body: REMDispatch <MetaData> and <Informational> according structuring and terms of RFC 5322 OSCI Transport, Kontext EU-Standardisierung August 201

Specified evidence core components. Syntaxes: XML, ASN.1 and PDF. Rem Evidence Sender and REM-MD related events: original message acceptance/rejection, object relay acceptance/rejection, etc. Recipient related events: delivery/non delivery to recipient, download/non download by recipient, etc. Specified evidence core components. Syntaxes: XML, ASN.1 and PDF. May be individually signed (each one in its own format) or/and collectively signed through a signature. Specified signature profile. Titel - Datum Name

Evidence - Bestandteile

Einige Kernfeatures BusDox (PEPPOL) Ebenfalls WS-Profiling, Gateway-Konzept („Access Point“) eProcurement basiert eher auf gebundener Kommunikation Wohl definierte XML-Dokument, ggf. signiert Standardisierung Format/Semantik bei CEN In Metadata-Tag ausgezeichnet und einem Business-Process zugeordnet Adressierung über „Participant Identifier“ (z.B. HREG-Nr., DUNS…) Address-Resolution über DNS-Indirection: DNS zeigt auf Service Meta Data Publisher (SML) SML liefert „Capabilities“, Adresse Gateway, Tranportprotkoll Ähnelt eher XÖV-Szenarien Konvergenz der unterschiedlichen Ansätze in eCODEX / BCSS

M460: A more comprehensive framework for eSig and trusted services Through The rationalise of the legal framework The rationalise of the standardisation framework The rationalise of the trust framework 2011 2014 …Revision of DIR 1999/93/EC... Feasibility study on IAS Policy Political decision Mandate M460 2011 2014 CD 2010/425/EU updating CD 2009/767/EC on Trusted Lists 2011 2014 today OSCI Transport, Kontext EU-Standardisierung August 201 13 © ETSI 2011. All rights reserved 13

Trust Service Status (Lists) Providers TSP supporting eSignature Trust ApplicationServices CSPQC CSPPKC TSSP SVSP SPSP SSSP REM & eDelivery Long Term Storage Signature Creation & Validation CAdES XAdES PAdES ASiC … Signature Creation Devices Cryptographic Suites Guidance Suites Requirements SSCD SCD used by TSPs OSCI Transport, Kontext EU-Standardisierung August 201 14 © ETSI 2011. All rights reserved 14

Vielen Dank für Ihre Aufmerksamkeit! Jörg Apitzsch +49 421 204 95-39 ja@bos-bremen.de bremen online services GmbH & Co. KG Am Fallturm 9 28359 Bremen, Germany www.bos-bremen.de