EPC e-Mandates e-Operating Model...EPC208-08 e-Operating Model Detailed Specification v1.2 Approved.doc Page 8 - 9 April 2013 0.4 Purpose of Document This document defines the EPC

Conseil Européen des Paiements AISBL– Cours Saint-Michel 30 – B 1040 Brussels Tel: +32 2 733 35 33 Fax: +32 2 736 49 88

Enterprise N° 0873.268.927 www.epc-cep.eu [email protected] © 2012 Copyright European Payments Council (EPC) AISBL:

Reproduction for non-commercial purposes is authorised, with acknowledgement of the source

Doc: EPC208-08 9 April 2013 Version 1.2 Approved EPC

EPC e-Mandates e-Operating Model

Detailed Specification

Abstract This is the Detailed Specification for the development of the EPC e-Operating Model supporting e-Mandates in the SEPA Direct Debit Scheme.

Document Reference EPC208-08

Issue Version 1.2 Approved

Date of Issue 9 April 2013

Reason for Issue Update

Reviewed by EPC

Produced by EPC

Authorised by EPC

Circulation Publicly available

http://www.epc-cep.eu/�

EPC208-08 e-Operating Model Detailed Specification v1.2 Approved.doc Page 2 - 9 April 2013

TABLE OF CONTENTS

0 DOCUMENT INFORMATION .................................................................................................................. 6 0.1 REFERENCES ........................................................................................................................................ 6 0.2 DEFINED TERMS ................................................................................................................................... 7 0.3 CHANGE HISTORY ................................................................................................................................ 7 0.4 PURPOSE OF DOCUMENT ...................................................................................................................... 8

1 MANAGEMENT SUMMARY .................................................................................................................... 9 2 VISION AND OBJECTIVES ...................................................................................................................... 11

2.1 VISION ................................................................................................................................................. 11 2.2 OBJECTIVES ......................................................................................................................................... 11 2.3 READING ROADMAP ............................................................................................................................. 11

3 EPC E-OPERATING MODEL OVERVIEW ........................................................................................... 14 3.1 FOUR CORNER MODEL ......................................................................................................................... 14 3.2 SCOPE .................................................................................................................................................. 14 3.3 E-OPERATING MODEL PARTIES ............................................................................................................ 15 3.4 PRINCIPLES .......................................................................................................................................... 16 3.5 MODEL DESCRIPTION ........................................................................................................................... 17 3.6 MESSAGE FLOWS.................................................................................................................................. 18 3.7 SECURITY ............................................................................................................................................. 27 3.8 ROUTING AND INTEROPERABILITY ....................................................................................................... 34

4 IMPLEMENTATION GUIDELINES ........................................................................................................ 36 4.1 GENERAL REQUIREMENTS .................................................................................................................... 36 4.2 DEBTOR REQUIREMENTS ...................................................................................................................... 38 4.3 CREDITOR REQUIREMENTS ................................................................................................................... 38 4.4 ROUTING SERVICE PROVIDER REQUIREMENTS ..................................................................................... 44 4.5 VALIDATION SERVICE PROVIDER REQUIREMENTS ............................................................................... 52 4.6 DIRECTORY SERVICE REQUIREMENTS .................................................................................................. 68 4.7 CERTIFICATION AUTHORITY REQUIREMENTS ....................................................................................... 69

5 MESSAGE SPECIFICATION .................................................................................................................... 70 5.1 NOTATION CONVENTIONS .................................................................................................................... 70 5.2 EPC E-OPERATING MODEL MESSAGES ................................................................................................ 70 5.3 ERROR CODES ...................................................................................................................................... 85

6 TERMS USED IN THE DOCUMENT ....................................................................................................... 88 ANNEX A XML SCHEMAS ......................................................................................................................... 90

A.1 EOM-COMMON.XSD ................................................................................................................................. 90 A.2 EOM-STATUS.XSD ................................................................................................................................. 93 A.3 EOM-MSG-CRED-TO-RS-001.XSD ....................................................................................................... 94 A.4 EOM-MSG-RS-TO-VS-001.XSD ........................................................................................................... 96 A.5 EOM-MSG-VS-TO-RS-001.XSD ........................................................................................................... 98 A.6 EOM-MSG-RS-TO-CRED-001.XSD ....................................................................................................... 100 A.7 EOM-MSG-CRED-TO-RS-002.XSD ....................................................................................................... 103 A.8 EOM-MSG-RS-TO-VS-002.XSD ........................................................................................................... 105 A.9 EOM-MSG-VS-TO-RS-002.XSD ........................................................................................................... 106 A.10 EOM-MSG-RS-TO-CRED-002.XSD ....................................................................................................... 108


ANNEX B XML MESSAGE SAMPLES ...................................................................................................... 111 B.1 EOM-MSG-CRED-TO-RS-001 ............................................................................................................... 111 B.2 EOM-MSG-RS-TO-VS-001 ................................................................................................................... 111 B.3 EOM-MSG-VS-TO-RS-001 ................................................................................................................... 111 B.4 ERROR EOM-MSG-VS-TO-RS-001 ....................................................................................................... 112 B.5 EOM-MSG-RS-TO-CRED-001 ............................................................................................................... 113 B.6 ERROR EOM-MSG-RS-TO-CRED-001 ................................................................................................... 113 B.7 EOM-MSG-CRED-TO-RS-002 FOR RETRIEVAL OF AN E-MANDATE ....................................................... 114 B.8 EOM-MSG-RS-TO-VS-002 FOR RETRIEVAL OF AN E-MANDATE .......................................................... 115 B.9 EOM-MSG-VS-TO-RS-002 ................................................................................................................... 115 B.10 ERROR EOM-MSG-VS-TO-RS-002 ....................................................................................................... 117 B.11 EOM-MSG-RS-TO-CRED-002 ............................................................................................................... 118 B.12 ERROR EOM-MSG-RS-TO-CRED-002 ................................................................................................... 120 B.13 EOM-MSG-CRED-TO-RS-002 FOR ACKNOWLEDGEMENT OF AN E-MANDATE ....................................... 120 B.14 EOM-MSG-RS-TO-VS-002 FOR ACKNOWLEDGEMENT OF AN E-MANDATE .......................................... 121

ANNEX C RECOMMENDED STRATEGIES FOR BIC RESOLUTIONS ............................................. 122 C.1 ONLINE RESOLUTION............................................................................................................................ 122 C.2 OFFLINE RESOLUTION .......................................................................................................................... 123

ANNEX D CERTIFICATE ENROLMENT REQUIREMENTS ............................................................... 124 D.1 AUTHENTICATION CERTIFICATE FOR ROUTING SERVICE PROVIDERS ................................................... 124 D.2 AUTHENTICATION CERTIFICATE FOR VALIDATION SERVICE PROVIDERS ............................................. 125 D.3 SIGNING CERTIFICATE FOR VALIDATION SERVICE PROVIDERS ............................................................. 127

ANNEX E X.509 CERTIFICATE PROFILES ............................................................................................ 130 E.1 ROUTING SERVICE AUTHENTICATION CERTIFICATE PROFILE ................................................................ 131 E.2 VALIDATION SERVICE AUTHENTICATION CERTIFICATE PROFILE .......................................................... 135 E.3 SIGNING CERTIFICATE PROFILE ............................................................................................................ 139


FIGURES

FIGURE 1: E-MANDATE CONCEPTUAL FOUR CORNER MODEL ........................................................... 14

FIGURE 2: E-OPERATING MODEL .................................................................................................................. 17

FIGURE 3: SIMPLE AUTHORIZATION MESSAGE FLOW .......................................................................... 19

FIGURE 4: MULTIPLE AUTHORIZATIONS MESSAGE FLOW .................................................................. 23

FIGURE 5: SIGNIFICANT STEPS OF THE CERTIFICATE VERIFICATION ............................................ 28

FIGURE 6: ENVELOPING XML SIGNATURE ................................................................................................. 29

FIGURE 7: ELECTRONIC SIGNATURE VERIFICATION ............................................................................ 29

FIGURE 8: PKI AND CERTIFICATES FOR THE E-OPERATING MODEL ............................................... 33

FIGURE 9: E-OPERATING MODEL - OPTIONS FOR DIRECTORY SERVICES. ..................................... 35

FIGURE 10: SIGNIFICANT STEPS OF THE CERTIFICATE VERIFICATION .......................................... 37

FIGURE 11: SEQUENCE DIAGRAM OF THE SINGLE AUTHORIZATION MESSAGE FLOW FOR CREDITORS 40

FIGURE 12: SEQUENCE DIAGRAM OF THE MULTIPLE AUTHORIZATIONS MESSAGE FLOW FOR CREDITORS 40

FIGURE 13: STATE DIAGRAM FOR TRANSACTIONS IN CREDITORS ................................................... 44

FIGURE 14: SEQUENCE DIAGRAM FOR ROUTING SERVICE PROVIDERS ......................................... 45

FIGURE 15: STATE DIAGRAM FOR TRANSACTIONS IN ROUTING SERVICE PROVIDERS ............ 52

FIGURE 16: SEQUENCE DIAGRAM OF THE SINGLE AUTHORIZATION MESSAGE FLOW FOR VALIDATION SERVICE PROVIDERS .............................................................................................................. 54

FIGURE 17: SEQUENCE DIAGRAM OF THE MULTIPLE AUTHORIZATIONS MESSAGE FLOW FOR VALIDATION SERVICE PROVIDERS .............................................................................................................. 55

FIGURE 18: STATE DIAGRAM OF THE SINGLE AUTHORIZATION MESSAGE FLOW FOR TRANSACTIONS IN VALIDATION SERVICE PROVIDERS ........................................................................ 61

FIGURE 19: STATE DIAGRAM OF THE MULTIPLE AUTHORIZATIONS MESSAGE FLOW FOR TRANSACTIONS IN VALIDATION SERVICE PROVIDERS ........................................................................ 68

FIGURE 20: XML SCHEMA MODULES FOR THE EPC E-OPERATING MODEL ................................... 90

FIGURE 21: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-CRED-TO-RS-001 ....................... 94

FIGURE 22: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-VS-001 ............................ 96

FIGURE 23: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-VS-TO-RS-001 ............................ 98

FIGURE 24: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-CRED-001 ....................... 100

FIGURE 25: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-CRED-TO-RS-002 ....................... 103

FIGURE 26: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-VS-002 ............................ 105

FIGURE 27: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-VS-TO-RS-002 ............................ 106

FIGURE 28: GRAPHICAL XML SCHEMA OF MESSAGE EOM-MSG-RS-TO-CRED-002 ....................... 108

FIGURE 29: ONLINE BIC RESOLUTION ......................................................................................................... 122

FIGURE 30: CACHING OF FULL BIC RESOLUTION TABLES ................................................................... 123

FIGURE 31: OFFLINE BIC RESOLUTION ....................................................................................................... 123


TABLES TABLE 1: PROPOSED READING ROADMAP ................................................................................................. 11

TABLE 2: SINGLE AUTHORIZATION MESSAGE FLOW DESCRIPTION ................................................ 20

TABLE 3: MULTIPLE AUTHORIZATIONS MESSAGE FLOW DESCRIPTION ....................................... 24

TABLE 4: DESCRIPTION OF THE E-OPERATING MODEL CERTIFICATES ......................................... 33

TABLE 5: XADES-BES PROFILE FOR THE EPC E-OPERATING MODEL ............................................... 58

TABLE 5: XADES-BES PROFILE FOR THE EPC E-OPERATING MODEL ............................................... 64

TABLE 6: DESCRIPTION OF MESSAGE EOM-MSG-CRED-TO-RS-001 ..................................................... 70

TABLE 7: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-VS-001 ......................................................... 73

TABLE 8: DESCRIPTION OF MESSAGE EOM-MSG-VS-TO-RS-001 ......................................................... 75

TABLE 9: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-CRED-001 ..................................................... 77

TABLE 10: DESCRIPTION OF MESSAGE EOM-MSG-CRED-TO-RS-002 ................................................... 79

TABLE 11: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-VS-002 ....................................................... 80

TABLE 12: DESCRIPTION OF MESSAGE EOM-MSG-VS-TO-RS-002 ....................................................... 81

TABLE 13: DESCRIPTION OF MESSAGE EOM-MSG-RS-TO-CRED-002 ................................................... 83

TABLE 14: ERROR CODES ................................................................................................................................. 85


0 DOCUMENT INFORMATION

0.1 References This section lists external references mentioned in this document. Use of square brackets throughout this document is used to reference documents in this list.

N.º Document Number Title Issued by:

[1] EPC027-07 SEPA Scheme Management Internal Rules EPC

[2] EPC114-06 SEPA Direct Debit Scheme Implementation Guidelines EPC

[3] EPC016-06 SEPA Core Direct Debit – Scheme Rulebook – Annex VII e-Mandates EPC

[4] EPC222-07 SEPA Business to Business Direct Debit – Scheme Rulebook EPC

[5] EPC261-06 Risk Mitigation in the SEPA Direct Debit Scheme EPC

[6] EPC052-08 Customer-to-Bank Security Threat Assessment EPC

[7] EPC292-09 Approval Scheme for EPC Approved CAs EPC

[8] SPTF-029/05 Impact of the EESSI Standards on the European Banking Community EPC

[9] EPC397-08 Customer-to-Bank Security Good Practices Guide EPC

[10] EPC109-08 e-Mandates e-Operating Model - High-level Definition EPC

[11] EPC002-09 SEPA e-Mandates messages definition EPC

[12] ISO 7498-2 Information processing systems – Open Systems Interconnection – Basic Reference Model – Part 2: Security Architecture, 1989 ISO

[13] ISO 9362 Bank Identifier Codes (BIC) ISO

[14] ISO 13616 Financial services - International bank account number (IBAN) -- Part 1: Structure of the IBAN ISO

[15] ISO 20022 Financial Services – Universal Financial Industry Message Scheme ISO

[16] ISO 27000 Information technology – Security techniques – Information security management systems – Fundamentals and vocabulary ISO

[17] ISO 27005 Information technology – Security techniques – Information security risk management ISO

[18] RFC 2560 Internet X.509 Public Key Infrastructure – Online Certificate Status Protocol – OCSP

IETF

[19] RFC 2616 Hypertext Transfer Protocol – HTTP/1.1 IETF

[20] RFC 3339 Date and Time on the Internet: Timestamps IETF

[21] RFC 3986 Uniform Resource Identifier (URI): Generic Syntax IETF

[22] RFC 5246 The Transport Layer Security (TLS) Protocol IETF

[23] RFC 5280 Internet X.509 Public Key Infrastructure – Certificate and Certificate Revocation List (CRL) Profile

IETF

[24] XML Extensible Markup Language (XML) 1.0 W3C

[25] XMLDSIG XML Signature Syntax and Processing W3C

http://www.europeanpaymentscouncil.eu/�










http://www.iso.org/�






http://www.ietf.org/rfc/rfc2560.txt�






http://www.w3.org/TR/2006/REC-xml-20060816/�

http://www.w3.org/TR/xmldsig-core/�


N.º Document Number Title Issued by:

[26] CWA 14167-1 Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures - Part 1: System Security Requirements, 2003

CEN

[27] CWA 14170 Security requirements for signature creation applications, 2004 CEN

[28] CWA 14365-1 Guide on the Use of Electronic Signatures – Part 1: Legal and Technical Aspects, 2004 CEN

[29] TS 101 456 Policy requirements for certification authorities issuing qualified certificates, version 1.2.1 ETSI

[30] TS 102 042 Policy requirements for certification authorities issuing public key certificates, version 1.3.4 ETSI

[31] TS 101 903 XML Advanced Electronic Signatures (XAdES), version 1.3.2 ETSI

[32] TS 102 904 Profiles of XML Advanced Electronic Signatures based on TS 101 903 (XAdES), version 1.1.1 ETSI

[33] IP/08/803 An unlimited source of Internet addresses to be on stream in Europe by 2010

European Commission

[34] Dir.1999/93/EC Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a community framework for electronic signatures

European Council

[35] OECD Broadband Subscriber Criteria OECD

[36] Guidelines for the Issuance and Management of Extended Validation Certificates, version 1.1 CAB Forum

[37] NIST 800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations NIST

0.2 Defined Terms This document refers to various defined terms, which have a specific meaning in the context of this document. Chapter 6 includes a full list of defined terms used in this document.

0.3 Change History

Issue number Dated Reason for revision

v1.0 August 2008 First document

v1.1 2 September 2010

Added Multiple Authorisations Message Flow

XML signature algorithm is RSA with SHA-256

Deleted reference to enrolment process managed by the EPC in section 3.8

v1.2 9 April 2013 Added the EPC Base OID to Annex E

ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14167-01-2003-Jun.pdf�

ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14170-00-2004-May.pdf�

ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14365-01-2004-Mar.pdf�

http://www.etsi.org/�




http://europa.eu/rapid/pressReleasesAction.do?reference=IP/08/803&format=HTML&aged=0&language=EN&guiLanguage=en�

http://europa.eu/rapid/pressReleasesAction.do?reference=IP/08/803&format=HTML&aged=0&language=EN&guiLanguage=en�

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2000:013:0012:0020:EN:PDF�

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2000:013:0012:0020:EN:PDF�

http://www.oecd.org/sti/ict/broadband�

http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf�

http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf�


0.4 Purpose of Document This document defines the EPC e-Operating Model. It takes as a basis the e-Mandates Service Description of the Core SDD [3] and the B2B SDD [4] and builds up an operating model that will be detailed in the following chapters:

• Vision and Objectives – Introduces the Detailed Specification; the context in which it is being developed, the scope of applicability, its vision and objectives.

• EPC e-Operating Model Overview – Documents the EPC e-Operating Model, covering the description of the operating model, the description of the parties of the model, message flows, routing, interoperability and the security concept,

• Implementation Guidelines – Identifies the requirements and procedures to be implemented by each of the participants in the EPC e-Operating Model.

• Message specification – Describes the protocol messages exchanged in the EPC e-Operating Model.


1 MANAGEMENT SUMMARY

The e-Mandate service is an optional feature complementing the SDD Schemes. The process of issuing an e-Mandate will allow Debtors and Creditors to exchange mandates in a fully electronic way, presenting advantages for Debtors, Creditors, Creditor Banks, and Debtor Banks.

The objective of the e-Mandates is to replace the paper in the Mandate Flow, allowing the Debtors to issue, to amend and to cancel a Direct Debit Mandate through electronic means, while the collection process stays the same as in the existing SDD Scheme. A Bank involved in the e-Mandate service may choose to act as Debtor Bank and/or as Creditor Bank for offering the e-Mandate related services.

The Creditors may offer an optional functionality by allowing Debtors to amend and cancel paper based mandates electronically.

The e-Mandate is based on the Four Corner Model of the SDD Scheme and it adds two new entities that play a key role in the e-Mandates flow: the Routing Service and the Validation Service.

To implement the e-Mandate solution, the e-Mandate service description needs to be completed by a set of ISO 20022 XML Standards messages and a technical standard (the EPC e-Operating Model).

The EPC e-Operating Model focuses on applicational data transport over the Internet between the Creditor Websites and Validation Services, through a Routing Service. The requirements and procedures to be implemented by each party on the EPC e-Operating Model are defined in this document, as well with the XML schemas for the data transport and certificate profiles.

The requirements, data transport, security and authentication mechanisms between Debtor and Validation Service are out of scope of this document. The Validation Service is expected to deploy a set of mechanisms coherent with the Debtor Bank security policy.

This model considers that the total transaction time to request an e-Mandate should be acceptable to the Debtor, providing a fluid and responsive user experience. The transport mechanism supports the transmission of account access, data validation (BIC, IBAN, etc) and is prepared for future enhancements such as multiple authorizations.

The EPC e-Operating Model is designed to allow the issuance, amendment and cancellation of e-Mandates with a clear focus on reachability and interoperability between different Routing Service providers and Validation Service providers. In this model, it is necessary to have the support of a Directory Service and Certification Authorities, in order to offer a trusted connection between Routing Services and Validation Services.

Routing Service providers use Directory Services as enablers for reachability to all trusted participant Debtor Banks, while EPC approved Certification Authorities are used to securely qualify legitimate Validation Service providers and Routing Service providers.

Two possible message flows are defined for the EPC e-Operating Model: the Single Authorization Message Flow that is applicable when just a single authorization from an account holder is needed to issue an e-Mandate and the Multiple Authorization Message Flow (MAMF) that is applicable when authorizations from n different account holders are needed to issue an e-Mandate (a typical B2B scenario).

The essential steps of the EPC e-Operating Model are as follows (for the issue of an e-Mandate):

• The Debtor using a browser initiates the creation of an e-Mandate on the Creditor’s Website, by entering all the required elements (including the operational BIC).


• The Creditor Website creates the e-Mandate proposal and submits it to a Routing Service of the Creditor Bank. In order to identify the Validation Service, the Routing Service queries a Directory Service using the BIC provided by the Debtor.

• The Routing Service submits the e-Mandate proposal to the Validation Service of the Debtor Bank. Mutual authentication between the Routing Service and the Validation Service is achieved by using certificates issued according to EPC requirements.

• The Validation Service performs the validation of the BIC, IBAN (if provided) and account access rigths.

• The Debtor is routed from the Creditor’s Website to the Validation Service for the validation of the Debtor’s authenticity.

• The Debtor must identify and authenticate himself according to the instructions received from the Debtor Bank.

• After a successful authentication, the Debtor confirms the e-Mandate and is routed back to the Creditors Website. The signed e-Mandate is delivered to the Creditor through the initial Routing Service.

• The Creditor Website acknowledges the reception of the e-Mandate and confirms this to the Debtor.


2 VISION AND OBJECTIVES

2.1 Vision “The e-Mandate process is an optional feature complementing the Core Scheme1

The e-Mandate service is built upon the e-Operating Model that has the objective of establishing a trusted platform for models with a similar structure implemented over open networks, assuring adequate levels of security and interoperability.

. This process will allow Debtors and Creditors to agree on mandates in a fully electronic way. If an e-Mandate process is offered then each of the process of issuing, amendment and cancellation of e-Mandates must be possible in an electronic way and cannot be offered separately. In addition, the Debtor Bank has an important role in the authentication of (i.e. checking the due authority of the person claiming to be) the Debtor ("validation"). This will allow the complete avoidance of paper administration in the mandate flow, while the collection process stays the same as in the existing Core Scheme.” [3], §1.2.

The e-Operating Model defines a platform to guarantee secure and reliable transactions between parties communicating over the internet. This assurance is achieved through contractual relationships between the parties and their respective banks, and through an infrastructure that provides a trusted environment for the interactions between parties.

The e-Operating Model covers aspects such as guaranteed delivery, non-repudiation, data integrity and encryption of exchanged information as well as authentication of the involved parties and is aligned with the EPC business requirements (e-Mandates Service Description [3] and B2B scheme [4]), rules and best practices.

