ETSI EN 319 522-3 V1.1.1 (2018-09)
Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 3: Formats
Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 3: Formats
DEN/ESI-0019522-3
Elektronski podpisi in infrastruktura (ESI) - Storitve elektronske priporočene dostave - 3. del: Formati
Ta dokument določa format semantične vsebine (metapodatki, dokazovanje, prepoznavanje, skupna storitvena infrastruktura), ki se pretaka prek različnih vmesnikov storitev elektronske priporočene dostave (ERDS), kot je opredeljeno v standardu ETSI EN 319 522-2 [1].
General Information
Standards Content (Sample)
Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
������������������
Electronic Signatures and Infrastructures (ESI);
Electronic Registered Delivery Services;
Part 3: Formats
�
2 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
Reference
DEN/ESI-0019522-3
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
3 Draft ETSI EN 319 522-3 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 and abbreviations . 7�
3.1 Definitions . 7�
3.2 Abbreviations . 7�
4 Metadata formats . 7�
4.1 Introduction . 7�
4.2 IETF RFC 5322 format. 8�
4.3 XML format for use in AS4 binding . 8�
4.3.1 Introduction . 8�
4.3.2 Namespaces used . 8�
4.3.3 Auxiliary elements . 8�
4.3.3.1 Introduction . 8�
4.3.3.2 URI related types . 8�
4.3.3.3 String related types . 9�
4.3.3.4 Container for extensibility . 9�
4.3.3.5 ������������� root element .10�
4.3.4 MessageIdentifier element .10�
4.3.5 ERDMessageType element .11�
4.3.6 InReplyTo element .11�
4.3.7 RelayTime element .11�
4.3.8 ExpirationTime element .11�
4.3.9 ScheduledDeliveryTime element .11�
4.3.10 SenderId element .11�
4.3.11 ReplyTo element .12�
4.3.12 RecipientId element .12�
4.3.13 UserContentInfo element .12�
4.3.14 RequiredAssuranceLevel element .13�
4.3.15 ApplicablePolicy element .15�
4.3.16 RequestedConsigmentMode element .15�
4.3.17 Extensions element .15�
4.3.18 ds:Signature element .16�
5 Evidence and identification formats . 16�
5.1 Introduction .16�
5.2 XML format.16�
5.2.1 Namespaces used .16�
5.2.2 Evidence format .16�
5.2.2.1 Introduction .16�
5.2.2.2 Auxiliary elements .17�
5.2.2.2.1 Introduction .17�
5.2.2.3 �������� root element .17�
5.2.2.4 ������������������ element .17�
5.2.2.5 ����������� element .17�
5.2.2.6 ���������� elements group .18�
5.2.2.7 ������������ element.18�
5.2.2.8 ��������� element .20�
5.2.2.9 ���������������������� element .20�
5.2.2.10 ����������������� type .20�
ETSI
4 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
5.2.2.11 �������� element .20�
5.2.2.12 ���������������������� type .21�
5.2.2.13 ��������������������� element .22�
5.2.2.14 �������������������������� type .22�
5.2.2.15 ��������������� type .22�
5.2.2.16 ������������� element .23�
5.2.2.17 ��������������������� element .23�
5.2.2.18 ���������������� element .24�
5.2.2.19 ������������������������� element .24�
5.2.2.20 �������������� element .25�
5.2.2.21 ������������������������� element .25�
5.2.2.22 ����������������� element .25�
5.2.2.23 ��������������� element .25�
5.2.2.24 � ������������ element .25�
5.2.2.25 � ����������������� element .25�
5.2.2.26 ������������������������� element .26�
5.2.2.27 � �������� element .26�
5.2.2.28 ��!��������� element.26�
6 Common Service Infrastructure (CSI) formats . 26�
6.1 Routing information .26�
6.2 Trust information .27�
6.3 Capability management .27�
6.3.1 Recipient metadata (recipient capabilities) .27�
6.3.2 ERDS metadata (ERDS capabilities) .27�
Annex A (normative): XML schema files . 29�
A.1 XML Schema file location for namespace http://uri.etsi.org/19522/v1# . 29�
History . 30�
ETSI
5 Draft ETSI EN 319 522-3 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 3 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.10].
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
6 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
1 Scope
The present document specifies the format for the semantic content (metadata, evidence, identification, and Common
Service Infrastructure) that flows across the different interfaces of an Electronic Registered Delivery Service (ERDS) as
defined in ETSI EN 319 522-2 [1].
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-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic contents".
[2] W3C Recommendation: "XML Signature Syntax and Processing. Version 1.1, 11 April 2013".
[3] IETF RFC 3061: "A URN Namespace of Object Identifiers".
[4] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile". Version 1.1.2. October 2016.
[5] OASIS: "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)
V2.0", March 2005.
[6] IETF RFC 5646: "Tags for Identifying Languages".
[7] IETF RFC 5035: "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility".
[8] OASIS: "Service Metadata Publishing (SMP) Version 1.0", OASIS standard, August 2017.
[9] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[10] ETSI EN 319 522-4-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 3: Capability/requirements bindings".
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.
ETSI
7 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
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] Commission implementing Regulation (EU) 2015/1502 "on setting out minimum technical
specifications and procedures for assurance levels for electronic identification means pursuant to
Article 8(3) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on
electronic identification and trust services for electronic transactions in the internal market".
[i.2] NIST Special Publication 800-63: "Digital Identity Guidelines".
[i.3] NIST Special Publication 800-63-A: "Digital Identity Guidelines. Enrolment and Identity Proofing
Requirements".
[i.4] NIST Special Publication 800-63-B: "Digital Identity Guidelines. Authentication and Lifecycle
Management".
[i.5] NIST Special Publication 800-63-C: "Digital Identity Guidelines. Federation and Assertions".
[i.6] IETF RFC 5322: "Internet Message Format".
[i.7] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
[i.8] IETF RFC 7522: "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
Authentication and Authorization Grants".
[i.9] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists".
[i.10] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[i.11] OASIS: "AS4 Profile of ebMS 3.0 Version 1.0, OASIS Standard", January 2013.
[i.12] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI EN 319 522-1 [i.10] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 319 522-1 [i.10] apply.
4 Metadata formats
4.1 Introduction
The following clause aims at providing specific formats for metadata components identified in ETSI EN 319 522-2 [1],
clause 6. Clause 4.2 maps metadata components in IETF RFC 5322 format; clause 4.3 maps metadata components in
AS4 format [i.6].
Other mappings can be provided by future versions of the present document or by other parties.
In clause 4.3, all XML elements are given for information only. In case of conflict with the XML Schema file
referenced to, clause A.1 takes precedence.
ETSI
8 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
4.2 IETF RFC 5322 format
Specification for the mapping of ERDS metadata in an IETF RFC 5322 [i.6] format shall be as specified in ETSI
EN 319 532-3 [9].
4.3 XML format for use in AS4 binding
4.3.1 Introduction
This clause defines an XML format for the ERDS relay meta-data as defined in ETSI EN 319 522-2 [1], clause 6, which
is to be included in the AS4 message that is exchanged between ERDSs. Although its primary use is in the AS4
bindings it may also be used in other bindings.
4.3.2 Namespaces used
Table 1 shows the URIs corresponding to the namespaces and the prefixes associated to them in the present document.
Table 1: Namespaces URIs and prefixes
Namespace's URI Namespace's prefix
!
""#" !
Below follows a copy of the ��������� element of the XML Schema file whose location is detailed in clause A.1 and
that defines the namespace whose URI is �����������������������������:
$ %&’’
!"&’ !’ !" &’’
!"&’’ !"!&’""#"’(
$ "&’)"’
"&’ ! ’(
$ "&’ !’
"&’*++,-. !. !. ’(
$ "&’""#"’"&’.
"/!!.". ’(
4.3.3 Auxiliary elements
4.3.3.1 Introduction
The present clause provides details of a number of auxiliary types and elements used in throughout the XML Schema
file whose location is detailed in clause A.1.
4.3.3.2 URI related types
The present clause defines a number of types whose instances' values are URIs.
These types element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
$0.%&’’.(
$ !*/"&’%",/1+2*/’(
$ "3&’ "/1+2’(
$ ""!&’’(
$ "(
$ !*/(
ETSI
9 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
!"
#!"
"
"
"
$%!
!&"
"
"
"
$%!%
&
$%!’"
"&
"
Instances of ��������������� type shall have a non-empty URI as value.
Instances of ������������������������� shall have a non-empty URI as value. The �������� attribute shall
identify a language using the language code as specified in IETF RFC 5646 [6]. The ������ attribute shall indicate
the scheme for the URI value of the element.
Instances of NonEmptyMultiLangURIType shall have a non-empty URI as value. The �������� attribute shall
identify a language using the language code as specified in IETF RFC 5646 [6].
4.3.3.3 String related types
The present clause defines a number of types whose instances' values are strings.
These types element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
())!#""**!"+,-."/+0))
1!
!
%!#/+"
"
"
1!
1!
1!&"
"
"
"
Instances of ������������������ type shall have a non-empty string as value.
Instances of ���������������������������� type shall have a non-empty string as value. The ���� attribute
shall indicate the type of the corresponding string value.
4.3.3.4 Container for extensibility
The present clause defines the ��� element that may have any content.
The present clause also defines the ������� type whose instances may have any content.
They are specified for serving as placeholders for contents that are not specified in the present document.
This ��� element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below
for information:
ETSI
10 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
!!"!##"!#$#
$#!"!#$#%
&!!’(’!)!%%
!#!!#*!!
&!
!#")!!#
$#
4.3.3.5 ������������� root element
The root element of the XML document containing the ERDS meta-data shall be the ������������� element.
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
!!+ #,%#+ #,%$#
$#!+ #,%$#
&!
!-,.%!-
!!/+0,$##/+01,$#$#
!!’(!.!+ #$#,.%!-$#
!!’(!+ #$#%$
!!’(!/!$#%$
!!’(!1% %0 #$#%$
!!1!%.%#/!#.%!-$#
!!’(!+ #$#/!#.%!-$#
!!+!.%#/!#.%!-$#
!-2*!!.!-
!!+&%"!3 #"!3 0 $#!’(
!!" ) 4 #!’(#/+014 #.0$#
!!+&%*!!!,%!’(#*!!,%$#
!!’(-/!!
!!’(-%1!
&!
)!!&%
$#
!)!
$#
)
$#
Meta-data documents shall have "��������������" as value for ������� attribute.
Attribute ������� shall implement the semantics specified in clause 6.2.1 of ETSI EN 319 522-2 [1].
Clauses from 4.3.4 to 4.3.18 provide XML Schema definitions and requirements on its components.
4.3.4 MessageIdentifier element
The ����������������� element shall have the semantics of component MD11 as specified in clause 6.2.11 of
ETSI EN 319 522-2 [1].
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
!!,.%!-#,.%!-$#
$#!,.%!-$#
!)!/#1!$#
$#
ETSI
11 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
4.3.5 ERDMessageType element
The �������������� element shall have the semantics of component MD13 as specified in clause 6.2.13 of ETSI
EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information. It enumerates the ERD message types as defined in table 1 in clause 4 of ETSI
EN 319 522-2 [1]:
!"#$%&’(!"!"
#)#"*%+
## $%&(!",
## $%&(!"
## $%&(!"+#-
## $%&(!"" ,
#
!"
4.3.6 InReplyTo element
The optional ��������� element shall have the semantics of component MD12 as specified in clause 6.2.12 of ETSI
EN 319 522-2 [1].
The type of this element shall be a message identifier as defined by the ��������������������� type definition
in XML Schema file whose location is detailed in clause A.1 and is copied in clause 4.3.4 for information.
4.3.7 RelayTime element
The optional ��������� element shall have the semantics of component MD02 as specified in clause 6.2.2 of ETSI
EN 319 522-2 [1]. The 'Z' indicator for UTC may be used.
4.3.8 ExpirationTime element
The optional �������������� element shall have the semantics of component MD03 as specified in clause 6.2.3 of
ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used.
4.3.9 ScheduledDeliveryTime element
The optional ��������������������� element shall have the semantics of component MD07 as specified in
clause 6.2.7 of ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used.
4.3.10 SenderId element
The �������� element shall have the semantics of component MD08 as specified in clause 6.2.8 of ETSI
EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
!"#$#"+,#-!"
.##
##)#$"’#!"
)#+,#-’"#$"’#!"/,
##
.##
!"
The content of this element shall contain the identifier of the sender. The attribute �������������������� shall
contain the identifier of the naming scheme for assigning identifiers to users.
ETSI
12 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
4.3.11 ReplyTo element
The optional ������� element shall have the semantics of component MD09 as specified in clause 6.2.9 of ETSI
EN 319 522-2 [1].
The type of this element shall be the identifier of the user as defined by the �������������������� type
definition in XML Schema file whose location is detailed in clause A.1 and which is copied in the previous clause for
information.
4.3.12 RecipientId element
The optional ����������� element shall have the semantics of component MD10 as specified in clause 6.2.10 of
ETSI EN 319 522-2 [1].
The type of this element shall be the identifier of the user as defined by the �������������������� type
definition in XML Schema file whose location is detailed in clause A.1 and which is copied in clause 4.3.10 for
information.
4.3.13 UserContentInfo element
The ��������������� element shall have the semantics of component MD14 as specified in clause 6.2.14 of ETSI
EN 319 522-2 [1].
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
!!"#!!$!%&"#!!$!%’&
’&!"#!!$!%’&
(!
!!)*&$+!%&!!,-
!!#!.&!!,-
!%.$!%
(!
’&
!!.$!%&.$!%’&
’&!.$!%’&
(!,!/!++
!%.$!%
(!
’&
!!.$!%&.$!%’&
’&!.$!%’&
(!
!!$+!%&!
!!#!!’&&!
!%+01+!,-
!%+02 !,-
(!
’&
If included in the meta-data document the ������������������ child shall contain a string indicating the
application layer identifier assigned to the user content.
When used in the meta-data document the �������������� child shall contain an integer value indicating the
number of parts of the user content.
The ��������� child shall contain one or more �������� children each one containing detailed information of one
of the parts of the user content.
���������� child element of �������� shall contain the identifier of the corresponding part of the user content.
ETSI
13 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
����������� child element of �������� shall indicate the type of content of the corresponding part of the user
content.
Child element ��������������� of �������� may be used to indicate the algorithm used for computing the
digest value of the corresponding part of the user content.
Child element �������������� of �������� may be used to include the base-64 encoded digest value of the
corresponding part of the user content as computed using the digest algorithm indicated in the aforementioned
��������������� child element.
NOTE: When using the AS4 binding to exchange ERD messages between ERDS as defined in ETSI
EN 319 522-4-1 [i.12] the digest algorithm and value are already included in the message header and
there is no need to include these again the meta-data document.
4.3.14 RequiredAssuranceLevel element
The optional ���������������������� element shall have the semantics of component MD04 as specified in
clause 6.2.4 of ETSI EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
!"#$#% & !"
’#
##( ) $#% "$#% & !"
#*$##&
’#
’#
#*$##&$#+$#%
##,+#"-*$#% "$#% & !"
##.+#$#% "$#% & !"#/0
’#
!"
!"#$#% & !"
’#
##$#% "#"12,
##- ",&"#"12,#/0
##- ",&& "##/0
##- ",&& 2"#3"4 %#12,%!"
#/0
’#
!"
##$##& "$##& !"
!"#$##& !"
#* $#
##/$"$#"!"
’#
##$##!"+!
##$##4+"#"12,
’#
##"$#"!"
!"
##$##&$#+$#%
"$##&$#+$#% !"
!"#$##&$#+$#% !"
’#
##$#% "$#% & !"
#*$##& #/0
’#
!"
ETSI
14 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
Each instance of ������������������������� type shall contain detailed information of a certain assurance
level.
Instances of ������������������������� type may support schemes that define separated assurance levels for
authentication process, identity proof processes, and an assertion protocol in case there is a federation for
communicating authentication and identity information.
EXAMPLE 1: The Commission Implementing Regulation (EU) 2015/1502 [i.1] specifies three assurance levels
for identity proof and authentication processes. Each one would require one instance of
������������������������� type.
EXAMPLE 2: NIST Special Publications 800-63 [i.2], 800-63-A [i.3], 800-63-B [i.4] and 800-63-C [i.5]
providing guidelines to federal agencies for implementing digital identification and authentication
also provide means for managing these three different assurance levels if required. Each one would
require one instance of ������������������������� type.
One instance of ������������������������� type may also support schemes that define a unique global
assurance level jointly assigned to the identification proof and authentication processes.
The �������������� child element of instances of ������������������������� shall indicate the value of
an assurance level.
The �������� child element of instances of ������������������������� shall identify the policy that
defined the different assurance levels.
The ��������������� child element of instances of ������������������������� shall contain relevant
textual details of the policy that defined the different assurance levels.
The ������������������������ child element of instances of ������������������������� shall
contain a list of URIs pointing to resources providing details of the policy that defined the different assurance levels,
each one in a certain language. The �������� attribute of each ��� child element shall indicate the language used in
the resource pointed by this element.
Each instance of �������������������������� shall convey either:
� a global assurance level jointly assigned to the identification proof and authentication processes, supported by
the �������������������� and ��������������������� children elements, or
� separated information related to the assurance levels of identification proof process, authentication process and
the assertion protocols in federated environments, supported by the sequence of
�����������������������������������, ���������������������������, and
����������������������� children elements.
�������������������� child element of an instance of �������������������������� shall contain the
information of a unique global assurance level jointly assigned to the identification proof and authentication processes.
One instance of ������������������������� type (as the ��������������������� child element of an
instance of ��������������������������) shall contain details of one authentication process within either a
�������������� element or the sequence formed by ������������������ and ��������������"�����
children elements.
The �������������� element shall contain a SAML assertion as specified in SAML V2.0 [5].
The #����$ element shall contain an OAuth2 token. This token may also be embedded within a SAML2 assertion as
specified in IETF RFC 7522 [i.8].
The #���� element is a placeholder for incorporating tokens different than the ones contained in the other elements.
The ������������������ child element shall indicate the time when the authentication process was conducted.
The ��������������"����� child element shall identify the authentication method using an URI.
ETSI
15 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
����������������������������������� child element shall include the details of the assurance level of the
conducted authentication process within its �������������� child element. It may also include all the details
corresponding to the conducted authentication method within its ��������������������� child element.
���������������������������� child element shall include the details of the assurance level of the conducted
identity proof process.
������������������������� child element shall include the details of the assurance level of the assertion
protocol implemented in the federation.
4.3.15 ApplicablePolicy element
The optional ���������������� element shall have the semantics of component MD05 as specified in clause 6.2.5
of ETSI EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
!"#$%&’( ")&!"
###
*#
##( ")&"#"+%),#-#.
*#
!"
���������������� shall have a URI reference as value, which shall identify one policy. If the policy is identified
by an OID, the URI reference shall have a URN as value. The value of this URN shall be compliant with IETF
RFC 3061 [3].
4.3.16 RequestedConsigmentMode element
The optional �������������������� element shall have the semantics of component MD06 as specified in
clause 6.2.6 of ETSI EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information. It enumerates the consignment modes as defined in clause 6.2.6 of ETSI EN 319 522-2 [1]:
!"#/##0.!"
#-#"+%)
## ###-
## #####
## ####.
## ###
#
!"
4.3.17 Extensions element
The optional � �������� element shall have the semantics of component MD15 as specified in clause 6.2.15 of
ETSI EN 319 522-2 [1].
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
##$##"$##1!"
!"#$##1!"
*#,#-#.
#2$##
*#
!"
ETSI
16 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
Each ��������� child element shall contain one component whose content model is not specified within the present
document.
The ���������� attribute shall indicate whether the extension is critical or non-critical. If this attribute is absent,
then the extension shall be designated as non-critical.
4.3.18 ds:Signature element
The optional ������������ element may be used to include the enveloped signature in the meta-data document.
NOTE: When the meta-data document is exchanged using the AS4 binding as specified in ETSI
EN 319 522-4-1 [i.12] the signature of the meta-data is included in the message header and this element
should not be used.
5 Evidence and identification formats
5.1 Introduction
The present clause defines an XML format for ERDS evidence components identified in ETSI EN 319 522-2 [1],
clause 8.
ERDS can generate PDF-formatted ERDS evidences. This format, although valid, is thought more for final human
usage rather than in situations where interoperability has to be addressed or automatic processes have to take some
decision based on ERDS evidence content.
XML format is better suited for these last cases, where the automatic processing of the evidence content prevails over
its immediate human interpretation. For the aforementioned reasons, the detailed specification of PDF evidence format
is out of scope of the present document.
In clause 5.2, all XML elements are given for information only. In case of conflict with the XML Schema file whose
location is detailed in clause A.1, it is the Schema file which takes precedence.
5.2 XML format
5.2.1 Namespaces used
The URIs corresponding to the namespaces and the prefixes associated to them in the XML Schema excerpts shown in
this clause shall be the ones specified in Table 1 of clause 4.3.1.
5.2.2 Evidence format
5.2.2.1 Introduction
The present clause specifies a XML format for the Evidences generated by an ERDS.
ETSI
17 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
5.2.2.2 Auxiliary elements
5.2.2.2.1 Introduction
The same auxiliary types defined in clause 4.3.3 are used in the following definitions.
5.2.2.3 �������� root element
The root element of evidence shall be the �������� element.
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
!!"#!$"#!%$
%$!"#!%$
&!
!’"#!(#!’
!’")*+"!(#
’,!!
&!
-!!$!&#
-!(#$(*!
%$
Evidences shall have "��������������" as value for ������� attribute.
Attribute ������� shall implement the semantics specified in clause 8.2.2 of ETSI EN 319 522-2 [1].
Attribute Id shall be used to reference the �������� element.
Clauses 5.2.2.4 to 5.2.2.25 provide XML Schema definitions and requirements on its components.
5.2.2.4 ������������������ element
The content of this element shall have the semantics specified in clause 8.2.1 of ETSI EN 319 522-2 [1]:
!!"#!(#!’$!
5.2.2.5 ����������� element
The content of this element shall have the semantics specified in clause 8.2.3 of ETSI EN 319 522-2 [1].
The content of this element shall be one of the URI values listed in Table 2.
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information.
!!")*+"!(#$!"$.)(%$
!
URI values corresponding to each of the events specified in clause 6.2 of ETSI EN 319 522-2 [1] shall be as specified in
Table 2.
ETSI
18 Draft ETSI EN 319 522-3 V1.0.0 (2018-05)
Table 2: URI values identifying the ERDS events triggering the generation of ERDS evidences
URI value Event identified
����������������������������������������������������� ���������������������
���������������������������������������������������� ��������������������
������������������������������������ ����������� ���� �����������
������������������������������������ ���������� ���� ����������
������������������������������������ !������� ���� !�������
��������������������������������"���#�������!������������� "���#�������!�������������
��������������������������������"���#�������!������������!�� "���#�������!������������!��
����� �����
��������������������������������$��������������������� $���������������������
��������������������������������$�������������������� $��������������������
����������������������������������������������������%��� � ��������������������%��� �
��������������������������������$������$����������� $������$�����������
��������������������������������$������$����������!������� $������$����������!�������
��������������������������������$����������"���#�������� $����������"���#��������
��������������������������������$����������"���#�������!���� $����������"���#�������!����
��� ���
��������������������������������$������&��’����� $������&��’�����
��������������������������������$������&��’����!������� $������&��’����!�������
������������������������������������ (�"����)�� ���� (�"����)��
������������������������������������ (�"����)�!������� ���� (�"����)�!�������
���������������������������������������’!���"����)�� �������’!���"����)��
5.2.2.6 $��������� elements group
Below follows a copy of a part of the XML Schema file that defines a group of elements, whose components are
specified in clauses 5.2.2.7 to 5.2.2.25:
!
"
# $% & ’(
# % )*+)
# $%+ ,-#*,. ’(
# $%+ ,.#
# $/ +.#
# $/ +.#.# ’(
# $& .#’ 0 ++
# $& .#.# ’(’ 0 ++
# $/0 ) ’(
# %+ &$)& *
...
EUROPEAN STANDARD
Electronic Signatures and Infrastructures (ESI);
Electronic Registered Delivery Services;
Part 3: Formats
2 ETSI EN 319 522-3 V1.1.1 (2018-09)
Reference
DEN/ESI-0019522-3
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
3 ETSI EN 319 522-3 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 and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Metadata formats . 7
4.1 Introduction . 7
4.2 IETF RFC 5322 format . 8
4.3 XML format for use in AS4 binding . 8
4.3.1 Introduction. 8
4.3.2 Namespaces used . 8
4.3.3 Auxiliary elements . 8
4.3.3.1 Introduction . 8
4.3.3.2 URI related types . 8
4.3.3.3 String related types . 9
4.3.3.4 Container for extensibility . 9
4.3.3.5 RelayMetadata root element . 10
4.3.4 MessageIdentifier element . 10
4.3.5 ERDMessageType element . 11
4.3.6 InReplyTo element . 11
4.3.7 RelayTime element . 11
4.3.8 ExpirationTime element . 11
4.3.9 ScheduledDeliveryTime element . 11
4.3.10 SenderId element . 11
4.3.11 ReplyTo element . 12
4.3.12 RecipientId element . 12
4.3.13 UserContentInfo element . 12
4.3.14 RequiredAssuranceLevel element . 13
4.3.15 ApplicablePolicy element . 15
4.3.16 RequestedConsigmentMode element . 15
4.3.17 Extensions element . 15
4.3.18 ds:Signature element . 16
5 Evidence and identification formats . 16
5.1 Introduction . 16
5.2 XML format . 16
5.2.1 Namespaces used . 16
5.2.2 Evidence format . 16
5.2.2.1 Introduction . 16
5.2.2.2 Auxiliary elements . 17
5.2.2.2.1 Introduction . 17
5.2.2.3 Evidence root element . 17
5.2.2.4 EvidenceIdentifier element . 17
5.2.2.5 ERDSEventId element . 17
5.2.2.6 Components elements group . 18
5.2.2.7 EventReasons element . 18
5.2.2.8 EventTime element . 20
5.2.2.9 EvidenceIssuerPolicyID element. 20
5.2.2.10 EntityDetailsType type . 20
ETSI
4 ETSI EN 319 522-3 V1.1.1 (2018-09)
5.2.2.11 Identity element . 20
5.2.2.12 CertificateDetailsType type . 21
5.2.2.13 EvidenceIssuerDetails element . 22
5.2.2.14 AssuranceLevelsDetailsType type . 22
5.2.2.15 UserDetailsType type . 22
5.2.2.16 SenderDetails element . 23
5.2.2.17 SenderDelegateDetails element . 23
5.2.2.18 RecipientDetails element . 24
5.2.2.19 RecipientsDelegateDetails element . 24
5.2.2.20 SubmissionTime element . 25
5.2.2.21 EvidenceRefersToRecipient element . 25
5.2.2.22 MessageIdentifier element . 25
5.2.2.23 UserContentInfo element . 25
5.2.2.24 ExternalSystem element . 25
5.2.2.25 ExternalERDSDetails element . 25
5.2.2.26 TransactionLogInformation element . 26
5.2.2.27 Extensions element . 26
5.2.2.28 ds:Signature element . 26
6 Common Service Infrastructure (CSI) formats . 26
6.1 Routing information . 26
6.2 Trust information . 27
6.3 Capability management . 27
6.3.1 Recipient metadata (recipient capabilities) . 27
6.3.2 ERDS metadata (ERDS capabilities) . 27
Annex A (normative): XML schema files. 29
A.1 XML Schema file location for namespace http://uri.etsi.org/19522/v1# . 29
History . 30
ETSI
5 ETSI EN 319 522-3 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 3 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.10].
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
6 ETSI EN 319 522-3 V1.1.1 (2018-09)
1 Scope
The present document specifies the format for the semantic content (metadata, evidence, identification, and Common
Service Infrastructure) that flows across the different interfaces of an Electronic Registered Delivery Service (ERDS) as
defined in ETSI EN 319 522-2 [1].
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-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 2: Semantic contents".
[2] W3C Recommendation: "XML Signature Syntax and Processing. Version 1.1, 11 April 2013".
[3] IETF RFC 3061: "A URN Namespace of Object Identifiers".
[4] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile". Version 1.1.2. October 2016.
[5] OASIS: "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)
V2.0", March 2005.
[6] IETF RFC 5646: "Tags for Identifying Languages".
[7] IETF RFC 5035: "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility".
[8] OASIS: "Service Metadata Publishing (SMP) Version 1.0", OASIS standard, August 2017.
[9] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail
(REM) Services; Part 3: Formats".
[10] ETSI EN 319 522-4-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 3: Capability/requirements bindings".
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.
ETSI
7 ETSI EN 319 522-3 V1.1.1 (2018-09)
[i.1] Commission implementing Regulation (EU) 2015/1502 "on setting out minimum technical
specifications and procedures for assurance levels for electronic identification means pursuant to
Article 8(3) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on
electronic identification and trust services for electronic transactions in the internal market".
[i.2] NIST Special Publication 800-63: "Digital Identity Guidelines".
[i.3] NIST Special Publication 800-63-A: "Digital Identity Guidelines. Enrolment and Identity Proofing
Requirements".
[i.4] NIST Special Publication 800-63-B: "Digital Identity Guidelines. Authentication and Lifecycle
Management".
[i.5] NIST Special Publication 800-63-C: "Digital Identity Guidelines. Federation and Assertions".
[i.6] IETF RFC 5322: "Internet Message Format".
[i.7] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures;
Part 1: Building blocks and XAdES baseline signatures".
[i.8] IETF RFC 7522: "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
Authentication and Authorization Grants".
[i.9] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists".
[i.10] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 1: Framework and Architecture".
[i.11] OASIS: "AS4 Profile of ebMS 3.0 Version 1.0, OASIS Standard", January 2013.
[i.12] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered
Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI EN 319 522-1 [i.10] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 319 522-1 [i.10] apply.
4 Metadata formats
4.1 Introduction
The following clause aims at providing specific formats for metadata components identified in ETSI EN 319 522-2 [1],
clause 6. Clause 4.2 maps metadata components in IETF RFC 5322 format; clause 4.3 maps metadata components in
AS4 format [i.6].
Other mappings can be provided by future versions of the present document or by other parties.
In clause 4.3, all XML elements are given for information only. In case of conflict with the XML Schema file
referenced to, clause A.1 takes precedence.
ETSI
8 ETSI EN 319 522-3 V1.1.1 (2018-09)
4.2 IETF RFC 5322 format
Specification for the mapping of ERDS metadata in an IETF RFC 5322 [i.6] format shall be as specified in ETSI
EN 319 532-3 [9].
4.3 XML format for use in AS4 binding
4.3.1 Introduction
This clause defines an XML format for the ERDS relay meta-data as defined in ETSI EN 319 522-2 [1], clause 6, which
is to be included in the AS4 message that is exchanged between ERDSs. Although its primary use is in the AS4
bindings it may also be used in other bindings.
4.3.2 Namespaces used
Table 1 shows the URIs corresponding to the namespaces and the prefixes associated to them in the present document.
Table 1: Namespaces URIs and prefixes
Namespace's URI Namespace's prefix
http://uri.etsi.org/19522/v1# erds
http://www.w3.org/2001/XMLSchema xs
http://www.w3.org/2000/09/xmldsig# ds
urn:oasis:names:tc:SAML:2.0:assertion saml
Below follows a copy of the xs:schema element of the XML Schema file whose location is detailed in clause A.1 and
that defines the namespace whose URI is http://uri.etsi.org/19522/v1#:
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://uri.etsi.org/19522/v1#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
4.3.3 Auxiliary elements
4.3.3.1 Introduction
The present clause provides details of a number of auxiliary types and elements used in throughout the XML Schema
file whose location is detailed in clause A.1.
4.3.3.2 URI related types
The present clause defines a number of types whose instances' values are URIs.
These types element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
ETSI
9 ETSI EN 319 522-3 V1.1.1 (2018-09)
Instances of NonEmptyURIType type shall have a non-empty URI as value.
Instances of NonEmptyAttributedURIType shall have a non-empty URI as value. The xml:lang attribute shall
identify a language using the language code as specified in IETF RFC 5646 [6]. The scheme attribute shall indicate
the scheme for the URI value of the element.
Instances of NonEmptyMultiLangURIType shall have a non-empty URI as value. The xml:lang attribute shall
identify a language using the language code as specified in IETF RFC 5646 [6].
4.3.3.3 String related types
The present clause defines a number of types whose instances' values are strings.
These types element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
Instances of NonEmptyStringType type shall have a non-empty string as value.
Instances of NonEmptyAttributedStringType type shall have a non-empty string as value. The type attribute
shall indicate the type of the corresponding string value.
4.3.3.4 Container for extensibility
The present clause defines the Any element that may have any content.
The present clause also defines the AnyType type whose instances may have any content.
They are specified for serving as placeholders for contents that are not specified in the present document.
ETSI
10 ETSI EN 319 522-3 V1.1.1 (2018-09)
This Any element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below
for information:
4.3.3.5 RelayMetadata root element
The root element of the XML document containing the ERDS meta-data shall be the RelayMetadata element.
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
Meta-data documents shall have "EN319522v1.1.1" as value for version attribute.
Attribute version shall implement the semantics specified in clause 6.2.1 of ETSI EN 319 522-2 [1].
Clauses from 4.3.4 to 4.3.18 provide XML Schema definitions and requirements on its components.
4.3.4 MessageIdentifier element
The MessageIdentifier element shall have the semantics of component MD11 as specified in clause 6.2.11 of
ETSI EN 319 522-2 [1].
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
ETSI
11 ETSI EN 319 522-3 V1.1.1 (2018-09)
4.3.5 ERDMessageType element
The ERDMessageType element shall have the semantics of component MD13 as specified in clause 6.2.13 of ETSI
EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information. It enumerates the ERD message types as defined in Table 1 in clause 4 of ETSI
EN 319 522-2 [1]:
4.3.6 InReplyTo element
The optional InReplyTo element shall have the semantics of component MD12 as specified in clause 6.2.12 of ETSI
EN 319 522-2 [1].
The type of this element shall be a message identifier as defined by the MessageIdentifierType type definition
in XML Schema file whose location is detailed in clause A.1 and is copied in clause 4.3.4 for information.
4.3.7 RelayTime element
The optional RelayTime element shall have the semantics of component MD02 as specified in clause 6.2.2 of ETSI
EN 319 522-2 [1]. The 'Z' indicator for UTC may be used.
4.3.8 ExpirationTime element
The optional ExpirationTime element shall have the semantics of component MD03 as specified in clause 6.2.3 of
ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used.
4.3.9 ScheduledDeliveryTime element
The optional ScheduledDeliveryTime element shall have the semantics of component MD07 as specified in
clause 6.2.7 of ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used.
4.3.10 SenderId element
The SenderId element shall have the semantics of component MD08 as specified in clause 6.2.8 of ETSI
EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
The content of this element shall contain the identifier of the sender. The attribute IdentifierSchemeName shall
contain the identifier of the naming scheme for assigning identifiers to users.
ETSI
12 ETSI EN 319 522-3 V1.1.1 (2018-09)
4.3.11 ReplyTo element
The optional ReplyTo element shall have the semantics of component MD09 as specified in clause 6.2.9 of ETSI
EN 319 522-2 [1].
The type of this element shall be the identifier of the user as defined by the EntityIdentifierType type
definition in XML Schema file whose location is detailed in clause A.1 and which is copied in the previous clause for
information.
4.3.12 RecipientId element
The optional RecipientId element shall have the semantics of component MD10 as specified in clause 6.2.10 of
ETSI EN 319 522-2 [1].
The type of this element shall be the identifier of the user as defined by the EntityIdentifierType type
definition in XML Schema file whose location is detailed in clause A.1 and which is copied in clause 4.3.10 for
information.
4.3.13 UserContentInfo element
The UserContentInfo element shall have the semantics of component MD14 as specified in clause 6.2.14 of ETSI
EN 319 522-2 [1].
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for
information:
If included in the meta-data document the AppLayerIdentifier child shall contain a string indicating the
application layer identifier assigned to the user content.
When used in the meta-data document the ComposingParts child shall contain an integer value indicating the
number of parts of the user content.
The PartsInfo child shall contain one or more PartInfo children each one containing detailed information of one
of the parts of the user content.
Identifier child element of PartInfo shall contain the identifier of the corresponding part of the user content.
ETSI
13 ETSI EN 319 522-3 V1.1.1 (2018-09)
ContentType child element of PartInfo shall indicate the type of content of the corresponding part of the user
content.
Child element ds:DigestMethod of PartInfo may be used to indicate the algorithm used for computing the
digest value of the corresponding part of the user content.
Child element ds:DigestValue of PartInfo may be used to include the base-64 encoded digest value of the
corresponding part of the user content as computed using the digest algorithm indicated in the aforementioned
ds:DigestMethod child element.
NOTE: When using the AS4 binding to exchange ERD messages between ERDS as defined in ETSI
EN 319 522-4-1 [i.12] the digest algorithm and value are already included in the message header and
there is no need to include these again the meta-data document.
4.3.14 RequiredAssuranceLevel element
The optional RequiredAssuranceLevel element shall have the semantics of component MD04 as specified in
clause 6.2.4 of ETSI EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
minOccurs="0"/>
type="AuthenticationDetsAndAssuranceLevelType"/>
ETSI
14 ETSI EN 319 522-3 V1.1.1 (2018-09)
Each instance of AssuranceLevelDetailsType type shall contain detailed information of a certain assurance
level.
Instances of AssuranceLevelDetailsType type may support schemes that define separated assurance levels for
authentication process, identity proof processes, and an assertion protocol in case there is a federation for
communicating authentication and identity information.
EXAMPLE 1: The Commission Implementing Regulation (EU) 2015/1502 [i.1] specifies three assurance levels
for identity proof and authentication processes. Each one would require one instance of
AssuranceLevelDetailsType type.
EXAMPLE 2: NIST Special Publications 800-63 [i.2], 800-63-A [i.3], 800-63-B [i.4] and 800-63-C [i.5]
providing guidelines to federal agencies for implementing digital identification and authentication
also provide means for managing these three different assurance levels if required. Each one would
require one instance of AssuranceLevelDetailsType type.
One instance of AssuranceLevelDetailsType type may also support schemes that define a unique global
assurance level jointly assigned to the identification proof and authentication processes.
The AssuranceLevel child element of instances of AssuranceLevelDetailsType shall indicate the value of
an assurance level.
The PolicyID child element of instances of AssuranceLevelDetailsType shall identify the policy that
defined the different assurance levels.
The PolicyIDDetails child element of instances of AssuranceLevelDetailsType shall contain relevant
textual details of the policy that defined the different assurance levels.
The PolicyIDDetailsResources child element of instances of AssuranceLevelDetailsType shall
contain a list of URIs pointing to resources providing details of the policy that defined the different assurance levels,
each one in a certain language. The xml:lang attribute of each URI child element shall indicate the language used in
the resource pointed by this element.
Each instance of AssuranceLevelsDetailsType shall convey either:
• a global assurance level jointly assigned to the identification proof and authentication processes, supported by
the GlobalAssuranceLevel and AuthenticationDetails children elements, or
• separated information related to the assurance levels of identification proof process, authentication process and
the assertion protocols in federated environments, supported by the sequence of
AuthenticationDetsAndAssuranceLevel, IdentityProofAssuranceLevel, and
FederationAssuranceLevel children elements.
GlobalAssuranceLevel child element of an instance of AssuranceLevelsDetailsType shall contain the
information of a unique global assurance level jointly assigned to the identification proof and authentication processes.
One instance of AuthenticationDetailsType type (as the AuthenticationDetails child element of an
instance of AssuranceLevelsDetailsType) shall contain details of one authentication process within either a
saml:Assertion element or the sequence formed by AuthenticationTime and AuthenticationMethod
children elements.
The saml:Assertion element shall contain a SAML assertion as specified in SAML V2.0 [5].
The OAuth2 element shall contain an OAuth2 token. This token may also be embedded within a SAML2 assertion as
specified in IETF RFC 7522 [i.8].
The Other element is a placeholder for incorporating tokens different than the ones contained in the other elements.
The AuthenticationTime child element shall indicate the time when the authentication process was conducted.
The AuthenticationMethod child element shall identify the authentication method using an URI.
ETSI
15 ETSI EN 319 522-3 V1.1.1 (2018-09)
AuthenticationDetsAndAssuranceLevel child element shall include the details of the assurance level of the
conducted authentication process within its AssuranceLevel child element. It may also include all the details
corresponding to the conducted authentication method within its AuthenticationDetails child element.
IdentityProofAssuranceLevels child element shall include the details of the assurance level of the conducted
identity proof process.
FederationAssuranceLevels child element shall include the details of the assurance level of the assertion
protocol implemented in the federation.
4.3.15 ApplicablePolicy element
The optional ApplicablePolicy element shall have the semantics of component MD05 as specified in clause 6.2.5
of ETSI EN 319 522-2 [1].
The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied
below for information:
...
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 3: Formats35.040.01Kodiranje informacij na splošnoInformation coding in generalICS:Ta slovenski standard je istoveten z:ETSI EN 319 522-3 V1.1.1 (2018-09)SIST EN 319 522-3 V1.1.1:2018en01-november-2018SIST EN 319 522-3 V1.1.1:2018SLOVENSKI
STANDARD
EUROPEAN STANDARD SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 2
Reference DEN/ESI-0019522-3 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-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 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 and abbreviations . 7 3.1 Definitions . 7 3.2 Abbreviations . 7 4 Metadata formats . 7 4.1 Introduction . 7 4.2 IETF RFC 5322 format . 8 4.3 XML format for use in AS4 binding . 8 4.3.1 Introduction. 8 4.3.2 Namespaces used . 8 4.3.3 Auxiliary elements . 8 4.3.3.1 Introduction . 8 4.3.3.2 URI related types . 8 4.3.3.3 String related types . 9 4.3.3.4 Container for extensibility . 9 4.3.3.5 RelayMetadata root element . 10 4.3.4 MessageIdentifier element . 10 4.3.5 ERDMessageType element . 11 4.3.6 InReplyTo element . 11 4.3.7 RelayTime element . 11 4.3.8 ExpirationTime element . 11 4.3.9 ScheduledDeliveryTime element . 11 4.3.10 SenderId element . 11 4.3.11 ReplyTo element . 12 4.3.12 RecipientId element . 12 4.3.13 UserContentInfo element . 12 4.3.14 RequiredAssuranceLevel element . 13 4.3.15 ApplicablePolicy element . 15 4.3.16 RequestedConsigmentMode element . 15 4.3.17 Extensions element . 15 4.3.18 ds:Signature element . 16 5 Evidence and identification formats . 16 5.1 Introduction . 16 5.2 XML format . 16 5.2.1 Namespaces used . 16 5.2.2 Evidence format . 16 5.2.2.1 Introduction . 16 5.2.2.2 Auxiliary elements . 17 5.2.2.2.1 Introduction . 17 5.2.2.3 Evidence root element . 17 5.2.2.4 EvidenceIdentifier element . 17 5.2.2.5 ERDSEventId element . 17 5.2.2.6 Components elements group . 18 5.2.2.7 EventReasons element . 18 5.2.2.8 EventTime element . 20 5.2.2.9 EvidenceIssuerPolicyID element. 20 5.2.2.10 EntityDetailsType type . 20 SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 4 5.2.2.11 Identity element . 20 5.2.2.12 CertificateDetailsType type . 21 5.2.2.13 EvidenceIssuerDetails element . 22 5.2.2.14 AssuranceLevelsDetailsType type . 22 5.2.2.15 UserDetailsType type . 22 5.2.2.16 SenderDetails element . 23 5.2.2.17 SenderDelegateDetails element . 23 5.2.2.18 RecipientDetails element . 24 5.2.2.19 RecipientsDelegateDetails element . 24 5.2.2.20 SubmissionTime element . 25 5.2.2.21 EvidenceRefersToRecipient element . 25 5.2.2.22 MessageIdentifier element . 25 5.2.2.23 UserContentInfo element . 25 5.2.2.24 ExternalSystem element . 25 5.2.2.25 ExternalERDSDetails element . 25 5.2.2.26 TransactionLogInformation element . 26 5.2.2.27 Extensions element . 26 5.2.2.28 ds:Signature element . 26 6 Common Service Infrastructure (CSI) formats . 26 6.1 Routing information . 26 6.2 Trust information . 27 6.3 Capability management . 27 6.3.1 Recipient metadata (recipient capabilities) . 27 6.3.2 ERDS metadata (ERDS capabilities) . 27 Annex A (normative): XML schema files. 29 A.1 XML Schema file location for namespace http://uri.etsi.org/19522/v1# . 29 History . 30
ETSI ETSI EN 319 522-3 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 3 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.10].
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 ETSI EN 319 522-3 V1.1.1 (2018-09) 6 1 Scope The present document specifies the format for the semantic content (metadata, evidence, identification, and Common Service Infrastructure) that flows across the different interfaces of an Electronic Registered Delivery Service (ERDS) as defined in ETSI EN 319 522-2 [1]. 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-2: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 2: Semantic contents". [2] W3C Recommendation: "XML Signature Syntax and Processing. Version 1.1, 11 April 2013". [3] IETF RFC 3061: "A URN Namespace of Object Identifiers". [4] CEF eIDAS Technical Sub-group: "eIDAS SAML Attribute profile". Version 1.1.2. October 2016. [5] OASIS: "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005. [6] IETF RFC 5646: "Tags for Identifying Languages". [7] IETF RFC 5035: "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility". [8] OASIS: "Service Metadata Publishing (SMP) Version 1.0", OASIS standard, August 2017. [9] ETSI EN 319 532-3: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM) Services; Part 3: Formats". [10] ETSI EN 319 522-4-3: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 4: Bindings; Sub-part 3: Capability/requirements bindings". 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. SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 7 [i.1] Commission implementing Regulation (EU) 2015/1502 "on setting out minimum technical specifications and procedures for assurance levels for electronic identification means pursuant to Article 8(3) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market". [i.2] NIST Special Publication 800-63: "Digital Identity Guidelines". [i.3] NIST Special Publication 800-63-A: "Digital Identity Guidelines. Enrolment and Identity Proofing Requirements". [i.4] NIST Special Publication 800-63-B: "Digital Identity Guidelines. Authentication and Lifecycle Management". [i.5] NIST Special Publication 800-63-C: "Digital Identity Guidelines. Federation and Assertions". [i.6] IETF RFC 5322: "Internet Message Format". [i.7] ETSI EN 319 132-1: "Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures". [i.8] IETF RFC 7522: "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants". [i.9] ETSI TS 119 612: "Electronic Signatures and Infrastructures (ESI); Trusted Lists". [i.10] ETSI EN 319 522-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 1: Framework and Architecture". [i.11] OASIS: "AS4 Profile of ebMS 3.0 Version 1.0, OASIS Standard", January 2013. [i.12] ETSI EN 319 522-4-1: "Electronic Signatures and Infrastructures (ESI); Electronic Registered Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in ETSI EN 319 522-1 [i.10] apply. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in ETSI EN 319 522-1 [i.10] apply. 4 Metadata formats 4.1 Introduction The following clause aims at providing specific formats for metadata components identified in ETSI EN 319 522-2 [1], clause 6. Clause 4.2 maps metadata components in IETF RFC 5322 format; clause 4.3 maps metadata components in AS4 format [i.6]. Other mappings can be provided by future versions of the present document or by other parties. In clause 4.3, all XML elements are given for information only. In case of conflict with the XML Schema file referenced to, clause A.1 takes precedence. SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 8 4.2 IETF RFC 5322 format Specification for the mapping of ERDS metadata in an IETF RFC 5322 [i.6] format shall be as specified in ETSI EN 319 532-3 [9]. 4.3 XML format for use in AS4 binding 4.3.1 Introduction This clause defines an XML format for the ERDS relay meta-data as defined in ETSI EN 319 522-2 [1], clause 6, which is to be included in the AS4 message that is exchanged between ERDSs. Although its primary use is in the AS4 bindings it may also be used in other bindings. 4.3.2 Namespaces used Table 1 shows the URIs corresponding to the namespaces and the prefixes associated to them in the present document. Table 1: Namespaces URIs and prefixes Namespace's URI Namespace's prefix http://uri.etsi.org/19522/v1# erds http://www.w3.org/2001/XMLSchema xs http://www.w3.org/2000/09/xmldsig# ds urn:oasis:names:tc:SAML:2.0:assertion saml
Below follows a copy of the xs:schema element of the XML Schema file whose location is detailed in clause A.1 and that defines the namespace whose URI is http://uri.etsi.org/19522/v1#:
schemaLocation="http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd"/>
4.3.3 Auxiliary elements 4.3.3.1 Introduction The present clause provides details of a number of auxiliary types and elements used in throughout the XML Schema file whose location is detailed in clause A.1. 4.3.3.2 URI related types The present clause defines a number of types whose instances' values are URIs. These types element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 9
Instances of NonEmptyURIType type shall have a non-empty URI as value. Instances of NonEmptyAttributedURIType shall have a non-empty URI as value. The xml:lang attribute shall identify a language using the language code as specified in IETF RFC 5646 [6]. The scheme attribute shall indicate the scheme for the URI value of the element. Instances of NonEmptyMultiLangURIType shall have a non-empty URI as value. The xml:lang attribute shall identify a language using the language code as specified in IETF RFC 5646 [6]. 4.3.3.3 String related types The present clause defines a number of types whose instances' values are strings. These types element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
Instances of NonEmptyStringType type shall have a non-empty string as value. Instances of NonEmptyAttributedStringType type shall have a non-empty string as value. The type attribute shall indicate the type of the corresponding string value. 4.3.3.4 Container for extensibility The present clause defines the Any element that may have any content. The present clause also defines the AnyType type whose instances may have any content. They are specified for serving as placeholders for contents that are not specified in the present document. SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 10 This Any element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
4.3.3.5 RelayMetadata root element The root element of the XML document containing the ERDS meta-data shall be the RelayMetadata element.
This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
Meta-data documents shall have "EN319522v1.1.1" as value for version attribute. Attribute version shall implement the semantics specified in clause 6.2.1 of ETSI EN 319 522-2 [1]. Clauses from 4.3.4 to 4.3.18 provide XML Schema definitions and requirements on its components. 4.3.4 MessageIdentifier element The MessageIdentifier element shall have the semantics of component MD11 as specified in clause 6.2.11 of ETSI EN 319 522-2 [1]. This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 11 4.3.5 ERDMessageType element The ERDMessageType element shall have the semantics of component MD13 as specified in clause 6.2.13 of ETSI EN 319 522-2 [1]. The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information. It enumerates the ERD message types as defined in Table 1 in clause 4 of ETSI EN 319 522-2 [1]:
4.3.6 InReplyTo element The optional InReplyTo element shall have the semantics of component MD12 as specified in clause 6.2.12 of ETSI EN 319 522-2 [1]. The type of this element shall be a message identifier as defined by the MessageIdentifierType type definition in XML Schema file whose location is detailed in clause A.1 and is copied in clause 4.3.4 for information. 4.3.7 RelayTime element The optional RelayTime element shall have the semantics of component MD02 as specified in clause 6.2.2 of ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used. 4.3.8 ExpirationTime element The optional ExpirationTime element shall have the semantics of component MD03 as specified in clause 6.2.3 of ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used. 4.3.9 ScheduledDeliveryTime element The optional ScheduledDeliveryTime element shall have the semantics of component MD07 as specified in clause 6.2.7 of ETSI EN 319 522-2 [1]. The 'Z' indicator for UTC may be used. 4.3.10 SenderId element The SenderId element shall have the semantics of component MD08 as specified in clause 6.2.8 of ETSI EN 319 522-2 [1]. The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
The content of this element shall contain the identifier of the sender. The attribute IdentifierSchemeName shall contain the identifier of the naming scheme for assigning identifiers to users. SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 12 4.3.11 ReplyTo element The optional ReplyTo element shall have the semantics of component MD09 as specified in clause 6.2.9 of ETSI EN 319 522-2 [1]. The type of this element shall be the identifier of the user as defined by the EntityIdentifierType type definition in XML Schema file whose location is detailed in clause A.1 and which is copied in the previous clause for information. 4.3.12 RecipientId element The optional RecipientId element shall have the semantics of component MD10 as specified in clause 6.2.10 of ETSI EN 319 522-2 [1]. The type of this element shall be the identifier of the user as defined by the EntityIdentifierType type definition in XML Schema file whose location is detailed in clause A.1 and which is copied in clause 4.3.10 for information. 4.3.13 UserContentInfo element The UserContentInfo element shall have the semantics of component MD14 as specified in clause 6.2.14 of ETSI EN 319 522-2 [1]. This element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
If included in the meta-data document the AppLayerIdentifier child shall contain a string indicating the application layer identifier assigned to the user content. When used in the meta-data document the ComposingParts child shall contain an integer value indicating the number of parts of the user content. The PartsInfo child shall contain one or more PartInfo children each one containing detailed information of one of the parts of the user content. Identifier child element of PartInfo shall contain the identifier of the corresponding part of the user content. SIST EN 319 522-3 V1.1.1:2018
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 13 ContentType child element of PartInfo shall indicate the type of content of the corresponding part of the user content. Child element ds:DigestMethod of PartInfo may be used to indicate the algorithm used for computing the digest value of the corresponding part of the user content. Child element ds:DigestValue of PartInfo may be used to include the base-64 encoded digest value of the corresponding part of the user content as computed using the digest algorithm indicated in the aforementioned ds:DigestMethod child element. NOTE: When using the AS4 binding to exchange ERD messages between ERDS as defined in ETSI EN 319 522-4-1 [i.12] the digest algorithm and value are already included in the message header and there is no need to include these again the meta-data document. 4.3.14 RequiredAssuranceLevel element The optional RequiredAssuranceLevel element shall have the semantics of component MD04 as specified in clause 6.2.4 of ETSI EN 319 522-2 [1]. The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
type="xs:anyURI" minOccurs="0"/>
type="xs:string" minOccurs="0"/>
type="NonEmptyMultiLangURIListType" minOccurs="0"/>
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 14 Each instance of AssuranceLevelDetailsType type shall contain detailed information of a certain assurance level. Instances of AssuranceLevelDetailsType type may support schemes that define separated assurance levels for authentication process, identity proof processes, and an assertion protocol in case there is a federation for communicating authentication and identity information. EXAMPLE 1: The Commission Implementing Regulation (EU) 2015/1502 [i.1] specifies three assurance levels for identity proof and authentication processes. Each one would require one instance of AssuranceLevelDetailsType type. EXAMPLE 2: NIST Special Publications 800-63 [i.2], 800-63-A [i.3], 800-63-B [i.4] and 800-63-C [i.5] providing guidelines to federal agencies for implementing digital identification and authentication also provide means for managing these three different assurance levels if required. Each one would require one instance of AssuranceLevelDetailsType type. One instance of AssuranceLevelDetailsType type may also support schemes that define a unique global assurance level jointly assigned to the identification proof and authentication processes. The AssuranceLevel child element of instances of AssuranceLevelDetailsType shall indicate the value of an assurance level. The PolicyID child element of instances of AssuranceLevelDetailsType shall identify the policy that defined the different assurance levels. The PolicyIDDetails child element of instances of AssuranceLevelDetailsType shall contain relevant textual details of the policy that defined the different assurance levels. The PolicyIDDetailsResources child element of instances of AssuranceLevelDetailsType shall contain a list of URIs pointing to resources providing details of the policy that defined the different assurance levels, each one in a certain language. The xml:lang attribute of each URI child element shall indicate the language used in the resource pointed by this element. Each instance of AssuranceLevelsDetailsType shall convey either:
• a global assurance level jointly assigned to the identification proof and authentication processes, supported by the GlobalAssuranceLevel and AuthenticationDetails children elements, or • separated information related to the assurance levels of identification proof process, authentication process and the assertion protocols in federated environments, supported by the sequence of AuthenticationDetsAndAssuranceLevel, IdentityProofAssuranceLevel, and FederationAssuranceLevel children elements. GlobalAssuranceLevel child element of an instance of AssuranceLevelsDetailsType shall contain the information of a unique global assurance level jointly assigned to the identification proof and authentication processes. One instance of AuthenticationDetailsType type (as the AuthenticationDetails child element of an instance of AssuranceLevelsDetailsType) shall contain details of one authentication process within either a saml:Assertion element or the sequence formed by AuthenticationTime and AuthenticationMethod children elements. The saml:Assertion element shall contain a SAML assertion as specified in SAML V2.0 [5]. The OAuth2 element shall contain an OAuth2 token. This token may also be embedded within a SAML2 assertion as specified in IETF RFC 7522 [i.8]. The Other element is a placeholder for incorporating tokens different than the ones contained in the other elements. The AuthenticationTime child element shall indicate the time when the authentication process was conducted. The AuthenticationMethod child element shall identify the authentication method using an URI.
ETSI ETSI EN 319 522-3 V1.1.1 (2018-09) 15 AuthenticationDetsAndAssuranceLevel child element shall include the details of the assurance level of the conducted authentication process within its AssuranceLevel child element. It may also include all the details corresponding to the conducted authentication method within its AuthenticationDetails child element. IdentityProofAssuranceLevels child element shall include the details of the assurance level of the conducted identity proof process. FederationAssuranceLevels child element shall include the details of the assurance level of the assertion protocol implemented in the federation. 4.3.15 ApplicablePolicy element The optional ApplicablePolicy element shall have the semantics of component MD05 as specified in clause 6.2.5 of ETSI EN 319 522-2 [1]. The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information:
ApplicablePolicy shall have a URI reference as value, which shall identify one policy. If the policy is identified by an OID, the URI reference shall have a URN as value. The value of this URN shall be compliant with IETF RFC 3061 [3]. 4.3.16 RequestedConsigmentMode element The optional RequestedConsignment element shall have the semantics of component MD06 as specified in clause 6.2.6 of ETSI EN 319 522-2 [1]. The type of this element shall be defined as in XML Schema file whose location is detailed in clause A.1 and is copied below for information. It enumerates the consignment modes as defined in clause 6.2.6 of ETSI EN 319 522-2 [1]:
4.3.17 Extensions element The optional Extensions element shall have 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.
Loading comments...