Peppol online ws. 3 start and agreements

PEPPOLWorkshop – START and Agreements
Martin Forsberg, Ecru Consulting
Mikael Aksamit, Tickstar AB

The PEPPOL project
The PEPPOL project is the result of the European Competitiveness and Innovation Programme (CIP) ICT Policy Support Programme (ICTPSP) 2007 and 2009 Call for Proposals
Pilot A objective: Enabling EU-wide public eProcurement
50% EU contribution for achieving interoperability
Coordinated by the Norwegian Agency for Public Management and eGovernment (Difi)
Consortium and scope:
18 beneficiaries from 12 countries
Total budget 30,8 M€
8 work packages, <1.600 person months and 10 M€ on sub-contractors
Project start up: 1 May 2008, duration 48 months*
*Current project duration is 42 months (+6 months extension subject to European Commission's approval)

Any supplier (incl. SMEs) in the EU can communicateelectronically with any European contracting authority for all procurement processes.
The PEPPOL Vision
3

eProcurement

Provider Agreements and Governance

Change of plans
Detailed walk through of the providers agreements will be done on the 9:th of May
This presentation will only give a short introduction
Page 6

Regional
domain
Regional
domain
AP
AP
Contracting
Authority
Economic
Operator
SMP
SMP
SML
Coordinating
Authority
Regional
Authority
Two levels of governance
Provides European wide governance for:
the PEPPOL Technical Standards
the PEPPOL Service Specifications
the PEPPOL SML
the PEPPOL Agreements
Provides regional governance for:
the implementation and use of the transport infrastructure
the legal framework for specific AP and SMP agreements
specific requirements applicable within a domain

PEPPOL Transport Infrastructure Agreements
The aim of the PEPPOL Transport Infrastructure Agreements is to regulate the roles and responsibilities of the actors involved in the governance and operation of the PEPPOL transport infrastructure.
Three separate agreements with a common set of annexes.
Contact points
Definitions
Service and Service Levels
Technical Standards
Regional domain and its specific services and service levels
Change Procedures
The PEPPOL Governance Model and model agreements

Key principles
Inspired by other initiatives, but reflects the uniqueness of the PEPPOL initiative:
An open community where interoperability is achieved through common specification and not point-to-point agreements.
The PEPPOL Transport Infrastructure Agreements provides governance for the PEPPOL Transport Infrastructure based on:
a European wide coordination over all common components of the transport infrastructure;
a regional coordination and supervision of the implementation and use of the transport infrastructure within a domain; and
open and transparent provision of SML, SMP and AP services based on a common set of agreements as well as common definition of services and service levels.

PEPPOL Transport Infrastructure Agreements
PEPPOL
Community Agreement
“… terms and conditions under which the Parties shall provide governance for the PEPPOL Transport Infrastructure.”
A model agreement regulating the “… terms and conditions under which: the PEPPOL AP Provider shall provide the required PEPPOL AP Services; the PEPPOL Regional Authority shall ensure that the services provided by the PEPPOL AP Provider are provided and maintained in a reliable, professional and state of the art manner, in compliance with all applicable laws and all relevant technical specifications, to ensure consistency across the full PEPPOL Transport Infrastructure .”
A model agreement regulating the “… terms and conditions under which: the PEPPOL SMP Provider shall provide the required PEPPOL SMP Services; the PEPPOL Regional Authority shall ensure that the services provided by the PEPPOL SMP Provider are provided and maintained in a reliable, professional and state of the art manner, in compliance with all applicable laws and all relevant technical specifications, to ensure consistency across the full PEPPOL Transport Infrastructure.”
PEPPOL
AP
Provider
Agreement
Coordinating
Authority
I.e. PEPPOL GB
Regional
Authority
E.g. VM
SMP
Provider
E.g. ITELLA
AP
Provider
E.g. ITELLA
PEPPOL
SMP Provider
Agreement

START – Secure Trusted Asynchronous Reliable Transport

Goals
START
SecureTrusted Asynchronous Reliable Transport
A SOAP-based profile that offers secure and reliable delivery of messages between Access Points.
START Access Point (START AP)
Communicates in a peer-to-peer manner with other START APs
Derives endpoints to other START APs through SMP-lookups
Can offer other transport profiles, but MUST always offer START
Restricted usage of standards to achieve interoperability

Goals of START Profile
A single profile that implementers can follow and therefore gain access to the infrastructure
Define a simple, interoperable communications pattern
Ensure messages reliable delivered between Access Points
Ensure confidentiality using transport-level encryption
Ensure integrity and authenticity of received messages by signature validation
Content of transferred messages is opaque for the Access Points

Technology in profile
15
START Profile
A set of well-known standard, to be strictly used to ensure interoperability
SOAP 1.1
WS-Addressing 1.0
WS-Security 1.1
WS-Transfer
WS-ReliableMessaging 1.1
SAML 2.0

Typical flow
SML
SMP
Company 2
(C2)
Company 1
(C1)
2.
START Access Point 2
(AP2)
4.
1.
3.
3 (5).
START Access Point 1
(AP1)

Typical flow
Message is created by C1 and transferred to AP1, containing necessary identifiers
AP1 does a SML/SMP-lookup to find out location of AP2 (where the receiver C2 is located behind)
AP1 prepares any tokens it needs to include in transfer and calculates the SAML 2.0 assertions
AP1 adds identifiers to SOAP headers and signs message
AP1 uses WS-ReliableMessaging and TLS to transfer message to AP2
AP2 can deliver message to C2 in a synchronous or asynchronous manner, in either case a proof-of-delivery needs to be returned at some point to AP1
AP1 log signed proof of delivery

Sequence of a typical flow

Security overview
Timestamp with 5 minutes expiration
Message Authentication and Integrity
START AP Certificate must be included
SAML 2.0 Assertions
Due to the complexity and size of the SOAP-Envelopes, an in-depth analysis will be held during the Face2Face meeting the 18th of April.

Types of SAML Assertions
Sender-Vouches
Used when sender AP itself have authenticated the sender
Sender AP both issues and signs the token, authenticating the senders identity
Receiving AP must trust the sending AP regarding authentication of sender
Holder-of-key
Trusted 3rd parties authenticate the sender on behalf of the sending AP
SAML assertion issued and signed by a 3rd party

Receiving START AP
Page 21
Must validate the message signature and security tokens
Test of validity of period (timestamp expiration)
Trust in certificate issuer
Check revocation status of certificates
In return the receiving START AP must sign and include its certificate in any responses.
Sending AP have the possibility to verify that returned certificate is the same that was included in SMP reply.

SOAP Faults
Page 22
In case of error in the transaction the START AP can return 5 faults
Channel Full Fault
Unknown Endpoint
Security Error
Document Type Not Accepted
Server Error
The detailed information about fault handling in the START specification contains contradictions. A corrigendum will be issued shortly.

Environment
Page 23
Previous version of Metro WS Framework contained a bug!
It is essential to upgrade Metro, to version 2.1
Similar bug may exist in .NET WCF (unconfirmed!)
Environments proven to work
GlassFish 2.1.1 with Metro 2.1, Windows and Linux
Tomcat 6 with Metro 2.1, Linux

About the certificates
Page 24
Three certificates can be issued
START AP Certificate
SMP Certificate
Security Token Service (STS) Certificate
START AP Certificate
Used to authenticate START AP (both sending and receiving)
Can be attached in SMP responses
Can be used to authenticate the sender
SMP Certificate
Used to authenticate response from SMP service
Used for client authentication when managing SML
Security Token Service Certificate
Used in a “holder-of-key”-scenario by a 3rd party

Certificate Hierarchy
Page 25
Hierarchy of certificates
One Root CA
Three Intermediate CAs

Certificate Revocation
Page 26
Certificates are issued by Verisign on behalf of the PEPPOL consortium.
Certificates can be revoked by the issuer
Certificate still looks valid
Needs to be checked against revocation list (usually a mechanism not enabled by default in most application servers)
Can be solved by:
Certificate Revocation List (CRL)
Online Certificate Status Protocol (OCSP)

Questions…

eProcurementwithout borders in Europe
www.peppol.eu

Peppol online ws. 3 start and agreements

by mf_sthlm on Apr 11, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 39

Statistics

Peppol online ws. 3 start and agreements — Presentation Transcript

http://www.tickstar.com	38
http://www.ecru-bi.se	1