OSCI 2 Erkenntnisse fr Anpassungen aus laufenden Projekten

OSCI 2 – Erkenntnisse für Anpassungen aus laufenden Projekten national und EUEbene Jörg Apitzsch

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

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

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

EU-Projekte - Konvergenz verwandter Ansätze Interconnect Protocol TS 102 640 „REM“ SOAP Binding eb. MS 3. 0 Bus. Do. X CEN BII 5

EU-LSPs: e. Delivery v Eigebettet in Ziele des e. Goverment Action Plans: Errichtung einer „Connect Europe Facility“ v Ä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 v Bisher nur asynchrone Austauschmuster v e. CODEX u. geplantes BSCC haben auch „e. Interaction“ (synchron) auf der Agenda 6 XTA/EU-“Convergence“: OSCI Erweiterungen/Anpassungen 10. Mai 2012 Name

SPOCS e. Delivery, Design Essentials, Solutions connected § Interop framework interconnects national solutions of different technologies and security features Common exchange Protocol, no Service! Ø Requires absolutely minimal changes for existing solutions Ø Gateway (GW) approach chosen …. 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 s: a 1 Ø „normalized“ Msg; to some extend 6 XML /1 structuring of RFC 5233 e. Mail 0 format ed 0 v 4 o r 6 e p l 2 i p f 0 A o 1 r § Cross realm end entity authentication via SAML „sender P S T g I n i vouches“ ETS Bind P A issued token in the future O Ø Ready to use PEPS (STORK) S D M Ø Other distributed e. IDM systems may be used, if federated (cross. M E R border) trust established § Open to connect to PEPPOL‘s Bus. Dox concept „Universal Identifier Scheme“ Ø Addressing („Participant Identifier“); other keywords may be defined / agreed on (eg. Document. ID, Process. ID) § Adoption of ETSI TS 102 640 (REM evidences) Ø Traceability/ receipting of delivery, provability of communication

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

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

Evidence - Bestandteile 11

Einige Kernfeatures Bus. Dox (PEPPOL) v Ebenfalls WS-Profiling, Gateway-Konzept („Access Point“) v e. Procurement 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 v Adressierung über „Participant Identifier“ (z. B. HREG-Nr. , DUNS…) v 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 e. CODEX / BCSS 12

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

Trust Service Status (Lists) Providers TSP supporting e. Signature Trust Application. Services REM & e. Delivery CSPQ CSPP TSSP SVSP SPSP SSSP C Long Term Storage KC Signature Creation & Validation CAd. ES XAd. ES PAd. ES Signature Creation Devices ASi. C … Cryptographic Suites Guidance SSCD 14 SCD used by TSPs 14 © ETSI 2011. All rights OSCI Transport, Kontext EU-Standardisierung reserved Suites Requirements August 201

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