ISO 17090-4

ISO/DISFDIS 17090-4:2025(en)
ISO/TC 215
Secretariat: ANSI
Date: 2025-04-2110-23
Health informatics — Public key infrastructure — —
Part 4:
Digital signatures for healthcare documents
Informatique de la santé — Infrastructure clé publique —
Partie 4: Signatures numériques pour les documents des soins médicaux
FDIS stage
ISO/DIS FDIS 17090-4:####(X:2025(en)
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO #### 2025 – All rights reserved
ii
ISO/DISFDIS 17090-4:2025(en)
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Target of application . 2
4.1 Target system . 2
4.2 Generation process . 4
4.3 Verification process . 5
4.4 CAdES specification . 13
4.5 XAdES specification . 18
4.6 PAdES specification . 24
Annex A (informative) JAdES specification . 31
Annex B (informative) Use cases . 38
Bibliography . 41

iii
ISO/DIS FDIS 17090-4:####(X:2025(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO [had/had not] received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that this
may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO'sISO’s adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 215, Health informatics.
This third edition cancels and replaces the second edition (ISO 17090-4:2020), which has been technically
revised.
The main changes are as follows:
— — update of the reference standard and addition of JAdES definitions.
A list of all parts in the ISO 17090 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
© ISO #### 2025 – All rights reserved
iv
ISO/DISFDIS 17090-4:2025(en)
Introduction
The healthcare industry is faced with the challenge of reducing costs by moving from paper-based processes
to automated electronic processes. New models of healthcare delivery are emphasizing the need for patient
information to be shared among a growing number of specialist healthcare providers and across traditional
organizational boundaries.
Healthcare information concerning individual citizens is commonly interchanged by means of electronic mail,
remote database access, electronic data interchange, and other applications. The internet provides a highly
cost-effective and accessible means of interchanging information, but it is also an insecure vehicle that
demands additional measures be taken to maintain the privacy and confidentiality of information. Threats to
the security of health information through unauthorized access (either inadvertent or deliberate) are
increasing. It is essential that reliable information security services that minimize the risk of unauthorized
access be available to the healthcare system.
How does the healthcare industry provide appropriate protection for the data conveyed across the internet in
a practical, cost-effective way? Public key infrastructure (PKI) and digital certificate technology seek to
address this challenge.
The proper deployment of digital certificates requires a blend of technology, policy, and administrative
processes that enable the exchange of sensitive data in an unsecured environment by the use of public key
cryptography to protect information in transit and certificates to confirm the identity of a person or entity. In
healthcare environments, this technology uses authentication, encipherment and digital signatures to
facilitate confidential access to, and movement of, individual health records to meet both clinical and
administrative needs. The services offered by the deployment of digital certificates (including encipherment,
information integrity and digital signatures) are able to address many of these security issues. This is
especially the case if digital certificates are used in conjunction with an accredited information security
standard. Many individual organizations around the world have started to use digital certificates for this
purpose.
Interoperability of digital certificate technology and supporting policies, procedures, and practices is of
fundamental importance if information is to be exchanged between organizations and between jurisdictions
in support of healthcare applications (for example between a hospital and a community physician working
with the same patient).
Achieving interoperability between different digital certificate implementations requires the establishment of
a framework of trust, under which parties responsible for protecting an individual’s information rights
mightcan rely on the policies and practices and, by extension, on the validity of digital certificates issued by
other established authorities.
Many countries are deploying digital certificates to support secure communications within their national
boundaries. Inconsistencies will arise in policies and procedures between the certification authorities (CAs)
and the registration authorities (RAs) of different countries if standards development activity is restricted to
within national boundaries.
Digital certificate technology is still evolving in certain aspects that are not specific to healthcare. Important
standardization efforts and, in some cases, supporting legislation are ongoing. On the other hand, healthcare
providers in many countries are already using or planning to use digital certificates. This document seeks to
address the need for guidance to support these rapid international developments.
The internet is increasingly used as the vehicle of choice to support the movement of healthcare data between
healthcare organizations and is the only realistic choice for cross-border communication in this sector.
v
ISO/DIS FDIS 17090-4:####(X:2025(en)
The ISO 17090 series, contributes to defining how digital certificates can be used to provide security services
in the healthcare industry, including authentication, confidentiality, data integrity, and the technical capacity
to support the quality of digital signature.
This document is in line with ISO/ETSI standards for long-term signature formats to improve and guarantee
interoperability in the healthcare field.
There is no limitation regarding the data format and the subject for which the signature is created.
© ISO #### 2025 – All rights reserved
vi
DRAFT International Standard ISO/DIS 17090-4:2025(en)