2.2 Objectives This document is intended for the use of any party that requires a detailed understanding of the EPC e-Operating Model. Although this model is being devised to support e-Mandates, the design has taken into account that it should also support other services based on the four corner model. In this sense, references to e-Mandate throughout this document can be seen in generic terms as an authorization. Thus, whenever an authorization is required, this e-Operating Model can be applied.

2.3 Reading Roadmap The proposed reading Roadmap indicates the importance of each section to each party, since this document is focused on the various implementations that have to be performed. Nevertheless, reading of other sections contributes to a better global understanding of the EPC e-Operating Model. Table 1 indicates the importance of each section to each party.

Table 1: Proposed reading roadmap

Chapter Creditor Routing Service

Validation Service

Directory Service

Certification Authority

3. EPC e-Operating Model Overview X X X X X

4. Implementation Guidelines

4.1 General requirements X X X X X

1 It is also intended for use with the B2B Scheme



Validation Service

Directory Service


4.2 Debtor requirements X

4.3 Creditor requirements X

4.4 Routing Service Provider requirements X

4.5 Validation Service Provider requirements X

4.6 Directory Service requirements X

4.7 Certification Authority requirements X X X

5 Message specification

5.1 Notation Conventions X X X

5.2 EPC e-Operating Model Messages

5.2.1 eom-msg-cred-to-rs-001 X X

5.2.2 eom-msg-rs-to-vs-001 X X

5.2.3 eom-msg-vs-to-rs-001 X X

5.2.4 eom-msg-rs-to-cred-001 X X

5.2.5 eom-msg-cred-to-rs-002 X X

5.2.6 eom-msg-rs-to-vs-002 X X

5.2.7 eom-msg-vs-to-rs-002 X X

5.2.8 eom-msg-rs-to-cred-002 X X

5.3 Error codes X X X

Annex A - XML Schemas

A.1 eom-common.xsd X X X

A.2 eom-status.xsd X X X

A.3 eom-msg-cred-to-rs-001.xsd X X

A.4 eom-msg-rs-to-vs-001.xsd X X

A.5 eom-msg-vs-to-rs-001.xsd X X

A.6 eom-msg-rs-to-cred-001.xsd X X

A.7 eom-msg-cred-to-rs-002.xsd X X

A.8 eom-msg-rs-to-vs-002.xsd X X



Validation Service

Directory Service


A.9 eom-msg-vs-to-rs-002.xsd X X

A.10 eom-msg-rs-to-cred-002.xsd X X

Annex B - XML Message Samples

B.1 eom-msg-cred-to-rs-001 X X

B.2 eom-msg-rs-to-vs-001 X X

B.3 eom-msg-vs-to-rs-001 X X

B.4 Error eom-msg-vs-to-rs-001 X X

B.5 eom-msg-rs-to-cred-001 X X

B.6 Error eom-msg-rs-to-cred-001 X X

B.7 eom-msg-cred-to-rs-002 X X

B.8 eom-msg-rs-to-vs-002 X X

B.9 eom-msg-vs-to-rs-002 X X

B.10 Error eom-msg-vs-to-rs-002 X X

B.11 eom-msg-rs-to-cred-002 X X

B.12 Error eom-msg-rs-to-cred-002 X X

Annex C Recommended Strategies for BIC Resolutions X X

Annex D Certificate Enrolment Requirements

D.1 Authentication Certificate for Routing Service providers X X

D.2 Authentication Certificate for Validation Service providers X X

D.3 Signing Certificate for Validation Service providers X X

Annex E. X.509 Certificate Profiles

E.1 Routing Service authentication certificate profile X X X

E.2 Validation Service authentication certificate profile X X X

E.3 Signing certificate profile X X X X


3 EPC E-OPERATING MODEL OVERVIEW

3.1 Four Corner Model The e-Mandates conceptual model is based on the Four Corner Model of the SDD Scheme, which introduces two new entities: the Routing Service and the Validation Service.

Figure 1: e-Mandate Conceptual Four Corner Model

To implement the e-Mandate conceptual model a technical standard has been designed: the EPC e-Operating Model.

3.2 Scope The EPC e-Operating Model covers exclusively the application data transport over the Internet between the Creditor Websites and Validation Services making use of Routing Services. The messages described on the e-Operating Model will envelop the ISO 20022 XML e-Mandate messages2

The interactions between the Debtor and the Creditor (to the exception of TLS usage in the connections) and the Debtor and the Online Banking / Validation Service are out of scope of this specification. In particular, the means of authentication used by Validation Service to authenticate the Debtor are at the sole discretion of the underlying Debtor Bank.

.

This document only describes the process flow. The liabilities and responsibilities of each party are described in [3] and [4].

2 For the sake of simplicity, the terms e-Mandate and e-Mandate request/proposal will be used throughout this document to refer to the “e-Operating Model messages enveloping the ISO 20022 XML e-Mandate messages”.


The accommodation of the requirements of this specification to particular contexts, environments, architectures or infrastructures is also outside the scope of this specification. Implementing parties must guarantee the deployment of the requirements in such a way as to maintain the overall security, availability and interoperability, applying the best known practices to additional particular procedures and processes.

3.3 e-Operating Model Parties The execution of the e-Mandate service, complementing the SEPA Direct Debit Scheme, involves the following main parties:

• Debtor: “gives the Mandate to the Creditor to initiate Collections. The Debtor’s bank account is debited in accordance with the Collections initiated by the Creditor. By definition, the Debtor is always the holder of the account to be debited” [2]

• Creditor: “receives the Mandate from the Debtor to initiate Collections, which are instructions to receive Funds from the Debtor Bank by debiting the account of the Debtor. On the basis of this Mandate, the Creditor collects the direct debits” [2]

• Creditor Bank: “is the bank where the Creditor's account is held and which has concluded an agreement with the Creditor about the rules and conditions of a product based on the Scheme. On the basis of this agreement, it receives and executes instructions from the Creditor to initiate the Direct Debit Transaction by forwarding the Collection to the Debtor Bank in accordance with the Rulebook.” [2]

• Debtor Bank: “is the bank where the account to be debited is held and which has concluded an agreement with the Debtor about the rules and conditions of a product based on the Scheme. On the basis of this agreement, it executes each Collection of the direct debit originated by the Creditor by debiting the Debtor’s account, in accordance with the Rulebook.” [2]

• Routing Service: “Providers offer this service, in agreement with and on behalf of Creditor Banks, for giving access, by Creditors, to validation services made available by Debtor Banks for the validation of e-Mandates initiated by Debtors through the electronic channels of Creditors. Creditor Banks may provide these routing services themselves.” [3]

• Validation Service: “Providers offer this service in agreement with and on behalf of Debtor Banks for validation of e-Mandate proposals initiated by Debtors through the electronic channels of Creditors and the routing services offered by Creditor Banks. Debtor Banks may provide these validation services themselves.” [3]

In order for the e-Operating Model to fulfil the reachability and security requirements, it is necessary to consider two new parties: the Directory Service providers and the EPC Approved Certification Authorities.

• Directory Service: Providers offer this service in agreement with a Routing Service Provider to enable reachability to all participant Banks with the role of Debtor Bank. The directory must have an update list of all participant Debtor Banks’ operational BICs and the correspondent Validation Service URLs.

• Approved Certification Authorities: PKI Certification Authorities (CAs) that issue certificates for Validation Service providers and Routing Service providers, with extensions that qualify the entities as legitimate Validation Service providers or Routing Service providers. These CAs must present a “Declaration of Compliance” to the EPC.


3.4 Principles The e-Operating Model is based on the following principles, as stated in the e-Mandates EPC e-Operating Model - High-level Definition [10]:

• It is not mandatory for Debtors to use this service, when offered by the Debtor Bank;

• The Debtor must have a commercial agreement with a Creditor and the Creditor must give access to his Website;

• The Debtor must have access to the Online Banking service provided by the Debtor Bank;

• The Debtor’s Bank and the Debtor must have an agreement on the conditions for using the means of authentication;

• The Creditor and the Creditor’s Bank must have an agreement on the conditions for using the Routing Service(s) providers;

• In order to participate, Routing Services must be accredited by Creditor Banks;

• The Creditor Bank must designate one or more Routing Service providers and must have an agreement with each one on the conditions of use;

• In order to participate, Validation Services must be accredited by Debtor Banks;

• The Validation Service will always respond to the Routing Service from which the enquiry was originated.

• The parties defined in the model can be provided by one or more entities, assuming that segregation measurers are in place.

• Each party is allowed to create additional features on top of the model as long as the interoperability is not affected.

• The Validation Service electronically signs the e-Operating Model enveloped message, on behalf of the Debtor if the authentication / authorization means are correctly used.

For technical purposes, the following additional principles are considered:

• In order to participate, Creditors must enrol with a Routing Service acting on-behalf of the Creditor Bank;

• All Routing Services must be able to connect with all e-Mandate Validation Services;

• A Routing Service must be able to connect at least to one Directory Service.


3.5 Model Description

Figure 2: e-Operating Model

The Debtor accesses the Creditor’s Website (flow 1, in Figure 2) using the browser for the completion of the Debtor Information by entering all the required elements (including the Operational BIC).

Afterwards, the Creditor’s Website creates the e-Mandate proposal by adding the Creditor Information to the Debtor Information and submits the e-Mandate proposal to a Routing Service (flow 2). In order to identify the Validation Service URL, the Routing Service queries a Directory Service using the provided Operational BIC.

Using the Validation Service URL of the Debtor Bank, the Routing Service submits the e-Mandate proposal (flow 3) to the Validation Service. The mutual authentication between the Routing Service and the Validation Service is achieved by using certificates issued by EPC Approved Certification Authorities. The Validation Service performs the validation of the BIC, IBAN and account access.

The Debtor is routed from the Creditor’s Website to the Validation Service of the Debtor Bank (flow 4) for the authentication of the Debtor. Alternatively, the Validation Service may assign a unique proposal reference and transmit it through the Routing Service to the Creditor to display it to the Debtor on the website. The Debtor may resume the operation on the Validation Service at a later time by using that reference.

At the Validation Service, the Debtor must identify and authenticate (flow 5) himself according to the instructions received from the Debtor Bank. The Debtor Bank defines and provides the authentication means that the Debtors should use. If multiple authorizations are required for a given account (a typical B2B scenario), the Debtor Bank must gather enough authorizations from the other account holders.

After a successful authentication, the Debtor Bank confirms (flow 6) the result to the Debtor and returns the e-Mandate to the Creditor through the intermediary of the initial Routing Service (flows 7 and 8). The mutual authentication between the Routing Service and the Validation Service is achieved by using certificates issued by EPC Approved Certification Authorities.

The Debtor is routed back to the Creditor’s Website which acknowledges the receipt of the e-Mandate and confirms this to the Debtor (flow 9).


This model applies for all three operations: issuance, amendment and cancellation of e-Mandates.

3.6 Message flows In order to implement the e-Operating Model, it is necessary to describe message flows between the four parties: the Debtor’s Browser (used by the Debtor), the Creditor’s Website, the Routing Service and the Validation Service. Two possible message flows are defined:

• the Single Authorization Message Flow (SAMF) that is applicable when just a single authorization from an account holder is needed to issue an e-Mandate. This message flow is described in section 3.6.1.

• the Multiple Authorization Message Flow (MAMF) that is applicable when authorizations from n different account holders are needed to issue an e-Mandate (a typical B2B scenario and therefore not for inclusion in the Core Scheme). This message flow may also be used when n = 1 in the following example scenarios:

o automatic redirects from the Creditor Website to the Validation Service are undesirable.

o the Debtor is to be given the opportunity to authorize the e-Mandate at a later time (he may not have all its access credentials at the moment).

This message flow is described in section 3.6.2.


3.6.1 Single Authorization Message Flow

The several interactions for the Single Authorization Message Flow are illustrated in Figure 3.

Figure 3: Simple Authorization Message Flow

The message flow is described on Table 2 and applies to all available e-Mandate operations (issuing, amendment and cancellation).


Table 2: Single Authorization Message Flow description

Step Action Service

Description Reference

Data / Message

1

The Debtor using an Internet Browser accesses the Creditor’s Website.

The Debtor must validate that the presented Creditor Information is correct (Creditor Name, Address, etc) and mandatory legal wording are shown.

The Debtor selects the transaction (issuing, amendment or cancellation) and the Creditor’s Website presents a form to collect the Debtor’s information required for the transaction (e.g. operational BIC of the Debtor’s Bank for an e-Mandate issuance). The Website may already have some Debtor information stored and pre-fill some of the fields.

1. Initiation Debtor Info

2

Using the information provided by the Debtor, the Creditor’s Website merges the Debtor data with the required Creditor information to generate the e-Mandate proposal message.

Regardless of the information that is transported for the e-Mandate service, the BIC is a mandatory field for the routing of the message.

The Creditor’s Website URL (CWS URL) must also be included to redirect the Debtor back to the Creditor at a later stage (step 16) along with the exact date and time limit for the whole transaction to be finished before it will be discarded (in the absence of a value, a default 15 minutes timeout must be considered).

The message, along with the CWS URL, is submitted to the Routing Service using the URL and credentials provided by the Creditor Bank (issued by the Routing Service Provider) or directly by the Routing Service Provider.

Creditor credentials may include a certificate, username/password or other secure means provided by the Routing Service.

2. Mandate Request

eom-msg-cred-to-rs-001

3

After verifying the Creditor’s credentials, the Routing Service receives the e-Mandate proposal message and validates that all the required fields are filled-in.

The Routing Service then looks up the Directory Service (either an online request or a cached mapping) to resolve the Operational BIC into the Validation Service URL. The Directory Service provider may request the use of authentication credentials.

The Directory Service provider may request the use of authentication credentials.

The Directory Service returns the Validation Service URL for the provided Operational BIC.

BIC (input), Validation Service URL

4

The Routing Service dispatches the received request to the Validation Service URL indicating that this is an e-Mandate enrolment request.

The Routing Service must present a client certificate issued by an EPC approved CA qualifying it as legitimate Routing Service and the Validation Service must present a server certificate issued by an EPC approved CA qualifying it as a legitimate Validation Service (see section 3.8).

3. Mandate Request

eom-msg-rs-to-vs-001

5 The Validation Service validates the e-Mandate proposal and stores the information.

e-mandate proposal, optype, CWS URL


Step Action Service


Data / Message

6 The Validation Service returns a status code (OK) and a URL specific to this transaction (VS URL), which will be used on step 8/9 to redirect the Debtor’s browser.

eom-msg-vs-to-rs-001

7 The Validation Service response is returned to the Creditor’s Website. eom-msg-rs-to-cred-001

8, 9 The Creditor, which is still holding the control of the Debtor’s browser, performs a redirect to the given Validation Service URL. VS URL

10 The Debtor is redirected from the Creditor’s Website to an authentication screen offered by the Validation Service to the Debtor, in order to authenticate the Debtor.

4. Request authentication means

Authentication form

11

The Debtor enters the authentication credentials agreed with the Debtor Bank The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features ([1] PT-07.03).

Authentication data

12 The Validation Service verifies the provided authentication credentials. Authentication data

13

If the authentication credentials provided are correct and valid, the Validation Service presents an authorization form along with all the mandate data and mandatory legal wording.

The Validation Service will collect the IBAN from the Debtor and any other relevant information for Debtor Banks. The Validation Service can present the accounts for which he is the holder and has direct debit rights.

mandate info, authorization form

14

The Debtor is asked to verify the mandate data (e.g., the accuracy of the Creditor information, for example, name and address) and proceeds with the authorization. The authorization is defined here as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment and cancellation of an e-Mandate.

5. Authorization

Authorization data

15 The Validation Service verifies the authorization and performs an electronic signature of the e-Mandate data on the envelop message.

e-mandate (input), electronically signed e-mandate (output)

16 The Validation Service presents a confirmation message to the Debtor along with the e-Mandate data and a link to the Creditor’s Website (URL provided on step 4)

6. Confirmation

mandate info, CWS URL

17 The Debtor follows the link to the Creditor’s Website. CWS URL

18

The Creditor’s Website recovers the e-Mandate transaction data and sends a request with the e-Mandate request identifier to the arranged Routing Service in order to retrieve the issued e-Mandate.

The Creditor must present the credentials previously arranged with the Routing Service provider (similar to step 2).



Step Action Service


Data / Message

19

The Routing Service dispatches the e-Mandate retrieving request to the same Validation Service URL resolved in step 3, indicating that this is a retrieval operation.



20 The Validation Service returns the electronically signed enveloped message of the e-Mandate to the Routing Service. 7. e-Mandate eom-msg-vs-

to-rs-002

21 The Routing Service performs an electronic signature validation of the enveloped e-Mandate received. e-signed

mandate

22

The Routing Service returns the electronically signed e-Mandate enveloped message to the Creditor’s Website. The Creditor may perform a validation of the e-Mandate enveloped message electronic signature received or rely on the verification previously performed by the Routing Service.

8. e-Mandate eom-msg-rs-to-cred-002

23 The Creditor acknowledges the reception of the e-Mandate. eom-msg-cred-to-rs-002

24

The Creditor’s Website presents a confirmation message along with the e-Mandate data to the Debtor.

The Creditor stores the electronically signed e-Mandate XML file according to national legal requirements.

9. Confirmation mandate info

25 The Routing Service forwards the acknowledgment of the reception of the e-Mandate to the Validation Service. eom-msg-rs-

to-vs-002

The data sets exchanged in each of the steps are the same for all the operations defined for e-Mandates: issuance, amendment and cancellation. However, some of the optional fields defined in the e-Mandate request message (DS-12, [3]; [11]) and the e-Mandate validation message (DS-13, [3]; [11]) may be required for some of the operations.

3.6.2 Multiple Authorizations Message Flow

(Only applicable in the B2B Scheme)

The several interactions for the Multiple Authorizations Message Flow are illustrated in Figure 4.


Figure 4: Multiple Authorizations Message Flow

The message flow is described on Table 3 and applies to all available e-Mandate operations (issuing, amendment and cancellation).


Table 3: Multiple Authorizations Message Flow description

Step Action Service


Data / Message

1

The Debtor using an Internet Browser accesses the Creditor’s Website.

The Debtor must validate that the presented Creditor Information is correct (Creditor Name, Address, etc) and mandatory legal wording are shown.

The Debtor selects the transaction (issuing, amendment or cancellation) and the Creditor’s Website presents a form to collect the Debtor’s information required for the transaction (e.g. operational BIC of the Debtor’s Bank for an e-Mandate issuance). The Website may already have some Debtor information stored and pre-fill some of the fields.

1. Initiation Debtor Info

2

Using the information provided by the Debtor, the Creditor’s Website merges the Debtor data with the required Creditor information to generate the e-Mandate proposal message.

Regardless of the information that is transported for the e-Mandate service, the BIC is a mandatory field for the routing of the message.

The Creditor’s Website URL (CWS URL) must also be included to redirect the Debtor back to the Creditor at a later stage (step 16) along with the exact date and time limit for the whole transaction to be finished before it will be discarded (in the absence of a value, a default 48 hours timeout must be considered ).

The message, along with the CWS URL, is submitted to the Routing Service using the URL and credentials provided by the Creditor Bank (issued by the Routing Service Provider) or directly by the Routing Service Provider.

Creditor credentials may include a certificate, username/password or other secure means provided by the Routing Service.

2. Mandate Request


3

After verifying the Creditor’s credentials, the Routing Service receives the e-Mandate proposal message and validates that all the required fields are filled-in.

The Routing Service then looks up the Directory Service (either an online request or a cached mapping) to resolve the Operational BIC into the Validation Service URL. The Directory Service provider may request the use of authentication credentials.

The Directory Service provider may request the use of authentication credentials.

The Directory Service returns the Validation Service URL for the provided Operational BIC.

BIC (input), Validation Service URL

4

The Routing Service dispatches the received request to the Validation Service URL indicating that this is an e-Mandate enrolment request.


3. Mandate Request


5 The Validation Service validates the e-Mandate proposal and stores the information.

e-mandate proposal, optype, CWS URL


Step Action Service


Data / Message

6 The Validation Service returns a status code (OK) and an identifier code specific to this transaction (VS mandate ID), which will be used by the Debtor later on step 14.


7 The Validation Service response is returned to the Creditor’s Website. eom-msg-rs-to-cred-001

8 The Creditor, which is still holding the control of the Debtor’s browser, displays the VS proposal reference to the Debtor. VS proposal

ref

93 The account holder goes to the Validation Service authentication URL. VS auth URL

10 The account holder is presented with an authentication screen offered by the Validation Service asking for the authentication credentials.

4. Request authentication means

Authentication form

11

The account holder enters the authentication credentials agreed with the Debtor Bank. The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features ([1] PT-07.03).

Authentication data

12 The Validation Service verifies the provided authentication credentials. Authentication data

13

If the authentication credentials provided are correct and valid, the Validation Service asks the account holder to select the e-Mandate request to be authorized. This may be performed by having an input field to enter the VS proposal reference presented in step 8 or a select list from which the account holder can choose one of the pending e-Mandate requests.

[proposals list]

14 The account holder selects the e-Mandate request to be authorized. VS proposal ref

15

The Validation Service presents an authorization form along with all the mandate data and mandatory legal wording.

The account holder is asked to verify the mandate data (e.g., the accuracy of the Creditor information, for example, name and address).

5. Authorization

Authorization data

16

The account holder verifies the mandate data and proceeds with the authorization. The authorization is defined here as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment and cancellation of an e-Mandate.

mandate info, authorization form

17 The Validation Service verifies the authorization and performs an electronic signature of the e-Mandate data on the envelop message.

e-mandate (input), electronically signed e-mandate (output)

3 If multiple authorizations are required for that account (a typical B2B scenario), the Debtor Bank must gather enough authorizations from the other account holders, by repeating steps 9 through 16 (loop).


Step Action Service


Data / Message

18 The Validation Service presents a confirmation message to the Debtor along with the e-Mandate data and a link to the Creditor’s Website (URL provided on step 4)

6. Confirmation

mandate info, CWS URL

19 The Debtor follows the link to the Creditor’s Website. CWS URL

20

The Creditor’s Website recovers the e-Mandate transaction data and sends a request with the e-Mandate request identifier to the arranged Routing Service in order to retrieve the issued e-Mandate.

The Creditor must present the credentials previously arranged with the Routing Service provider (similar to step 2).


21

The Routing Service dispatches the e-Mandate retrieving request to the same Validation Service URL resolved in step 3, indicating that this is a retrieval operation.



22 The Validation Service returns the electronically signed enveloped message of the e-Mandate to the Routing Service. 7. e-Mandate eom-msg-vs-

to-rs-002

23 The Routing Service performs an electronic signature validation of the enveloped e-Mandate received. e-signed

mandate

24

The Routing Service returns the electronically signed e-Mandate enveloped message to the Creditor’s Website. The Creditor may perform a validation of the e-Mandate enveloped message electronic signature received or rely on the verification previously performed by the Routing Service.

8. e-Mandate eom-msg-rs-to-cred-002

25 The Creditor acknowledges the reception of the e-Mandate. eom-msg-cred-to-rs-002

26

