www.oasis-open.org Defining a federated messaging and trust infrastructure for secure and reliable exchange of data Kenneth Bengtsson OASIS Business Document Exchange (BDX) TC 19th UN/CEFACT Forum Geneva,
Download ReportTranscript www.oasis-open.org Defining a federated messaging and trust infrastructure for secure and reliable exchange of data Kenneth Bengtsson OASIS Business Document Exchange (BDX) TC 19th UN/CEFACT Forum Geneva,
www.oasis-open.org Defining a federated messaging and trust infrastructure for secure and reliable exchange of data Kenneth Bengtsson OASIS Business Document Exchange (BDX) TC 19th UN/CEFACT Forum Geneva, 17 April 2012 BDX – Business Document eXchange n n n n n Defining specifications for multi-cornered messaging infrastructures Secure and reliable exchange of information Content agnostic Defining both trust and messaging standards Base on existing and proven technologies wherever possible BDX background May 2008 PEPPOL project November 2009 1st specifications ready January 2011 OASIS BDX TC November 2011 April 2012 European LSP eDelivery convergence BDX rechartered to accept new requirements PEPPOL’s 4-corner model PEPPOL’s architecture framework Current situation n Many solutions to the same problem l n Big difference in complexity and architecture l l l l n National / regional / local / sector specific / public / private Peer-2-peer model 3-corner models 4-corner models Web-based and/or based on machine-2-machine interaction Many different business models High-level infrastructure requirements n n Secure and reliable Support for small and medium sized organizations l l n n Trust requirements raise the barrier Low-latency and availability requirements raise the barrier Leverage investments in existing infrastructures Base on existing and proven standards Achievements n n Clear architecture model that fits into existing approaches Coexists and enhances existing infrastructures and networks l n Scalable and robust - no single point of failure l n n n Avoids creating another infrastructure “island” As few centrally managed parts as possible Trust in the network Governance enabled Low barriers-to-entry PEPPOL’s overall architecture Central Governance Points Service Metadata Locator PEPPOL Certificate Authority Distributed Replicated Scaled Systems Service Metadata Publisher PEPPOL Access Point Service Basic elements of the PEPPOL infrastructure PEPPOL scenario Country A Invoice Operator 1 Company B Company A • Key: CompanyC SML Registry SMP point: • SMP point de • http://smp.de/ • Key: CompanyC • Doc: Invoice • Profile: Peppol Access point, VAN 1 BusDox Transport properties • Secure • Reliable Profile properties • Transport + QoS Endpoint: • Access point 2 • http://ap2.de/ SMP Registry Country B Access point 2, Operator 2 Operator 2 Company C Public agency D Roadmap for OASIS BDX PEPPOL specifications and requirements have been submitted • Other European LSPs have submitted requirements as well Gather further requirements and analyze use cases Specifications for a unified architecture for secure and reliable exchange of business documents Thank you Kenneth Bengtsson OASIS BDX TC [email protected] BACKUP SLIDES Overall standards used in PEPPOL n DNS l n HTTP l l n START and LIME profiles WS-Transfer l n SMP (HTTP GET) START and LIME profiles (SOAP transport) SOAP l n Service Metadata Locator (SML) START and LIME profiles WS-Security, WS-ReliableMessaging l START profile Why use a four-corner model? n n Connecting existing infrastructures rather than creating a new “island among the islands” Freedom to choose service provider and avoiding lock-ins l n Avoiding the need to connect to multiple providers The requirements differs a lot between service providers, large companies and SME’s l Trust requirements raise the barrier n l Low-latency and availability requirements raise the barrier n l The technical solution requires a trusted third-party Requires hosted services with good SLA No single transport profile matches all the requirements. The four-corner model caters for this inherent problem Why is the SMP separate from the Access Point? Metadata n n n n n Orthogonal Can use metadata without agreed transport protocol Can use transport protocol without looking up metadata l e.g. hardcoded endpoints Allows new protocols to be added Allows alternate governance models Transport