Health informatics — Public key infrastructure — —
Part 4:
Digital signatures for healthcare documents
1 Scope
This document supports interchangeability of digital signatures and the prevention of incorrect or illegal
digital signatures by providing minimum requirements and formats for generating and verifying digital
signatures and related certificates.
This document describes the common technical, operational, and policy requirements to enable digital
certificates to be used in protecting the exchange of healthcare information within a single domain, between
domains, and across jurisdictional boundaries. The purpose of this document is to create a platform for global
interoperability. It specifically supports digital certificate enabled communication across borders but can also
provide guidance for the national or regional deployment of digital certificates in healthcare.
This document defines the provable compliance with a public key infrastructure (PKI) policy necessary in the
domain of healthcare. It specifies a method of adopting long-term signature formats to ensure integrity and
non-repudiation in long-term electronic preservation of healthcare information.
This document provides healthcare-specific PKI (HPKI) profiles of digital signature based on the ISO/ETSI
[ [1] ]
standard profiles specified in CAdES (CMS Advanced Electronic Signature) 1) , , XAdES (XML Advanced
[ [2]]
Electronic Signature), PAdES (PDF Advanced Electronic Signature) 2) and the ETSI standard specified in
[ [13] ]
JAdES (JSON Advanced Electronic Signature) 13) . .
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 17090--1, Health informatics — Public key infrastructure — Part 1: Overview of digital certificate services
ISO 14533--2:20222021, Processes, data elements and documents in commerce, industry and administration —
Long term signature — Part 2: Profiles for XML Advanced Electronic Signatures (XAdES)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17090-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
ISO/FDIS 17090-4:2025(en)
3.1 3.1
certification path
connection of a series of certificates binding the certificate that is to be validated to a trusted root trust anchor
3.2 3.2
certification path validation
path to be validated to a trusted root trust anchor including revocation checking
3.3 3.3
hash value
value calculated by a hash function, which is a computation method used to generate a random value of fixed
length from the data of any optional length
4 Target of application
4.1 Target system
The target systems of this document are as follows:
[ [4]]
a) a) the environment built in accordance with the requirements of the ISO 17090-2 4 certificate
[ [5]]
profile and the ISO 17090-3 5 certificate policy;
b) b) the digital signature library with the digital signature function and the digital signature
verification function for the medical treatment application;
c) c) the digital signature program and the digital signature verification program as the stand-alone
software or with the medical treatment application;
The following are out of the scope of application:
— — the medical treatment application that does not process the digital signature data directly;
— — the medical treatment application that processes the digital signature and the result of signature
verification with the digital signature library, the specific digital signature program, or the specific digital
signature verification program;
— — the application interface and user interface; Figure 1Figure 1 shows an example of the
processing layer. The digital signature application layer (the digital signature library, the digital signature
program, or the digital signature verification program) is the target scope of this example. Therefore, the
following layer, CSP and PKCS#11, is not within the targeted scope of this document.
The target use cases of this document are listed in Annex BAppendix B. .
In HPKI, it is assumed that storage modules of the end entity subscriber private key conform to standards of
[ [17]]
levels equal to or higher than US FIPS 140--2 17 level 1. Also, in addition to the smart card, as illustrated in
Figure 1Figure 1,, a system could use a USB token, software token, etc. as the medium that stores the private
key.
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
ISO/FDIS 17090-4:2025(en)
Figure 1 — Example of processing layer digital signature specification
4.2 Generation process
The digital signature format is based on ISO and ETSI advanced digital signatures, where CAdES XAdES, PAdES
and JAdES are described in this document.
These specifications define the various formats according to purpose of operation.
— — ES-BES: the format that has the digital signature value, data itself, and information about the signer.
— — ES-T: the format that has the signature timestamp in addition to the ES format. Signature timestamp
is a trusted timestamp provided by a timestamp authority to prove the existence of the signature.
— — ES-X Long: the format that has a set of certificates and revocation information for signature
verification.
— — ES-A: the format that has an archive timestamp to protect the signature, the timestamps, and the
validation data.
See Figure 2Figure 2 for the different format types of digital signature.
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Figure 2 — Format types of digital signature
These specifications define the profile of ES-T, ES-X Long and ES-A. However, since ES-X Long is an
intermediate format, the validation process is not described in this document.
4.44.4 describes the CAdES profile that specifies defines the required or allowed specifies elementstoelements
to generate ES-T and ES-A. 4.54.5 describes the XAdES profile for ES-T, ES-X Long and ES-A. 4.64.6 describes
the PAdES profile for ES-T and ES-A. Annex A4.7 describes the JAdES profile for ES-T, ES-X Long and ES-A.
4.3 Verification process
4.3.1 General
4.34.3 describes an overview of the basic verification processes. This document does not provide verification
methods for optional attributes. If the signature data contains any optional attributes, the optional attributes
should be correctly verified in accordance with other specifications, policies, or guidelines.
4.3.2 Verification of ES-BES
The verification processes of ES-BES are described below, and the order of the processes should not be
changed. See Figure 3Figure 3.
ISO/FDIS 17090-4:2025(en)
Figure 3 — Verification processes of ES-BES
The above processes shown in Figure 3 are explained in Table 1Table 1.
Table 1 — Description of verification processes of ES-BES
Verification process Description
a) a) Ascertain correctness of format.
The following conditions shall be checked.
— — If the structure of the signature data conforms to the

