defining a federated messaging and trust infrastructure for secure and reliable exchange of data...
TRANSCRIPT
Defining a federated messaging and trust infrastructure for secure and reliable exchange of data
Kenneth BengtssonOASIS Business Document Exchange (BDX) TC
19th UN/CEFACT ForumGeneva, 17 April 2012
www.oasis-open.org
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
BDX background
May 2008PEPPOL project
November 20091st specifications
ready
January 2011OASIS BDX TC
November 2011European LSP
eDelivery convergence
April 2012BDX rechartered
to accept new requirements
PEPPOL’s 4-corner model
PEPPOL’s architecture framework
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
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
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
PEPPOL’s overall architecture
Service Metadata Locator
PEPPOL Certificate Authority
Service Metadata Publisher
PEPPOL Access Point
Service
Central Governance Points
DistributedReplicatedScaledSystems
Basic elements of the PEPPOL infrastructure
PEPPOL scenario
Company ACompany B
Country A
Country B
Operator 1
Company C
Operator 2
BusDox
SML Registry
Access point, VAN 1
Access point 2, Operator 2
Transport properties• Secure• ReliableProfile properties• Transport + QoS
Invoice
Public agency D
• Key: CompanyC
SMP point: • SMP point
de•
http://smp.de/
SMP Registry
Endpoint: • Access point
2•
http://ap2.de/
• Key: CompanyC
• Doc: Invoice• Profile:
Peppol
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
BACKUP SLIDES
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
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
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