Peppol online ws. 3 start and agreements

www.peppol.eu

PEPPOL is an EU co-funded project CIP-ICT PSP-2007 No 224974

PEPPOLWorkshop – START and AgreementsMartin Forsberg, Ecru ConsultingMikael Aksamit, Tickstar AB


The PEPPOL project

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)

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


Any supplier (incl. SMEs) in the EU can communicate electronically with any European contracting authority for all procurement processes.

The PEPPOL Vision

3


eProcurement

PEPPOL is an EU co-funded project CIP-ICT PSP-2007 No 224974Page 5

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


ContractingAuthority

EconomicOperator

AP

SMPSMP

SML

AP

CoordinatingAuthority

RegionalAuthority

Regionaldomain

Regionaldomain

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

2. Definitions

3. Service and Service Levels

4. Technical Standards

5. Regional domain and its specific services and service levels

6. Change Procedures

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

“… 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.”

PEPPOLCommunity Agreement

PEPPOLAP

ProviderAgreement

PEPPOLSMP Provider

Agreement

CoordinatingAuthority

I.e. PEPPOL GB

RegionalAuthorityE.g. VM

SMPProvider

E.g. ITELLA

APProvider

E.g. ITELLA


START – Secure Trusted Asynchronous Reliable Transport


Goals

STARTSecureTrusted 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 ProfileA 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

Company 1(C1)

Company 2(C2)

SMLSMP

START Access Point 1(AP1)

START Access Point 2(AP2)1.

2.

4.3.

3 (5).


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 IntegritySTART 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-VouchesUsed 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-keyTrusted 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…

PEPPOL is an EU co-funded project CIP-ICT PSP-2007 No 224974www.peppol.eu

eProcurementwithout borders in Europe

www.peppol.eu

Peppol online ws. 3 start and agreements

Technology

public management

euwide public eprocurement50

eu contribution

european competitiveness

egovernment dificonsortium

ecru consultingmikael

norwegian agency

agreementsmartin forsberg