defined format.
— — If the signature data contains all elements required in
the profile.
— — If the version number of the signature data is correct
(applicable only to PAdES and CAdES).
b) b) Verify the signer’s certificate.
1) 1) Certification path validation described
[ [16] ]
in RFC5280 16 . .
— — Build and verify the certification path for the signer’s
certificate.
2) 2) Ascertain extensions regarding HPKI
contained in the signer’s certificate.
Implementations are required to support functions to check
the following elements.
— — HPKI certificate policy identifier.
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Verification process Description
— — The value of the hcRole attribute in the signer’s
certificate.
— — The ascertainment method not covered by this
document. It is possible to choose suitable methods for
applications.
c) c) Verify the signed attributes. — Verify the attributes incorporated to the digital signature.
d) d) Verify the signature value and signer
1) 1) Verify the signature value using the
identifier.
signer’s public key.
The following steps shall be performed.
— — Calculate the hash value(s) of the signed data
object(s) and ascertain that it(they) matches(match) the
value(s) of the digest(s) contained in the signature.
— — Verify the signature value using the signer’s public
key.
2) 2) Verify the correspondence of the
identifier information of the signer’s certificate.
— — Ascertain that the signer identifier matches the
signer’s certificate attributes contained in the signature
data.
4.3.3 Verification of ES-T
4.3.3.1This subclause describes the process to verify a signature in ES-T format.
The validation process of ES-T is performed after the validation of ES-BES. The verification processes of ES-T
are described below, and the order of the processes should not be changed. See Figure 4Figure 4.