The Creditor’s Website presents a confirmation message along with the e-Mandate data to the Debtor.

The Creditor stores the electronically signed e-Mandate XML file according to national legal requirements.

9. Confirmation mandate info

27 The Routing Service forwards the acknowledgment of the reception of the e-Mandate to the Validation Service. eom-msg-rs-

to-vs-002

The data sets exchanged in each of the steps are the same for all the operations defined for e-Mandates: issuance, amendment and cancellation. However, some of the optional fields defined in the e-Mandate request message (DS-12, [3]; [11]) and the e-Mandate validation message (DS-13, [3]; [11]) may be required for some of the operations.


3.7 Security The e-Operating Model design is intended for Internet use, meaning that the interactions between the different parties take place across interlinked public networks. These networks have been subject to a great number and variety of threats during the past years. Banking and e-commerce services provided on the Internet have been specially targeted in recent years given the potential financial benefits that can be gained by the perpetrators. Entities providing these services have been able to adapt and counter these attacks.

The e-Operating Model interconnects a vast number and variety of parties and therefore the capability to respond to threats are unavoidably cumbersome. Thus, the security requirements for this model are raised to a level as to minimize the needs for change when confronted with new threats.

The security mechanisms hereby presented are at two levels: the transport level (section 3.7.1) and the application level (section 3.7.2). The Certification Authorities are the key enablers for those mechanisms (section 3.7.3).

Although the Debtor authentication through the Validation Service is out of scope, the overall risk level of the e-Operating Model still strongly depends on the security measures adopted in those interactions between the Validation Service and the Debtor. The adoption of authentication methods aligned with industry best practices, as found in the EPC document “Customer-to-Bank Security Good Practices Guide” [9] complements the overall security model.

3.7.1 Transport Level Security

The first step towards a secure model is to protect the exchanged data on a host-to-host connection by creating a secure networking channel. This can be achieved by using the TLS protocol [22], which has standard built-in mechanisms to provide:

• Authentication of parties, based on X.509 certificates. The server is always authenticated whereas the client may optionally be authenticated (mutual authentication);

• Confidentiality of data, by performing a symmetric key agreement at session initiation and using that key to cipher the exchanged data. The risk of eavesdropping is mitigated;

• Data Integrity, based on cryptographic hash functions. The risk of tampering is mitigated. The EPC e-Operating model enforces the use of TLS on all connections between Debtors and Creditors, Creditors and Routing Services, Routing Services and Directory Services and Routing Services and Validation Services. The connections between Debtors and Validation Services/Online Banking of Debtor Banks are outside the scope of the EPC e-Operating Model.

The mutual authentication feature of TLS is required between the Routing Services and Validation Services, in order to allow only legitimate Routing Services to access legitimate Validation Services. Due to the absence of a direct contractual relationship between those parties, it is expectable that Routing Services and Validation Services may not know each other prior to the first connection establishment. Therefore, a secure and interoperable mechanism is necessary to allow Routing Services to be able to recognize Validation Services as being SEPA enrolled and legitimate and, reversely, Validation Services to be able to recognize Routing Services as being SEPA enrolled and legitimate.

This objective is accomplished by restricting the set of approved issuing Certification Authorities and by using specific certificate extensions that qualifies the entitled entities as being legitimate participants (Routing Services or Validation Services). The issuing Certification Authority is responsible to comply with the full set of procedures defined in the EPC e-Operating Model which are required for the enrolment of Routing Service and Validation Service providers.


When establishing a TLS session, the authentication is performed during the “handshake”. When the parties present each other their certificates, a verification of the presented certificates must be performed. The certificate verification must follow the general rules described on the RFC 5280 [23], and, if applicable to the certificates presented, an additional step to verify the existence of the EPC e-Operating Model specific policy. The most significant steps of the process are illustrated on Figure 5.

Figure 5: Significant steps of the certificate verification

The minimum version of TLS to be supported is 1.0, but all parties are recommended to migrate to TLS v1.2 as soon as possible (for interoperability purposes, all versions of TLS have mechanisms to provide both forward and backward compatibility).

3.7.2 Application level security

The security measures discussed in Section 3.7.1 are focused on the transport level, providing network security on a host-to-host basis. Additional complimentary measures must be addressed to further increase the overall security of the e-Operating Model. Those measures are targeted to the application level and include:

• Electronic signatures, described in Section 3.7.2.1; • Time accuracy, described in Section 3.7.2.2; • Audit trails, described in Section 3.7.2.3;Error reporting, described in Section 3.7.2.4; • Timeouts, described in Section 3.7.2.5; • Caching of BIC resolutions, described in Section 3.7.2.6.


3.7.2.1 Electronic signatures

The most important security measure at the application level is the binding of electronic signatures4

• Authenticity – a party receiving an electronically signed e-Mandate is able to positively confirm the identity claimed by the source of the e-Mandate.

to e-Mandates by Validation Services. Electronic signatures are based on common cryptographic techniques and are efficient and highly secure mechanisms that provide the following security properties [16] at the application level:

• Integrity - verification of the completeness and accuracy of an e-Mandate. • Non-Repudiation - ability to prove that the issuance of an e-Mandate has taken place, so

that it can not be repudiated later in support of a dispute resolution.

Since the e-Mandate is a XML electronic document, the format of the electronic signature will be in accordance with XML Advanced Electronic Signatures (XAdES) [31], in the form of Basic Electronic Signatures (XAdES-BES). The profiles defined for XAdES-BES [32] are compliant with the requirements of the European Directive 1999/93/EC [34] for Advanced Electronic Signatures5

The electronic signature will be applied as an enveloping signature. The original XML content of the e-Mandate remains unchanged and is encapsulated into a secure XML case (

, while being also fully compatible and interoperable with legacy implementations of the plain W3C specification XML Signature [25] (from which XAdES derives).

Figure 6).

Figure 6: Enveloping XML signature

The electronic signature verification is composed of a verification of the signing certificate followed by a cryptographic verification of the electronic signature (see Figure 5). This process is depicted in Figure 7.

Figure 7: Electronic signature verification

4 Electronic Signature is a concept introduced by the European Directive 1999/93/EC [34]. It is also commonly referred as Digital Signature, as defined in ISO 7498-2:1989. 5 See also document “Impact of the EESSI Standards on the European Banking Community” (SPTF-029/05) [8].


The electronic signature verification of e-Mandates must be performed by Creditors and Routing Services. However, due to the complexity of the verification process and given the contractual nature of the relationship between Creditors and Routing Services, Creditors may delegate the responsibility of the verification to the relying Routing Service provider.

3.7.2.2 Time accuracy

Each party of the model should have its system clocks synchronized with a trusted time source of its choice. This guarantees a reasonable timeliness of data and operations between several different parties and the accuracy of exchanged times and dates (e.g., field AT-25 [3], [4]).

3.7.2.3 Audit trails

Routing Service and Validation Service providers must produce audit trails on their systems for all relevant operations, including the initialization of the audit trail, issuance, amendment and cancellation of e-Mandates, configuration changes, access attempts, exceptions and key management functions critical to the security of the reliance being placed on PKI processes and operations.

The audit trails can be applicational logs or other equivalent means of evidence, as long they contain sufficient information to trace back the complete details of an operation and can be searched or queried in an automated way.

The audit trails must be stored in a long-term support and a tamper evident format, such that illicit addition, modification or deletion of any audit trail can be detected.

The dates and times registered in the audit trails must be obtained from a trusted time source to ensure accuracy and a reasonable clock synchronization of the different parties (see section 3.7.2.2).

Annex C of CWA 14170 [27] presents guidelines for the implementation of a Signature Logging Component.

3.7.2.4 Error reporting

To avoid unpredictable and/or ad-hoc operation results on abnormal situations, error messages are defined to report incidents. Having well-known error messages has the following advantages:

• Handling of errors can be improved since all possible cases are known in advance

• The strict formatting of error messages avoids accidental disclosure of sensitive details (e.g., infrastructure details)

3.7.2.5 Timeouts

The services running over the EPC e-Operating Model are usually composed of several steps. In each of them, the requests may be in a holding state, waiting for some event, be it input or the occurrence of a given action. During this time, resources are consumed to maintain the context of the state. If the event does not occur, the systems may end up with too many exhausted resources resulting from aborted requests.

Therefore, adequate timeout mechanisms must be implemented to invalidate endless requests and free up the committed resources.


3.7.2.6 Caching of BIC resolutions

In order to contact the corresponding Validation Services, the Routing Service providers must be able to resolve BICs into Validation Service URLs. This is achieved by using a Directory Service that maps the Debtor’s Bank Operational BICs into the designated Validation Service URLs.

If the Directory Service is queried for each incoming transaction and the Routing Service provider is fully dependent on the response to proceed with the transaction, the Directory Service would be a single point of failure. This means that an interruption (either accidental or deliberate) of the Directory Service can make the whole system unavailable, since Routing Services will not be able to route the requests.

One important mechanism to mitigate this risk is to cache the BIC resolutions. Routing Services are recommended to maintain an internal mapping of the BICs and respective Validation Service URLs.

The e-Operating Model suggests three approaches to build the cache:

1. Request the Directory Service for the full mapping table and store it locally; 2. Request the changes occurring between a previous version and the current table; 3. Collect and cache the queries as they are being processed.

Regardless of the implementation, cached results must not be used longer than 30 days to assure that any mapping changes and new additions or deletions are reflected in a predictable period of time.

3.7.3 Public Key Infrastructure

Some of the identified mechanisms in the above sections make use of certificates, either for TLS or for electronic signatures. Therefore, a Public Key Infrastructure (PKI) is needed not only to issue the certificates, but to manage their lifecycle (suspensions, revocations and reactivations) and provide additional services (e.g., CRL, OCSP, etc.) as well.

Since the EPC e-Operating Model is to be run by heterogeneous entities, both in nature and interests, it is desirable to allow some flexibility in the choice of the Certification Authority (CA) from which to request the certificates. Nonetheless, it is fundamental to create mutual trust and recognition between players operating cross border in the SEPA environment. This trustable set of CAs is defined by the EPC by accepting candidate CAs that declare strict compliance with the rules of enrolment and certification practices defined in the EPC e-Operating Model and are sponsored by a Routing Service or Validation Service provider.

Applicant CAs may be already established in the market, private internal CAs in use by the parties or special purpose CAs specifically targeted to the EPC e-Operating Model. In either of the cases, the conditions for application to the EPC are a sponsorship of a Routing Service or Validation Service provider and full compliance with the defined rules for Certification Authorities.

The adoption of the required certification practices minimizes the risk of compromise of a CA, while the enrolment rules guarantees the univocal identity and legitimacy of the end entity.

Once a CA is approved by the EPC, it becomes part of the EPC Approved CAs set and must be trusted by all participating parties that need SEPA certificates (i.e., Routing Service and Validation Service providers). This common set of trust anchors is the basis for the interoperability between Routing Services and Validation Services, which may not know each other prior to a transaction.

Besides the EPC Approved CAs, the following additional categories of CAs are also considered in the e-Operating Model:


• Commercial Certification Authorities are current market established CAs, generally trusted by browsers and server frameworks. Interoperability of certificates issued by these CAs is out of the scope of this e-Operating model;

• Routing Service CA is a CA that issues TLS client certificates for Creditors by request of the Routing Service. This provides stronger authentication of Creditors for the Routing Service. The Routing Service CA can be a commercial available CA for which the Routing Service settles an agreement or a self-owned specific purpose CA.


The full set of certificates necessary for the e-Operating Model is illustrated in Figure 8.

Figure 8: PKI and certificates for the e-Operating model

Table 4 presents a description of the certificates depicted in Figure 8. Table 4: Description of the e-Operating Model certificates

Ref Certificate Type CA Authenticated

Object Verifying

Party Description

1 TLS Server Commercial Creditor Debtor Authenticates the Creditor to the Debtor. Protects the communication between these two parties.

2 TLS Server Commercial / EPC approved

Routing Service Creditor

Authenticates the Routing Service to the Creditor. Protects the communication between these two parties.

3 TLS Client Routing Service / Commercial

Creditor Routing Service

(Optional) Authenticates the Creditor to the Routing Service.

4 TLS Server EPC approved

Validation Service

Routing Service

Authenticates the Validation Service to the Routing Service. This certificate is specific for the Validation Services of the e-Operating Model. Protects the communication between these two parties.

5 TLS Client EPC approved

Routing Service

Validation Service

Authenticates the Routing Service to the Validation Service. This certificate is specific for the Routing Service of the e-Operating Model.


Ref Certificate Type CA Authenticated

Object Verifying

Party Description

6 Signing EPC approved

Validation Service e-mandate

Creditor, Routing Service

Signs messages in the e-Operating Model through the use of a specific certificate for this purpose.

7 TLS Server Commercial Directory Service

Routing Service

Authenticates the Directory Service to the Routing Service. Protects the communication between these two parties.

The profiles for the certificates to be issued by EPC approved Certification Authorities are detailed in Annex E.

The profile specified on the e-Operating Model for certificate 5 (Routing Service TLS Client) allows Routing Services to use it simultaneously as certificate 2, as it will also be ready for server-side usage.

3.8 Routing and interoperability According to the message flow described on section 3.6, Routing Service providers are responsible for delivering the messages exchanged between Creditors and Validation Service providers. Therefore, Routing Service providers must “be able to connect” to every Validation Service provider available. In order to do so, the following conditions must be met by the Routing Service:

1. The URL address of the target Validation Service must be known;

2. The Validation Service must be authenticated as a legitimate one;

3. Must provide credentials so that the Validation Service can be guaranteed that it is a legitimate Routing Service provider.

Condition 1 is achieved by resolving the BIC into the Validation Service provider URL using the Directory Service.

This information complements the already existing market offer of BIC Directory services that namely provide routing information for SEPA payments. The existing providers may complement their service offer with the additional information of the Validation Service address (e.g. URL) for any operational BIC.

Providers that offer this enhanced BIC Directory service to Routing Service Providers will facilitate reachability to the Validation Services of Debtor Banks. For this purpose, the directory must have an updated list of all participant Debtor Banks’ operational BICs and the correspondent Validation Service URLs. The Directory Service providers must maintain an updated mapping of the operational BICs of the e-Mandates Debtor Banks and the corresponding Validation Service URLs. These URLs are the Validation Service entry points for the EPC e-Operating Model to be used by Routing Services

Each Routing Service can then choose to use either a service provider for BIC Directory (option “a”) or download the information directly from the EPC website (option “b”), depicted on Figure 9.


Debtor Creditor

Browser Website

Validation Service Routing Service

Creditor Bank

1. Initiation

Debtor Bank

9. Confirmation

7. e-Mandate

3. Mandate Request

8. e-Mandate2. Mandate Request6. Confirmation

4. Request Authentication

Means5. Authorization

EPC SEPA Directory

BIC Directory Service Provider

Directory

2. Mandate Request

a)

b)

Figure 9: e-Operating Model - options for Directory Services.

Condition 2 is achieved by using exclusive Validation Service authentication certificates and condition 3 is achieved by using exclusive Routing Service” authentication certificates. These two types of certificates, described on section 3.7.3, are used to establish secure HTTP connections over TLS. Both parties taking place on such a session must validate the presented certificates similarly as described in section 3.7.1.


4 IMPLEMENTATION GUIDELINES

4.1 General requirements The baseline requirements that are generic to all entities are presented in this section.

4.1.1 Networking

The e-Operating Model runs over the standard networking stack TCP/IP, widely used on the Internet.

Parties must use standard TCP ports, namely port 80 for HTTP and 443 for HTTPS.

At the application layer, data must be exchanged over HTTP version 1.1. For all HTTP responses whose content is an XML message, the Content-Type header must be set to the MIME type text/xml.

4.1.2 Internationalisation

Parties must use UTF-8 as the character set for the data exchanged. UTF-8 supports all characters of European languages, thus improving interoperability.

Due to the international nature of SEPA, parties are recommended to provide Debtors with “localized interfaces”. This means to have not only translated text, but also properly formatted currency and date values, support for time zones and legal and regulatory compliance.

4.1.3 Time accuracy

Creditors, Routing Services, Validation Services and Directory Services are recommended to keep their system clocks synchronized with a trusted time source of their choice. As a reference, if the NTP protocol is used, stratum 3 is the minimum acceptable level.

Certification Authorities are subject to specific time accuracy restrictions described in CWA 14167-1 [28] and TS 102 042 [30].

The time information exchanged must be always related to UTC.

4.1.4 Processing time

The total transaction time to request an e-Mandate should be acceptable to the Debtor, providing a fluid and responsive user experience. Parties must be aware that the Debtor will be guided through several different screens and, at the Validation Service/Online Banking, will be authenticated through specific means that can greatly extend the total transaction time.

4.1.5 Certificate Verification

The X.509 certificates issued by EPC approved Certificate Authorities must be verified by a relying party according to the general rules defined in RFC 5280 [23]. The most significant steps of the process are illustrated on Figure 10.


Figure 10: Significant steps of the certificate verification

The presented certificate must comply with the expected profile as defined in Annex E. In particular, the existence of the expected certificate policy identifiers must be verified, as well as the subject alternative name(s), if applicable.

The certificate validity dates must be verified to guarantee that:

1. “Not Before” date is sooner than the actual validation date, meaning that the certificate is already valid; and

2. “Not After” date is later than the actual validation date, meaning that the certificate is not already expired.

A trusted certificate chain must also be built in order to consider the presented certificate as trustful by completing a process known as Certification Path Validation. A certificate chain is a sequence of certificates where each certificate is signed by the next certificate in the chain. The chain starts with the presented certificate and ends with a self-signed certificate – the root CA certificate. In the case of the EPC e-Operating Model, the root CA must be part of the EPC approved CAs in order for the certificate to be considered trustful.

The certificate chain is considered to be trustful only when:

1. It is correctly constructed and terminates in a trusted self-signed certificate from one of the EPC approved CAs, and

2. Each of its belonging certificates is also successfully verified.


Section 6 “Certification Path Validation” of RFC 5280 [23] presents a comprehensive description of this process along with the recommended processing rules.

Finally, the revocation status must be checked for all certificates belonging to the certificate chain. In order to do that, each certificate is verified against its corresponding OCSP server [18] (URL obtained from the “Authority Information Access” extension) or the available online CRL [23] (URL obtained from the “CRL Distribution Point” extension).

The use of OCSP is recommended as the primary source for checking revocation status. To increase the performance and scalability, OCSP responses may be cached for a maximum period of 24 hours. CRLs are recommended to be used as a fallback mechanism when the OCSP server is unavailable.

If the revocation status verification can not be perfomed – for example, due to unavailability of both the OCSP and CRL –, the e-Mandate must be rejected.

4.2 Debtor requirements In order to become eligible to use the e-Mandates service, the Debtor must have established a contractual agreement with the Debtor Bank, allowing him to be the holder of an account with the following characteristics:

• Have permissions to use and manage direct debit services and e-Mandates;

• Have access to the account services via the electronic channels supplied by the Debtor Bank.

Parties interacting directly with Debtors may expect the existence of an Internet broadband connection6

• HTML 4.0 or higher;

and a web browser compliant with the following requirements:

• HTTP 1.1 support;

• Ability to perform HTTP redirects;

• Support TLSv1 / SSLv3 (or higher) with strong security cipher suites;

• Security options enabled.

Given the importance of security awareness, entities with direct relationships with Debtors (namely Banks, Validation Services and Creditors) should promote security awareness, training and education wherever possible. Debtors should be encouraged to adopt security measures advised by the parties such as personal firewalls, antivirus, antispyware and other security mechanisms.

4.3 Creditor requirements This section describes the requirements to be followed by adhering Creditors. It is worthwhile noting that Creditors may choose to either develop a customized implementation of the requirements defined in this specification on their systems or integrate with any possibly available standardized compliant plug-ins.

6 According to the OECD broadband criteria [35], an Internet connection is considered to be “broadband” if it is capable of download speeds of at least 256 kbit/s.


4.3.1 Setup

1. A contractual agreement with a Creditor Bank must be established in the terms defined in [3] or [4].

2. A contractual agreement with a Routing Service provider designated by the Creditor Bank must be established in the terms defined in [3] or [4]. This contractual agreement may be either directly with the Routing Service provider or intermediated by the Creditor Bank.

3. The Creditor website must use a TLS X.509 server certificate on the communications with the Debtor to ensure the legitimacy of the website domain name and to enable the usage of HTTPS for data integrity and confidentiality. The choice of the issuing Certification Authority is up to the Creditor but it must choose one that has a certification path recognized by the commonly available web browsers expected to be used by Debtors.

4. HTTPS must be performed using only the strong cipher suites of TLS [22] (a list of strong cipher suites is available in [37]). Weak cipher suites must be disabled on the configuration of the web server. The minimum version of TLS to be supported is 1.0, but Creditors are recommended to migrate to TLS v1.2 as soon as possible (all versions of TLS are retrocompatible for interoperability purposes).

5. The Creditor must choose to either develop a customized implementation of the requirements defined in this specification on their systems or integrate with any possibly available standardized compliant plug-ins.

6. The Creditor must be given by the Routing Service provider the authentication credentials to access the operations available.

7. The Creditor must trust the certification path of the TLS server certificate of the Routing Service provider for HTTPS communications.

8. All stored personal information about Debtors and the e-Mandates they hold must be protected in strict accordance with the legal and regulatory requirements and used solely for the purposes explicitly allowed by the respective Debtor.

4.3.2 Processing

The sequence diagram presented below in Figure 11 illustrates the processing steps of the Single Authorization Message Flow for Creditors, while the sequence diagram in Figure 12 illustrates the processing steps of the Multiple Authorizations Message Flow. The only difference in terms of processing is on step 4, which varies according to the information received on step 3. Each of the steps is further detailed on this section.


Figure 11: Sequence diagram of the Single Authorization Message Flow for Creditors

Figure 12: Sequence diagram of the Multiple Authorizations Message Flow for Creditors


1. The Creditor starts the process by collecting all the necessary data about the Debtor in order to build the proposal message. The Creditor may already have some information about the Debtor and pre-fill the corresponding form fields. Both the form presentation and submission at the website must be performed over HTTPS. The form must contain the mandatory national legal wording and the same information about the Creditor that will be present on the e-Mandate message.

2. After gathering all the necessary data, the Creditor builds the XML proposal message according to schema eom-msg-cred-to-rs-001 and sends a HTTPS POST to the URL indicated by the Routing Service provider, using the assigned authentication credentials and with the following parameters:

Parameter Format Description

service Fixed string: mandate Service identifier.

operation Fixed string: proposal Operation identifier.

eom-message XML message XML proposal message, according to schema eom-msg-cred-to-rs-001.

If the Creditor does not use a session mechanism (e.g, cookies or URL rewriting), the URL set on element /eom-msg-cred-to-rs-001/payload/eom-data/creditor-return-url7

5

