SIST EN 319 522-2 V1.2.1:2024

EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
Electronic Registered Delivery Services;
Part 2: Semantic contents
2 ETSI EN 319 522-2 V1.2.1 (2024-01)

Reference
REN/ESI-0019522-2v121
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 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2024.
All rights reserved.
ETSI
3 ETSI EN 319 522-2 V1.2.1 (2024-01)
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 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 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 . 10
5.4 Identity verification and authentication assurance levels information . 11
6 ERDS relay metadata . 11
6.1 Introduction . 11
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 . 12
6.2.4 MD04 - Recipient required level of assurance . 12
6.2.5 MD05 - Applicable policy . 13
6.2.6 MD06 - Mode of consignment . 13
6.2.7 MD07 - Scheduled delivery . 13
6.2.8 MD08 - Sender's identifier . 14
6.2.9 MD09 - Reply-to . 14
6.2.10 MD10 - Recipient's identifier . 14
6.2.11 MD11 - Message identifier . 14
6.2.12 MD12 - In reply to . 14
6.2.13 MD13 - Message type . 14
6.2.14 MD14 - User content information . 15
6.2.15 MD15 - Other metadata . 15
7 Digital signatures in ERDS provisioning . 15
7.1 Objects and actors for digital signatures . 15
7.2 Common requirements for digital signatures . 15
8 ERDS evidence set and components . 16
8.1 Introduction . 16
8.2 Evidence components . 17
8.2.1 G01 - Evidence identifier . 17
8.2.2 G02 - Evidence version . 17
8.2.3 G03 - Event identifier . 17
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 . 18
ETSI
4 ETSI EN 319 522-2 V1.2.1 (2024-01)
8.2.8 R02 - Evidence issuer details . 18
8.2.9 R03 - Signature by issuing ERDS . 19
8.2.10 I01 - Sender's identity attributes . 19
8.2.11 I02 - Sender's identifier . 19
8.2.12 I03 - Sender's delegate identity attributes . 19
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 . 20
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 . 21
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 . 22
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.x (Sender's submission) . 24
8.3.3.2 Reasons related to the Events B.x (Relay between ERDSs) . 25
8.3.3.3 Reasons related to events C.x (Acceptance/rejection by the recipient) . 25
8.3.3.4 Reasons related to events D.x (Consignment to the recipient) . 27
8.3.3.5 Reasons related to events E.x (Handover to the recipient) . 27
8.3.3.6 Reasons related to events F.x (Connection to non ERDS) . 28
8.4 Additional requirements for components of evidence . 29
9 Common Services Interface content . 31
9.1 Introduction . 31
9.2 ERD message routing . 31
9.3 ERDS trust establishment and governance . 31
9.4 Capability management . 32
9.4.1 Introduction. 32
9.4.2 Resolving recipient identification to ERDS identification . 32
9.4.3 Recipient metadata . 33
9.4.4 ERDS capability metadata . 33
Annex A (informative): Change History . 35
History . 36

ETSI
5 ETSI EN 319 522-2 V1.2.1 (2024-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
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: 3 January 2024
Date of latest announcement of this EN (doa): 30 April 2024
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 October 2024
Date of withdrawal of any conflicting National Standard (dow): 31 October 2024

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
6 ETSI EN 319 522-2 V1.2.1 (2024-01)
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.
[4] Registered Organizations Vocabulary v2.0.
[5] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile", Version 1.2. August 2019.
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] Void.
[i.3] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[i.4] IETF RFC 5322: "Internet Message Format".
[i.5] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
[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".
ETSI
7 ETSI EN 319 522-2 V1.2.1 (2024-01)
[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] Void.
[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 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms 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
3.2 Symbols
Void.
3.3 Abbreviations
Void.
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 4-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
8 ETSI EN 319 522-2 V1.2.1 (2024-01)

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] and [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
NOTE: ERDS receipt (which contains ERDS relay metadata and also ERDS evidence) and ERDS serviceInfo
(which only contains ERDS relay metadata) may play the role of notifications in those cases where this
feature is required, and in such cases the recipient can be informed of this role by some metadata or other
element.
Table 2 provides an abstract specification of the functions provided by the ERDS APIs as defined in ETSI
EN 319 522-1 [1].
ETSI
9 ETSI EN 319 522-2 V1.2.1 (2024-01)
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).

ETSI
10 ETSI EN 319 522-2 V1.2.1 (2024-01)
The following clauses specify the semantics of the data which are transported through the interfaces; in particular:
• Clause 5 specifies the semantics of the components required for identifying the sender and the recipient.
• Clause 6 specifies the semantics of ERDS relay metadata.
• Clause 8 specifies the semantics of ERDS Evidence.
• Clause 9 specifies the semantics of information for Common Service Interface.
5 Identification of actors
5.1 Introduction
An ERDS needs to generate, exchange and validate attributes to support the identification and authentication of end
entities like sender, recipient or a delegate.
5.2 Identifiers
An identifier shall have two components: an identifying scheme name and the identifier value, which shall be coherent
with the identifying scheme name. The identifier shall be unique within the network of interoperating ERDSs.
5.3 Identity attributes
5.3.1 Introduction
All attributes in the present document related to identification and authentication are derived from the EU Vocabulary.
For natural persons, the attributes defined by the Core Person Vocabulary [3] shall be used, for legal persons, the
attributes defined by the Registered Organization Vocabulary [4] shall be used. The Registered Organization
Vocabulary defines the core vocabulary for legal persons registered through a formal process, typically in a national or
regional register.
For the sake of simplicity, the present document limits the supported attributes to the ones defined in the eIDAS
attribute profile specification [5], which are also attributes derived from the ISA vocabulary.
5.3.2 Identity attributes of natural persons
For legal persons, a non empty subset of the identity attributes identified in [5], clause 2.3.1 shall be used.
Table 3: Void.
5.3.3 Identity attributes of legal person
For natural persons, a non empty subset of the identity attributes identified in [5], clause 2.2.1 shall be used.
Table 4: Void.
5.3.4 Identity attributes of other entities
Identity attributes may also be provided for entities which do not correspond to natural or legal persons
(e.g. applications, things). They are not specified in the current version of the present document.
ETSI
11 ETSI EN 319 522-2 V1.2.1 (2024-01)
5.4 Identity verification and authentication assurance levels
information
This clause defines the information which is necessary to establish the level of assurance for the entities which take part
in the electronic delivery process. This information shall include:
1) An attribute containing details of the registration and identity proofing and verification assurance level. This
attribute:
a) shall contain one identifier of the assurance level itself. This identifier shall have a URI as value;
b) may also contain an identifier of the identification policy. This identifier shall have a URI as value;
c) may also contain details on the identification policy;
d) may also contain one or more URIs pointing to resources that contain details of the aforementioned
policy provided in different languages.
2) An attribute containing details of the authentication means and mechanisms assurance level. This attribute:
a) shall contain one identifier of the assurance level itself. This identifier shall have a URI as value;
b) may also contain an identifier of the authentication policy. This identifier shall have a URI as value;
c) may also contain details on the authentication policy;
d) may also contain one or more URIs pointing to resources that contain details of the aforementioned
policy provided in different languages.
Furthermore, the identity assurance information may include an attribute containing details of the performed
authentication, either an assertion generated by an assertion provider or as a sequence of components, consisting of:
• the date and time when the authentication process was conducted;
• the identification of the authentication method used.
6 ERDS relay metadata
6.1 Introduction
ERDS relay metadata is produced by an ERDS and is provided to a peer ERDS. It includes a set of information for the
correct processing of the user content between different actors in the delivery process. The ERDS relay metadata may
be transmitted together with the user content, with some evidence, or alone as described in ETSI EN 319 522-4-1 [i.8]
and ETSI EN 319 522-4-2 [i.9].
Part of ERDS relay metadata may be replicated in evidences. This is allowed, since metadata may be used for the
delivery process; it is also relevant when the user content flows detached from the evidence. ERDS relay metadata shall
include metadata components as indicated in the Cardinality column of table 5.
Table 5: Relay metadata components
Component Component name Cardinality Ref.
code
Delivery MD01 Metadata version 1 6.2.1
constraints
MD02 Relay date and time 0-1 6.2.2
MD03 Expiry date and time 0-1 6.2.3
MD04 Recipient required level of assurance 0-1 6.2.4
MD05 Applicable policy 0-n 6.2.5
MD06 Mode of consignment 0-1 6.2.6
MD07 Scheduled delivery 0-1 6.2.7
ETSI
12 ETSI EN 319 522-2 V1.2.1 (2024-01)
Component Component name Cardinality Ref.
code
Sender/ MD08 Sender's identifier 1 6.2.8
Recipient MD09 Reply-to 0-1 6.2.9
MD10 Recipient's identifier 1 6.2.10
ERD MD11 Message identifier 0-1 6.2.11
Message
MD12 In reply to 0-1 6.2.12
information
MD13 ERD Message type 1 6.2.13
MD14 User content information 1 6.2.14
MD15 Extensions 0-1 6.2.15
Signature 0-1 7
6.2 Metadata components
6.2.1 MD01 - Metadata version
Description
Metadata version
Format Binding specific
Meaning The version of the metadata, corresponding to the version of the binding document where it is
defined
Requirements
None
6.2.2 MD02 - Relay date and time
Description Relay date and time
Format Date and time in UTC values
Meaning The date and time when an ERDS relays the ERD message to the next ERDS in the delivery
chain
Requirements An ERDS which forwards the ERD message to a different ERDS may use this component to
indicate the time when the relay takes place