Figure 4 — Verification processes of ES-T
The above processes shown in Figure 4 are explained in Table 2Table 2.
ISO/FDIS 17090-4:2025(en)
Table 2 — Description of verification processes of ES-T
Verification process Description
a) a) Verify the signature timestamp.
1) 1) Verify the certificate of the TSA that
provides the signature timestamp.
The following steps shall be performed for the TSA
certificate.
— — Certification path validation as described in
[ ]
RFC5280 16. .
— — Ascertain that the certificate contains extended key
usage for TSA purpose.
2) 2) Verify the signature of the TSA that
provides the signature timestamp.
— — Verify the signature value of the timestamp token
using the public key of a TSA certificate.
3) 3) Verify the message imprint of the
timestamp token.
— — Calculate the hash value of the signer’s signature
value and ascertain that it matches the value of the
message imprint within the timestamp token.
b) b) Verify the ES-BES at the time of the
1) 1) Verify the ES-BES at the time of the
signature timestamp.
signature timestamp.
— — Verify that the certificate of the signer was valid at
the time of the signature timestamp.
2) 2) Verify that the trust anchor is
appropriate.
— — Verification could be performed in a long period of
time after the ES-T data were created. The trust anchor
that was valid at the time of signature might be expired
or compromised at the time of verification. In this case,
the verifier shall verify that the trust anchor is
appropriate.
— — For example, the signer and the verifier specify an
agreement about the trust anchor (for example, the
signature policy) and manage it under protection against
CA compromise, or the verifier refers to a trusted third
party that manages the history of verification
information of certificates. Specific methods are out of
the scope of this document.
4.3.4 Verification of ES-A
The validation process of ES-A is performed after the validation of ES-BES and ES-T. The verification processes
of ES-A are described below, and the order of the processes should not be changed. See Figure 5Figure 5.
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Figure 5 — Verification processes of ES-A
The above processes shown in Figure 5 are explained in Table 3Table 3.
Table 3 — Description of verification processes of ES-A
Verification process Description
a) a) Verify the latest archive timestamp.
1) 1) Verify the certificate of the TSA that
provides the latest archive timestamp.
The following steps shall be performed for the TSA
certificate.
— — Verify the validity of the certificate at the time of

verification.
— — Ascertain that the certificate contains extended key
usage for TSA certificate is purpose.
2) 2) Verify the signature of the TSA that

provides the latest archive timestamp.
— — Verify the signature value of the timestamp token
using the public key of the TSA certificate.
3) 3) Verify the message imprint of the

timestamp token.
— — Calculate the hash value of the target fields for the
archive and verify that it matches the value of the
message imprint within the timestamp token.
— — Compute the message imprint based on the data that
should be timestamped by the archive timestamp and
verify that the result of this computation matches the
message imprint within the time-stamp token
ISO/FDIS 17090-4:2025(en)
Verification process Description
b) b) Verify the previous archive
1) 1) Verify the certificate of the TSA that
timestamp, if it is present.
provides the archive timestamp.
— — Verify the validity of the TSA certificate of the archive
timestamp at the time that is shown in the archive
timestamp that timestamps it.
The relationship of time for verification is shown in the
Figure 6Figure 6.
2) 2) Verify the signature of the TSA that

issued the archive timestamp.
3) 3) Verify the correspondence between the

archive timestamp and the imprint data.
4) 4) Verify that the trust anchor of the TSA

certificate is appropriate.
— — The validity of the certificate at the trust point could
be expired at the time of verification of the TSA certificate
for the archive timestamp.
— — In order to verify the trust anchor of b) 1), confirm
that the certificate at the trust point is appropriate.
Specific methods are out of the scope of this document.
c) c) Verify validation data for the signer’s
1) 1) Ascertain the validity of the certificate
certificate.
chain archived in the validation data.

2) 2) Ascertain that the trust anchor of the

certificate is appropriate.
3) 3) Ascertain the validity of revocation
information archived in the validation data.
— — Compare the issued time of revocation information
with the time of archiving and confirm that the revocation
information is appropriate.
4) 4) Ascertain that the trust point of the
revocation information is valid.
— — Confirm that the trust point certificate is appropriate
at the time of verification of validity of the certificate used
for signing the revocation information.
d) d) Verify the signature timestamp at
1) 1) Ascertain that the signature timestamp
the time of the first archive timestamp.
was valid at the time of the first archive timestamp.
— — Execute 4.3.3, Table 24.3.3.2, Table 2,, step a)
assuming the time of the first archive timestamp. Verify
that the TSA certificate was valid at the time of the first
archive timestamp.
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Verification process Description
2) 2) Verify that the trust anchor of the