must contain sufficient HTTP GET parameters to be able to resume the transaction later at step . For security reasons, the URL must also contain a parameter with a randomly generated value: the Random Transaction Token (RTT). The RTT must be an ASCII representation (e.g, hexadecimal, Base64) of a minimum of 16 bytes generated using a cryptographically secure pseudo-random number generator adequately seeded. This is to avoid hijacking and snooping of pending transactions by manipulation of easily guessable parameters on the URL.

This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-001/header/service and /eom-msg-cred-to-rs-001/header/operation, respectively. This redundancy allows Routing Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message.

The Routing Service provider may define additional data elements to be included on the eom-message or the POST. The Creditor must comply with those additional requirements. After submission of the POST, the Creditor advances the transaction state to “Waiting for VS URL” (Figure 13).

3. Within a maximum of 10 seconds, the Creditor should receive the response to the POST, containing an XML message according to schema eom-msg-rs-to-cred-001.

4. Depending on the content of element /eom-msg-rs-to-cred-001/payload/status:

a. If the value is 0 (zero), depending on the content of element /eom-msg-rs-to-cred-001/payload/eom-data:

7 References to values of elements on XML messages are referred using the XPath convention throughout this section.


i. If there is an element vs-url, it means that the Validation Service has chosen the Single Authorization Message Flow and the Creditor must perform a redirect of the Debtor to the Validation Service URL set on that element. The redirect is recommended to be performed by returning an HTTP response code 301 along with the URL. Other methods are permitted but may need further interaction with the Debtor (return an HTML page with a “click here to proceed” link) or present browser incompatibilities (e.g., usage of JavaScript). By redirecting the Debtor, the Creditor advances the transaction state to “Wait for Debtor redirection” (Figure 13).

ii. Else, if there is an element vs-mandate-ref, it means that the Validation Service has chosen the Multiple Authorizations Message Flow and the Creditor must present the content of that element to the Debtor. It will subsequently be used by the Debtor as a reference to authorize the e-Mandate.

iii. Otherwise, an error had occurred and the transaction must be aborted with no further processing. The user shall be presented with an appropriate error message.

b. Otherwise, an error had occurred and the transaction must be aborted with no further processing. The user shall be presented with an appropriate error message.

5. Afterwards, the Creditor will only resume the process when the Debtor is sent back by the Validation Service to the URL provided in step 2. This time gap is undetermined, but Creditors shall assume that transactions not completed before the date set on due-date in message eom-msg-cred-to-rs-001 on step 2 are aborted and can be discarded. If possible, the Creditor is recommended to notify the Debtor about the cancellation of the operation. When the Debtor is redirected, a HTTPS GET request is performed to the URL provided in step 2. The Creditor must be able to recover the state and data and resume the transaction with the parameters contained in the GET request. If the transaction is not resumed by means of a session mechanism (e.g., cookies or URL rewriting), the Creditor must also validate that the Random Transaction Token (RTT) included as a parameter in the URL is the same generated on step 2. If it is different, the request must be discarded.

6. The Creditor sends a HTTPS POST to the URL indicated by the Routing Service provider using the assigned authentication credentials and with the following parameters:



operation Fixed string: retrieval Operation identifier.

eom-message XML message XML retrieval message, according to schema eom-msg-cred-to-rs-002.


The Routing Service provider may define additional data elements to be included on the eom-message or the POST; the Creditor must comply with those additional requirements. After submission of the POST, the Creditor advances the transaction state to “Waiting for e-Mandate” (Figure 13).


7. Within a maximum of 15 seconds, the Creditor should receive the response to the POST, containing an XML message according to schema eom-msg-rs-to-cred-002. Depending on the content of element /eom-msg-rs-to-cred-002/payload/status:

a. If the value is 0 (zero), the e-Mandate is the content of the XML element /eom-msg-rs-to-cred-002/payload/eom-data/signed-message. The e-Mandate contains a XML signature that protects its content. The XML signature is verified by the Routing Service prior to delivery to the Creditor. Nonetheless, Creditors are recommended to verify it also according to the process illustrated in Figure 7.

b. Otherwise, an error had occurred and the transaction must be aborted with no further processing. The user shall be presented with an appropriate error message.

8. The Creditor sends a HTTPS POST to the URL indicated by the Routing Service provider using the assigned authentication credentials and with the following parameters:



operation Fixed string: acknowledge Operation identifier.

eom-message XML message XML acknowledgement message, according to schema eom-msg-cred-to-rs-002.


The Routing Service provider may define additional data elements to be included on the eom-message or the POST; the Creditor must comply with those additional requirements. After submitting the POST

9. The Creditor stores the e-Mandate and presents a confirmation message along with the e-Mandate data to the Debtor. The transaction is finished.

If a recoverable error occurs between steps 6 and 9 (e.g, a connection timeout, lack of disk space on the Creditor, lost e-Mandate, etc.), the Creditor has the opportunity to retry the retrieval of the e-Mandate. However, once the e-Mandate is confirmed to the Debtor, the e-Mandate must never be retrieved again by action of the Debtor reusing the URL of step 5 in order to avoid abusive reuses of the URL.

Transactions not completed before the date and time set on field due-date of message eom-msg-cred-to-rs-001 may be discarded. Creditors are recommended to set due dates long enough such that the several intermediate steps can be processed, but no longer than reasonable for the resources that might be locked during the transaction. In the absence of a specified value for due-date, Creditors must consider a default timeout of 15 minutes for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow.

Figure 13 illustrates the state transitions for transactions in Creditors according to the processing instructions described above.


Figure 13: State diagram for transactions in Creditors

4.4 Routing Service Provider requirements

4.4.1 Setup

1. A contractual agreement with a Creditor Bank must be established in the terms defined in [3] or [4].

2. The Routing Service provider must apply to the EPC to be able to participate in the e-Operating Model. The application must be sponsored by a Creditor Bank registered at the EPC.

3. The Routing Service web container must use a TLS X.509 server certificate to ensure the legitimacy of the web domain name and to enable the usage of HTTPS for data integrity and confidentiality. The choice of the issuing Certification Authority is up to the Routing Service provider. Incoming Creditors must trust the issuing Certification Authority (or its certification trusted chain) in order to accept the certificate and initiate the communications.

4. An e-Operating Model X.509 authentication certificate must be requested from one of the approved EPC Certification Authorities.

5. For the communications of Validation Services and verification of electronic signatures, the Routing Service provider must trust only the EPC approved Certification Authorities and disable all other Certification Authorities. The set of EPC approved Certification Authorities is provided at the adherence of the Routing Service provider and is updated regularly.

6. HTTPS must be performed using only the strong cipher suites defined on TLSv1 [22] (a list of strong cipher suites is available in [37]). Weak cipher suites must be disabled on the configuration of the web server. The minimum version of TLS to be supported is 1.0, but Routing Service providers are recommended to migrate to TLS v1.2 as soon as possible (all versions of TLS are retrocompatible for interoperability purposes).


7. A contractual agreement with a Directory Service provider must be established in order to have access to the BIC-to-Validation Service resolution data and periodic updates or to an online resolution service.

8. For each applying Creditor, the Routing Service provider must supply:

a. Unique authentication credentials;

b. The e-Operating Model service URL;

4.4.2 Processing

The sequence diagram presented below in Figure 14 illustrates the processing steps for Routing Services. Each of the steps is further detailed in this section.

Figure 14: Sequence diagram for Routing Service providers

1. The Routing Service provider receives an HTTPS POST on the URL indicated to the Creditor. The Routing Service provider must verify the authentication credentials provided by the Creditor to confirm the claimed identity. If the verification fails, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail.

The received POST must contain the following parameters:





eom-message XML message XML proposal message, according to schema eom-msg-cred-to-rs-001.

The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-cred-to-rs-001/header/service and /eom-msg-cred-to-rs-001/header/operation, respectively. This redundancy allows the Routing Service provider to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message. The Routing Service provider may define additional convenience data elements that may be included on the eom-message or the POST.

Regarding the received parameters, the Routing Service provider must verify that:

a. The calling Creditor has permissions to use mandate as a value for service, by checking the terms of the contractual agreement established.

b. The value set for parameter operation is proposal.

c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-cred-to-rs-001.

d. The content of /eom-msg-cred-to-rs-001/header/service8

e. The content of /

is mandate.

eom-msg-cred-to-rs-001/header/operation is proposal.

f. The value of /eom-msg-cred-to-rs-001/payload/eom-data/creditor-id is a valid Creditor identifier and corresponds to the calling authenticated Creditor.

g. The value of element /eom-msg-cred-to-rs-001/payload/eom-data/creditor-return-url is a well-formed URL.

h. The content of element /eom-msg-cred-to-rs-001/payload/message is a well-formed XML document. Optionally, the Routing Service provider may verify if it is a valid XML document according to the e-Mandate schema.

If any of the above conditions fail, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail.



2. The Routing Service provider gets the Validation Service BIC by parsing the content of element /eom-msg-cred-to-rs-001/payload/eom-data/bic. The parsed BIC is used as the input on a resolution process to obtain the specific EPC e-Operating Model entry point URL of the corresponding Validation Service. Directory Service providers maintain updated mappings of BIC/URL for this resolution process. This specification presents two implementation options for this resolution process in Annex C, but Directory Service providers and Routing Service providers may develop others that best suit their needs, as long as the results are equivalently accurate and scalable. If an error occurs on the resolution process, the Routing Service provider must return an error message according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing. The result of the resolution process must be logged to an audit trail.

3. The Routing Service provider sends a HTTPS POST to the Validation Service URL using its e-Operating Model certificate for mutual authentication and with the following parameters:




eom-message XML message XML proposal message, according to schema eom-msg-rs-to-vs-001.

This POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-001/header/service and /eom-msg-rs-to-vs-001/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message.

At the TLS handshake, the Routing Service provider must verify the certificate presented by the Validation Service according to the process illustrated in Figure 5. According to the certificate verification result:

a) If the verification succeeds, the Routing Service provider transmits the request data described above and logs the event to an audit trail. After submission of the POST, the Routing Service provider advances the transaction state to “Waiting for VS URL” (Figure 15).

b) Otherwise, the Routing Service provider must close the connection immediately without transmitting any request data and logs the occurrence to an audit trail. Additionally, the Routing Service provider must return an error message to the Creditor according to schema eom-msg-rs-to-cred-001 and the transaction must be aborted with no further processing.

4. Within a maximum of 10 seconds, the Routing Service provider should receive the response to the POST, which contains a XML message according to schema eom-msg-vs-to-rs-001. Depending on the content of element /eom-msg-vs-to-rs-001/payload/status:

a. If the value is 0 (zero), the Validation Service has processed correctly the message sent on step 3. The Routing Service provider logs the event to an audit trail.


b. Otherwise, an error had occurred. The Routing Service provider logs the event to an audit trail and returns a XML error message according to schema eom-msg-rs-to-cred-001 to the holding Creditor as the response to the POST received on step 1. The transaction must be aborted with no further processing.

5. The Routing Service provider returns a XML message according to schema eom-msg-rs-to-cred-001 to the holding Creditor as the response to the POST received on step 1. After returning the message, the Routing Service provider advances the transaction state to “Waiting for e-Mandate retrieval”.






eom-message XML message XML retrieval message, according to schema eom-msg-cred-to-rs-002.




b. The value set for parameter operation is retrieval.


d. The content of /eom-msg-cred-to-rs-002/header/service is mandate.

e. The content of /eom-msg-cred-to-rs-002/header/operation is retrieval.



g. The value of element /eom-msg-cred-to-rs-002/payload/eom-data/creditor-request_id matches the value of the creditor_request_id element of a transaction in either state “Waiting for e-Mandate retrieval” or “e-Mandate acknowledged”9

If any of the above conditions fail, the Routing Service provider must return an error message according to schema

for the same Creditor and for which an operation proposal has been processed previously.

eom-msg-rs-to-cred-002 and the transaction must be aborted with no further processing. In any case, the verification result must be logged to an audit trail.

7. The Routing Service provider sends a HTTPS POST to the Validation Service URL (the same used on step 3) using its e-Operating Model certificate for mutual authentication and with the following parameters:







a) If the verification succeeds, the Routing Service provider transmits the request data described above and logs the event to an audit trail. After submission of the POST, the Routing Service provider advances the transaction state to “Waiting for e-Mandate” (Figure 15).

b) Otherwise, the Routing Service provider must close the connection immediately without transmitting any request data and logs the occurrence to an audit trail. Additionally, the Routing Service provider must return an error message to the Creditor according to schema eom-msg-rs-to-cred-002 and the transaction must be aborted with no further processing.

8. Within a maximum of 15 seconds, the Routing Service provider should receive the response to the POST, containing an XML message according to schema eom-msg-vs-to-rs-002. Depending on the content of element /eom-msg-vs-to-rs-002/payload/status:

a. If it is 0 (zero), the Validation Service has processed correctly the message sent on step 7. The Routing Service provider logs the event to an audit trail.

9 This allows retrials of the operation retrieval by Creditors.


b. Otherwise, an error had occurred. The Routing Service provider logs the event to an audit trail and returns a XML error message according to schema eom-msg-rs-to-cred-002 to the holding Creditor as the response to the POST received on step 6. The transaction must be aborted with no further processing.

9. The received XML message contains the e-Mandate as the content of element /eom-msg-vs-to-rs-002/payload/message. The e-Mandate is protected with an enveloping XML Signature. At this step, the Routing Service provider must verify the electronic signature according to the process illustrated in Figure 7.

10. Depending on the result of the signature verification:

a. If it succeeds, the Routing Service provider logs the event to an audit trail and returns a XML message according to schema eom-msg-rs-to-cred-002 to the holding Creditor as the response to the POST received on step 7. The XML enveloping signature received on step 8 must be embedded into element /eom-msg-rs-to-cred-002/payload/eom-data/signed-message. The Routing Service provider sets the state of the transaction to “e-Mandate retrieved”.

b. Otherwise, the signature is invalid. The Routing Service provider logs the event to an audit trail and returns a XML error message according to schema eom-msg-rs-to-cred-002 to the holding Creditor as the response to the POST received on step 7. The transaction must be aborted with no further processing.






eom-message XML message XML acknowledgement message, according to schema eom-msg-cred-to-rs-002.





b. The value set for parameter operation is acknowledge.


d. The content of /eom-msg-cred-to-rs-002/header/service is mandate.

e. The content of /eom-msg-cred-to-rs-002/header/operation is acknowledge.


g. The value of element /eom-msg-cred-to-rs-002/payload/eom-data/creditor-request_id matches the value of the creditor_request_id element of a transaction in state “Waiting for acknowledge” for the same Creditor and for which an operation retrieval has been processed previously.

If any of the above conditions fail, the Routing Service must abort the transaction with no further processing. In any case, the verification must be logged to an audit trail.

12. The Routing Service provider sends a HTTPS POST to the Validation Service URL (the same used on step 3) using its e-Operating Model certificate for mutual authentication and with the following parameters:




eom-message XML message XML acknowledgement message, according to schema eom-msg-rs-to-vs-002.



a) If the verification succeeds, the Routing Service provider transmits the request data described above and logs the event to an audit trail. After submission of the POST, the Routing Service provider sets the state of the transaction to “e-Mandate acknowledged” (Figure 15).

b) Otherwise, the Routing Service provider must close the connection immediately without transmitting any request data and logs the occurrence to an audit trail.


Transactions not completed before the date and time set on field due-date of message eom-msg-cred-to-rs-001 may be discarded. In the absence of a specified value for due-date, Routing Service providers must consider a default timeout of 48 hours10

Figure 15

.

illustrates the state transitions for transactions in Routing Service providers according to the processing instructions described above.

Figure 15: State diagram for transactions in Routing Service providers

4.5 Validation Service Provider requirements

4.5.1 Setup

1. A contractual agreement with the Debtor Bank must be established in the terms defined in [3] iand [4].

2. The Validation Service provider must apply to the EPC to be able to participate in the e-Operating Model. The application must be sponsored by the Debtor Bank registered at the EPC. Thus, the application to the EPC must be performed on a per-BIC basis.

3. An e-Operating Model X.509 authentication certificate must be requested from one of the approved EPC Certification Authorities.

10 Since Routing Service providers are not required to process differently the two message flows defined (Single Authorization and Multiple Authorizations), the 48 hours default timeout is to accommodate both of them. However, Routing Service providers that are able to distinguish the message flows (see description of step 4.a in section 4.3.2) may set the default timeout for the Single Authorization Message Flow to 15 minutes.


4. For each registered BIC, an e-Operating Model X.509 signing certificate must be requested from one of the approved EPC Certification Authorities.

5. The keys for the signing certificates described in requirement 4 must be generated and kept secure in a Signature Creation Device adequate for performing Advanced Electronic Signatures. These devices are typically Hardware Security Modules with certification FIPS 140-1/2 Level 2 or higher, or Common Criteria EAL 3 or higher.

6. For the communications of Routing Services, the Validation Service provider must trust only the EPC approved Certification Authorities and disable all other Certification Authorities. The set of EPC approved Certification Authorities is provided at the adherence of the Validation Service provider and is updated regularly.

7. HTTPS must be performed using only the strong cipher suites defined on TLSv1 [22] (a list of strong cipher suites is available in [37]). Weak cipher suites must be disabled on the configuration of the web server. The minimum version of TLS to be supported is 1.0, but Validation Service providers are recommended to migrate to TLS v1.2 as soon as possible (all versions of TLS are retrocompatible for interoperability purposes).

8. The Validation Service provider must communicate to the EPC the URL to which it will be willing to process e-Operating Model messages for a given BIC. All updates to the URL must be communicated to the EPC.

4.5.2 Processing

The sequence diagram presented below in Figure 16 illustrates the processing steps of the Single Authorization Message Flow (SAMF) for Validation Services, while the sequence diagram in Figure 17 illustrates the processing steps of the Multiple Authorizations Message Flow (MAMF).

Validation Services that want to avoid automatic redirects from Creditors or need multiple authorizations should adopt the MAMF.

Each of the steps for the SAMF are further detailed in section 4.5.2.1 and for MAMF in section 4.5.2.2.


Figure 16: Sequence diagram of the Single Authorization Message Flow for Validation Service providers


Figure 17: Sequence diagram of the Multiple Authorizations Message Flow for Validation Service providers

4.5.2.1 Single Authorization Message Flow

1. The Validation Service provider receives an HTTPS POST on the URL registered at the EPC for the requested BIC. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result:

a. If the verification succeeds, the Validation Service proceeds with the request and logs the event to an audit trail.


b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. Additionally, the Validation Service provider must return an error message to the Routing Service according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. If the Validation Service provider is not able to return an error message conforming to eom-msg-vs-to-rs-001, it must return an HTTP status code 403 (Forbidden).






The received POST request contains the service and operation parameters as a repetition of the content of elements /eom-msg-rs-to-vs-001/header/service and /eom-msg-rs-to-vs-001/header/operation, respectively. This redundancy allows Validation Service providers to filter, reject or dispatch to other chained server processors the incoming requests without having to parse the whole XML message contained in parameter eom-message.

2. Regarding the received parameters, the Validation Service provider must verify that:

a. The value set for parameter service is mandate.


c. The content of parameter eom-message is a valid XML document compliant with schema eom-msg-rs-to-vs-001.

d. The content of /eom-msg-rs-to-vs-001/header/service11

e. The content of /

is mandate.

eom-msg-rs-to-vs-001/header/operation is proposal.

f. The value of element /eom-msg-rs-to-vs-001/payload/eom-data/creditor-return-url is a well-formed URL.

g. The content of element /eom-msg-rs-to-vs-001/payload/message is a valid XML document compliant with the e-Mandate schema.

If any of the above conditions fail, the Validation Service provider must return an error message according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. Otherwise, the Validation Service provider stores the received data. In any case, the results of the verifications must be logged to an audit trail.



3. In response to the received POST, the Validation Service provider returns a XML message according to schema eom-msg-vs-to-rs-001 for SAMF (i.e. providing a URL at the Validation Service on the content of elementc /eom-msg-vs-to-rs-001/payload/eom-data/vs-url for which the Debtor will subsequentely be redirected by the Creditor in step 4), and advances the transaction state to “Waiting for Debtor redirection” (Figure 18).

4. The Debtor is redirected by the Creditor to the Validation Service URL provided at element /eom-msg-vs-to-rs-001/payload/eom-data/vs-url on the message returned in step 3.

5. The Validation Service provider retrieves the data about the request previously stored on step 2 and presents an authentication screen to the Debtor. The transaction state advances to “Waiting for authentication means” (Figure 18).

6. The Debtor enters the authentication credentials agreed with the Debtor Bank The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features.

7. The Validation Service verifies the correctness of the authentication credentials provided and logs the event to an audit trail.

8. Depending on the results of the verification of the authentication credentials:

a. If the authentication credentials provided are correct and valid, the Validation Service presents an authorization form that must include all data fields of the e-mandate and advances the transaction state to “Waiting for authorization” (Figure 18).

b. If the authentication can not be correctly verified (even after a limited number of retrials of steps 6 and 7), an error message must be presented and the transaction must be aborted with no further processing.

9. The Debtor is asked to verify all the data fields of the e-mandate (e.g., the accuracy of the Creditor’s name and address, the Debtor’s account identifier, etc.) along with the mandatory national legal wording and then proceeds with the authorization. The authorization is defined [3], [4] as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment or cancellation of an e-Mandate. If the IBAN was not set on the e-Mandates message received in step 1, the Debtor must choose one of the accounts for which he is the holder and has direct debits rights.

10. The Validation Service verifies the authorization and performs an electronic signature of the XML e-Mandate data using the e-Operating Model X.509 signing certificate issued by an approved EPC Certification Authority. The electronic signature must be generated by a Signature Creation Application (SCA) compliant with CWA 14170 [27], using a Signature Creation Device adequate for performing Advanced Electronic Signatures. These devices are typically Hardware Security Modules with certification FIPS 140-1/2 Level 2 or higher, or Common Criteria EAL 3 or higher. The format of the electronic signature must be an enveloping XML signature in accordance with XML Advanced Electronic Signatures (XAdES) [31], in the form of Basic Electronic Signatures (XAdES-BES) conforming to the profile defined in Table 5.


Table 5: XAdES-BES profile for the EPC e-Operating Model

Element Value

CanonicalizationMethod @Algorithm = http://www.w3.org/2001/10/xml-exc-c14n#

SignatureMethod @Algorithm = http://www.w3.org/2000/09/xmldsig#rsa-sha1

Reference @URI = #message

DigestMethod @Algorithm = http://www.w3.org/2001/04/xmlenc#sha256

Reference @URI = #keyInfo


KeyInfo

@Id = keyInfo Must include a X509Data element containing X509Certificate elements for the signing certificate and the certificates composing the trusted certification chain. The first X509Certificate must be the signing certificate and last must be the root Certification Authority.

Object @Id = message

The XAdES-BES signature will have the following sample structure: <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#message"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>...</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>...</X509Certificate>  <X509Certificate>...</X509Certificate>  </X509Data> </KeyInfo> <Object Id="message">...</Object> </Signature>

A complete XML sample message of eom-msg-vs-to-rs-002 can be found in annex B.9.