6.2.3 MD03 - Expiry date and time
Description
Expiry date and time
Format Date and time in UTC values
Meaning The date-time by which the consignment or handover to recipient is required to be completed.
Requirements R-ERDS shall not consign or hand over the user content if the date-time is after the one
indicated by this component.
The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.4 MD04 - Recipient required level of assurance
Description Recipient required level of assurance
Format
LoA enumeration
Meaning
The level of assurance of the identity of the recipient that the sender requires.
Requirements The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
An ERDS shall not relay the ERD message if R-ERDS capabilities (retrieved through CSI) do
not include the capability to identify the recipient at or above the required level.
R-ERDS shall not deliver the user content if it cannot meet the required identification LoA
specified by this component.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

ETSI
13 ETSI EN 319 522-2 V1.2.1 (2024-01)
6.2.5 MD05 - Applicable policy
Description Applicable policy
Format This component shall be either an URI or an OID.
If the identifier is an OID, it shall be represented as URN built as specified in IETF
RFC 3061 [2].
Meaning The policy that the S-ERDS requires to be applied to the management of the ERD message by
the subsequent ERDSs in the delivery chain. As an example, the policy may require the
evidence of relay to be returned to the sending ERDS, or that the message is not delivered to a
delegate.
Requirements
The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
Any ERDS shall not relay the user content if the next ERDS capabilities (retrieved through CSI)
do not include the capability to support the mentioned policy.
Any ERDS in the chain shall refuse the ERD message if it cannot support the policy specified
by this component.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.6 MD06 - Mode of consignment
Description Mode of consignment
Format Binding specific, so that to express one of the options below
Meaning
The requested mode of consignment of the user content to the recipient chosen among the
following options:
• Basic: the user content has to be made available to the recipient without the
possibility for the recipient to accept/deny before delivery.
• Consented: a notification shall be sent to the recipient before actual
consignment/handover. The recipient shall be required to perform an explicit action to
accept or reject the user content; the user content shall only be accessible to the
recipient upon acceptance.
• Consented signed: as for Consented, with the addition that the recipient shall be
required to digitally sign an acknowledgment of receipt.
• Other: other modes of consignment can be agreed and specified in specific domains.
Requirements If this component is not present, R-ERDS shall consign the user content according to its policy
and to the recipient's setting.
Any ERDS shall not relay the ERD message if the R-ERDS capabilities (retrieved through CSI)
do not include the capability to support the consignment mode.
R-ERDS shall refuse the consignment of the user content if it cannot support the requested
consignment mode or if the recipient's settings do not allow that consignment mode.
Otherwise, it shall consign the user content according to the requested consignment mode.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.7 MD07 - Scheduled delivery
Description Scheduled delivery
Format Date and time in UTC values
Meaning The time instant after which the user content can be consigned/handed over.
Requirements The user content shall not be handed over to the recipient before this time.
If this component is present, its content shall be provided by the S-ERDS on the base of its
policies or of specific requests from the sender.
Any ERDS in the chain should refuse the ERD message if it cannot support delaying the
delivery of the user content until the time indicated in this component.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