signature timestamp was appropriate at the time of
first archive timestamp.
— — The validity of the certificate at the trust point could
be expired at the time of verification of the TSA certificate
for the signature timestamp.
— — In order to verify the trust anchor of d) 1), confirm
that the certificate at the trust point is appropriate.
Specific methods are out of the scope of this document.
e) e) Verify the signer’s signature at the
1) 1) Verify the signer’s signature based upon
time of the signature timestamp.
process specified in 4.3.2Clause 4.3.2.2 using
validation data that is verified by process (c) and
ascertain that the certificate was valid at the time of
the signature timestamp.
2) 2) Ascertain that the trust anchor is

appropriate.
— — The validity of the certificate at the trust point could
be expired at the time of verification of the signer’s
certificate.
— — In order to verify the trust anchor of e) 1), confirm
that the certificate at the trust point is appropriate.
Specific methods are out of the scope of this document.
f) f) Verify the ordering of times.
Ensure that the signature timestamp and archive timestamp
are in consistent time order. That is, the archive timestamp
Confirm the correspondence of time. shall be later than the signature timestamp.
— — Ascertain the correspondence of signature

timestamps and archive timestamps. Check that the
order of each time is consistent.
ISO/FDIS 17090-4:2025(en)
Figure 6 — Relationship of time for ES-A verification
(the case of 2 archive timestamps)
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
4.4 CAdES specification
4.4.1 General
4.44.4 shows the requirements about generation and validation of CAdES data.
4.4.24.4.2 shows the outline of two profiles which this standard defines, and shows the structure of CAdES.
4.4.34.4.3 defines the expression of requirement levels. 4.4.44.4.4 to 4.4.54.4.5 show the requirements for two
profiles.
4.4.2 Long term signature profile
In order to make digital signatures verifiable for the long term, signing time shall be identifiable, any illegal
alterations of information pertaining to signatures shallbeshall be detectable, including the subject of
information and validation data, and interoperability shall be ensured. By defining the following two profiles,
this document satisfies the previous requirements for CAdES.
a) a) CAdES-T profile
A profile pertaining to the generation and validation of CAdES-T data.
b) b) CAdES-A profile
A profile pertaining to the generation and validation of CAdES-A data.
Figure 7Figure 7 shows the relationship between CAdES-T data and CAdES-A data.

