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 Report

Transcript 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