ETSI
14 ETSI EN 319 522-2 V1.2.1 (2024-01)
6.2.8 MD08 - Sender's identifier
Description Sender's identifier
Format
Meaning Identifier of the sender of the user content.
Requirements As defined in clause 5.2.

6.2.9 MD09 - Reply-to
Description A unique reply-to identifier
Format
Binding specific
Meaning
The identifier, as specified in clause 5.2, to which any reply from the recipient or delegate of the
recipient should be sent to, as a result of the reception of the sender's user content.
Requirements The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.10 MD10 - Recipient's identifier
Description
Recipient's identifier
Format
Meaning Identifier of the recipient of the user content, as defined in clause 5.2.
Requirements None.
6.2.11 MD11 - Message identifier
Description Message identifier
Format Binding specific
Meaning Unique identifier of the original message as generated by S-ERDS (e.g. a UUID according to
IETF RFC 4122 [i.3], or an UID as defined in IETF RFC 5322 [i.4]).
Requirements The content of this component is provided by the S-ERDS.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.12 MD12 - In reply to
Description In reply to
Format
Binding specific
Meaning Association to a previous original message. I.e. the message identifier of the original message
to which the new original message is a reply.
Requirements
S-ERDS should produce this component if in-reply-to information is present in su
...

SLOVENSKI STANDARD
01-marec-2024
Elektronski podpisi in infrastruktura (ESI) - Storitve elektronske priporočene
dostave - 2. del: Semantične vsebine
Electronic Signatures and Infrastructures (ESI) - Electronic Registered Delivery Services
- Part 2: Semantic contents
Ta slovenski standard je istoveten z: ETSI EN 319 522-2 V1.2.1 (2024-01)
ICS:
35.040.01 Kodiranje informacij na Information coding in general
splošno
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
Electronic Registered Delivery Services;
Part 2: Semantic contents
2 ETSI EN 319 522-2 V1.2.1 (2024-01)