11. The Validation Service presents a confirmation message to the Debtor along with the e-Mandate data and a link to the Creditor website (URL provided at element /eom-msg-rs-to-vs-001/payload/eom-data/creditor-return-url on the message received in step 1). The transaction state advances to “Waiting for e-Mandate retrieval” (Figure 18).

12. The Validation Service provider receives an HTTPS POST from the same Routing Service provider, on the same URL as the message received in step 1. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result:










Regarding the received parameters, the Validation Service provider must verify that:




d. The content of /eom-msg-rs-to-vs-002/header/service is mandate.

e. The content of /eom-msg-rs-to-vs-002/header/operation is retrieval.

f. The value of elements /eom-msg-rs-to-vs-002/payload/eom-data/creditor-id and /eom-msg-rs-to-vs-002/payload/eom-data/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in either state “Waiting for e-Mandate retrieval” or “e-Mandate retrieved”12

If any of the above conditions fail, the Validation Service provider must return an error message according to schema

for the same Routing Service provider and for which a proposal operation has been processed previously.

eom-msg-vs-to-rs-002 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail.

12 This allows retrials of the operation retrieval by Creditors..


13. In response to the POST, the Validation Service provider returns a XML message according to schema eom-msg-rs-to-vs-002, embedding the XML enveloping signature performed on step 10 into element /eom-msg-rs-to-vs-002/payload/eom-data/signed-message. The transaction state is set to “e-Mandate retrieved” (Figure 18)



b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. The transaction must be aborted with no further processing.












e. The content of /eom-msg-rs-to-vs-002/header/operation is acknowledge.

f. The value of elements /eom-msg-rs-to-vs-002/payload/eom-data/creditor-id and /eom-msg-rs-to-vs-002/payload/eom-data/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in state “Waiting for e-Mandate retrieval” for the same Routing Service provider and for which a proposal operation has been processed previously.


If any of the above conditions fail, the Validation Service provider must discard the message with no further processing. Otherwise, the Validation Service advances the transaction state to “e-Mandate acknowledged” (Figure 18). In any case, the verification must be logged to an audit trail.

Transactions not completed before the date and time set on field due-date of message eom-msg-rs-to-vs-001 may be discarded. In the absence of a specified value for due-date, Validation Service providers must consider a default timeout of 15 minutes for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow.

Figure 18 illustrates the state transitions for transactions in Validation Service providers according to the processing instructions described above.

Figure 18: State diagram of the Single Authorization Message Flow for transactions in Validation Service

providers

4.5.2.2 Multiple Authorizations Message Flow

1. The Validation Service provider receives an HTTPS POST on the URL registered at the EPC for the requested BIC. At the TLS handshake, the Validation Service provider must verify the certificate presented by the Routing Service according to the process illustrated in Figure 5. Depending on the certificate verification result:










2. Regarding the received parameters, the Validation Service provider must verify that:




d. The content of /eom-msg-rs-to-vs-001/header/service13

e. The content of /

is mandate.

eom-msg-rs-to-vs-001/header/operation is proposal.

f. The value of element /eom-msg-rs-to-vs-001/payload/eom-data/creditor-return-url is a well-formed URL.

g. The content of element /eom-msg-rs-to-vs-001/payload/message is a valid XML document compliant with the e-Mandate schema.

If any of the above conditions fail, the Validation Service provider must return an error message according to schema eom-msg-vs-to-rs-001 and the transaction must be aborted with no further processing. Otherwise, the Validation Service provider stores the received data. In any case, the results of the verifications must be logged to an audit trail.



3. In response to the received POST, the Validation Service provider returns a XML message according to schema eom-msg-vs-to-rs-001 for MAMF (i.e. assigning a unique proposal reference on the element /eom-msg-vs-to-rs-001/payload/eom-data/vs-mandate-ref that the Debtor can subsequentely use on step 9), and advances the transaction state to “Waiting for Debtor” (Figure 19).

4. The Debtor enters into the Validation Service authentication homepage.

5. The Validation Service provider presents an authentication screen to the Debtor. The transaction state advances to “Waiting for authentication means” (Figure 19).

6. The Debtor enters the authentication credentials agreed with the Debtor Bank The authentication credentials may be composed of personalised device(s) and/or a set of procedures, including its personalized security features.

7. The Validation Service verifies the correctness of the authentication credentials provided and logs the event to an audit trail.

8. Depending on the results of the verification of the authentication credentials:

a. If the authentication credentials provided are correct and valid, the Validation Service presents a form to the Debtor to enter the identifier code set on step 3 or a list of pending e-Mandate requests.

b. If the authentication can not be correctly verified (even after a limited number of retrials of steps 6 and 7), an error message must be presented and the transaction must be aborted with no further processing.

9. The Debtor enters the proposal reference of the pending e-Mandate request to be authorized (or selects it from the list). If the IBAN is not already selected for the e-Mandate (it might have been set on the e-Mandates message received in step 1 or another account holder has already chosen on a previous authorization), the Debtor must choose one of the accounts for which he is one of the holders and has direct debits rights.

10. According to the data received,

a. if it is valid, the Debtor is asked to verify all the data fields of the e-mandate (e.g., the accuracy of the Creditor’s name and address, the Debtor’s account identifier, etc.) along with the mandatory national legal wording and then proceeds with the authorization. The authorization is defined [3], [4] as the set of procedures agreed between the Debtor and the Debtor Bank to assure the clear consent of the Debtor for the issuing, amendment or cancellation of an e-Mandate.

b. otherwise, the Debtor might be given another opportunity to enter the correct data by returning to step 8.a.

11. The Validation Service receives the authorization and proceeds as the following:

a. If multiple authorizations are required for that account (a typical B2B scenario), the Validation Service must gather enough authorizations from the other account holders, by repeating steps 4 through 11.


b. If all required authorizations were already gathered, the Validation Service performs an electronic signature of the XML e-Mandate data using the e-Operating Model X.509 signing certificate issued by an approved EPC Certification Authority. The electronic signature must be generated by a Signature Creation Application (SCA) compliant with CWA 14170 [27], using a Signature Creation Device adequate for performing Advanced Electronic Signatures. These devices are typically Hardware Security Modules with certification FIPS 140-1/2 Level 2 or higher, or Common Criteria EAL 3 or higher. The format of the electronic signature must be an enveloping XML signature in accordance with XML Advanced Electronic Signatures (XAdES) [31], in the form of Basic Electronic Signatures (XAdES-BES) conforming to the profile defined in Table 5.

Table 6: XAdES-BES profile for the EPC e-Operating Model

Element Value

CanonicalizationMethod @Algorithm = http://www.w3.org/2001/10/xml-exc-c14n#

SignatureMethod @Algorithm = http://www.w3.org/2000/09/xmldsig#rsa-sha1

Reference @URI = #message


Reference @URI = #keyInfo


KeyInfo

@Id = keyInfo Must include a X509Data element containing X509Certificate elements for the signing certificate and the certificates composing the trusted certification chain. The first X509Certificate must be the signing certificate and last must be the root Certification Authority.

Object @Id = message

The XAdES-BES signature will have the following sample structure: <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#message"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>...</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>...</X509Certificate>  <X509Certificate>...</X509Certificate>  </X509Data> </KeyInfo> <Object Id="message">...</Object> </Signature>

A complete XML sample message of eom-msg-vs-to-rs-002 can be found in annex B.9.


12. The Validation Service presents a confirmation message to the Debtor along with the e-Mandate data and a link to the Creditor website (URL provided at element /eom-msg-rs-to-vs-001/payload/eom-data/creditor-return-url on the message received in step 1). The transaction state advances to “Waiting for e-Mandate retrieval” (Figure 19).















e. The content of /eom-msg-rs-to-vs-002/header/operation is retrieval.


f. The value of elements /eom-msg-rs-to-vs-002/payload/eom-data/creditor-id and /eom-msg-rs-to-vs-002/payload/eom-data/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in either state “Waiting for e-Mandate retrieval” or “e-Mandate retrieved”14

If any of the above conditions fail, the Validation Service provider must return an error message according to schema

for the same Routing Service provider and for which a proposal operation has been processed previously.

eom-msg-vs-to-rs-002 and the transaction must be aborted with no further processing. In any case, the verification must be logged to an audit trail.

14. In response to the POST, the Validation Service provider returns a XML message according to schema eom-msg-rs-to-vs-002, embedding the XML enveloping signature performed on step 10 into element /eom-msg-rs-to-vs-002/payload/eom-data/signed-message. The transaction state is set to “e-Mandate retrieved” (Figure 19)



b. Otherwise, the Validation Service provider must close the connection immediately without receiving any further request data and logs the occurrence to an audit trail. The transaction must be aborted with no further processing.










14 This allows retrials of the operation retrieval by Creditors.




e. The content of /eom-msg-rs-to-vs-002/header/operation is acknowledge.

f. The value of elements /eom-msg-rs-to-vs-002/payload/eom-data/creditor-id and /eom-msg-rs-to-vs-002/payload/eom-data/creditor-request-id matches the value of the combined key creditor-id and creditor-request-id element of a transaction in state “Waiting for e-Mandate retrieval” for the same Routing Service provider and for which a proposal operation has been processed previously.

If any of the above conditions fail, the Validation Service provider must discard the message with no further processing. Otherwise, the Validation Service advances the transaction state to “e-Mandate acknowledged” (Figure 19). In any case, the verification must be logged to an audit trail.

Transactions not completed before the date and time set on field due-date of message eom-msg-rs-to-vs-001 may be discarded. In the absence of a specified value for due-date, Validation Service providers must consider a default timeout of 15 minutes for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow.

Figure 19 illustrates the state transitions for transactions in Validation Service providers according to the processing instructions described above.


Figure 19: State diagram of the Multiple Authorizations Message Flow for transactions in Validation Service

providers

4.6 Directory Service requirements In order to be an EPC e-Operating Model Directory Service provider, an applicant must comply with the following requirements:

1. A contractual agreement with the EPC must be established in order to be recognized as a legitimate EPC e-Operating Model Directory Service provider.

2. The Directory Service provider must establish a protocol to securely receive information about:

a. Current adherent BICs and respective URLs of its designated Validation Services; b. New adherent BICs and respective URLs of their designated Validation Services; c. Changes to URLs of registered BICs; d. Cessation of operation of BICs.


3. The Directory Service provider must offer to customer Routing Service providers at least one BIC resolution method, i.e., a method to obtain the Validation Service URL associated to a given BIC. This specification recommends two methods in Annex C. Nonetheless, a Directory Service provider may develop other equivalent methods as long as they ensure equivalent levels of availability, performance and throughput.

4. If the Directory Service provider distributes mapping data or results online, it must use a TLS X.509 server certificate on the web container to ensure the legitimacy of the web domain name and to enable the usage of HTTPS for data integrity and confidentiality. The choice of the issuing Certification Authority is up to the Directory Service provider. Incoming Routing Service providers must trust the issuing Certification Authority (or its certification trusted chain) in order to accept the certificate and initiate the communications.

5. If the Directory Service uses other out-of-band methods (e.g., a CD) to disseminate the mapping data, it must use a secure protocol that guarantees the authentication of the parties and the integrity of the distributed data.

4.7 Certification Authority requirements In order to be accepted and listed on the EPC portal as an EPC approved Certification Authority (CA), an applicant CA must comply with the following requirements:

1. Successfully pass the Approval Scheme for EPC Approved CAs [7]. 2. Be able to issue certificates in accordance with the customized certificate profiles defined

in Annex E. 3. Strictly follow the enrolment steps defined in Annex D for applying Routing Service and

Validation Service providers. 4. Offer an accessible Certificate Revocation List (CRL) for certificate status validation and

an Online Certificate Status Protocol (OCSP) service. 5. Strictly follow CWA 14167-1 (for Non-Qualified Certificates) [28] and TS 102 042 (for

Normalized Certificate Policy) [30].


5 MESSAGE SPECIFICATION

This chapter presents a comprehensive description of the EPC e-Operating Model XML messages. The following eight messages are defined:

1. eom-msg-cred-to-rs-001 – message sent by the Creditor to the Routing Service to initiate the e-Mandate request.

2. eom-msg-rs-to-vs-001 – message sent by the Routing Service to the Validation Service to route the e-Mandate request data.

3. eom-msg-vs-to-rs-001 – return message sent by the Validation Service to the Routing Service.

4. eom-msg-rs-to-cred-001 – return message sent by the Routing Service to the Creditor.

5. eom-msg-cred-to-rs-002 – message sent by the Creditor to the Routing Service to retrieve the e-Mandate.

6. eom-msg-rs-to-vs-002 – message sent by the Routing Service to the Validation Service to retrieve the e-Mandate.

7. eom-msg-vs-to-rs-002 – return message sent by the Validation Service to the Routing Service containing the e-Mandate.

8. eom-msg-rs-to-cred-002 – return message sent by the Routing Service to the Creditor containing the e-Mandate.

5.1 Notation Conventions The multiplicity (or the range of occurrences) of each element, is defined by the “Mult” column in the format “[a..b]”, where:

• a, is the minimum number of occurrences and

• b, is the maximum number of occurrences. Value “n” means an unlimited number of occurrences

Conditional relationships between components of a message element (for example, either component 1 or component 2 must be present, but not both) are indicated in the “Mult” column as “{Or” and “Or}”.

When an element contains sub-elements these are noted with a plus sign (“+”) per level in the “Element” column. An element name followed by the sign “@” and a label, means that the label is an attribute of that element.

5.2 EPC e-Operating Model Messages

5.2.1 eom-msg-cred-to-rs-001

The message type eom-msg-cred-to-rs-001 is generated and sent by Creditors to Routing Services in order to initiate e-Mandate proposal requests. The data elements that compose this message type are detailed in Table 7 and the corresponding XML schema is presented in annex A.3.

Table 7: Description of message eom-msg-cred-to-rs-001


Mult Element Format/Type Description

[1..1] eom-msg-cred-to-rs-001

[1..1] + header

[1..1] + header@version string Version of message format.

Usage Rule: Must have the value 1.1.

[1..1] ++ date dateTime

Message timestamp.

Usage Rule: Current date and time of generation of the message. Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20].

[1..1] ++ service Service Service identification tip.

Usage Rule: Must have the value mandate.

[1..1] ++ operation Operation Operation identification tip.

Usage Rule: Must have the value proposal.

[1..1] + payload

[1..1] ++ eom-data

[1..1] +++ vs-address string Addressing information of the Validation Service.

Usage Rule: Must have the Bank Identifier Code (BIC) of the Debtor Bank.

[1..1] +++ vs-address@type string Type of addressing information of the Validation Service.

Usage Rule: Must have the value BIC.

[1..1] +++ creditor-id ReferenceID

Identifier of the Creditor requesting the e-Mandate.

Usage Rule: Must be set in accordance with the rules defined for field AT-02 (Identifier of the Creditor) in [2] §1.6.2.

[1..1] +++ creditor-request-id ReferenceID Creditor’s request identifier.

Usage Rule: This identifier must be unique per request.

[1..1] +++ creditor-return-url URL

Creditor’s website URL for later redirection of the Debtor’s browser back to the Creditor.

Usage Rule: Must contain sufficient HTTP GET parameters to be able to resume the transaction at a later step.

[0..1] +++ due-date dateTime

Maximum allowed date set by the Creditor for the whole transaction to be completed before it is discarded.

Usage Rule: Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. In the absence of a specified value, a default timeout of 15 minutes must be considered for the Single Authorization Message Flow and 48 hours for the Multiple Authorizations Message Flow.



[0..n] +++ other elements any Allows inclusion of additional customized element(s).

[0..1] ++ extended-data

[0..n] +++ other elements any Allows inclusion of additional customized elements.

[1..1] ++ message anyType e-Mandate request message.


5.2.2 eom-msg-rs-to-vs-001

The message type eom-msg-rs-to-vs-001 is generated and sent by Routing Services to Validation Services in order to route the e-Mandate request data. The data elements that compose this message type are detailed in Table 8 and the corresponding XML schema is presented in annex A.4.

Table 8: Description of message eom-msg-rs-to-vs-001


[1..1] eom-msg-rs-to-vs-001

[1..1] + header




Message timestamp.



Usage Rule: must have the value mandate.



[1..1] + payload

[1..1] ++ eom-data

[1..1] +++ vs-address string

Addressing information of the Validation Service.

Usage Rule: The Bank Identifier Code (BIC) of the Debtor Bank. Must have the same value as element vs-address of eom-msg-cred-to-rs-001

[1..1] +++ vs-address@type string

Type of addressing information of the Validation Service.

Usage Rule: Must have the value BIC, the same value as attribute type of element vs-address of eom-msg-cred-to-rs-001

[1..1] +++ creditor-id ReferenceID Identification of the Creditor requesting the e-Mandate.

Usage Rule: Must have the same value as element creditor-id of eom-msg-cred-to-rs-001


Usage Rule: Must have the same value as element creditor-request-id of eom-msg-cred-to-rs-001



[1..1] +++ creditor-return-url URL

Creditor’s website URL for later redirection of the Debtor’s browser back to Creditor.

Usage Rule: Must have the same value as element creditor-return-url of eom-msg-cred-to-rs-001

[1..1] +++ due-date dateTime

Maximum allowed date set by the Creditor for the whole transaction to be completed before it is discarded.

Usage Rule: Must be in UTC (suffix Z) or include timezone information, as defined in RFC 3339 [20]. Must have the same value as element due-date of eom-msg-cred-to-rs-001 if present.

[1..1] ++ message anyType e-Mandate request message.

Usage Rule: Must have the same content as element message of eom-msg-cred-to-rs-001


5.2.3 eom-msg-vs-to-rs-001

The message type eom-msg-vs-to-rs-001 is generated and sent by Validation Services to Routing Services in order to return operational data or report errors. The data elements that compose this message type are detailed in Table 9 and the corresponding XML schema is presented in annex A.5.

Table 9: Description of message eom-msg-vs-to-rs-001


[1..1] eom-msg-vs-to-rs-001

[1..1] + header




Message timestamp.



Usage Rule: Must have value mandate.


Usage Rule: Must have value proposal.

[1..1] + payload

[1..1] ++ status int Response status.

Usage Rule: Values restricted to 0 (meaning “OK”) or the error codes defined in section 5.3.

{Or ++ eom-data Usage Rule: This element must be present if status value is 0 (OK).


Usage Rule: Must have the same value as element creditor-id of eom-msg-rs-to-vs-001


Usage Rule: Must have the same value as element creditor-request-id of eom-msg-rs-to-vs-001

{Or +++ vs-url URL

Validation Service’s website URL (specific to this transaction) which will be used to redirect the Debtor’s browser.

Usage Rule: Must be used if the Validation Service chooses to use the Single Authorization Message Flow. Must contain sufficient HTTP GET parameters to be able to resume the transaction at a later step.



Or} +++ vs-mandate-ref ReferenceID

Reference assigned by the Validation Service for the e-Mandate request to be used by the account holders of the Debtor to authorize it.

Usage Rule: Must be used if the Validation Service chooses to use the Multiple Authorizations Message Flow..

Or} ++ error-details Usage Rule: This element must be present if status value is different from 0.

[0..1] +++ description string Error description.

Usage Rule: Information that may compromise security must not be disclosed. Language used must be English.

[0..1] +++ hint string Hint about the cause of the problem.


[0..1] +++ message anyType e-Mandate error message.

[0..1] +++ src-message NestedMessage

Original message eom-msg-rs-to-vs-001 received by the Validation Service.

Usage Rule: If the element is to be used, the original message must be included unmodified.



5.2.4 eom-msg-rs-to-cred-001

The message type eom-msg-rs-to-cred-001 is generated and sent by Routing Services to Creditors in order to return operational data or report errors. The data elements that compose this message type are detailed in Table 10 and the corresponding XML schema is presented in annex A.6.

Table 10: Description of message eom-msg-rs-to-cred-001


[1..1] eom-msg-rs-to-cred-001

[1..1] + header




Message timestamp.






[1..1] + payload





Usage Rule: Must have the same value as element creditor-id of eom-msg-vs-to-rs-001


Usage Rule: Must have the same value as element creditor-request-id of eom-msg-vs-to-rs-001

{Or +++ vs-url URL

Validation Service’s website URL (specific to this transaction) which will be used to redirect Debtor’s browser. If present, it means that the Validation Service has chosen to use the Single Authorization Message Flow.

Usage Rule: Must have the same value as element vs-url of eom-msg-vs-to-rs-001



Or} +++ vs-mandate-ref ReferenceID

Reference assigned by the Validation Service for the e-Mandate request to be used by the account holders of the Debtor to authorize it. If present, it means that the Validation Service has chosen to use the Multiple Authorizations Message Flow.

Usage Rule: Must have the same value as element vs-mandate-ref of eom-msg-vs-to-rs-001.







[0..1] +++ message anyType

e-Mandate error message.

Usage Rule: If the element is to be used, the e-Mandate error message received in eom-msg-vs-to-rs-001 must be included unmodified.


Original message eom-msg-cred-to-rs-001 received by the Routing Service.






5.2.5 eom-msg-cred-to-rs-002

The message type eom-msg-cred-to-rs-002 is generated and sent by Creditors to Routing Services in order to retrieve an e-Mandate. The data elements that compose this message type are detailed below in Table 11 and the corresponding XML schema is presented in annex A.7.

Table 11: Description of message eom-msg-cred-to-rs-002


[1..1] eom-msg-cred-to-rs-002

[1..1] + header




Message timestamp.




[1..1] ++ operation Operation

Operation identification tip.

Usage Rule: Must have the value retrieval to retrieve the e-Mandate or acknowledge to acknowledge the reception of the e-Mandate.

[1..1] + payload

[1..1] ++ eom-data









5.2.6 eom-msg-rs-to-vs-002

The message type eom-msg-rs-to-vs-002 is generated and sent by Creditors to Routing Services in order to retrieve an e-Mandate. The data elements that compose this message type are detailed below in Table 12 and the corresponding XML schema is presented in annex A.8.

Table 12: Description of message eom-msg-rs-to-vs-002


[1..1] eom-msg-rs-to-vs-002

[1..1] + header




Message timestamp.




[1..1] ++ operation Operation

Operation identification tip.

Usage Rule: Must have the value retrieval to retrieve the e-Mandate or acknowledge to acknowledge the reception of the e-Mandate.

[1..1] + payload

[1..1] ++ data



[1..1] +++ creditor-request-id ReferenceID

Creditor’s request identifier.



5.2.7 eom-msg-vs-to-rs-002

The message type eom-msg-vs-to-rs-002 is generated and sent by Routing Services to Validation Services in order to return an e-Mandate. The data elements that compose this message type are detailed below in Table 13 and the corresponding XML schema is presented in annex A.9.

Table 13: Description of message eom-msg-vs-to-rs-002


[1..1] eom-msg-vs-to-rs-002

[1..1] + header




Message timestamp.





Usage Rule: Must have the value retrieval.

[1..1] + payload





Usage Rule: Must have the same value as element creditor-id of eom-msg-rs-to-vs-002


