SIST EN 319 522-2 V1.1.1:2018
(Main)Electronic Signatures and Infrastructures (ESI) - Electronic Registered Delivery Services - Part 2: Semantic contents
Electronic Signatures and Infrastructures (ESI) - Electronic Registered Delivery Services - Part 2: Semantic contents
The present document specifies the semantic content that flows across the interfaces of ERD services which are
specified in ETSI EN 319 522-1 [1], clause 5.
Elektronski podpisi in infrastruktura (ESI) - Storitve elektronske priporočene dostave - 2. del: Semantične vsebine
Ta dokument določa semantično vsebino, ki se pretaka prek vmesnikov storitev ERD, opredeljenih v standardu ETSI EN 319 522-1 [1], točka 5.
General Information
Buy Standard
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Electronic Signatures and Infrastructures (ESI) - Electronic Registered Delivery Services - Part 2: Semantic contents35.040.01Kodiranje informacij na splošnoInformation coding in generalICS:Ta slovenski standard je istoveten z:ETSI EN 319 522-2 V1.1.1 (2018-09)SIST EN 319 522-2 V1.1.1:2018en01-november-2018SIST EN 319 522-2 V1.1.1:2018SLOVENSKI
STANDARD
SIST EN 319 522-2 V1.1.1:2018
ETSI EN 319 522-2 V1.1.1 (2018-09) Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 2: Semantic contents
EUROPEAN STANDARD SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 2
Reference DEN/ESI-0019522-2 Keywords e-delivery services, registered e-delivery services, registered electronic mail ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00
Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88
Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018. All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETM are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSM® and the GSM logo are trademarks registered and owned by the GSM Association. SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 3 Contents Intellectual Property Rights . 5 Foreword . 5 Modal verbs terminology . 5 1 Scope . 6 2 References . 6 2.1 Normative references . 6 2.2 Informative references . 6 3 Definitions . 7 4 Overview . 7 5 Identification of actors. 10 5.1 Introduction . 10 5.2 Identifiers . 10 5.3 Identity attributes . 10 5.3.1 Introduction. 10 5.3.2 Identity attributes of natural persons . 10 5.3.3 Identity attributes of legal person . 11 5.3.4 Identity attributes of other entities . 11 5.4 Identity verification and authentication assurance levels information . 11 6 ERDS relay metadata . 12 6.1 Introduction . 12 6.2 Metadata components . 12 6.2.1 MD01 - Metadata version . 12 6.2.2 MD02 - Relay date and time . 12 6.2.3 MD03 - Expiry date and time . 13 6.2.4 MD04 - Recipient required level of assurance . 13 6.2.5 MD05 - Applicable policy . 13 6.2.6 MD06 - Mode of consignment . 14 6.2.7 MD07 - Scheduled delivery . 14 6.2.8 MD08 - Sender's identifier . 14 6.2.9 MD09 - Reply-to . 14 6.2.10 MD10 - Recipient's identifier . 15 6.2.11 MD11 - Message identifier . 15 6.2.12 MD12 - In reply to . 15 6.2.13 MD13 - Message type . 15 6.2.14 MD14 - User content information . 15 6.2.15 MD15 - Other metadata . 16 7 Digital signatures in ERDS provisioning . 16 7.1 Objects and actors for digital signatures . 16 7.2 Common requirements for digital signatures . 16 8 ERDS evidence set and components . 17 8.1 Introduction . 17 8.2 Evidence components . 17 8.2.1 G01 - Evidence identifier . 17 8.2.2 G02 - Evidence version . 18 8.2.3 G03 - Event identifier . 18 8.2.4 G04 - Reason identifier . 18 8.2.5 G05 - Event time . 18 8.2.6 G06 - Transaction log information . 18 8.2.7 R01 - Evidence issuer policy identifier . 19 8.2.8 R02 - Evidence issuer details . 19 8.2.9 R03 - Signature by issuing ERDS . 19 8.2.10 I01 - Sender's identity attributes . 19 SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 4 8.2.11 I02 - Sender's identifier . 19 8.2.12 I03 - Sender's delegate identity attributes . 20 8.2.13 I04 - Sender's delegate identifier. 20 8.2.14 I05 - Recipient's identity attributes . 20 8.2.15 I06 - Recipient's identifier. 20 8.2.16 I07 - Recipient's delegate identity attributes . 21 8.2.17 I08 - Recipient's delegate identifier . 21 8.2.18 I09 - Recipient referred to by the evidence . 21 8.2.19 I10 - Sender's identity assurance level details . 21 8.2.20 I11 - Sender's delegate identity assurance level details . 22 8.2.21 I12 - Recipient's identity assurance level details . 22 8.2.22 I13 - Recipient's delegate identity assurance level details . 22 8.2.23 M01 - Message identifier . 22 8.2.24 M02 - User content information . 22 8.2.25 M03 - Submission date and time . 23 8.2.26 M04 - External system . 23 8.2.27 M05 - External ERDS . 23 8.2.28 E01 - Extensions . 23 8.3 Evidence components values . 23 8.3.1 Free text . 23 8.3.2 Events . 23 8.3.3 Reasons . 24 8.3.3.1 Reasons related to Events A.1, A.2 (Sender's submission) . 24 8.3.3.2 Reasons related to the Events B.1, B.2, B.3 (Relay between ERDSs) . 24 8.3.3.3 Reasons related to events C.1, C.2, C.3, C.4, C.5 (Acceptance/rejection by the recipient) . 24 8.3.3.4 Reasons related to events D.1, D.2, D.3, D.4 (Consignment to the recipient) . 25 8.3.3.5 Reasons related to events E.1, E.2 (Handover to the recipient) . 25 8.3.3.6 Reasons related to events F1, F2 (Connection to non ERDS) . 25 8.4 Additional requirements for components of evidence . 25 9 Common Services Interface content . 28 9.1 Introduction . 28 9.2 ERD message routing . 28 9.3 ERDS trust establishment and governance . 28 9.4 Capability management . 29 9.4.1 Introduction. 29 9.4.2 Resolving recipient identification to ERDS identification . 29 9.4.3 Recipient metadata . 30 9.4.4 ERDS capability metadata . 30 History . 32
SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 5 Intellectual Property Rights Essential patents IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https://ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Trademarks The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks. Foreword This European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI). The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [1].
National transposition dates Date of adoption of this EN: 23 August 2018 Date of latest announcement of this EN (doa): 30 November 2018 Date of latest publication of new National Standard or endorsement of this EN (dop/e):
31 May 2019 Date of withdrawal of any conflicting National Standard (dow): 31 May 2019
Modal verbs terminology In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). "must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 6 1 Scope The present document specifies the semantic content that flows across the interfaces of ERD services which are specified in ETSI EN 319 522-1 [1], clause 5. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at https://docbox.etsi.org/Reference/. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. [1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 1: Framework and Architecture". [2] IETF RFC 3061: "A URN Namespace of Object Identifiers". [3] Core Person Vocabulary v2.0. NOTE: Available at https://joinup.ec.europa.eu/solution/core-person-vocabulary.
[4] Registered Organizations Vocabulary v2.0. NOTE: Available at https://joinup.ec.europa.eu/solution/registered-organization-vocabulary.
2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. [i.1] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. [i.2] Directive 2012/17/EU of the European Parliament and of the Council of 13 June 2012 amending Council Directive 89/666/EEC and Directives 2005/56/EC and 2009/101/EC of the European Parliament and of the Council as regards the interconnection of central, commercial and companies registers. Text with EEA relevance. [i.3] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace". [i.4] IETF RFC 5332: "Internet Message Format". [i.5] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites". SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 7 [i.6] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists". [i.7] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 3: Formats". [i.8] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings". [i.9] ETSI EN 319 522-4-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 4: Bindings; Sub-part 2: evidence and identification bindings". [i.10] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile", Version 1.1.2. October 2016. [i.11] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures". [i.12] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures". [i.13] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures". 3 Definitions For the purposes of the present document, the terms and definitions given in ETSI EN 319 522-1 [1] and the following apply: ERD dispatch: ERD message which contains the user content, some ERDS relay metadata and ERDS evidence ERD payload: ERD message which contains the user content and some ERDS relay metadata ERDS receipt: ERD message which contains ERDS evidence and some ERDS relay metadata ERDS serviceinfo: ERD message which contains some ERDS relay metadata 4 Overview The present document specifies the semantic content that flows across the interfaces which have been identified in ETSI EN 319 522-1 [1]. No requirements are introduced on the specific formats for the content; formats are specified in ETSI EN 319 522-3 [i.7]. Figure 1 outlines how data flows through the interfaces in the four corner model. User content shall not be changed by ERDSs. Data flowing between systems is always encrypted, as specified by the applicable binding. As detailed below, not all objects are always required. SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 8
Figure 1: Data flowing through interfaces For convenience, the present document defines (table 1) some aggregate constructs (ERD dispatch, ERDS receipt, ERDS serviceInfo, ERD payload, original message) which package the basic objects (user content, ERDS relay metadata, ERDS evidence, submission metadata) in different modes. Constructs define the semantic information flowing between parties, so they ease the definition of bindings [3] [4], even if, specific bindings may split the construct in its basic objects for transport. The naming convention used in the present document is that constructs whose content is completely generated by the ERDS are prefixed with "ERDS", while constructs whose content includes user generated data is prefixed with "ERD". Table 1 specifies the composition of constructs as a collection of basic objects. Table 1: Composition of constructs Basic object Construct user content ERDS relay metadata ERDS evidence submission metadata ERD message ERD dispatch 1 1 1.n 0 ERDS receipt 0 1 1.n 0 ERDS serviceInfo 0 1 0 0 ERD payload 1 1 0 0
original message 1 0 0 0.1
Table 2 provides an abstract specification of the functions provided by the ERDS APIs as defined in ETSI EN 319 522-1 [1]. SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 9 Table 2: Abstract interfaces Interface Provided function Description Arguments and output ERDS MSI out := SubmitMessage(og) The method is used for posting an original message to the S-ERDS. In order to use the SubmitMessage API, the UA/Application has to prove that the sender is the owner of the sender's identifier (via an authentication token, a challenge response, etc.). og: original message, composed of user content and (optional) submission metadata. out: the outcome of the method. There is no specification on the outcome, which may be a simple success/error indication, or may include a message identifier or a larger set of information. ERDS MERI out :=RetrieveMessage (mi) The method is used for retrieving a user content from the R-ERDS. Alternatively, a push of the user content to the recipient UA/application can be used through the ERD-UA MEPI interface In order to use the RetrieveMessageAPI, the UA/Application has to prove that the recipient is the owner of the recipient's identifier (via an authentication token, a challenge response, etc.). mi: this is a set of parameters which is used for the identification and retrieval of the requested user content. out: this is the outcome of the method, which, in case of success, includes the user content and possibly handover metadata and ERDS evidence. In case of failure the outcome will include error information. e := GetEvidences(ei) The method is used for retrieving one or more evidences associated to a user content which has previously been managed by the ERDS. Note that this is not the only way to obtain evidence, since an evidence can be transmitted in different ways (e.g. as an output of the SubmitMessage or the RetrieveMessage). ei: this is a set of parameters which is used for the identification and retrieval of the requested evidence.
e: the requested evidences. ERD-UA MEPI out := HandoverObjects(o) The method is used for handing over user content, ERDS evidence, handover metadata to the ERD-UA. o: a combination of user content [0.1], ERDS evidence [0.n], handover metadata [0.1], excluding void. out: this is the outcome of the method, which is a success/failure indication plus error information in case of failure.
ERDS RI out := Relay(em) The method is used for relaying an ERD message to a different ERDS. Relaying is used when S-ERDS has not the capability to deliver to the recipient itself. Metadata and evidences may be transmitted with the user content or independently from the user content through this method. em: ERD message. out: this is the outcome of the method, which is a success/failure indication plus error information in case of failure. It may also include an evidence and ERDS relay metadata. CSI re:= LookupERDS(ri) This method is used to identify the ERDS which has the capability to deliver to a defined recipient. The method may return more than one ERDS. ri: unique identification of the recipient, which may be one identifier or a set of attributes that together provides unique identification (e.g. id, domain, application protocol, etc.). re: one or more endpoints of the ERDS(s) which has(have) the capability to deliver to the recipient identified by ri. out := ValidateERDS(ei, p) This method may be used to validate the inclusion of an ERDS intro a trust circle. The method may receive some parameters for the validation (e.g. date and time of validity, specific trust circle, etc.). ei: a unique identifier for the ERDS. p: a set of parameters for the validation out: the outcome of the check, which may include a set of information about the ERDS from a trust perspective.
em := GetERDSMetadata (ei) This method is used to retrieve operational metadata about a specific ERDS.
ei: a unique identifier for the ERDS. em: a set of information about the ERDS from an operational perspective (capabilities, requirements, endpoints).
SIST EN 319 522-2 V1.1.1:2018
ETSI ETSI EN 319 522-2 V1.1.1 (2018-09) 10 The following
...
ETSI EN 319 522-2 V1.1.1 (2018-09)
EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
Electronic Registered Delivery Services;
Part 2: Semantic contents
---------------------- Page: 1 ----------------------
2 ETSI EN 319 522-2 V1.1.1 (2018-09)
Reference
DEN/ESI-0019522-2
Keywords
e-delivery services, registered e-delivery
services, registered electronic mail
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI EN 319 522-2 V1.1.1 (2018-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions . 7
4 Overview . 7
5 Identification of actors. 10
5.1 Introduction . 10
5.2 Identifiers . 10
5.3 Identity attributes . 10
5.3.1 Introduction. 10
5.3.2 Identity attributes of natural persons . 10
5.3.3 Identity attributes of legal person . 11
5.3.4 Identity attributes of other entities . 11
5.4 Identity verification and authentication assurance levels information . 11
6 ERDS relay metadata . 12
6.1 Introduction . 12
6.2 Metadata components . 12
6.2.1 MD01 - Metadata version . 12
6.2.2 MD02 - Relay date and time . 12
6.2.3 MD03 - Expiry date and time . 13
6.2.4 MD04 - Recipient required level of assurance . 13
6.2.5 MD05 - Applicable policy . 13
6.2.6 MD06 - Mode of consignment . 14
6.2.7 MD07 - Scheduled delivery . 14
6.2.8 MD08 - Sender's identifier . 14
6.2.9 MD09 - Reply-to . 14
6.2.10 MD10 - Recipient's identifier . 15
6.2.11 MD11 - Message identifier . 15
6.2.12 MD12 - In reply to . 15
6.2.13 MD13 - Message type . 15
6.2.14 MD14 - User content information . 15
6.2.15 MD15 - Other metadata . 16
7 Digital signatures in ERDS provisioning . 16
7.1 Objects and actors for digital signatures . 16
7.2 Common requirements for digital signatures . 16
8 ERDS evidence set and components . 17
8.1 Introduction . 17
8.2 Evidence components . 17
8.2.1 G01 - Evidence identifier . 17
8.2.2 G02 - Evidence version . 18
8.2.3 G03 - Event identifier . 18
8.2.4 G04 - Reason identifier . 18
8.2.5 G05 - Event time . 18
8.2.6 G06 - Transaction log information . 18
8.2.7 R01 - Evidence issuer policy identifier . 19
8.2.8 R02 - Evidence issuer details . 19
8.2.9 R03 - Signature by issuing ERDS . 19
8.2.10 I01 - Sender's identity attributes . 19
ETSI
---------------------- Page: 3 ----------------------
4 ETSI EN 319 522-2 V1.1.1 (2018-09)
8.2.11 I02 - Sender's identifier . 19
8.2.12 I03 - Sender's delegate identity attributes . 20
8.2.13 I04 - Sender's delegate identifier. 20
8.2.14 I05 - Recipient's identity attributes . 20
8.2.15 I06 - Recipient's identifier. 20
8.2.16 I07 - Recipient's delegate identity attributes . 21
8.2.17 I08 - Recipient's delegate identifier . 21
8.2.18 I09 - Recipient referred to by the evidence . 21
8.2.19 I10 - Sender's identity assurance level details . 21
8.2.20 I11 - Sender's delegate identity assurance level details . 22
8.2.21 I12 - Recipient's identity assurance level details . 22
8.2.22 I13 - Recipient's delegate identity assurance level details . 22
8.2.23 M01 - Message identifier . 22
8.2.24 M02 - User content information . 22
8.2.25 M03 - Submission date and time . 23
8.2.26 M04 - External system . 23
8.2.27 M05 - External ERDS . 23
8.2.28 E01 - Extensions . 23
8.3 Evidence components values . 23
8.3.1 Free text . 23
8.3.2 Events . 23
8.3.3 Reasons . 24
8.3.3.1 Reasons related to Events A.1, A.2 (Sender's submission) . 24
8.3.3.2 Reasons related to the Events B.1, B.2, B.3 (Relay between ERDSs) . 24
8.3.3.3 Reasons related to events C.1, C.2, C.3, C.4, C.5 (Acceptance/rejection by the recipient) . 24
8.3.3.4 Reasons related to events D.1, D.2, D.3, D.4 (Consignment to the recipient) . 25
8.3.3.5 Reasons related to events E.1, E.2 (Handover to the recipient) . 25
8.3.3.6 Reasons related to events F1, F2 (Connection to non ERDS) . 25
8.4 Additional requirements for components of evidence . 25
9 Common Services Interface content . 28
9.1 Introduction . 28
9.2 ERD message routing . 28
9.3 ERDS trust establishment and governance . 28
9.4 Capability management . 29
9.4.1 Introduction. 29
9.4.2 Resolving recipient identification to ERDS identification . 29
9.4.3 Recipient metadata . 30
9.4.4 ERDS capability metadata . 30
History . 32
ETSI
---------------------- Page: 4 ----------------------
5 ETSI EN 319 522-2 V1.1.1 (2018-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI).
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [1].
National transposition dates
Date of adoption of this EN: 23 August 2018
Date of latest announcement of this EN (doa): 30 November 2018
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 May 2019
Date of withdrawal of any conflicting National Standard (dow): 31 May 2019
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 5 ----------------------
6 ETSI EN 319 522-2 V1.1.1 (2018-09)
1 Scope
The present document specifies the semantic content that flows across the interfaces of ERD services which are
specified in ETSI EN 319 522-1 [1], clause 5.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[2] IETF RFC 3061: "A URN Namespace of Object Identifiers".
[3] Core Person Vocabulary v2.0.
NOTE: Available at https://joinup.ec.europa.eu/solution/core-person-vocabulary.
[4] Registered Organizations Vocabulary v2.0.
NOTE: Available at https://joinup.ec.europa.eu/solution/registered-organization-vocabulary.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the user
with regard to a particular subject area.
[i.1] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and
repealing Directive 1999/93/EC.
[i.2] Directive 2012/17/EU of the European Parliament and of the Council of 13 June 2012 amending
Council Directive 89/666/EEC and Directives 2005/56/EC and 2009/101/EC of the European
Parliament and of the Council as regards the interconnection of central, commercial and
companies registers. Text with EEA relevance.
[i.3] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[i.4] IETF RFC 5332: "Internet Message Format".
[i.5] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
ETSI
---------------------- Page: 6 ----------------------
7 ETSI EN 319 522-2 V1.1.1 (2018-09)
[i.6] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists".
[i.7] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[i.8] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings".
[i.9] ETSI EN 319 522-4-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 2: evidence and identification bindings".
[i.10] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile", Version 1.1.2. October 2016.
[i.11] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures;
Part 1: Building blocks and CAdES baseline signatures".
[i.12] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
[i.13] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures;
Part 1: Building blocks and PAdES baseline signatures".
3 Definitions
For the purposes of the present document, the terms and definitions given in ETSI EN 319 522-1 [1] and the following
apply:
ERD dispatch: ERD message which contains the user content, some ERDS relay metadata and ERDS evidence
ERD payload: ERD message which contains the user content and some ERDS relay metadata
ERDS receipt: ERD message which contains ERDS evidence and some ERDS relay metadata
ERDS serviceinfo: ERD message which contains some ERDS relay metadata
4 Overview
The present document specifies the semantic content that flows across the interfaces which have been identified in ETSI
EN 319 522-1 [1]. No requirements are introduced on the specific formats for the content; formats are specified in ETSI
EN 319 522-3 [i.7].
Figure 1 outlines how data flows through the interfaces in the four corner model. User content shall not be changed by
ERDSs. Data flowing between systems is always encrypted, as specified by the applicable binding. As detailed below,
not all objects are always required.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI EN 319 522-2 V1.1.1 (2018-09)
Figure 1: Data flowing through interfaces
For convenience, the present document defines (table 1) some aggregate constructs (ERD dispatch, ERDS receipt,
ERDS serviceInfo, ERD payload, original message) which package the basic objects (user content, ERDS relay
metadata, ERDS evidence, submission metadata) in different modes. Constructs define the semantic information
flowing between parties, so they ease the definition of bindings [3] [4], even if, specific bindings may split the construct
in its basic objects for transport.
The naming convention used in the present document is that constructs whose content is completely generated by the
ERDS are prefixed with "ERDS", while constructs whose content includes user generated data is prefixed with "ERD".
Table 1 specifies the composition of constructs as a collection of basic objects.
Table 1: Composition of constructs
Basic object user content ERDS relay ERDS submission
Construct metadata evidence metadata
ERD dispatch 1 1 1.n 0
ERD ERDS receipt 0 1 1.n 0
message
ERDS serviceInfo 0 1 0 0
ERD payload 1 1 0 0
original message 1 0 0 0.1
Table 2 provides an abstract specification of the functions provided by the ERDS APIs as defined in ETSI
EN 319 522-1 [1].
ETSI
---------------------- Page: 8 ----------------------
9 ETSI EN 319 522-2 V1.1.1 (2018-09)
Table 2: Abstract interfaces
Interface Provided function Description Arguments and output
out := The method is used for posting an og: original message, composed of user
SubmitMessage(og) original message to the S-ERDS. content and (optional) submission
In order to use the SubmitMessage API, metadata.
ERDS the UA/Application has to prove that the out: the outcome of the method. There is
MSI sender is the owner of the sender's no specification on the outcome, which
identifier (via an authentication token, a may be a simple success/error
challenge response, etc.). indication, or may include a message
identifier or a larger set of information.
out The method is used for retrieving a user mi: this is a set of parameters which is
:=RetrieveMessage content from the R-ERDS. Alternatively, used for the identification and retrieval of
(mi) a push of the user content to the the requested user content.
recipient UA/application can be used out: this is the outcome of the method,
through the ERD-UA MEPI interface which, in case of success, includes the
In order to use the RetrieveMessageAPI, user content and possibly handover
the UA/Application has to prove that the metadata and ERDS evidence. In case
recipient is the owner of the recipient's of failure the outcome will include error
identifier (via an authentication token, a information.
ERDS
challenge response, etc.).
MERI
e := GetEvidences(ei) The method is used for retrieving one or ei: this is a set of parameters which is
more evidences associated to a user used for the identification and retrieval of
content which has previously been the requested evidence.
managed by the ERDS. Note that this is e: the requested evidences.
not the only way to obtain evidence,
since an evidence can be transmitted in
different ways (e.g. as an output of the
SubmitMessage or the
RetrieveMessage).
out := The method is used for handing over o: a combination of user content [0.1],
HandoverObjects(o) user content, ERDS evidence, handover ERDS evidence [0.n], handover
ERD-UA metadata to the ERD-UA. metadata [0.1], excluding void.
MEPI out: this is the outcome of the method,
which is a success/failure indication plus
error information in case of failure.
out := Relay(em) The method is used for relaying an ERD em: ERD message.
message to a different ERDS. Relaying out: this is the outcome of the method,
is used when S-ERDS has not the which is a success/failure indication plus
capability to deliver to the recipient itself. error information in case of failure. It may
ERDS RI
Metadata and evidences may be also include an evidence and ERDS
transmitted with the user content or relay metadata.
independently from the user content
through this method.
re:= LookupERDS(ri) This method is used to identify the
ri: unique identification of the recipient,
ERDS which has the capability to deliver which may be one identifier or a set of
to a defined recipient. The method may attributes that together provides unique
return more than one ERDS. identification (e.g. id, domain, application
protocol, etc.).
re: one or more endpoints of the
ERDS(s) which has(have) the capability
to deliver to the recipient identified by ri.
out := This method may be used to validate the ei: a unique identifier for the ERDS.
CSI
ValidateERDS(ei, p) inclusion of an ERDS intro a trust circle. p: a set of parameters for the validation
The method may receive some out: the outcome of the check, which
parameters for the validation (e.g. date may include a set of information about
and time of validity, specific trust circle, the ERDS from a trust perspective.
etc.).
em := This method is used to retrieve ei: a unique identifier for the ERDS.
GetERDSMetadata operational metadata about a specific em: a set of information about the ERDS
(ei) ERDS. from an operational perspective
(capabilities, requirements, endpoints).
ETS
...
Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
������������������
Electronic Signatures and Infrastructures (ESI);
Electronic Registered Delivery Services;
Part 2: Semantic contents
---------------------- Page: 1 ----------------------
2 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
Reference
DEN/ESI-0019522-2
Keywords
e-delivery services, registered e-delivery
services, registered electronic mail
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
Contents
Intellectual Property Rights . 5�
Foreword . 5�
Modal verbs terminology . 5�
1 Scope . 6�
2 References . 6�
2.1 Normative references . 6�
2.2 Informative references . 6�
3 Definitions . 7�
4 Overview . 7�
5 Identification of actors . 10�
5.1 Introduction .10�
5.2 Identifiers .10�
5.3 Identity attributes .10�
5.3.1 Introduction .10�
5.3.2 Identity attributes of natural persons .10�
5.3.3 Identity attributes of legal person .10�
5.3.4 Identity attributes of other entities .11�
5.4 Identity verification and authentication assurance levels information .11�
6 ERDS relay metadata . 12�
6.1 Introduction .12�
6.2 Metadata components .12�
6.2.1 MD01 - Metadata version .12�
6.2.2 MD02 - Relay date and time .12�
6.2.3 MD03 - Expiry date and time .13�
6.2.4 MD04 - Recipient required level of assurance .13�
6.2.5 MD05 - Applicable policy .13�
6.2.6 MD06 - Mode of consignment .14�
6.2.7 MD07 - Scheduled delivery .14�
6.2.8 MD08 - Sender's identifier .14�
6.2.9 MD09 - Reply-to .14�
6.2.10 MD10 - Recipient's identifier .15�
6.2.11 MD11 - Message identifier .15�
6.2.12 MD12 - In reply to .15�
6.2.13 MD13 - Message type .15�
6.2.14 MD14 - User content information .15�
6.2.15 MD15 - Other metadata .16�
7 Digital signatures in ERDS provisioning . 16�
7.1 Objects and actors for digital signatures .16�
7.2 Common requirements for digital signatures .16�
8 ERDS evidence set and components . 17�
8.1 Introduction .17�
8.2 Evidence components .17�
8.2.1 G01 - Evidence identifier .17�
8.2.2 G02 - Evidence version .18�
8.2.3 G03 - Event identifier .18�
8.2.4 G04 - Reason identifier .18�
8.2.5 G05 - Event time .18�
8.2.6 G06 - Transaction log information .18�
8.2.7 R01 - Evidence issuer policy identifier .19�
8.2.8 R02 - Evidence issuer details .19�
8.2.9 R03 - Signature by issuing ERDS .19�
8.2.10 I01 - Sender's identity attributes .19�
ETSI
---------------------- Page: 3 ----------------------
4 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
8.2.11 I02 - Sender's identifier .19�
8.2.12 I03 - Sender's delegate identity attributes .20�
8.2.13 I04 - Sender's delegate identifier .20�
8.2.14 I05 - Recipient's identity attributes .20�
8.2.15 I06 - Recipient's identifier .20�
8.2.16 I07 - Recipient's delegate identity attributes .21�
8.2.17 I08 - Recipient's delegate identifier.21�
8.2.18 I09 - Recipient referred to by the evidence .21�
8.2.19 I10 - Sender's identity assurance level details .21�
8.2.20 I11 - Sender's delegate identity assurance level details .22�
8.2.21 I12 - Recipient's identity assurance level details .22�
8.2.22 I13 - Recipient's delegate identity assurance level details .22�
8.2.23 M01 - Message identifier .22�
8.2.24 M02 - User content information .22�
8.2.25 M03 - Submission date and time .23�
8.2.26 M04 - External system .23�
8.2.27 M05 - External ERDS .23�
8.2.28 E01 - Extensions .23�
8.3 Evidence components values .23�
8.3.1 Free text .23�
8.3.2 Events.23�
8.3.3 Reasons .24�
8.3.3.1 Reasons related to Events A.1, A.2 (Sender's submission) .24�
8.3.3.2 Reasons related to the Events B.1, B.2, B.3 (Relay between ERDSs) .24�
8.3.3.3 Reasons related to events C.1, C.2, C.3, C.4, C.5 (Acceptance/rejection by the recipient) .24�
8.3.3.4 Reasons related to events D.1, D.2, D.3, D.4 (Consignment to the recipient) .25�
8.3.3.5 Reasons related to events E.1, E.2 (Handover to the recipient) .25�
8.3.3.6 Reasons related to events F1, F2 (Connection to non ERDS) .25�
8.4 Additional requirements for components of evidence .25�
9 Common Services Interface content . 28�
9.1 Introduction .28�
9.2 ERD message routing .28�
9.3 ERDS trust establishment and governance .28�
9.4 Capability management .29�
9.4.1 Introduction .29�
9.4.2 Resolving recipient identification to ERDS identification .29�
9.4.3 Recipient metadata .30�
9.4.4 ERDS capability metadata .30�
History . 32�
ETSI
---------------------- Page: 4 ----------------------
5 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This draft European Standard (EN) has been produced by ETSI Technical Committee Electronic Signatures and
Infrastructures (ESI), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI standards EN
Approval Procedure.
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 [1].
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 5 ----------------------
6 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
1 Scope
The present document specifies the semantic content that flows across the interfaces of ERD services which are
specified in ETSI EN 319 522-1 [1], clause 5.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[2] IETF RFC 3061: "A URN Namespace of Object Identifiers".
[3] Core Person Vocabulary v2.0.
NOTE: Available at https://joinup.ec.europa.eu/solution/core-person-vocabulary.
[4] Registered Organizations Vocabulary v2.0.
NOTE: Available at https://joinup.ec.europa.eu/solution/registered-organization-vocabulary.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the user
with regard to a particular subject area.
[i.1] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on
electronic identification and trust services for electronic transactions in the internal market and
repealing Directive 1999/93/EC.
[i.2] Directive 2012/17/EU of the European Parliament and of the Council of 13 June 2012 amending
Council Directive 89/666/EEC and Directives 2005/56/EC and 2009/101/EC of the European
Parliament and of the Council as regards the interconnection of central, commercial and
companies registers. Text with EEA relevance.
[i.3] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[i.4] IETF RFC 5332: "Internet Message Format".
[i.5] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
ETSI
---------------------- Page: 6 ----------------------
7 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
[i.6] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists".
[i.7] ETSI EN 319 522-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 3: Formats".
[i.8] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings".
[i.9] ETSI EN 319 522-4-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 2: evidence and identification bindings".
[i.10] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile", Version 1.1.2. October 2016.
[i.11] ETSI EN 319 122-1: "Electronic Signatures and Infrastructures (ESI); CAdES digital signatures;
Part 1: Building blocks and CAdES baseline signatures".
[i.12] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
[i.13] ETSI EN 319 142-1: "Electronic Signatures and Infrastructures (ESI); PAdES digital signatures;
Part 1: Building blocks and PAdES baseline signatures".
3 Definitions
For the purposes of the present document, the terms and definitions given in ETSI EN 319 522-1 [1] and the following
apply:
ERD dispatch: ERD message which contains the user content, some ERDS relay metadata and ERDS evidence
ERD payload: ERD message which contains the user content and some ERDS relay metadata
ERDS receipt: ERD message which contains ERDS evidence and some ERDS relay metadata
ERDS serviceinfo: ERD message which contains some ERDS relay metadata
4 Overview
The present document specifies the semantic content that flows across the interfaces which have been identified in ETSI
EN 319 522-1 [1]. No requirements are introduced on the specific formats for the content; formats are specified in ETSI
EN 319 522-3 [i.7].
Figure 1 outlines how data flows through the interfaces in the four corner model. User content shall not be changed by
ERDSs. Data flowing between systems is always encrypted, as specified by the applicable binding. As detailed below,
not all objects are always required.
ETSI
---------------------- Page: 7 ----------------------
8 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
Figure 1: Data flowing through interfaces
For convenience, the present document defines (table 1) some aggregate constructs (ERD dispatch, ERDS receipt,
ERDS serviceInfo, ERD payload, original message) which package the basic objects (user content, ERDS relay
metadata, ERDS evidence, submission metadata) in different modes. Constructs define the semantic information
flowing between parties, so they ease the definition of bindings [3] [4], even if, specific bindings may split the construct
in its basic objects for transport.
The naming convention used in the present document is that constructs whose content is completely generated by the
ERDS are prefixed with "ERDS", while constructs whose content includes user generated data is prefixed with "ERD".
Table 1 specifies the composition of constructs as a collection of basic objects.
Table 1: Composition of constructs
Basic object user content ERDS relay ERDS submission
Construct metadata evidence metadata
ERD dispatch 1 1 1.n 0
ERD ERDS receipt 0 1 1.n 0
message ERDS serviceInfo 0 1 0 0
ERD payload 1 1 0 0
original message 1 0 0 0.1
Table 2 provides an abstract specification of the functions provided by the ERDS APIs as defined in ETSI
EN 319 522-1 [1].
ETSI
---------------------- Page: 8 ----------------------
9 Draft ETSI EN 319 522-2 V1.0.0 (2018-05)
Table 2: Abstract interfaces
Interface Provided function Description Arguments and output
out := The method is used for posting an og: original message, composed of user
SubmitMessage(og) original message to the S-ERDS. content and (optional) submission
In order to use the SubmitMessage API, metadata.
ERDS the UA/Application has to prove that the out: the outcome of the method. There is
MSI sender is the owner of the sender's no specification on the outcome, which
identifier (via an authentication token, a may be a simple success/error
challenge response, etc.). indication, or may include a message
identifier or a larger set of information.
out The method is used for retrieving a user mi: this is a set of parameters which is
:=RetrieveMessage content from the R-ERDS. Alternatively, used for the identification and retrieval of
(mi) a push of the user content to the the requested user content.
recipient UA/application can be used out: this is the outcome of the method,
through the ERD-UA MEPI interface which, in case of success, includes the
In order to use the RetrieveMessageAPI, user content and possibly handover
the UA/Application has to prove that the metadata and ERDS evidence. In case
recipient is the owner of the recipient's of failure the outcome will include error
identifier (via an authentication token, a information.
ERDS
challenge response, etc.).
MERI
e := GetEvidences(ei) The method is used for retrieving one or ei: this is a set of parameters which is
more evidences associated to a user used for the identification and retrieval of
content which has previously been the requested evidence.
managed by the ERDS. Note that this is e: the requested evidences.
not the only way to obtain evidence,
since an evidence can be transmitted in
different ways (e.g. as an output of the
SubmitMessage or the
RetrieveMessage).
out := The method is used for handing over o: a combination of user content [0.1],
HandoverObjects(o) user content, ERDS evidence, handover ERDS evidence [0.n], handover
ERD-UA metadata to the ERD-UA. metadata [0.1], excluding void.
MEPI out: this is the outcome of the method,
which is a success/failure indication plus
error information in case of failure.
out := Relay(em) The method is used for relaying an ERD em: ERD message.
message to a different ERDS. Relaying out: this is the outcome of the method,
is used when S-ERDS has not the which is a success/failure indication plus
capability to deliver to the recipient itself. error information in case of failure. It may
ERDS RI
Metadata and evidences may be also include an evidence and ERDS
transmitted with the user content or relay metadata.
independently from the user content
through this method.
re:= LookupERDS(ri) This method is used to identify the ri: unique identification of the recipient,
ERDS which has the capability to deliver which may be one identifier or a set of
to a defined recipient. The method may attributes that together provides unique
return more than one ERDS. identification (e.g. id, domain, application
protocol, etc.).
re: one or more endpoints of the
ERDS(s) which has(have) the capability
to deliver to the recipient identified by ri.
CSI
out := This method may be used to validate the ei: a unique identifier for the ERDS.
ValidateERDS(ei, p) inclusion of an ERDS intro a trust circle. p: a set of parameters for the validation
The method may receive some out: the outcome of the check, which
parameters for the validation (e.g. date may include a set of information about
and time of validity, specific trust circle, the ERDS from a trust perspective.
etc.).
em := This method is used to retrieve ei: a unique identifier for the ERDS.
GetERDSMetadata operational metadata about a specific em: a set of information about th
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.