Reference
REN/ESI-0019522-2v121
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 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2024.
All rights reserved.
ETSI
3 ETSI EN 319 522-2 V1.2.1 (2024-01)
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 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 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 . 10
5.4 Identity verification and authentication assurance levels information . 11
6 ERDS relay metadata . 11
6.1 Introduction . 11
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 . 12
6.2.4 MD04 - Recipient required level of assurance . 12
6.2.5 MD05 - Applicable policy . 13
6.2.6 MD06 - Mode of consignment . 13
6.2.7 MD07 - Scheduled delivery . 13
6.2.8 MD08 - Sender's identifier . 14
6.2.9 MD09 - Reply-to . 14
6.2.10 MD10 - Recipient's identifier . 14
6.2.11 MD11 - Message identifier . 14
6.2.12 MD12 - In reply to . 14
6.2.13 MD13 - Message type . 14
6.2.14 MD14 - User content information . 15
6.2.15 MD15 - Other metadata . 15
7 Digital signatures in ERDS provisioning . 15
7.1 Objects and actors for digital signatures . 15
7.2 Common requirements for digital signatures . 15
8 ERDS evidence set and components . 16
8.1 Introduction . 16
8.2 Evidence components . 17
8.2.1 G01 - Evidence identifier . 17
8.2.2 G02 - Evidence version . 17
8.2.3 G03 - Event identifier . 17
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 . 18
ETSI
4 ETSI EN 319 522-2 V1.2.1 (2024-01)
8.2.8 R02 - Evidence issuer details . 18
8.2.9 R03 - Signature by issuing ERDS . 19
8.2.10 I01 - Sender's identity attributes . 19
8.2.11 I02 - Sender's identifier . 19
8.2.12 I03 - Sender's delegate identity attributes . 19
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 . 20
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 . 21
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 . 22
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.x (Sender's submission) . 24
8.3.3.2 Reasons related to the Events B.x (Relay between ERDSs) . 25
8.3.3.3 Reasons related to events C.x (Acceptance/rejection by the recipient) . 25
8.3.3.4 Reasons related to events D.x (Consignment to the recipient) . 27
8.3.3.5 Reasons related to events E.x (Handover to the recipient) . 27
8.3.3.6 Reasons related to events F.x (Connection to non ERDS) . 28
8.4 Additional requirements for components of evidence . 29
9 Common Services Interface content . 31
9.1 Introduction . 31
9.2 ERD message routing . 31
9.3 ERDS trust establishment and governance . 31
9.4 Capability management . 32
9.4.1 Introduction. 32
9.4.2 Resolving recipient identification to ERDS identification . 32
9.4.3 Recipient metadata . 33
9.4.4 ERDS capability metadata . 33
Annex A (informative): Change History . 35
History . 36

ETSI
5 ETSI EN 319 522-2 V1.2.1 (2024-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
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: 3 January 2024
Date of latest announcement of this EN (doa): 30 April 2024
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 October 2024
Date of withdrawal of any conflicting National Standard (dow): 31 October 2024

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
6 ETSI EN 319 522-2 V1.2.1 (2024-01)
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.
[4] Registered Organizations Vocabulary v2.0.
[5] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile", Version 1.2. August 2019.
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] Void.
[i.3] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[i.4] IETF RFC 5322: "Internet Message Format".
[i.5] ETSI TS 119 312: "Electronic Signatures and Infrastructures (ESI); Cryptographic Suites".
[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".
ETSI
7 ETSI EN 319 522-2 V1.2.1 (2024-01)
[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] Void.
[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 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms 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
3.2 Symbols
Void.
3.3 Abbreviations
Void.
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 4-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
8 ETSI EN 319 522-2 V1.2.1 (2024-01)

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] and [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
NOTE: ERDS receipt (which contains ERDS relay metadata and also ERDS evidence) and ERDS serviceInfo
(which only contains ERDS relay metadata) may play the role of notifications in those cases where this
feature is required, and in such cases the recipient can be informed of this role by some metadata or other
element.
Table 2 provides an abstract specification of the functions provided by the ERDS APIs as defined in ETSI
EN 319 522-1 [1].
ETSI
9 ETSI EN 319 522-2 V1.2.1 (2024-01)
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).

ETSI
10 ETSI EN 319 522-2 V1.2.1 (2024-01)
The following clauses specify the semantics of the data which are transported through the interfaces; in particular:
• Clause 5 specifies the semantics of the components required for identifying the sender and the recipient.
• Clause 6 specifies the semantics of ERDS relay metadata.
• Clause 8 specifies the semantics of ERDS Evidence.
• Clause 9 specifies the semantics of information for Common Service Interface.
5 Identification of actors
5.1 Introduction
An ERDS needs to generate, exchange and validate attributes to support the identification and authentication of end
entities like sender, recipient or a delegate.
5.2 Identifiers
An identifier shall have two components: an identifying scheme name and the identifier value, which shall be coherent
with the identifying scheme name. The identifier shall be unique within the network of interoperating ERDSs.
5.3 Identity attributes
5.3.1 Introduction
All attributes in the present document related to identification and authentication are derived from the EU Vocabulary.
For natural persons, the attributes defined by the Core Person Vocabulary [3] shall be used, for legal persons, the
attributes defined by the Registered Organization Vocabulary [4] shall be used. The Registered Organization
Vocabulary defines the core vocabulary for legal persons registered through a formal process, typically in a national or
regional register.
For the sake of simplicity, the present document limits the supported attributes to the ones defined in the eIDAS
attribute profile specification [5], which are also attributes derived from the ISA vocabulary.
5.3.2 Identity attributes of natural persons
For legal persons, a non empty subset of the identity attributes identified in [5], clause 2.3.1 shall be used.
Table 3: Void.
5.3.3 Identity attributes of legal person
For natural persons, a non empty subset of the identity attributes identified in [5], clause 2.2.1 shall be used.
Table 4: Void.
5.3.4 Identity attributes of other entities
Identity attributes may also be provided for entities which do not correspond to natural or legal persons
(e.g. applications, things). They are not specified in the current version of the present document.
ETSI
11 ETSI EN 319 522-2 V1.2.1 (2024-01)
5.4 Identity verification and authentication assurance levels
information
This clause defines the information which is necessary to establish the level of assurance for the entities which take part
in the electronic delivery process. This information shall include:
1) An attribute containing details of the registration and identity proofing and verification assurance level. This
attribute:
a) shall contain one identifier of the assurance level itself. This identifier shall have a URI as value;
b) may also contain an identifier of the identification policy. This identifier shall have a URI as value;
c) may also contain details on the identification policy;
d) may also contain one or more URIs pointing to resources that contain details of the aforementioned
policy provided in different languages.
2) An attribute containing details of the authentication means and mechanisms assurance level. This attribute:
a) shall contain one identifier of the assurance level itself. This identifier shall have a URI as value;
b) may also contain an identifier of the authentication policy. This identifier shall have a URI as value;
c) may also contain details on the authentication policy;
d) may also contain one or more URIs pointing to resources that contain details of the aforementioned
policy provided in different languages.
Furthermore, the identity assurance information may include an attribute containing details of the performed
authentication, either an assertion generated by an assertion provider or as a sequence of components, consisting of:
• the date and time when the authentication process was conducted;
• the identification of the authentication method used.
6 ERDS relay metadata
6.1 Introduction
ERDS relay metadata is produced by an ERDS and is provided to a peer ERDS. It includes a set of information for the
correct processing of the user content between different actors in the delivery process. The ERDS relay metadata may
be transmitted together with the user content, with some evidence, or alone as described in ETSI EN 319 522-4-1 [i.8]
and ETSI EN 319 522-4-2 [i.9].
Part of ERDS relay metadata may be replicated in evidences. This is allowed, since metadata may be used for the
delivery process; it is also relevant when the user content flows detached from the evidence. ERDS relay metadata shall
include metadata components as indicated in the Cardinality column of table 5.
Table 5: Relay metadata components
Component Component name Cardinality Ref.
code
Delivery MD01 Metadata version 1 6.2.1
constraints
MD02 Relay date and time 0-1 6.2.2
MD03 Expiry date and time 0-1 6.2.3
MD04 Recipient required level of assurance 0-1 6.2.4
MD05 Applicable policy 0-n 6.2.5
MD06 Mode of consignment 0-1 6.2.6
MD07 Scheduled delivery 0-1 6.2.7
ETSI
12 ETSI EN 319 522-2 V1.2.1 (2024-01)
Component Component name Cardinality Ref.
code
Sender/ MD08 Sender's identifier 1 6.2.8
Recipient MD09 Reply-to 0-1 6.2.9
MD10 Recipient's identifier 1 6.2.10
ERD MD11 Message identifier 0-1 6.2.11
Message
MD12 In reply to 0-1 6.2.12
information
MD13 ERD Message type 1 6.2.13
MD14 User content information 1 6.2.14
MD15 Extensions 0-1 6.2.15
Signature 0-1 7
6.2 Metadata components
6.2.1 MD01 - Metadata version
Description
Metadata version
Format Binding specific
Meaning The version of the metadata, corresponding to the version of the binding document where it is
defined
Requirements
None
6.2.2 MD02 - Relay date and time
Description Relay date and time
Format Date and time in UTC values
Meaning The date and time when an ERDS relays the ERD message to the next ERDS in the delivery
chain
Requirements An ERDS which forwards the ERD message to a different ERDS may use this component to
indicate the time when the relay takes place

