1 / 17

Defining a federated messaging and trust infrastructure for secure and reliable exchange of data

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 19 th UN/CEFACT Forum Geneva, 17 April 2012. BDX – Business Document eXchange.

hans
Download Presentation

Defining a federated messaging and trust infrastructure for secure and reliable exchange of data

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. BDX –Business Document eXchange • 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

  3. BDX background

  4. PEPPOL’s 4-corner model

  5. PEPPOL’s architecture framework

  6. Current situation • Many solutions to the same problem • National / regional / local / sector specific / public / private • Big difference in complexity and architecture • Peer-2-peer model • 3-corner models • 4-corner models • Web-based and/or based on machine-2-machine interaction • Many different business models

  7. High-level infrastructure requirements • Secure and reliable • Support for small and medium sized organizations • Trust requirements raise the barrier • Low-latency and availability requirements raise the barrier • Leverage investments in existing infrastructures • Base on existing and proven standards

  8. Achievements • Clear architecture model that fits into existing approaches • Coexists and enhances existing infrastructures and networks • Avoids creating another infrastructure “island” • Scalable and robust - no single point of failure • As few centrally managed parts as possible • Trust in the network • Governance enabled • Low barriers-to-entry

  9. PEPPOL’s overall architecture Service Metadata Locator PEPPOL Certificate Authority Central Governance Points Distributed Replicated Scaled Systems Service Metadata Publisher PEPPOL Access Point Service

  10. Basic elements of the PEPPOL infrastructure

  11. PEPPOL scenario SMP Registry SML Registry Country A Invoice • SMP point: • SMP point de • http://smp.de/ • Key: CompanyC Operator 1 • Key: CompanyC • Doc: Invoice • Profile: Peppol • Endpoint: • Access point 2 • http://ap2.de/ BusDox Access point, VAN 1 Company B Company A Company C • Transport properties • Secure • Reliable • Profile properties • Transport + QoS Country B Access point 2, Operator 2 Operator 2 Public agency D

  12. Roadmap for OASIS BDX

  13. Thank you Kenneth Bengtsson OASIS BDX TC kenneth@alfa1lab.com

  14. Backup Slides

  15. Overall standards used in PEPPOL • DNS • Service Metadata Locator (SML) • HTTP • SMP (HTTP GET) • START and LIME profiles (SOAP transport) • SOAP • START and LIME profiles • WS-Transfer • START and LIME profiles • WS-Security, WS-ReliableMessaging • START profile

  16. Why use a four-corner model? • Connecting existing infrastructures rather than creating a new “island among the islands” • Freedom to choose service provider and avoiding lock-ins • Avoiding the need to connect to multiple providers • The requirements differs a lot between service providers, large companies and SME’s • Trust requirements raise the barrier • The technical solution requires a trusted third-party • Low-latency and availability requirements raise the barrier • Requires hosted services with good SLA • No single transport profile matches all the requirements. The four-corner model caters for this inherent problem

  17. Why is the SMP separate from the Access Point? • Orthogonal • Can use metadata without agreed transport protocol • Can use transport protocol without looking up metadata • e.g. hardcoded endpoints • Allows new protocols to be added • Allows alternate governance models Metadata Transport

More Related