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 2009

1st 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 BDXPEPPOL

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 youKenneth Bengtsson

OASIS BDX TCkenneth@alfa1lab.com

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