Usage Rule: Must have the same value as element creditor-request-id of eom-msg-rs-to-vs-002

[1..1] +++ signed-message XmlSignature e-Mandate with an enveloping XML signature.

Usage Rule: XML signature must be compliant with XAdES-BES.

Or} ++ error-details Usage Rule: This element must be present if status value is different from “0”.







[0..1] +++ message anyType e-Mandate error message.


Original message eom-msg-rs-to-vs-002 received by the Validation Service.




5.2.8 eom-msg-rs-to-cred-002

The message type eom-msg-rs-to-cred-002 is generated and sent by Routing Services to Creditors in order to return an e-Mandate. The data elements that compose this message type are detailed below in Table 14 and the corresponding XML schema is presented in annex A.10.

Table 14: Description of message eom-msg-rs-to-cred-002


[1..1] eom-msg-rs-to-cred-002

[1..1] + header




Message timestamp.





Usage Rule: Must have the value retrieval.

[1..1] + payload






[1..1] +++ creditor-request-id ReferenceID

Creditor’s request identifier.


[1..1] +++ signed-message XmlSignature e-Mandate with an enveloping XML signature.

Usage Rule: XML signature must be compliant with XAdES-BES.









[0..1] +++ message anyType

e-Mandate error message.

Usage Rule: If the element is to be used, the e-Mandate error message received in eom-msg-vs-to-rs-001 must be included unmodified.


Original message eom-msg-vs-to-rs-002 received by the Routing Service.




5.3 Error codes This section presents a list of codes for possible errors to be used on the EPC e-Operating Model response messages, namely:

• eom-msg-vs-to-rs-001

• eom-msg-rs-to-cred-001

• eom-msg-vs-to-rs-002

• eom-msg-rs-to-cred-002

The error codes are listed in Table 15. The four rightmost columns indicate which response messages may report the identified errors.

Table 15: Error codes

Code Name Reason


eom-msg-rs-to-cred-001



100 GenericError Generic error. X X X X 101 BusinessError A specific error at the business level has occurred. X X X X 102 InternalServerError Internal server error. X X X X 103 UnkownError An unknown error has occurred. X X X X 104 OperationTimeout The defined transaction timeout was reached. X X X X 105 MissedDueDate The due date defined by the Creditor was reached. X X X X 106 BrokenSession The communication session was abruptly closed. X X X X 107 ErrorOnValidationService The Validation Service has returned an error. X X 108 UnavailableValidationService Routing Service failed to connect to the Validation Service. X X 200 GenericDataError Data provided has one or more errors. X X X X 201 BadFormedXML The XML message is not a well formed XML document. X X X X

202 InvalidXML The XML message is not valid according to the corresponding XML schema. X X X X

203 InvalidCharacterSet The message character is invalid or unspecified. X X X X 204 IncompleteData One or more data elements are missing. X X X X 205 BadFormatData One or more data elements are incorrectly formatted. X X X X 206 InvalidService The requested service is unknown or not supported. X X X X 207 ServiceNotAllowed The requester is not allowed to use this service. X X X X 208 InvalidOperation The requested operation is unknown or not supported. X X X X 209 OperationNotAllowed The requester is not allowed to use this operation. X X X X 210 InvalidVersion This message version is not supported. X X X X 211 BankIdentifierIncorrect Bank identifier incorrect (i.e. invalid BIC). X 212 InvalidCreditorID Invalid or incorrect Creditor ID. X X

213 IlegitimateCreditorID The Creditor ID does not correspond to the authenticated Creditor. X X

214 InvalidCreditorRequestID This request identifier has already been used by this Creditor. X X

215 InvalidValidationServiceRequestID This request identifier is invalid or unknown to the Validation Service. X

216 BadFormedURL The received URL is not a well formed URL. X X


Code Name Reason





217 BicResolutionError An error has occurred when trying to resolve the BIC. X

218 WrongValidationServiceForBic The BIC provided does not correspond to the resolved Validation Service. X

300 GeneralAuthenticationFailure A general error occurred while performing an authentication. X X X X

301 DebtorAuthenticationFailed Debtor did not present the correct authentication means to the Validation Service. X X

302 DebtorAuthorizationFailed Debtor has not authorized the e-Mandate. X X

303 InvalidRSAuthenticationCredentials Invalid authentication credentials presented by the Routing Service. X X

400 GeneralCryptographicError A general error occurred while performing a cryptographic operation. X X X X

401 WeakCipherSuites The system does not support the minimum cryptographic algorithm and/or the minimum key length needed to establish a secure connection.

X X X X

402 InvalidElectronicSignature Invalid electronic signature of the e-Mandate. X

403 InvalidDigestValue Invalid digest value on the electronic signature of the e-Mandate. X

404 IncompleteCertificateChain The certificate chain does not include all the certificates necessary to reach a trusted Root CA. X X X X

405 RevokedCertificate The certificate has been revoked. X X X X 406 ExpiredCertficate The certificate expiration date has been reached. X X X X

407 NotYetValidCertificate The initial validity date of the certificate is later than the current date. X X X X

408 InvalidCertificateChain At least one of the certificates in this certificate chain is invalid (i.e. is revoked, expired, not yet valid, etc.). X X X X