Figure 7 — Relationship between CAdES-T data and CAdES-A data
ISO/FDIS 17090-4:2025(en)
4.4.3 Representation of the required level
This document defines the following representation methods for the required level (as a profile) of each
element constituting CAdES-T data and CAdES-A data. IfdetailedIf detailed specifications are required, refer
to ISO 14533-1:2022, Clause 5, 6.2 and 6.3.
a) a) Mandatory (M)
Elements whose required level is ‘Mandatory’ shall be implemented. If such an element has optional sub-
elements, at least one sub-element shall be selected. Any element whose required level is ‘Mandatory’ and
is one of the sub-elements of an optional element shall be selected whenever the optional element is
selected.
b) b) Optional (O)
Elements whose required level is ‘Optional’ may be implemented at the discretion of the implementer.
c) Conditional (C)
Elements whose required level is ‘Conditional’ may be implemented at the discretion of the implementer.
Detailed specifications pertaining to the processing of any element whose required level is ‘Conditional’
shall be provided. For example, the implementer provides the specifications for any ‘Conditional’ elements
by disclosing a supplier’s declaration of conformity and its attachment (see ISOc) 14533-1:2022,
Annex A).
d)c) Conditional (C)
Elements whose required level is ‘Conditional’ may be implemented at the discretion of the implementer.
Detailed specifications pertaining to the processing of any element whose required level is ‘Conditional’
shall be provided. For example, the implementer provides the specifications for any ‘Conditional’ elements
by disclosing a supplier’s declaration of conformity and its attachment (see ISO 14533-1:2022, Annex A).
e)d) d) Prohibited (P)
Elements whose required level is ‘Prohibited’ shall not be in the data. The Prohibited element may be
ignored in validation processes.
4.4.4 CAdES-T profile
In Tables 4the Table 4 to 8Table 8,, Element indicates the element. Required Level is the Required Level
defined in 4.4.3 4.4.3. Value is written when the value is specified.
Table 4 — ContentInfo
Element Required level Value
contentType M Id-signedData
content M SignedData
Table 5 — SignedData
Element Required level Value
CMSVersion M
DigestAlgorithmIdentifiers M
EncapsulatedContentInfo M
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Element Required level Value
—  eContentType M
—  eContent O
CertificateSet (Certificates) O
—  Certificate O
—  AttributeCertificateV2 P
—  OtherCertificateFormat P
RevocationInfoChoices (crls) O
—  CertificateList O
—  OtherRevocationInfoFormat C
SignerInfos M
—  single O
—  parallel O
Table 6 — SignerInfo
Element Required level Value
CMSVersion M
SignerIdentifier M
—  IssuerAndSerialNumber O
—  SubjectKeyIdentifier O
DigestAlgorithmIdentifier M
SignedAttributes M
SignatureAlgorithmIdentifier M
SignatureValue M
UnsignedAttributes M
The required level shall be ‘Conditional’ for any signed and unsigned attribute elements not listed in Table 7
Table 7 and Table 8Table 8.
ISO/FDIS 17090-4:2025(en)
Table 7 — SignedAttributes — Signed attributes
Element Required level Value
ContentType M
MessageDigest M
SigningCertificateReference M
a
—  ESSSigningCertificate O
a
—  ESSSigningCertificateV2 O
—  OtherSigningCertificate P
SignaturePolicyIdentifier P
b
SigningTime O
ContentReference C
ContentIdentifier C
ContentHints C
CommitmentTypeIndicatio C
SignerLocation C
SignerAttribute C
ContentTimestamp C
c
Time Mark or other method C
a ESSSigningCertificate or ESSSigningCertificateV2 shall be selected.
b When the element is not implemented, it may be ignored.
[ [3] ]
c Other methods defined in ISO 14533-4 3 . .
Table 8 — Unsigned Attributesattributes (CAdES-T)
Element Required level Value
CounterSignature O
Signing time information M
—  SignatureTimestamp Timestamp defined in
M
[ [14]]
RFC3161 14
—  time mark, etc. P
4.4.5 CAdES-A profile
The CAdES-A profile is defined as an extended form of the CAdES-T profile to which the unsigned attributes
specified in Table 9Table 9 are added. The required level shall be ‘Conditional’ for any element not specified
in Table 9Table 9.
In the Table 9Table 9,, Element indicates the element. Required Level is the Required Level defined in
4.4.34.4.3. Value is written when the value is specified.

© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Table 9 — Unsigned Attributesattributes (CAdES-A)
Required level Value
Element
ArchiveTimestampV1
ArchiveTimestampV3
ArchiveTimestampV2
a
CounterSignature C C
Trusted time M M
—  SignatureTimeStamp Timestamp defined
O O
[ ]
in RFC3161 14
—  Time Mark or other method like
d
O O
archive time-stamp as its replacement
a
CompleteCertificateReferences M

C
(O for validation)
a
CompleteRevocationReferences M

C
(O for validation)
—  CompleteRevRefs CRL O O
—  CompleteRevRefs OCSP O O
—  OtherRevRefs P P
Attribute certificate references P P

Attribute revocation references P P
a
CertificateValues C M
—  CertificateValues O O
—  Certificates maintained by trusted

P P
service
a
RevocationValues C M
—  CertificateList O O
—  BasicOCSPResponse O O
—  OtherRevVals P P
—  Revocation information maintained by

P P
trusted service
Timestamped cert and crls reference P P

Archiving M M
—  ArchiveTimestampV3 id-aa-ets-

