Ausgangslage OSCI(2) Fokussiert auf Transport, keine Annahmen zum transportierten Inhalt Spezifiziert nur das Protokoll zwischen zwei OSCI-Gateways Lässt.

Präsentation zum Thema: "Ausgangslage OSCI(2) Fokussiert auf Transport, keine Annahmen zum transportierten Inhalt Spezifiziert nur das Protokoll zwischen zwei OSCI-Gateways Lässt."—  Präsentation transkript:

1

2 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

3 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

4 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

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

6 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

7 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, D , Sweden? … Protocol: ETSI TS (REM) SOAP Binding Profile

8 „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 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 (REM evidences) Traceability/ receipting of delivery, provability of communication Approved 06/11 as: ETSI TS REM-MD SOAP Binding Profile

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

10 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

11 Evidence - Bestandteile

12 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

13 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 All rights reserved 13

14 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 All rights reserved 14

15 Vielen Dank für Ihre Aufmerksamkeit!
Jörg Apitzsch bremen online services GmbH & Co. KG Am Fallturm 9 28359 Bremen, Germany