409 InvalidCertificate The certificate is invalid (i.e. it's revoked, expired, is not valid yet, etc.). X X X X

410 UntrustedCertificate The certificate has not been issued or signed by a trusted CA. X X X X

411 UntrustedCertificateChain A trusted certificate chain could not be achived for the certificate. X X X X

412 InvalidCertificateUsage The certificate does not include a valid "key usage" and/or policy to the aim which it is intended to be used. X X X X

413 CantCheckCertificateStatus Could not get the certificate status information, i.e., could not contact the corresponding OCSP server or get an updated CRL. X X X X

414 UnsupportedCryptoAlgorithm The cryptographic algorithm is not formatted. X X X X

The error codes listed above in Table 15 are to be used on the status element of EPC e-Operating Model response messages. A value of 0 (zero) means successful processing while any other value indicates that an error has occurred.

The BusinessError code is used to encapsulate errors occurred at the specific business logic layer. The returning business error message must be nested under the message element in error-details, while the original EPC e-Operating Model message is recommended to be nested under the src-message element.


For security reasons, parties receiving errors from other parties must not forward any error details to any other party that may be holding for a response. This means that a Routing Service provider must not forward EPC e-OperatingModel error codes and possible descriptions and hints returned by Validation Services to holding Creditors. In this situation, it is appropriate to return an ErrorOnValidationService error code. Equivalently, a Creditor must not display any EPC e-OperatingModel error codes and possible descriptions and hints returned by Routing Services to holding Debtors.


6 TERMS USED IN THE DOCUMENT

Term Definition

Adherence Agreement The agreement to be completed as part of the process by which an entity applies to become a Participant.

Bank Identifier Code (BIC)

An 8 or 11 character ISO code assigned by SWIFT and used to identify a financial institution in financial transactions (ISO 9362).

BIC See ‘Bank Identifier Code’.

Certificate Public key of a user, together with some other information, rendered un-forgeable by encipherment with the private key of the certification authority which issued it [30].

Certificate Revocation List

A signed list of revoked certificates periodically issued by a Certification Authority.

Certification Authority Entity trusted by one or more users to create and assign certificates.

Creditor Defined in [3].

Creditor Bank Defined in [3].

CRL See ‘Certificate Revocation List’.

Debtor Defined in [3].

Debtor Bank Defined in section [3].

Directory Service Defined in section [3].

Disclosure Disclosure occurs when sensitive data is retrieved by persons which are not supposed to have access to it.

EPC The European Payments Council (http://www.europeanpaymentscouncil.eu).

EPC Approved Certification Authority A Certification Authority compliant with the requirements defined by the EPC.

HTTP Hypertext Transfer Protocol.

HTTPS Hypertext Transfer Protocol over TLS.

IBAN

An expanded version of the basic bank account number (BBAN) intended for use internationally that uniquely identifies an individual account at a specific financial institution in a particular country (ISO 13616, EBS 204).

As of late-2005, ISO is in the process of aligning the ISO 13616 Standard with the European Standard EBS 204. In due course the ISO Standard will replace the EBS standard.

OCSP See ‘Online Certificate Status Protocol’.


Term Definition

Online Certificate Status Protocol A protocol designed to verify the current status of a given certificate.

Operational BIC Is the BIC that the Debtor receives from the Debtor Bank.

PKI Public Key Infrastructure.

Repudiation Repudiation occurs when someone claims to have not performed a disputed operation that he actually performed. Reversely, repudiation is also about being able to refute the validity of forged operations.

Routing Service Defined [3]. For the sake of simplicity, the terms “Routing Service” and “Routing Service Provider” may be used interchangeably throughout this document.

Routing Service Providers See ‘Routing Service’.

SDD See ‘SEPA Direct Debit Scheme’.

SEPA Direct Debit Scheme

The SEPA Direct Debit Scheme is the payments scheme for making direct debits across SEPA, as set out in the SEPA Direct Debit Scheme Rulebook.

SEPA Direct Debit Scheme Rulebook

The Rulebook setting out rules and business standards for the SEPA Direct Debit Scheme.

Tampering An attack in which data is modified or corrupted while in transit between two parties.

TLS Transport Layer Security.

URL Uniform Resource Locator.

Validation Service Defined in [3]. For the sake of simplicity, the terms “Validation Service” and “Validation Service Provider” may be used interchangeably throughout this document.

Validation Service Providers See ‘Validation Service’.

W3C World Wide Web Consortium (http://www.w3c.org)

XML Extensible Markup Language.


ANNEX A XML SCHEMAS

The set of XML messages defined for the EPC e-Operating Model are described on XML schemas oriented to a modular and flexible design. The messages are segmented in several schemas which make use of the “include” and “import” schema mechanisms. Figure 20 illustrates the relationships between the different XML schema modules.

Figure 20: XML schema modules for the EPC e-Operating Model

The target namespace set for this version of the e-Operating Model schemas is http://www.europeanpaymentscouncil.eu/ns/2008-07/eom.

A.1 eom-common.xsd

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:complexType name="Message" abstract="true"> 7


<xs:annotation> 8 <xs:documentation>Common message skeleton for all EPC e-Operating Model 9 messages.</xs:documentation> 10 </xs:annotation> 11 <xs:sequence> 12 <xs:element name="header" type="Header"/> 13 </xs:sequence> 14 </xs:complexType> 15 16 <xs:complexType name="Payload" abstract="true"/> 17 18 <xs:complexType name="Header"> 19 <xs:sequence> 20 <xs:element name="date" type="xs:dateTime"/> 21 <xs:element name="service" type="Service"/> 22 <xs:element name="operation" type="Operation"/> 23 </xs:sequence> 24 <xs:attribute name="version" type="xs:string" use="required"/> 25 </xs:complexType> 26 27 <xs:simpleType name="Service"> 28 <xs:restriction base="xs:string"/> 29 </xs:simpleType> 30 31 <xs:simpleType name="Operation"> 32 <xs:restriction base="xs:string"/> 33 </xs:simpleType> 34 35 <xs:complexType name="VSAddress"> 36 <xs:simpleContent> 37 <xs:extension base="xs:string"> 38 <xs:attribute name="type" type="xs:string" use="required"/> 39 </xs:extension> 40 </xs:simpleContent> 41 </xs:complexType> 42 43 <xs:simpleType name="ReferenceID"> 44 <xs:restriction base="xs:string"> 45 <xs:minLength value="1"/> 46 <xs:maxLength value="256"/> 47 </xs:restriction> 48 </xs:simpleType> 49 50 <xs:simpleType name="URL"> 51 <xs:restriction base="xs:anyURI"> 52 <xs:minLength value="1"/> 53 <xs:maxLength value="2048"/> 54 </xs:restriction> 55 </xs:simpleType> 56 57 <xs:complexType name="ExtendedData"> 58 <xs:sequence> 59 <xs:any namespace="##other" processContents="skip" minOccurs="0" 60 maxOccurs="unbounded"/> 61 </xs:sequence> 62 </xs:complexType> 63 64 <xs:complexType name="NestedMessage"> 65 <xs:sequence> 66 <xs:any namespace="http:// www.europeanpaymentscouncil.eu/ns/2008-07/eom" 67 processContents="skip"/> 68 </xs:sequence> 69 </xs:complexType> 70 71 <xs:complexType name="XmlSignature"> 72 <xs:sequence> 73 <xs:any namespace="http://www.w3.org/2000/09/xmldsig#" processContents="skip"/> 74 </xs:sequence> 75 </xs:complexType> 76


77 </xs:schema> 78


A.2 eom-status.xsd

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:include schemaLocation="eom-common.xsd"/> 7 8 <xs:complexType name="ErrorDetails"> 9 <xs:sequence> 10 <xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1"/> 11 <xs:element name="hint" type="xs:string" minOccurs="0" maxOccurs="1"/> 12 <xs:element name="message" type="NestedMessage" minOccurs="0" maxOccurs="1"/> 13 <xs:element name="src-message" type="NestedMessage" minOccurs="0" maxOccurs="1"/> 14 <xs:any namespace="##other" processContents="skip" minOccurs="0" 15 maxOccurs="unbounded"/> 16 </xs:sequence> 17 </xs:complexType> 18 19 </xs:schema> 20


A.3 eom-msg-cred-to-rs-001.xsd

Figure 21: Graphical XML schema of message eom-msg-cred-to-rs-001

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:annotation> 7 <xs:documentation> 8 e-Operating Model message cred-to-rs-001, to be sent by Creditors to 9 Routing Services. 10 </xs:documentation> 11 </xs:annotation> 12 13 <xs:include schemaLocation="eom-common.xsd"/> 14 15 <xs:element name="eom-msg-cred-to-rs-001" type="MessageCredToRs001"/> 16 17 <xs:complexType name="MessageCredToRs001"> 18 <xs:complexContent> 19 <xs:extension base="Message"> 20 <xs:sequence> 21 <xs:element name="payload" type="PayloadCredToRs001"/> 22 </xs:sequence> 23 </xs:extension> 24 </xs:complexContent> 25 </xs:complexType> 26


27 <xs:complexType name="PayloadCredToRs001"> 28 <xs:complexContent> 29 <xs:extension base="Payload"> 30 <xs:sequence> 31 <xs:element name="eom-data" type="DataCredToRs001"/> 32 <xs:element name="extended-data" type="ExtendedData" minOccurs="0" 33 maxOccurs="1"/> 34 <xs:element name="message" type="xs:anyType"/> 35 </xs:sequence> 36 </xs:extension> 37 </xs:complexContent> 38 </xs:complexType> 39 40 <xs:complexType name="DataCredToRs001"> 41 <xs:sequence> 42 <xs:element name="vs-address" type="VSAddress"/> 43 <xs:element name="creditor-id" type="ReferenceID"/> 44 <xs:element name="creditor-request-id" type="ReferenceID"/> 45 <xs:element name="creditor-return-url" type="URL"/> 46 <xs:element name="due-date" type="xs:dateTime" minOccurs="0" 47 maxOccurs="1"/> 48 <xs:any namespace="##other" processContents="skip" minOccurs="0" 49 maxOccurs="unbounded"/> 50 </xs:sequence> 51 </xs:complexType> 52 53 </xs:schema> 54


A.4 eom-msg-rs-to-vs-001.xsd

Figure 22: Graphical XML schema of message eom-msg-rs-to-vs-001

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:annotation> 7 <xs:documentation> 8 e-Operating Model message rs-to-vs-001, to be sent by Routing Services to 9 Validation Services. 10 </xs:documentation> 11 </xs:annotation> 12 13 <xs:include schemaLocation="eom-common.xsd"/> 14 15 <xs:element name="eom-msg-rs-to-vs-001" type="MessageRsToVs001"/> 16 17 <xs:complexType name="MessageRsToVs001"> 18 <xs:complexContent> 19 <xs:extension base="Message"> 20 <xs:sequence> 21 <xs:element name="payload" type="PayloadRsToVs001"/> 22 </xs:sequence> 23 </xs:extension> 24 </xs:complexContent> 25 </xs:complexType> 26 27 <xs:complexType name="PayloadRsToVs001"> 28 <xs:complexContent> 29 <xs:extension base="Payload"> 30 <xs:sequence> 31 <xs:element name="eom-data" type="DataRsToVs001"/> 32


<xs:element name="message" type="xs:anyType"/> 33 </xs:sequence> 34 </xs:extension> 35 </xs:complexContent> 36 </xs:complexType> 37 38 <xs:complexType name="DataRsToVs001"> 39 <xs:sequence> 40 <xs:element name="vs-address" type="VSAddress"/> 41 <xs:element name="creditor-id" type="ReferenceID"/> 42 <xs:element name="creditor-request-id" type="ReferenceID"/> 43 <xs:element name="creditor-return-url" type="URL"/> 44 <xs:element name="due-date" type="xs:dateTime" minOccurs="0" 45 maxOccurs="1"/> 46 </xs:sequence> 47 </xs:complexType> 48 49 </xs:schema> 50


A.5 eom-msg-vs-to-rs-001.xsd

Figure 23: Graphical XML schema of message eom-msg-vs-to-rs-001

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:annotation> 7 <xs:documentation> 8 e-Operating Model message vs-to-rs-001, to be sent by Validation Services to 9 Routing Services. 10 </xs:documentation> 11 </xs:annotation> 12 13 <xs:include schemaLocation="eom-common.xsd"/> 14 <xs:include schemaLocation="eom-status.xsd"/> 15 16 <xs:element name="eom-msg-vs-to-rs-001" type="MessageVsToRs001"/> 17 18 <xs:complexType name="MessageVsToRs001"> 19 <xs:complexContent> 20 <xs:extension base="Message"> 21 <xs:sequence> 22 <xs:element name="payload" type="PayloadVsToRs001"/> 23 </xs:sequence> 24


</xs:extension> 25 </xs:complexContent> 26 </xs:complexType> 27 28 <xs:complexType name="PayloadVsToRs001"> 29 <xs:sequence> 30 <xs:element name="status" type="StatusCodeVsToRs001"/> 31 <xs:choice> 32 <xs:element name="eom-data" type="DataVsToRs001"/> 33 <xs:element name="error-details" type="ErrorDetails"/> 34 </xs:choice> 35 </xs:sequence> 36 </xs:complexType> 37 38 <xs:complexType name="DataVsToRs001"> 39 <xs:sequence> 40 <xs:element name="creditor-id" type="ReferenceID"/> 41 <xs:element name="creditor-request-id" type="ReferenceID"/> 42 <xs:choice> 43 <xs:element name="vs-url" type="URL"/> 44 <xs:element name="vs-mandate-ref" type="ReferenceID"/> 45 </xs:choice> 46 </xs:sequence> 47 </xs:complexType> 48 49 <xs:simpleType name="StatusCodeVsToRs001"> 50 <xs:restriction base="xs:int"> 51 <xs:enumeration value="0"/>  52 <xs:enumeration value="100"/>  53 <xs:enumeration value="101"/>  54 <xs:enumeration value="102"/>  55 <xs:enumeration value="103"/>  56 <xs:enumeration value="104"/>  57 <xs:enumeration value="105"/>  58 <xs:enumeration value="200"/>  59 <xs:enumeration value="201"/>  60 <xs:enumeration value="202"/>  61 <xs:enumeration value="203"/>  62 <xs:enumeration value="204"/>  63 <xs:enumeration value="205"/>  64 <xs:enumeration value="206"/>  65 <xs:enumeration value="207"/>  66 <xs:enumeration value="208"/>  67 <xs:enumeration value="209"/>  68 <xs:enumeration value="210"/>  69 <xs:enumeration value="216"/>  70 <xs:enumeration value="218"/>  71 <xs:enumeration value="300"/>  72 <xs:enumeration value="303"/>  73 <xs:enumeration value="400"/>  74 <xs:enumeration value="401"/>  75 <xs:enumeration value="404"/>  76 <xs:enumeration value="405"/>  77 <xs:enumeration value="406"/>  78 <xs:enumeration value="407"/>  79 <xs:enumeration value="408"/>  80 <xs:enumeration value="409"/>  81 <xs:enumeration value="410"/>  82 <xs:enumeration value="411"/>  83 <xs:enumeration value="412"/>  84 <xs:enumeration value="413"/>  85 <xs:enumeration value="414"/>  86 </xs:restriction> 87 </xs:simpleType> 88 89 </xs:schema> 90


A.6 eom-msg-rs-to-cred-001.xsd

Figure 24: Graphical XML schema of message eom-msg-rs-to-cred-001

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:annotation> 7 <xs:documentation> 8 e-Operating Model message rs-to-cred-001, to be sent by Routing Services to 9 Creditors. 10 </xs:documentation> 11 </xs:annotation> 12 13 <xs:include schemaLocation="eom-common.xsd"/> 14 <xs:include schemaLocation="eom-status.xsd"/> 15 16 <xs:element name="eom-msg-rs-to-cred-001" type="MessageRsToCred001"/> 17 18


<xs:complexType name="MessageRsToCred001"> 19 <xs:complexContent> 20 <xs:extension base="Message"> 21 <xs:sequence> 22 <xs:element name="payload" type="PayloadRsToCred001"/> 23 </xs:sequence> 24 </xs:extension> 25 </xs:complexContent> 26 </xs:complexType> 27 28 <xs:complexType name="PayloadRsToCred001"> 29 <xs:sequence> 30 <xs:element name="status" type="StatusCodeRsToCred001"/> 31 <xs:choice> 32 <xs:element name="eom-data" type="DataRsToCred001"/> 33 <xs:element name="error-details" type="ErrorDetails"/> 34 </xs:choice> 35 <xs:element name="extended-data" type="ExtendedData" minOccurs="0" maxOccurs="1"/> 36 </xs:sequence> 37 </xs:complexType> 38 39 <xs:complexType name="DataRsToCred001"> 40 <xs:sequence> 41 <xs:element name="creditor-id" type="ReferenceID"/> 42 <xs:element name="creditor-request-id" type="ReferenceID"/> 43 <xs:choice> 44 <xs:element name="vs-url" type="URL"/> 45 <xs:element name="vs-mandate-ref" type="ReferenceID"/> 46 </xs:choice> 47 <xs:any namespace="##other" processContents="skip" minOccurs="0" 48 maxOccurs="unbounded"/> 49 </xs:sequence> 50 </xs:complexType> 51 52 <xs:simpleType name="StatusCodeRsToCred001"> 53 <xs:restriction base="xs:int"> 54 <xs:enumeration value="0"/>  55 <xs:enumeration value="100"/>  56 <xs:enumeration value="101"/>  57 <xs:enumeration value="102"/>  58 <xs:enumeration value="103"/>  59 <xs:enumeration value="104"/>  60 <xs:enumeration value="105"/>  61 <xs:enumeration value="106"/>  62 <xs:enumeration value="107"/>  63 <xs:enumeration value="200"/>  64 <xs:enumeration value="201"/>  65 <xs:enumeration value="202"/>  66 <xs:enumeration value="203"/>  67 <xs:enumeration value="204"/>  68 <xs:enumeration value="205"/>  69 <xs:enumeration value="206"/>  70 <xs:enumeration value="207"/>  71 <xs:enumeration value="208"/>  72 <xs:enumeration value="209"/>  73 <xs:enumeration value="210"/>  74 <xs:enumeration value="211"/>  75 <xs:enumeration value="212"/>  76 <xs:enumeration value="213"/>  77 <xs:enumeration value="214"/>  78 <xs:enumeration value="216"/>  79 <xs:enumeration value="217"/>  80 <xs:enumeration value="300"/>  81 <xs:enumeration value="400"/>  82 <xs:enumeration value="401"/>  83 <xs:enumeration value="404"/>  84 <xs:enumeration value="405"/>  85 <xs:enumeration value="406"/>  86 <xs:enumeration value="407"/>  87


<xs:enumeration value="408"/>  88 <xs:enumeration value="409"/>  89 <xs:enumeration value="410"/>  90 <xs:enumeration value="411"/>  91 <xs:enumeration value="412"/>  92 <xs:enumeration value="413"/>  93 <xs:enumeration value="414"/>  94 </xs:restriction> 95 </xs:simpleType> 96 97 </xs:schema> 98


A.7 eom-msg-cred-to-rs-002.xsd

Figure 25: Graphical XML schema of message eom-msg-cred-to-rs-002

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:annotation> 7 <xs:documentation> 8 e-Operating Model message cred-to-rs-002, to be sent by Creditors to 9 Routing Services. 10 </xs:documentation> 11 </xs:annotation> 12 13 <xs:include schemaLocation="eom-common.xsd"/> 14 15 <xs:element name="eom-msg-cred-to-rs-002" type="MessageCredToRs002"/> 16 17 <xs:complexType name="MessageCredToRs002"> 18 <xs:complexContent> 19 <xs:extension base="Message"> 20 <xs:sequence> 21 <xs:element name="payload" type="PayloadCredToRs002"/> 22 </xs:sequence> 23 </xs:extension> 24 </xs:complexContent> 25 </xs:complexType> 26 27 <xs:complexType name="PayloadCredToRs002"> 28 <xs:complexContent> 29 <xs:extension base="Payload"> 30 <xs:sequence> 31 <xs:element name="eom-data" type="DataCredToRs002"/> 32 <xs:element name="extended-data" type="ExtendedData" minOccurs="0" 33 maxOccurs="1"/> 34 </xs:sequence> 35 </xs:extension> 36 </xs:complexContent> 37 </xs:complexType> 38 39


<xs:complexType name="DataCredToRs002"> 40 <xs:sequence> 41 <xs:element name="creditor-id" type="ReferenceID"/> 42 <xs:element name="creditor-request-id" type="ReferenceID"/> 43 <xs:any namespace="##other" processContents="skip" minOccurs="0" 44 maxOccurs="unbounded"/> 45 </xs:sequence> 46 </xs:complexType> 47 48 </xs:schema> 49


A.8 eom-msg-rs-to-vs-002.xsd

Figure 26: Graphical XML schema of message eom-msg-rs-to-vs-002

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 2 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 3 elementFormDefault="qualified" 4 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 5 6 <xs:annotation> 7 <xs:documentation>e-Operating Model message rs-to-vs-002, to be sent by Routing 8 Services to Validation Services.</xs:documentation> 9 </xs:annotation> 10 11 <xs:include schemaLocation="eom-common.xsd"/> 12 13 <xs:element name="eom-msg-rs-to-vs-002" type="MessageRsToVs002"/> 14 15 <xs:complexType name="MessageRsToVs002"> 16 <xs:complexContent> 17 <xs:extension base="Message"> 18 <xs:sequence> 19 <xs:element name="payload" type="PayloadRsToVs002"/> 20 </xs:sequence> 21 </xs:extension> 22 </xs:complexContent> 23 </xs:complexType> 24 25 <xs:complexType name="PayloadRsToVs002"> 26 <xs:complexContent> 27 <xs:extension base="Payload"> 28 <xs:sequence> 29 <xs:element name="eom-data" type="DataRsToVs002"/> 30 </xs:sequence> 31 </xs:extension> 32 </xs:complexContent> 33 </xs:complexType> 34 35 <xs:complexType name="DataRsToVs002"> 36 <xs:sequence> 37 <xs:element name="creditor-id" type="ReferenceID"/> 38 <xs:element name="creditor-request-id" type="ReferenceID"/> 39 </xs:sequence> 40 </xs:complexType> 41 42 </xs:schema> 43


A.9 eom-msg-vs-to-rs-002.xsd

Figure 27: Graphical XML schema of message eom-msg-vs-to-rs-002

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema 2 xmlns:xs="http://www.w3.org/2001/XMLSchema" 3 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 4 elementFormDefault="qualified" 5 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 6 7 <xs:annotation> 8 <xs:documentation> 9 e-Operating Model message vs-to-rs-002, to be sent by Validation Services to 10 Routing Services. 11 </xs:documentation> 12 </xs:annotation> 13 14 <xs:include schemaLocation="eom-common.xsd"/> 15 <xs:include schemaLocation="eom-status.xsd"/> 16 17 <xs:element name="eom-msg-vs-to-rs-002" type="MessageVsToRs002"/> 18 19 <xs:complexType name="MessageVsToRs002"> 20 <xs:complexContent> 21 <xs:extension base="Message"> 22 <xs:sequence> 23 <xs:element name="payload" type="PayloadVsToRs002"/> 24 </xs:sequence> 25


</xs:extension> 26 </xs:complexContent> 27 </xs:complexType> 28 29 <xs:complexType name="PayloadVsToRs002"> 30 <xs:sequence> 31 <xs:element name="status" type="StatusCodeVsToRs002"/> 32 <xs:choice> 33 <xs:element name="eom-data" type="DataVsToRs002"/> 34 <xs:element name="error-details" type="ErrorDetails"/> 35 </xs:choice> 36 </xs:sequence> 37 </xs:complexType> 38 39 <xs:complexType name="DataVsToRs002"> 40 <xs:sequence> 41 <xs:element name="creditor-id" type="ReferenceID"/> 42 <xs:element name="creditor-request-id" type="ReferenceID"/> 43 <xs:element name="signed-message" type="XmlSignature"/> 44 </xs:sequence> 45 </xs:complexType> 46 47 <xs:simpleType name="StatusCodeVsToRs002"> 48 <xs:restriction base="xs:int"> 49 <xs:enumeration value="0"/>  50 <xs:enumeration value="100"/>  51 <xs:enumeration value="101"/>  52 <xs:enumeration value="102"/>  53 <xs:enumeration value="103"/>  54 <xs:enumeration value="105"/>  55 <xs:enumeration value="106"/>  56 <xs:enumeration value="200"/>  57 <xs:enumeration value="201"/>  58 <xs:enumeration value="202"/>  59 <xs:enumeration value="203"/>  60 <xs:enumeration value="204"/>  61 <xs:enumeration value="205"/>  62 <xs:enumeration value="206"/>  63 <xs:enumeration value="207"/>  64 <xs:enumeration value="208"/>  65 <xs:enumeration value="209"/>  66 <xs:enumeration value="210"/>  67 <xs:enumeration value="215"/>  68 <xs:enumeration value="300"/>  69 <xs:enumeration value="301"/>  70 <xs:enumeration value="302"/>  71 <xs:enumeration value="303"/>  72 <xs:enumeration value="400"/>  73 <xs:enumeration value="401"/>  74 <xs:enumeration value="404"/>  75 <xs:enumeration value="405"/>  76 <xs:enumeration value="406"/>  77 <xs:enumeration value="407"/>  78 <xs:enumeration value="408"/>  79 <xs:enumeration value="409"/>  80 <xs:enumeration value="410"/>  81 <xs:enumeration value="411"/>  82 <xs:enumeration value="412"/>  83 <xs:enumeration value="413"/>  84 <xs:enumeration value="414"/>  85 </xs:restriction> 86 </xs:simpleType> 87 88 </xs:schema> 89


A.10 eom-msg-rs-to-cred-002.xsd

Figure 28: Graphical XML schema of message eom-msg-rs-to-cred-002

<?xml version="1.0" encoding="UTF-8"?> 1 <xs:schema 2 xmlns:xs="http://www.w3.org/2001/XMLSchema" 3 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" 4 elementFormDefault="qualified" 5 targetNamespace="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom"> 6 7 <xs:annotation> 8 <xs:documentation> 9 e-Operating Model message rs-to-cred-002, to be sent by Routing Services to 10 Creditors. 11 </xs:documentation> 12 </xs:annotation> 13 14 <xs:include schemaLocation="eom-common.xsd"/> 15 <xs:include schemaLocation="eom-status.xsd"/> 16 17 <xs:element name="eom-msg-rs-to-cred-002" type="MessageRsToCred002"/> 18 19


<xs:complexType name="MessageRsToCred002"> 20 <xs:complexContent> 21 <xs:extension base="Message"> 22 <xs:sequence> 23 <xs:element name="payload" type="PayloadRsToCred002"/> 24 </xs:sequence> 25 </xs:extension> 26 </xs:complexContent> 27 </xs:complexType> 28 29 <xs:complexType name="PayloadRsToCred002"> 30 <xs:sequence> 31 <xs:element name="status" type="StatusCodeRsToCred002"/> 32 <xs:choice> 33 <xs:element name="eom-data" type="DataRsToCred002"/> 34 <xs:element name="error-details" type="ErrorDetails"/> 35 </xs:choice> 36 <xs:element name="extended-data" type="ExtendedData" minOccurs="0" maxOccurs="1"/> 37 </xs:sequence> 38 </xs:complexType> 39 40 <xs:complexType name="DataRsToCred002"> 41 <xs:sequence> 42 <xs:element name="creditor -id" type="ReferenceID"/> 43 <xs:element name="creditor-request-id" type="ReferenceID"/> 44 <xs:element name="signed-message" type="XmlSignature"/> 45 <xs:any namespace="##other" processContents="skip" minOccurs="0" 46 maxOccurs="unbounded"/> 47 </xs:sequence> 48 </xs:complexType> 49 50 <xs:simpleType name="StatusCodeRsToCred002"> 51 <xs:restriction base="xs:int"> 52 <xs:enumeration value="0"/>  53 <xs:enumeration value="100"/>  54 <xs:enumeration value="101"/>  55 <xs:enumeration value="102"/>  56 <xs:enumeration value="103"/>  57 <xs:enumeration value="104"/>  58 <xs:enumeration value="105"/>  59 <xs:enumeration value="106"/>  60 <xs:enumeration value="107"/>  61 <xs:enumeration value="200"/>  62 <xs:enumeration value="201"/>  63 <xs:enumeration value="202"/>  64 <xs:enumeration value="203"/>  65 <xs:enumeration value="204"/>  66 <xs:enumeration value="205"/>  67 <xs:enumeration value="206"/>  68 <xs:enumeration value="207"/>  69 <xs:enumeration value="208"/>  70 <xs:enumeration value="209"/>  71 <xs:enumeration value="210"/>  72 <xs:enumeration value="211"/>  73 <xs:enumeration value="212"/>  74 <xs:enumeration value="213"/>  75 <xs:enumeration value="214"/>  76 <xs:enumeration value="300"/>  77 <xs:enumeration value="301"/>  78 <xs:enumeration value="302"/>  79 <xs:enumeration value="400"/>  80 <xs:enumeration value="401"/>  81 <xs:enumeration value="402"/>  82 <xs:enumeration value="403"/>  83 <xs:enumeration value="404"/>  84 <xs:enumeration value="405"/>  85 <xs:enumeration value="406"/>  86 <xs:enumeration value="407"/>  87 <xs:enumeration value="408"/>  88


<xs:enumeration value="409"/>  89 <xs:enumeration value="410"/>  90 <xs:enumeration value="411"/>  91 <xs:enumeration value="412"/>  92 <xs:enumeration value="413"/>  93 <xs:enumeration value="414"/>  94 </xs:restriction> 95 </xs:simpleType> 96 97 </xs:schema> 98


ANNEX B XML MESSAGE SAMPLES

This annex presents XML samples for the messages defined in chapter 5 and according to the schemas defined in Annex A.

B.1 eom-msg-cred-to-rs-001 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-cred-to-rs-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:01Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <eom-data> <vs-address type="BIC">BBARPPTLXXX</vs-address> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <creditor-return-url>http://www.foo-creditor.com/eom/eom.do?id=111222333&service=mandate&rtt=2ce6296ca50d571347ec39f98fc03334</creditor-return-url> <due-date>2008-07-11T16:00:01Z</due-date> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-cred-to-rs-001>

B.2 eom-msg-rs-to-vs-001 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-vs-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:02Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <eom-data> <vs-address type="BIC">BBARPPTLXXX</vs-address> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <creditor-return-url>http://www.foo-creditor.com/eom/eom.do?id=111222333&service=mandate&rtt=2ce6296ca50d571347ec39f98fc03334</creditor-return-url> <due-date>2008-07-11T16:00:01Z</due-date> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-rs-to-vs-001>

B.3 eom-msg-vs-to-rs-001


Single Authorization Message Flow <?xml version="1.0" encoding="UTF-8"?> <eom-msg-vs-to-rs-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:03Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <vs-url>http://www.bar-vs.com/eom.do?id=987654321&service=mandate</vs-url> </eom-data> </payload> </eom-msg-vs-to-rs-001>

Multiple Authorizations Message Flow <?xml version="1.0" encoding="UTF-8"?> <eom-msg-vs-to-rs-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:03Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <vs-mandate-ref>987 654 321</vs-mandate-ref> </eom-data> </payload> </eom-msg-vs-to-rs-001>

B.4 Error eom-msg-vs-to-rs-001 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-vs-to-rs-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:03Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>100</status> <error-details> <description>Internal server error</description> <hint>Try again later</hint> <src-message> <eom-msg-rs-to-vs-001> <header version="1.1"> <date>2008-07-11T15:00:02Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload>


<eom-data> <vs-address type="BIC">BBARPPTLXXX</vs-address> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <creditor-return-url>http://www.foo-creditor.com/eom/eom.do?id=111222333&service=mandate&rtt=2ce6296ca50d571347ec39f98fc03334</creditor-return-url> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-rs-to-vs-001> </src-message> </error-details> </payload> </eom-msg-vs-to-rs-001>

B.5 eom-msg-rs-to-cred-001

Single Authorization Message Flow <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-cred-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:04Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <vs-url>http://www.bar-vs.com/eom.do?id=987654321&service=mandate</vs-url> </eom-data> </payload> </eom-msg-rs-to-cred-001>

MultipleAuthorizations Message Flow <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-cred-001 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:04Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <vs-mandate-ref>987 654 321</vs-mandate-ref> </eom-data> </payload> </eom-msg-rs-to-cred-001>

B.6 Error eom-msg-rs-to-cred-001 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-cred-001


xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:04Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <status>100</status> <error-details> <description>Internal server error</description> <hint>Try again later</hint> <src-message> <eom-msg-cred-to-rs-001> <header version="1.1"> <date>2008-07-11T15:00:01Z</date> <service>mandate</service> <operation>proposal</operation> </header> <payload> <eom-data> <vs-address type="BIC">BBARPPTLXXX</vs-address> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <creditor-return-url>http://www.foo-creditor.com/eom/eom.do?id=111222333&service=mandate&rtt=2ce6296ca50d571347ec39f98fc03334</creditor-return-url> </eom-data> <message> <e-mandate>...</e-mandate> </message> </payload> </eom-msg-cred-to-rs-001> </src-message> </error-details> </payload> </eom-msg-rs-to-cred-001>

B.7 eom-msg-cred-to-rs-002 for retrieval of an e-Mandate <?xml version="1.0" encoding="UTF-8"?> <eom-msg-cred-to-rs-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:05Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> </eom-data> </payload> </eom-msg-cred-to-rs-002>


B.8 eom-msg-rs-to-vs-002 for retrieval of an e-Mandate <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-vs-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:06Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> </eom-data> </payload> </eom-msg-rs-to-vs-002>

B.9 eom-msg-vs-to-rs-002 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-vs-to-rs-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:07Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <signed-message> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#message"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>esrCEau3mPR+QWwyxzZ1uy5u4E1M6wKmKMg5PDgC71Q=</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>o0aZTxQK84IZ2NH7VPUlQyJhl2Sp1YHiMAhHajsIeJQ=</DigestValue> </Reference> </SignedInfo> <SignatureValue>YnJ+XmdVoVxCfgd5LuoryUdTgEVd6CXYkAI0jAbpvzn/GU8OLPzdqK2vdaS/EEkKuPoSwGoPfbJv NpIi4hY45/Nqj/ejkAI+qMYYOhRRnmdtHpqkSH4EVHMwLQhZFTwvN0MdzY8CBbO0q7dfs+p5Cezv OS/5qQlpAat4I4w7td4=</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>MIIGVjCCBT6gAwIBAgIIVQL9SnN9J2MwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQxEjAQ BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MTA1MDM1WhcNMTExMDI1MTA1MDM1 WjBcMQswCQYDVQQGEwJQVDESMBAGA1UECgwJRGVtbyBCYW5rMRMwEQYDVQQLDAplLU1hbmRhdGVz MSQwIgYDVQQDDBtlLU9wZXJhdGluZyBNb2RlbCBEZW1vIEJhbmswgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAJfSq4uGZqscnn+mUREigXjgQo0o4pWEfkY4b5k9eQWN/Wx3YcBL6uDMz5f/mRzV i3P0DyHSGSKZWuMnsnAoILuFFkbDE/g7M7YQoWj2Qw2IUulQ8QILulYip50PnJNlleBdf1ArM9t1 P5p/ZUJZYeHBtgwIOu8cyubwM01CCwijAgMBAAGjggOWMIIDkjA8BggrBgEFBQcBAQQwMC4wLAYI


KwYBBQUHMAGGIGh0dHA6Ly93d3cuc2FtcGxlLWNhLmV1L3B1Yi9vY3NwMB0GA1UdDgQWBBSngNtt b83vOdLFVRL3Nnlqm/zq6DAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFHkIRwBCnWqsYb9CFC6Z UZWFRxWWMIIBvAYDVR0gAQH/BIIBsDCCAawwggGoBgwrBgEEAbA8ZAEBAQMwggGWMIIBkgYIKwYB BQUHAgIwggGEHoIBgABUAGgAZQAgAHUAcwBhAGcAZQAgAG8AZgAgAHQAaABpAHMAIABjAGUAcgB0 AGkAZgBpAGMAYQB0AGUAIABmAG8AcgAgAGUAbABlAGMAdAByAG8AbgBpAGMAIABzAGkAZwBuAGEA dAB1AHIAZQAgAHAAdQByAHAAbwBzAGUAcwAgAGkAbgAgAGEAYwBjAG8AcgBkAGEAbgBjAGUAIAB3 AGkAdABoACAAdABoAGkAcwAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAHAAbwBsAGkAYwB5ACAA ZQBuAHQAaQB0AGwAZQBzACAAdABoAGUAIABzAHUAYgBqAGUAYwB0ACAAYQBzACAAYQAgAGwAZQBn AGkAdABpAG0AYQB0AGUAIABzAGkAZwBuAGUAcgAgAGYAbwByACAAdABoAGUAIABCAGEAbgBrACgA cwApACAAaQBkAGUAbgB0AGkAZgBpAGUAZAAgAGIAeQAgAHQAaABlACAAQgBJAEMAKABzACkALjCB rAYDVR0fBIGkMIGhMIGeoDKgMIYuaHR0cDovL3d3dy5zYW1wbGUtY2EuZXUvcHViL2NybC9lb20t Y2EtMDAxLmNybKJopGYwZDELMAkGA1UEBhMCUFQxEjAQBgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UE CwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQDDBhlLU9wZXJhdGluZyBNb2RlbCBDQSAw MDEwDgYDVR0PAQH/BAQDAgZAMIGEBgNVHREBAf8EejB4oBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQ UFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxoBwGCysGAQQBgZA+ZAEBoA0MC0JC QVJQUFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxMA0GCSqGSIb3DQEBBQUAA4IB AQCTDpFEl7mOW7LqyOQE/HyfXFdKRcZBJeZMulG0bVprOlEFYQSkDGImVqC2DdcW6BvBmMt7cfVL +TmgtdFnv7HPJc9QiwiqKxYsjjEZaU69rLBryaAxaTO1tlSmhXTC5GgT/PxHRPjMpb9Say8N+aIq Iok+/WIWnETMi4LFvwsApnTOEI+yN584UkgsIL3YHVpl5VwFHEMDB93R0TUJCoBaz4TL5W67h3/D ACLYhH8skzZBidF+O2/s27RDr+NqH8FNA7XuKDIJYfnBsXqo9wlbUSeb9qQWriFBkgGobxACz3p8 LbE2pcjoY8LxcQpy0O2A4UwDJL5LCXHj249y3+Ld</X509Certificate> <X509Certificate>MIIDrTCCApWgAwIBAgIIJNoByZ381H0wDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQxEjAQ BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MDkyNjE1WhcNMTgwODI0MDkyNjE1 WjBkMQswCQYDVQQGEwJQVDESMBAGA1UECgwJU2FtcGxlIENBMR4wHAYDVQQLDBVlLU9wZXJhdGlu ZyBNb2RlbCBQS0kxITAfBgNVBAMMGGUtT3BlcmF0aW5nIE1vZGVsIENBIDAwMTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKfPK2UHTujsEsdSaQ2M00rSMeVeBsW74pJLUHgDe1y1u+yX btLxYmohZ8sojBYFcKEfxDvneMkX4pO/+o8vkbWhyv/Z8E2RPwsdbWklwxfgkgGfnhGQ82PvGdRn Jm5DFBE2ZuuMqXzFGZgh0nfbXB4oQV7TYsljDvXZBhfJetZonggDn7OSmUVNCwVBvwDzAraYGJBK n+ttSZdT8l/hbYYXY1Ax7KJeCmsWV+WQHN2MyFyQCa+5WVrliQpER7pbSYsKyK1ZQU0LNA/YgUsK zx3l8oHNYcekQOxxKAdNBocbzXHd1NDwKlpuPzaCyulleVFrkSHVRLNn1JCmo6s7Z1MCAwEAAaNj MGEwHQYDVR0OBBYEFHkIRwBCnWqsYb9CFC6ZUZWFRxWWMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0j BBgwFoAUeQhHAEKdaqxhv0IULplRlYVHFZYwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUA A4IBAQCGjFB4VzG7yUqvQhJLDD5JQ05e2RqwkK0vLT3m7SRXr3L+u3F6qdqq3uX1x9CHN+c2Ja61 PlauJ+kNUZHjisR1nSE0LANJOzebgtxOgrGERIi8PPaJDFazDPhcfg2ve/WnXkgaAVNUlXR8dHtB ArV7TApKd0K83BR/MqTxQgyaCC3OFJtrg0paUGq1egVe6dv+K3bxxDUCzRP34b7SIVj76AriKYyh AYD+xTn1WMV4cd8ncOX0Pew6r8p2m1vaFkO4Rj9KKZKQAz+UWKiFCbeeFgSX6SUq1HB77U93hobs wKgFFWjCny0l1JFfgTRby0k3FNe+9POtCGgWYKOfs/UE</X509Certificate> </X509Data> </KeyInfo> <Object Id="message"> <e-mandate xmlns="urn:swift:xsd:$e-mandate.002">This is the business message...</e-mandate> </Object> </Signature> </signed-message> </eom-data> </payload> </eom-msg-vs-to-rs-002>


B.10 Error eom-msg-vs-to-rs-002 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-vs-to-rs-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:07Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>100</status> <error-details> <description>Internal server error</description> <hint>Try again later</hint> <src-message> <eom-msg-rs-to-vs-002> <header version="1.1"> <date>2008-07-11T15:00:06Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> </eom-data> </payload> </eom-msg-rs-to-vs-002> </src-message> </error-details> </payload> </eom-msg-vs-to-rs-002>


B.11 eom-msg-rs-to-cred-002 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-cred-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:08Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>0</status> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> <signed-message> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#message"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>esrCEau3mPR+QWwyxzZ1uy5u4E1M6wKmKMg5PDgC71Q=</DigestValue> </Reference> <Reference URI="#keyInfo"> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <DigestValue>o0aZTxQK84IZ2NH7VPUlQyJhl2Sp1YHiMAhHajsIeJQ=</DigestValue> </Reference> </SignedInfo> <SignatureValue>YnJ+XmdVoVxCfgd5LuoryUdTgEVd6CXYkAI0jAbpvzn/GU8OLPzdqK2vdaS/EEkKuPoSwGoPfbJv NpIi4hY45/Nqj/ejkAI+qMYYOhRRnmdtHpqkSH4EVHMwLQhZFTwvN0MdzY8CBbO0q7dfs+p5Cezv OS/5qQlpAat4I4w7td4=</SignatureValue> <KeyInfo Id="keyInfo"> <X509Data> <X509Certificate>MIIGVjCCBT6gAwIBAgIIVQL9SnN9J2MwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQxEjAQ BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MTA1MDM1WhcNMTExMDI1MTA1MDM1 WjBcMQswCQYDVQQGEwJQVDESMBAGA1UECgwJRGVtbyBCYW5rMRMwEQYDVQQLDAplLU1hbmRhdGVz MSQwIgYDVQQDDBtlLU9wZXJhdGluZyBNb2RlbCBEZW1vIEJhbmswgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAJfSq4uGZqscnn+mUREigXjgQo0o4pWEfkY4b5k9eQWN/Wx3YcBL6uDMz5f/mRzV i3P0DyHSGSKZWuMnsnAoILuFFkbDE/g7M7YQoWj2Qw2IUulQ8QILulYip50PnJNlleBdf1ArM9t1 P5p/ZUJZYeHBtgwIOu8cyubwM01CCwijAgMBAAGjggOWMIIDkjA8BggrBgEFBQcBAQQwMC4wLAYI KwYBBQUHMAGGIGh0dHA6Ly93d3cuc2FtcGxlLWNhLmV1L3B1Yi9vY3NwMB0GA1UdDgQWBBSngNtt b83vOdLFVRL3Nnlqm/zq6DAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFHkIRwBCnWqsYb9CFC6Z UZWFRxWWMIIBvAYDVR0gAQH/BIIBsDCCAawwggGoBgwrBgEEAbA8ZAEBAQMwggGWMIIBkgYIKwYB BQUHAgIwggGEHoIBgABUAGgAZQAgAHUAcwBhAGcAZQAgAG8AZgAgAHQAaABpAHMAIABjAGUAcgB0 AGkAZgBpAGMAYQB0AGUAIABmAG8AcgAgAGUAbABlAGMAdAByAG8AbgBpAGMAIABzAGkAZwBuAGEA dAB1AHIAZQAgAHAAdQByAHAAbwBzAGUAcwAgAGkAbgAgAGEAYwBjAG8AcgBkAGEAbgBjAGUAIAB3 AGkAdABoACAAdABoAGkAcwAgAGMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAHAAbwBsAGkAYwB5ACAA ZQBuAHQAaQB0AGwAZQBzACAAdABoAGUAIABzAHUAYgBqAGUAYwB0ACAAYQBzACAAYQAgAGwAZQBn AGkAdABpAG0AYQB0AGUAIABzAGkAZwBuAGUAcgAgAGYAbwByACAAdABoAGUAIABCAGEAbgBrACgA cwApACAAaQBkAGUAbgB0AGkAZgBpAGUAZAAgAGIAeQAgAHQAaABlACAAQgBJAEMAKABzACkALjCB rAYDVR0fBIGkMIGhMIGeoDKgMIYuaHR0cDovL3d3dy5zYW1wbGUtY2EuZXUvcHViL2NybC9lb20t Y2EtMDAxLmNybKJopGYwZDELMAkGA1UEBhMCUFQxEjAQBgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UE CwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQDDBhlLU9wZXJhdGluZyBNb2RlbCBDQSAw MDEwDgYDVR0PAQH/BAQDAgZAMIGEBgNVHREBAf8EejB4oBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQ UFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxoBwGCysGAQQBgZA+ZAEBoA0MC0JC QVJQUFRMWFhYoBwGCysGAQQBgZA+ZAEBoA0MC0JCQVJQUFRMMDAxMA0GCSqGSIb3DQEBBQUAA4IB AQCTDpFEl7mOW7LqyOQE/HyfXFdKRcZBJeZMulG0bVprOlEFYQSkDGImVqC2DdcW6BvBmMt7cfVL +TmgtdFnv7HPJc9QiwiqKxYsjjEZaU69rLBryaAxaTO1tlSmhXTC5GgT/PxHRPjMpb9Say8N+aIq


Iok+/WIWnETMi4LFvwsApnTOEI+yN584UkgsIL3YHVpl5VwFHEMDB93R0TUJCoBaz4TL5W67h3/D ACLYhH8skzZBidF+O2/s27RDr+NqH8FNA7XuKDIJYfnBsXqo9wlbUSeb9qQWriFBkgGobxACz3p8 LbE2pcjoY8LxcQpy0O2A4UwDJL5LCXHj249y3+Ld</X509Certificate> <X509Certificate>MIIDrTCCApWgAwIBAgIIJNoByZ381H0wDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCUFQxEjAQ BgNVBAoMCVNhbXBsZSBDQTEeMBwGA1UECwwVZS1PcGVyYXRpbmcgTW9kZWwgUEtJMSEwHwYDVQQD DBhlLU9wZXJhdGluZyBNb2RlbCBDQSAwMDEwHhcNMDgwODI2MDkyNjE1WhcNMTgwODI0MDkyNjE1 WjBkMQswCQYDVQQGEwJQVDESMBAGA1UECgwJU2FtcGxlIENBMR4wHAYDVQQLDBVlLU9wZXJhdGlu ZyBNb2RlbCBQS0kxITAfBgNVBAMMGGUtT3BlcmF0aW5nIE1vZGVsIENBIDAwMTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKfPK2UHTujsEsdSaQ2M00rSMeVeBsW74pJLUHgDe1y1u+yX btLxYmohZ8sojBYFcKEfxDvneMkX4pO/+o8vkbWhyv/Z8E2RPwsdbWklwxfgkgGfnhGQ82PvGdRn Jm5DFBE2ZuuMqXzFGZgh0nfbXB4oQV7TYsljDvXZBhfJetZonggDn7OSmUVNCwVBvwDzAraYGJBK n+ttSZdT8l/hbYYXY1Ax7KJeCmsWV+WQHN2MyFyQCa+5WVrliQpER7pbSYsKyK1ZQU0LNA/YgUsK zx3l8oHNYcekQOxxKAdNBocbzXHd1NDwKlpuPzaCyulleVFrkSHVRLNn1JCmo6s7Z1MCAwEAAaNj MGEwHQYDVR0OBBYEFHkIRwBCnWqsYb9CFC6ZUZWFRxWWMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0j BBgwFoAUeQhHAEKdaqxhv0IULplRlYVHFZYwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUA A4IBAQCGjFB4VzG7yUqvQhJLDD5JQ05e2RqwkK0vLT3m7SRXr3L+u3F6qdqq3uX1x9CHN+c2Ja61 PlauJ+kNUZHjisR1nSE0LANJOzebgtxOgrGERIi8PPaJDFazDPhcfg2ve/WnXkgaAVNUlXR8dHtB ArV7TApKd0K83BR/MqTxQgyaCC3OFJtrg0paUGq1egVe6dv+K3bxxDUCzRP34b7SIVj76AriKYyh AYD+xTn1WMV4cd8ncOX0Pew6r8p2m1vaFkO4Rj9KKZKQAz+UWKiFCbeeFgSX6SUq1HB77U93hobs wKgFFWjCny0l1JFfgTRby0k3FNe+9POtCGgWYKOfs/UE</X509Certificate> </X509Data> </KeyInfo> <Object Id="message"> <e-mandate xmlns="urn:swift:xsd:$e-mandate.002">This is the business message...</e-mandate> </Object> </Signature> </signed-message> </eom-data> <extended-data/> </payload> </eom-msg-rs-to-cred-002>


B.12 Error eom-msg-rs-to-cred-002 <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-cred-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:08Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <status>100</status> <error-details> <description>Internal server error</description> <hint>Try again later</hint> <src-message> <eom-msg-cred-to-rs-002> <header version="1.1"> <date>2008-07-11T15:00:05Z</date> <service>mandate</service> <operation>retrieval</operation> </header> <payload> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> </eom-data> </payload> </eom-msg-cred-to-rs-002> </src-message> </error-details> </payload> </eom-msg-rs-to-cred-002>

B.13 eom-msg-cred-to-rs-002 for acknowledgement of an e-Mandate <?xml version="1.0" encoding="UTF-8"?> <eom-msg-cred-to-rs-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:09Z</date> <service>mandate</service> <operation>acknowledge</operation> </header> <payload> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> </eom-data> </payload> </eom-msg-cred-to-rs-002>


B.14 eom-msg-rs-to-vs-002 for acknowledgement of an e-Mandate <?xml version="1.0" encoding="UTF-8"?> <eom-msg-rs-to-vs-002 xmlns="http://www.europeanpaymentscouncil.eu/ns/2008-07/eom" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header version="1.1"> <date>2008-07-11T15:00:10Z</date> <service>mandate</service> <operation>acknowledge</operation> </header> <payload> <eom-data> <creditor-id>PT123456789</creditor-id> <creditor-request-id>111222333</creditor-request-id> </eom-data> </payload> </eom-msg-rs-to-vs-002>


ANNEX C RECOMMENDED STRATEGIES FOR BIC RESOLUTIONS

C.1 Online resolution On the online resolution, the Routing Service queries the Directory Service for each incoming request. The Routing Service sends the operational BIC and the Directory Service returns the corresponding Validation Service URL.

For faster processing and improved service availability, it is recommended that Routing Service providers implement a cache strategy to avoid repeated requests on frequent BICs. The cached results must be assigned a maximum validity of 30 days. After that period, the Routing Service must perform a query to refresh the mapping. This process is illustrated in Figure 29.

Figure 29: Online BIC resolution


C.2 Offline resolution On the offline resolution, the Directory Service provider publishes the full mapping of Operational BICs to their respective Validation Service URLs along with a serial number and the next update date (30 days as a maximum). Subscribing Routing Services download the mapping file at the announced periodic updating dates and cache it (Figure 30). The resolution can then be performed internally (Figure 31).

Figure 30: Caching of full BIC resolution tables

Figure 31: Offline BIC resolution

As an optimization to this model, the Directory Service provider may publish also an additional mapping file containing the differences from the last full mapping file.


ANNEX D CERTIFICATE ENROLMENT REQUIREMENTS

The enrolment requirements applicable to the issuance of certificates according to the profiles defined follow the general rules of “Guidelines for the Issuance and Management of Extended Validation Certificates” [36].

D.1 Authentication Certificate for Routing Service providers An EPC approved Certification Authority must only accept an enrolment request of an applying Routing Service provider if all the following conditions are met:

1. The request must be submitted by an authorized person who is either the applicant, employed by the applicant or an authorized agent who has express authority to represent the applicant.

2. Submission of a properly completed and signed Certificate Request form prescribed by the CA and that complies with these Guidelines. The application form must contain the following information, as a minimum:

a. Organization name - applicant’s formal legal organization name as registered with the government business Registration Agency;

b. Domain Name - Applicant’s domain name(s) to be included in the Certificate;

c. Jurisdiction of Incorporation or Registration - Applicant’s Jurisdiction of Incorporation or Registration, consisting of:

i. City or town (if any),

ii. State or province (if any), and

iii. Country.

d. Incorporating or Registration Agency - The name of the Applicant’s Incorporating or Registration Agency;

e. Registration Number - The Registration Number assigned to the Applicant by the Incorporating or Registration Agency in Applicant’s Jurisdiction of Incorporation or Registration. If the Incorporating or Registration Agency does not issue Registration numbers, then the date of Incorporation or Registration shall be collected.

f. Address - The address of the applicant’s place of business, including:

i. Building number and street,

ii. City or town,

iii. State or province (if any),

iv. Country,

v. Postal code (zip code), and vi. Main telephone number.

g. Certificate Approver - Name and contact information of the Certificate Approver submitting and signing, or that has authorized the Certificate Requester to submit and sign, the certificate application on behalf of the applicant;


h. Certificate Requester - Name and contact information of the Certificate Requester submitting the Certificate Request on behalf of the applicant, if other than the Certificate Approver.

i. A certification by, or on behalf of, the applicant that all of the information contained therein is true and correct;

3. Acceptance of the terms of usage of the certificate to be issued, namely:

a. Accuracy of Information - An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the certificate to be supplied by the CA;

b. Protection of Private Key - An obligation and warranty to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the private key that corresponds to the public key to be included in the requested certificate (and any associated access information or device, e.g. password or token);

c. Acceptance of Certificate - An obligation and warranty that it will not install and use the certificate until it has reviewed and verified the accuracy of the data in the certificate;

d. Use of Certificate - An obligation and warranty to install the certificate only on the server accessible at a domain name listed on the certificate, and to use the certificate solely in compliance with the terms described in the EPC e-Operating Model Detailed Specification for Routing Service providers;

e. Reporting and Revocation Upon Compromise - An obligation and warranty to promptly cease using the certificate and its associated private key, and promptly request the issuing CA to revoke the certificate, in the event that:

i. any information in the certificate is or becomes incorrect or inaccurate, or

ii. there is any actual or suspected misuse or compromise of the private key associated with the public key listed in the certificate;

f. Termination of Use of Certificate - An obligation and warranty to promptly cease all use of the private key corresponding to the public key listed in the certificate upon expiration or revocation of that certificate.

4. Submission of an authenticated copy of the EPC approval adherence agreement, declaring that the applicant is accepted as a Routing Service provider for the e-Mandates service.

5. Submission of an authenticated copy of the applicant register on the Incorporating or Registration Agency of its jurisdiction, containing the Organization Name, the Registration Number and the Address.

6. Submission of an authenticated copy of the possession of the domain names to be listed on the certificate.

7. Submission in electronic format (e.g., PKCS#10) of the public key to be listed in the certificate. The electronic format must provide a way to verify the proof-of-possession of the corresponding private key.

D.2 Authentication Certificate for Validation Service providers


An EPC approved Certification Authority must only accept an enrolment request of an applying Validation Service provider if all the following conditions are met:


2. Submission of a properly completed and signed certificate request form prescribed by the CA and that complies with these guidelines. The application form must contain the following information, as a minimum:


b. Domain Name - Applicant’s domain name(s) to be included in the Certificate;




iii. Country.





ii. City or town,


iv. Country,

v. Postal code (zip code), and

vi. Main telephone number.









d. Use of Certificate - An obligation and warranty to install the certificate only on the server accessible at a domain name listed on the certificate, and to use the certificate solely in compliance with the terms described in the EPC e-Operating Model Detailed Specification for Validation Service providers;





4. Submission of an authenticated copy of the EPC approval adherence agreement, declaring that the applicant is accepted as a Validation Service provider for the e-Mandates service.


6. Submission of an authenticated copy of the possession of the domain names to be registered.


D.3 Signing Certificate for Validation Service providers An EPC approved Certification Authority must only accept an enrolment request of an applying Validation Service provider if all the following conditions are met:



2. Submission of a properly completed and signed certificate request form prescribed by the CA and that complies with these guidelines. The application form must contain the following information, as a minimum:


b. BIC - BIC(s) to be included in the certificate;




iii. Country.





ii. City or town,


iv. Country,

v. Postal code (zip code), and

vi. Main telephone number.









d. Use of Certificate - An obligation and warranty to install the certificate only on the server accessible at a domain name listed on the certificate, and to use the certificate solely in compliance with the terms described in the EPC e-Operating Model Detailed Specification for Validation Service providers;





4. Submission of an authenticated copy of the EPC approval adherence agreement, declaring that the applicant is accepted as a Validation Service provider for the e-Mandates service and is the designated entity by the underlying Banks to respond for the designated BIC(s).




ANNEX E X.509 CERTIFICATE PROFILES

This annex presents a description of the certificate profiles to be used on the EPC e-Operating Model, namely:

a. Routing Service authentication certificate profile

b. Validation Service authentication certificate profile

c. Signing certificate profile

To be accepted and interoperable within the scope of the EPC e-Operating Model, certificates must be issued by EPC approved Certification Authorities and according to the certificate profiles defined below.

The specification of the certificate profiles describes the minimum set of characteristics of the certificates. Other X.509 extensions may be included by issuing Certification Authorities as long as:

a. Are marked as not critical

b. Do not affect the expected processing of relying parties

c. Do not decrease or compromise in any aspect the security level of the EPC e-Operating Model.


E.1 Routing Service authentication certificate profile

Cerificate Component Section in RFC 5280 Value Critical Comments

tbsCertificate

Version 4.1.2.1 v3

Serial Number 4.1.2.2 <unique, assigned by the CA to each certificate>

Signature 4.1.2.3 1.2.840.113549.1.1.5 Value MUST match the OID in signatureAlgorithm (below)

Issuer 4.1.2.4 Exactly as the distinguished name of the issuing Certification Authority

Validity 4.1.2.5 Implementations MUST specify using UTC time until 2049, from then on

using GeneralisedTime

Not Before <issuing date>

Not After <issuing date + 1155 days> 3 years + 60 days.

Subject 4.1.2.6 According to the subject naming policies of the issuing Certification

Authority

Subject Public Key Info 4.1.2.7 used to carry the public key and identify the algorithm with wich the key is

used (e.g., RSA, DSA or Diffie-Hellman)

algorithm 1.2.840.113549.1.1.1 The OID rsaEncryption identifies RSA public keys.

pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)

rsadsi(113549) pkcs(1) 1 }

rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}

The rsaEncryption OID is intended to be used in the algorithm field of a

value of type AlgorithmIdentifier. The parameters field MUST have ASN.1

type NULL for this algorithm identifier.


subjectPublicKey <Subject Public Key with modulus n of 2048 bits and

public exponent e equal to 65537>

X.509v3 Extensions 4.1.2.9

Authority Key Identifier 4.2.1.1 <The key Identifier is composed of the 160-bit SHA-1 or

256-bit SHA-2 hash of the value of the BIT STRING

subject key identifier in the issuer's certificate (excluding

the tag, length, and number of unused bits)>