6.2.3 MD03 - Expiry date and time
Description
Expiry date and time
Format Date and time in UTC values
Meaning The date-time by which the consignment or handover to recipient is required to be completed.
Requirements R-ERDS shall not consign or hand over the user content if the date-time is after the one
indicated by this component.
The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.4 MD04 - Recipient required level of assurance
Description Recipient required level of assurance
Format
LoA enumeration
Meaning
The level of assurance of the identity of the recipient that the sender requires.
Requirements The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
An ERDS shall not relay the ERD message if R-ERDS capabilities (retrieved through CSI) do
not include the capability to identify the recipient at or above the required level.
R-ERDS shall not deliver the user content if it cannot meet the required identification LoA
specified by this component.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

ETSI
13 ETSI EN 319 522-2 V1.2.1 (2024-01)
6.2.5 MD05 - Applicable policy
Description Applicable policy
Format This component shall be either an URI or an OID.
If the identifier is an OID, it shall be represented as URN built as specified in IETF
RFC 3061 [2].
Meaning The policy that the S-ERDS requires to be applied to the management of the ERD message by
the subsequent ERDSs in the delivery chain. As an example, the policy may require the
evidence of relay to be returned to the sending ERDS, or that the message is not delivered to a
delegate.
Requirements
The content of this component is provided by the S-ERDS on the base of its policies or of
specific requests from the sender.
Any ERDS shall not relay the user content if the next ERDS capabilities (retrieved through CSI)
do not include the capability to support the mentioned policy.
Any ERDS in the chain shall refuse the ERD message if it cannot support the policy specified
by this component.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.6 MD06 - Mode of consignment
Description Mode of consignment
Format Binding specific, so that to express one of the options below
Meaning
The requested mode of consignment of the user content to the recipient chosen among the
following options:
• Basic: the user content has to be made available to the recipient without the
possibility for the recipient to accept/deny before delivery.
• Consented: a notification shall be sent to the recipient before actual
consignment/handover. The recipient shall be required to perform an explicit action to
accept or reject the user content; the user content shall only be accessible to the
recipient upon acceptance.
• Consented signed: as for Consented, with the addition that the recipient shall be
required to digitally sign an acknowledgment of receipt.
• Other: other modes of consignment can be agreed and specified in specific domains.
Requirements If this component is not present, R-ERDS shall consign the user content according to its policy
and to the recipient's setting.
Any ERDS shall not relay the ERD message if the R-ERDS capabilities (retrieved through CSI)
do not include the capability to support the consignment mode.
R-ERDS shall refuse the consignment of the user content if it cannot support the requested
consignment mode or if the recipient's settings do not allow that consignment mode.
Otherwise, it shall consign the user content according to the requested consignment mode.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

6.2.7 MD07 - Scheduled delivery
Description Scheduled delivery
Format Date and time in UTC values
Meaning The time instant after which the user content can be consigned/handed over.
Requirements The user content shall not be handed over to the recipient before this time.
If this component is present, its content shall be provided by the S-ERDS on the base of its
policies or of specific requests from the sender.
Any ERDS in the chain should refuse the ERD message if it cannot support delaying the
delivery of the user content until the time indicated in this component.
Intermediate ERDS (in the extended model) shall propagate this component as received from
the previous ERDS in the delivery chain.

ETSI
14 ETSI EN 319 522-2 V1.2.1 (2024-01)
6.2.8 MD08 - Sender's identifier
Description Sender's identifier
Format
Meaning Identifier of the sender of the user content.
Requirements As defined in clause 5.2.

6.2.9 MD09 - Reply-to
Description A unique reply-to identifier
Format
Binding specific
Meaning
The identifier, as specified in clause 5.2, to which any reply from the recipient or delegate of the
recipient should be sent to, as a result of the reception of the sender's user content.
Requirements The content of this component is provided by the S-ERDS o
...