Presentation from the third online PEPPOL workshop now available. Topics: START protocol and provider agreements.

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

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

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

4. eProcurement

5. Page 5 Provider Agreements and Governance

7. This presentation will only give a short introductionPage 6

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

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

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

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

13. Page 12 START – Secure Trusted Asynchronous Reliable Transport

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

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

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

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

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

19. Sequence of a typical flow

20. Page 19 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.

21. Page 20 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

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

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

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

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

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

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

28. Page 27 Questions…

29. eProcurementwithout borders in Europe www.peppol.eu