N

Subject Key Identifier 4.2.1.2 <The key Identifier is composed of the 160-bit SHA-1 or


subjectPublicKey (excluding the tag, length, and number of

unused bits)>

N

Key Usage 4.2.1.3 Y This extension is marked CRITICAL

Digital Signature “1” selected

Non Repudiation “0” selected

Key Encipherment “1” selected

Data Encipherment “0” selected

Key Agreement “0” selected

Key Certificate Signature “0” selected

CRL Signature “0” selected

Encipher Only “0” selected

Decipher Only “0” selected

Certificate Policies 4.2.1.5


policyIdentifier 1.2.528.56.1001.1.1.1 Y Certificate policy OID for authentication certificates for Routing Service

providers

policyQualifiers policyQualiflierID: 1.3.6.1.5.5.7.2.2

userNotice explicitText: “The usage of this certificate for

authentication purposes in accordance with this certificate

policy entitles the subject as a legitimate Routing Service

provider for the EPC e-Operating Model.”

Y OID value: 1.3.6.1.5.5.7.2.2 (id-qt-unotice)

Subject Alternative Name 4.2.1.7 Y

dNSName Domain name system label for the Routing Service provider Inclusion of dNSName extensions is optional.

Can have more than one if the Routing Service provider responds on several

DNS labels.

Basic Constraints 4.2.1.10 Y

CA FALSE

Extended Key Usage 4.2.1.13 Y

id-kp-serverAuth 1.3.6.1.5.5.7.3.1 TLS server authentication

id-kp-clientAuth 1.3.6.1.5.5.7.3.2 TLS client authentication

CRLDistributionPoints 4.2.1.14 N

distributionPoint At least one HTTP (without TLS) URL must be provided to download the

CRL.

Internet Certificate Extensions

Authority Information Access 4.2.2.1 N

accessMethod 1.3.6.1.5.5.7.48.1 OID value: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp)

OID description: Online Certificate Status Protocol


accessLocation OCSP URL, without TLS

Signature Algorithm 4.1.1.2 1.2.840.113549.1.1.5 MUST contain the same OID algorithm identifier as the signature field in

the sequence tbsCertificate.

sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-

body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

Signature Value 4.1.1.3 <contains digital signature issued by the CA> By generating this signature, a Certification Authority certifies the binding

between the public key material and the subject of the certificate.


E.2 Validation Service authentication certificate profile


tbsCertificate

Version 4.1.2.1 v3





MUST use GeneralisedTime




Authority





rsadsi(113549) pkcs(1) 1 }













N




unused bits)>

N














providers



authentication purposes in accordance with this certificate

policy entitles the subject as a legitimate Validation Service

provider for the EPC e-Operating Model.”



dNSName Domain name system label for the Validation Service

provider

Can have more than one if the Validation Service provider responds on

several DNS labels.


CA FALSE

Extended Key Usage 4.2.1.13 Y

id-kp-serverAuth 1.3.6.1.5.5.7.3.1 TLS server authentication

id-kp-clientAuth 1.3.6.1.5.5.7.3.2 TLS client authentication



CRL.














E.3 Signing certificate profile


tbsCertificate

Version 4.1.2.1 v3





MUST use GeneralisedTime




Authority





rsadsi(113549) pkcs(1) 1 }













N




unused bits)>

N














providers



electronic signature purposes in accordance with this

certificate policy entitles the subject as a legitimate signer

for the Bank(s) identified by the BIC(s).”



otherName type-id: 1.3.21.7.1

value: the BIC value, coded in the ASN.1 type

PrintableString

Can have more than one BIC if the Validation Service provider uses the

certificate to sign e-Mandates for several BICs.


CA FALSE



CRL.