O O
archiveTimestampV3
—  ArchiveTimestampV2 id-aa-48 Timestamp defined
e
C O
[ ]
in RFC3161 14
b
—  ArchiveTimestampV1 id-aa-27
e
C O
Timestamp defined
[ ]
in RFC3161 14
c
—  Evidence Record O O
—  Other method P P
a Attribute shall not be included after applying those types of the time-stamp.
[ [11]]
b Defined in ETSI/TS 101 733 v1.4.0 11 or earlier versions.
ISO/FDIS 17090-4:2025(en)
Required level Value
Element
ArchiveTimestampV1
ArchiveTimestampV3
ArchiveTimestampV2
[ [15]]
c Defined in IETF RFC4998 15 RFC 4998
d Other methods defined in ISO 14533-4.
e Not recommended attribute.
4.5 XAdES specification
4.5.1 General
4.54.5 shows the requirements about generation and verification of XAdES.
4.5.24.5.2 shows the outline of three profiles which this standard defines, and shows the structure of XAdES.
4.5.34.5.3 defines the expression of requirement levels. 4.5.4, 4.5.54.5.4, 4.5.5,, and 4.5.64.5.6 show the
requirements for three profiles.
4.5.2 Defined long-term signature profiles
In order to make digital signatures verifiable for the long term, interoperability shall be ensured, signing time
shall be identifiable, and any illegal alterations of information pertaining to signatures shall be detectable,
including the subject of information and validation data. By defining the following three profiles, this
document satisfies these requirements for XAdES.
a) a) XAdES-T profile:
A profile pertaining to the generation and validation of XAdES-T data.
b) b) XAdES-X-Long profile:
A profile pertaining to the generation and validation of XAdES-X-Long data.
c) c) XAdES-A profile:
A profile pertaining to the generation and validation of XAdES-A data.
Figure 8Figure 8 shows the relationship between XAdES-T data, XAdES-X-Long data and XAdES-A data.
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Figure 8 — Relationship between XAdES-T data, XAdES-X-Long data and XAdES-A data
4.5.3 Representation of the required level
This document defines the following representation methods for the required level (as a profile) of each
element constituting XAdES-T data, XAdES-X-Long data, and XAdES-A data. If detailed specifications are
needed, refer to ISO 14533-2:2021 4.2 and 4.3.
a) a) Mandatory (M)
Elements whose required level is ‘Mandatory’ shall be implemented without fail. If such an element has
optional sub-elements, at least one sub-element shall be selected. Any element whose required level is
‘Mandatory’ and is one of the sub-elements of an optional element shall be selected whenever the optional
element is selected.
b) b) Optional (O)
Elements whose required level is ‘Optional’ may be implemented at the discretion of the implementer.
c) c) Conditional (C)
Elements whose required level is ‘Conditional’ may be implemented at the discretion of the implementer.
Detailed specifications pertaining to the processing of any element whose required level is ‘Conditional’
shall be provided. For example, the implementer provides the specifications for any ‘Conditional’ elements
by disclosing a supplier’s declaration of conformity and its attachment (see ISO 14533-2:2021, Annex A).
d)c) Conditional (C)
ISO/FDIS 17090-4:2025(en)
Elements whose required level is ‘Conditional’ may be implemented at the discretion of the implementer.
Detailed specifications pertaining to the processing of any element whose required level is ‘Conditional’
shall be provided. For example, the implementer provides the specifications for any ‘Conditional’ elements
by disclosing a supplier’s declaration of conformity and its attachment (see ISO 14533-2:2021, Annex A).
e)d) d) Prohibited (P)
Elements whose required level is ‘Prohibited’ shall not be in the data. The Prohibited element may be
ignored in validation processes.
4.5.4 XAdES-T profile
The required level shall be ‘Conditional’ for any elements not listed in Table 10, Table 11Table 10, Table 11,,
and Table 12Table 12.
In Table 10, Table 11the Table 10, Table 11,, and Table 12Table 12,, Element indicates the element. Required
Level is the Required Level defined in 4.5.34.5.3. Condition is written when the condition is specified.
Table 10 — Signature element
Element or attribute Required level Condition
a
Id attribute of ds:Signature M
ds:SignedInfo M
b
—  ds:CanonicalizationMethod M
—  ds:SignatureMethod M
—  ds:Reference M
—   —  ds:Transforms O
—   —  ds:DigestMethod M
—   —  ds:DigestValue M
ds:SignatureValue M
c
ds:KeyInfo O
ds:Object M
[ [10] ]
a “Optional” in an XML signature, but “Mandatory” in ETSI/EN 319-132 10 . .
b “the The value of this element shall be either “https://www.w3.org/2006/12/xml-
[ [18] ]
c14n11” 18"" , , corresponding to Canonical XML v1.1 (omits comments) or
[ [19] ]
“https://www.w3.org/2001/10/xml-exc-c14n#” 19"" , , corresponding to Exclusive
Canonicalization (omits comments)).
c If the xs:SigningCertificateV2 qualifying property (Table 11(Table 11)) is incorporated to the
signature, no restrictions apply to ds:KeyInfo element. Otherwise, then the following restrictions
apply:
—  the ds:KeyInfo element shall include a ds:X509Data containing the signing certificate;
—  the ds:KeyInfo element may also contain other certificates;
—  the ds:SignedInfo element shall contain a ds:Reference element that refers to ds:KeyInfo.
Table 11 — Object element, Signed Properties element
Element Required level Condition
a
xs:QualifyingProperties M
—  xs:SignedProperties M
—   —  xs:SignedSignatureProperties M
© ISO #### 2025 – All rights reserved
ISO/DISFDIS 17090-4:2025(en)
Element Required level Condition
b
—      —  xs:SigningTime O
b,c
—      —  xs:SigningCertificateV2 O
d
—      —  xs:SigningCertificate C
—      —  xs:SignaturePolicyIdentifier C
—      —  xs:SignatureProductionPlaceV2 C
—      —  xs:SignatureProductionPlace C
—      —  xs:SignerRoleV2 C
d
—      —  xs:SignerRole C
—   —  xs:SignedDataObjectProperties C
b
—      —  xs:DataObjectFormat C
—         —  xs:Description C
—         —  xs:ObjectIdentifier C
b
—         —  xs:MimeType C
—         —  xs:Encoding C
—      —  xs:CommitmentTypeIndication C
—      —  xs:AllDataObjectsTimeStamp C
—      —  xs:IndividualDataObjectTimeStamp C
a The Target attribute shall refer to the Id attribute of the corresponding ds:Signature element.
[ ]
b Mandatory in ETSI/EN 319-132-1 v1.1.1 10 Baseline Signature.
c Either xs:SigningCerticicateV2 or ds: KeyInfo (Table 10(Table 10)) is required.
d These elements are used for past compatibility and reference to ETSI/TS 101 903
[ [12] ]
v1.1.1 12 . .
Table 12 — Object element, Unsigned Properties element
Element Required level Condition
xs:QualifyingProperties M
—  xs:UnsignedProperties M
—   —  xs:UnsignedSignatureProperties M
—      —  xs:CounterSignature O
—      —  Trusted time M
a
—      —  xs:SignatureTimeStamp M Timestamp defined
as
[
RFC3161 14RFC31
b]b
—      —  other POE method P
—   —  xs:UnsignedDataObjectProperties C
[ ]
a Mandatory in ETSI/EN 319-132-1 v1.1.1 10 Baseline Signature.
[ ]
b Timestamp is defined as RFC3161 14 because the method of acquiring a Timestamp and
storing it in XAdES data and the method of verifying the Timestamp are clearly shown by
standards.
ISO/FDIS 17090-4:2025(en)
4.5.5 XAdES-X-Long form
The XAdES-X-Long profile is defined as an extended form of the XAdES-T data. The required level of each
element of the UnsignedSignatureProperties defined as XAdES shall be as specified in Table 13Table 13. The
required level shall be ‘Conditional’ for any element not specified in Table 13Table 13.
In the Table 13Table 13,, Element indicates the element. Required Level is the Required Level defined in
4.5.34.5.3. Condition is written when the condition is specified.
Table 13 — Additional UnsignedSignatureProperties for XAdES-X-Long form
Element or Processing method Required level Condition
xs141:TimeStampValidationData C
—  xs:CertificateValues C
—  xs:RevocationValues C
xs141:CompleteCertificateRefsV2 O
a
xs:CompleteCertificateRefs C
a
xs:CompleteRevocationRefs C
—  xs:CRLRefs O
—
...