European Metadata Container

From XBRLWiki

(Difference between revisions)

Current revision

CEN WS XBRL Experts: Elina Koskentalo (XBRL Finland), Eduardo González (Gonblan)

Foreword

This document has been prepared by CEN/WS XBRL, the secretariat of which is held by NEN.

This CWA is one of a series of related deliverables. The other deliverables are:

CWA XBRL 001 consists of the following parts, under the general title Improving transparency in financial and business reporting — Harmonisation topics:

Part 1: European data point methodology for supervisory reporting.

Part 2: Guidelines for data point modelling

Part 3: European XBRL Taxonomy Architecture

Part 4: European Filing Rules

Part 5: Mapping between DPM and MDM

CWA XBRL 003-1 Improving transparency in financial and business reporting — Standard regulatory roll-out package for better adoption — Part 1: XBRL Supervisory Roll-out Guide

CWA XBRL 003-2 Improving transparency in financial and business reporting — Standard regulatory roll-out package for better adoption — Part 2: XBRL Handbook for Declarers

Introduction

The present document specifies a standard security envelope and an approach to integrate metadata usable for the European supervision authorities in order to receive reporting data in a standardised way. This standard has been elaborated over the years 2012 and 2013 and has been reviewed in a public consultation in the third quarter of 2013.

1 1 Scope
2 2 Normative references
3 3 Terms and definitions
4 4 Files in containers
5 5 Container
- 5.1 5.1 Submission container
- 5.2 5.2 Response container
6 6 Primitive functions
7 7 Exchange model

[edit]

1 Scope

The purpose of this CWA is to propose a standard for submitting data instances to financial regulators in accordance with the chapter describing this CWA in the business plan [26]:

""Metadata container" to wrap a submitted XBRL instance document and compliance test. Provide a standard Metadata Container to enable XBRL sourcing, with in addition necessary compliance tools to enable all stakeholders to test and ensure full adherence to the technical standards.

Metadata such as sender of the document, contact details, date and time of submission, version, digital signature, etc.. are not included in the taxonomies, because they really don't belong to the data model. On the other hand, and often for legal reasons, these data are required by national regulators. As a consequence, a variety of national protocols has been engineered, which complicates the life of cross-border institutions, but also prohibit the possibility to create a harmonized European collection system. Metadata are needed as well for financial reporting as for company legal and economical data. For the digital signature, existing solutions from the Business Registers, who have a deep expertise of the topic, may be generalized. In order to ensure compliance with the protocol, this project will deliver online tools for all stakeholders to use and to test compliance with the complete set (metadata container and XBRL instance document.

This CWA will provide standard protocols and mechanisms for digital signature, administrative data such as identification of submitter, feedback parameters, versioning of subsequent submissions and encryption, as well as online collaborative tools to ensure compliance."

This document specifies:

a submission container structure to enable financial institutions to submit their regulatory reporting to the respective regulators in a standardised way;

a metadata information structure (called «Header») that is part of the submission container structure;

an adequate negative (or positive) acknowledgement to be returned by the regulator to indicate if the submission container was well received by the regulator (or not);

a response container structure to allow the regulator to return content-related error messages for the data instances in case errors occurred during any validation phase.

The main targeted authorities are the EBA (European Banking Authority) and EIOPA (European Insurance and Occupational Pensions Authority) as well as their related national supervision agencies, but the standard may also be used by other regulators. All container structures defined allow the packaging and securisation of data in a uniform way, which should lead to a greater transparency and interoperability between the declaring entities and the national and the European supervisory authorities.

In the course of the specification process, supplementary requirements were added by stakeholders or authorities concerned, among which:

The scope of the data instances to be supported has been extended from pure XBRL instances to any type of structured data instances, including XML, CSV, etc.;

The possibility of a 2-layer (or even multi-layer) submission process: some data instances are to be processed by the receiving authority itself (e.g. a national authority), others may be forwarded to a subsequent authority (e.g. a European one);

The possibility of using the structures of the present CWA in a secure environment i.e. an environment that has its own signature and/or encryption facilities;

The possibility of adding non-standard metadata if required (extensibility of the metadata header).

An important development approach for this CWA is to be flexible enough to support many different uses in different environments. For this reason some aspects (e.g. types of identifiers for financial institutions) could not be fixed by this standard and they shall be determined for every specific use of this standard via complementary instructions.

The present specification only defines the structures for the container itself, it does not define any transport aspects; the submission of a container may thus be freely combined with any type of transport protocol (submission via e-mail, (s)ftp, web portal, web services, …) in accordance with the local requirements.

[edit]

2 Normative references

The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ETSI Technical Report 102 038 v1.1.1, Electronic Signatures and Infrastructures; XML format for signature policies

ETSI Technical Specification 101 903 v1.4.1, XML Advanced Electronic Signatures (XAdES)

ETSI Technical Specification 102 176-1 v2.1.1, Electronic Signatures and Infrastructures; Algorithms and Parameters for Secure Electronic Signatures; Part 1 Hash functions and asymmetric algorithms

[edit]

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

3.1

reporting entity

entity submitted to financial reporting and legally responsible for it

Note 1 to entry: (in many cases it uses internal resources to play the role of Content Producer and Technical Sender too). Also known as 'Declarer', 'Sender', '<ReportingEntity>'.

Note 2 to entry: An authority may also play the role of a reporting entity, e.g. when a national authority is providing data to a subsequent European authority as level-2 reporting.

3.2

technical sender

(potential) sub-contractor in charge of physically sending the data in respect of the present CWA (aware of containers, encryption, etc.)

Note 1 to entry: Also known as '<TechnicalSender>'.

3.3

content producer

(potential) sub-contractor in charge of the production of the content of the reporting and responsible for the accuracy of the content

Note 1 to entry: Also known as '<ContentProducer>'.

3.4

receiver

entity receiving reported data; also known as 'Authority' or 'Regulator' or 'Supervisor’

3.5

security envelope

XML structures surrounding the .zip file(s) after encryption and / or signature phase in accordance with the present CWA

3.6

negative acknowledge

information to the sender that the submission container could not be accepted because of error conditions (usually an instance of the « ContainerFeedback » schema with the tag <ContainerValidationFlag> having the value false

3.7

positive acknowledgement

information to the sender that the submission container has been accepted for processing of the data instances (usually an instance of the « ContainerFeedback » schema with the tag <ContainerValidationFlag> having the value true

3.8

instructions

supplementary information drafted by the receiver on how exactly to use the present CWA for a determined use.

3.9

certificate

a standard IETF X.509 digital certificate

Note 1 to entry: Public key should be RSA (rsaEncryption) with key length at least 2048.

3.10

header file

header file that complies with the « Header » schema

Note 1 to entry: See chapter 4.3.1.

3.11

container feedback file

container feedback file that complies with the « ContainerFeedback » schema

Note 1 to entry: See chapter 4.3.2.

3.12

instance feedback file

An instance feedback file that complies with the « InstanceFeedback » schema

Note 1 to entry: See chapter 4.3.3.

3.13

alternative instance feedback file

instance feedback file that is in another format than that of an instance of the « InstanceFeedback » schema

[edit]

4 Files in containers

[edit]

4.1 Introduction

The present chapter describes the files intervening in this standard, starting with simple files and continuing with the composed ones.

[edit]

4.2 Data files

Data files are files that contain data, whether these data are structured of not. Data files can be any structured files like XBRL or XML instances, but also unstructured files like spread sheets or word processor files. The container controls files described in the next chapter as well as composed files (files that contain other files) are not part of the data files.

[edit]

4.3 Container control files

The three types of container control files developed within this CWA are described in the following chapters.

[edit]

4.3.1 Header file

A header file is an XML instance of an XML schema built according to the indications of chapter 6.3.3.

The function of the header file is to describe the global characteristics of the data files in the submission.

[edit]

4.3.2 Container feedback files

A container feedback file is an XML instance of the XML schema located at:

http://www.eurofiling.info/eu/fr/esrs/ContainerFeedback/ContainerFeedback.xsd.

The function of the container feedback file is to confirm to the sender the success (or not) of the submission.

[edit]

4.3.3 Instance feedback files

Instance feedback files are XML instances of the XML schema located at:

http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback/InstanceFeedback.xsd.

Alternative representations of the error conditions of the data files submitted (e.g. documents with links to external systems representing the errors graphically, spread sheets with “red” cells indicating error locations, …) may be added to a response container, either as a complement or as an alternative to the XML instance feedback file. In that case the term alternative instance feedback file will be used.

[edit]

4.4 ZIP compressed file

A Zip compressed file is a set of one or more files compressed together (ZIP [18]).

[edit]

4.5 Secured files

The following chapters describe the files to which security operations have been applied.

[edit]

4.5.1 Encrypted file

An encrypted file is a file embedded and encrypted in an XML instance of the XML schema (XMLENCR-CORE [14]).

[edit]

4.5.2 Signed file

A signed file is a file embedded and signed in an XML instance of the XML schema (ETSI-XAdES [2]).

[edit]

4.6 File naming conventions

The present CWA has defined the minimum required file naming conventions as described in the present chapter. The aim was to give the regulators vast degrees of freedom to define for their own purposes a file naming convention that serves best their requirements. So excepted for the reserved names and suffixes described in this chapter, the receiver’s instructions may define adequate file naming conventions for containers, folders, data files etc.

[edit]

4.6.1 Reserved file names

[edit]

4.6.1.1C:\Users\eduardo\AppData\Local\Temp header.xml

The name «header.xml» is exclusively reserved for files of the type «header file».

[edit]

4.6.2 Instance feedback file name

The name and location of instance feedback files and other types of alternative instance feedback files should be chosen in such a way that the reconciliation of the feedback file with the corresponding data instance in the submission container is evident.

[edit]

4.6.3 Reserved file name suffixes

All files shall have the « usual » file extension applicable in environments without restriction to the length of the extension: « .xbrl » for XBRL instances, « .xml » for XML instances, « .csv » for comma separated files etc.

[edit]

4.6.4 Reserved extended suffixes

[edit]

4.6.4.1 .signed.xml

The file extension «.signed.xml» is exclusively reserved for signed files.

[edit]

4.6.4.2 .encrypted.xml

The file extension «.encrypted.xml» is exclusively reserved for encrypted files.

[edit]

4.6.4.3 .containerfeedback.xml

The file extension«.containerfeedback.xml » is exclusively reserved for container feedback files complying with the ContainerFeedback schema.

[edit]

4.6.4.4 .instancefeedback.xml

The file extension«.instancefeedback.xml » is exclusively reserved for instance feedback files complying with the InstanceFeedback schema.

[edit]

5 Container

A container is a ZIP compressed file that contains a set of data files to be submitted.

A container may contain any type of files (e.g. other containers).

Folders may optionally be used in a container to better structure the files.

Folder conventions are not defined in this document.

[edit]

5.1 Submission container

Figure 1— Submission container example 1: Structure of a simple submission container with only one type of reporting in XBRL format and no use of folders

A submission container is a container that contains 1 header and 0 or more files and that is to transfer reporting data from the sender to the receiver.

Figure 2— Submission container example 2: Advanced structure of a submission container using folders (bold) to structure multiple types of reporting, containers, supplementary information etc.

[edit]

5.2 Response container

A response container is a container that may be returned by the receiver of a submission container to its sender to inform the sender about the result of the evaluation of its content (e.g. possible errors).

When applicable (i.e. XBRL instance documents), XML Instances of the InstanceFeedback schema may be used to report the errors that were identified during the validation phase by the receiver, knowing that:

1) alternative instance feedback files are allowed as a replacement or as a supplement to the instance feedback files;

2) instance feedback files should be generated systematically, even if no errors at validation time occurred (not only negative, but also positive feedback should be provided for the data instances in the related submission container).

A response container is composed of the following files:

0 or 1 container feedback file;

0 to n instance feedback files and / or 0 to n alternative error feedback files.

Figure 3— Example of a response container generated on the basis of an incoming submission container with one reporting consisting of three XBRL files. All files in the response container are instances of the XML schema InstanceFeedback

Figure4— Example of a response container generated on the basis of an incoming submission container with two different reportings and using folders. All XML files in the response container are instances of the XML schema InstanceFeedback. As a supplement, Excel-type error-diagnostics are returned for Report1

[edit]

6 Primitive functions

The present chapter describes the primitive functions required to put in place the present CWA.

[edit]

6.1 Compression functions

Compression is made in accordance with the ZIP file format specification [18].

The minimum feature version is 2.0 as defined in chapter 4.4.3.2 of the present version of the specification (version 6.3.3).

[edit]

6.1.1 Creating a ZIP compressed file

Many tools in the market are able to create ZIP compressed files; interoperability problems are not known as long as multi-volume zip is not used. This is why multi-volume ZIP compressed files are not supported by this CWA version.

In order to avoid problems with senders using features of very recent versions not yet supported by the receiver, the instructions of the receiver may fix further constraints on the compression to use (e.g. a maximum level of the zip standard, as supported by the receiver).

[edit]

6.1.2 Expanding a ZIP compressed file

This operation is the inverse operation of “Creating a ZIP compressed file”.

[edit]

6.2 Security functions

This chapter describes the primitive functions for signing or encrypting files as well as the way to calculate the hash required in schemata InstanceFeedback and ContainerFeedback.

Within this specification, encryption and / or digital signature shall be applied to a single file (not to a set of files).

[edit]

6.2.1 Encrypting a file

As references XMLENCR-CORE [14];

using key transport RSA-OAEP:

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

and encrypting data with AES256:

http://www.w3.org/2009/xmlenc11#aes256-gcm

The selected encryption uses the W3C XML Encryption to cipher a file, embedding it completely into the XML document that will result of the encryption process (there shall be no references to the file at an external location). Inside the CipherData element, there shall be a CipherValue element, but there shall not be a CipherReference element.

Basic steps for encryption are:

create XML document with the embedded file, using W3C Encryption schema;

generate AES-256 key (secret key);

get RSA public key (and certificate);

cipher secret key with public key, using RSA-OAEP;

cipher XML element with the embedded file with AES-256 using secret key;

store all in a file using W3C Encryption schema [14].

The embedded file is encrypted using a symmetric algorithm (AES-256) with a generated secret key. The security strength of AES-256 is 256 (NIST SP 800-57 part1 [19]).

The key transport algorithm RSA-OAEP with mask generation function MGF1 (MGF1p, padding) is used to cipher the generated AES-256 secret key. Key transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. RSA-OAEP uses the receiver’s public key to encrypt the secret key generated by AES while encrypting the file. This key transport algorithm chosen is SP800-56B compliant [21], using KTS-OAEP-basic, without key confirmation.

The AES256 has been chosen for encryption and decryption as the algorithm and key length is safe to use and no security risk is currently known (see NIST SP 800 131A [20]). Also, RSA is acceptable, with |n|=2048, for SP800-56B [21] key agreement schemas. Note is the length in bits of the RSA modulus , and means is at least 2048.

AES-256 is a block cipher, being able to encrypt/decrypt messages of a fixed length (called block, in AES it's 128). In order to be able to encrypt/decrypt larger messages (larger than one block size), a mode of operation is required which is an algorithm that describes how to apply the block cipher many times and how to be able to work with larger messages.

Selected mode of operation is Galois Counter Model (GCM), as recommended in "XMLENCR-CORE1 [16]". For details on GCM, see NIST SP 800-38D [27].

The certificate used to encrypt shall be X.509 and shall also be included in the XML file (as allowed by W3C encryption schema [14]) to be able to identify the private key corresponding to this certificate (when decrypting).

Basic steps for decryption are:

read XML document (W3C Encryption schema);

extract the RSA certificate to ask for (or look for) the corresponding private key;

decrypt AES secret key using private key;

decrypt XML element (xenc:CipherValue) with the encrypted content using the secret key;

as the content of the decrypted element should be the file, store this file externally in the file system.

[edit]

6.2.2 File name changes upon encryption

As the table 1 shows, when an encryption is applied to a file that has a reserved extended suffix (or, if there is none, a standard suffix), this reserved extended suffix (or, if there is none, a standard suffix) shall change into .encrypted.xml.

Similarly, when an encryption is applied to a file that has no suffix, the reserved extended suffix .encrypted.xml shall be added to the filename.

Table 1— Encrypted file name examples

File to encrypt	Name of the encrypted file	Filename inside the XML-enc file
Lol	Lol.encrypted.xml	Same as «File to encrypt»
Lol.pdf	Lol.encrypted.xml	Same as «File to encrypt »
Lol.zip	Lol.encrypted.xml	Same as «File to encrypt »
Lol.signed.xml	Lol.encrypted.xml	Same as «File to encrypt »
Lol.encrypted.xml	Lol.encrypted.xml	Same as «File to encrypt »

[edit]

6.2.3 Decrypting a file

This operation is the inverse operation of “Encrypting a file”.

The filename of the decrypted file should become the filename inside the XML signature file.

[edit]

6.2.4 Signing a file

The present chapter explains the requirements and determines the standard finally chosen for applying electronic signatures.

[edit]

6.2.5 Requirements

The requirements for the choice of the standard were:

provide non-repudiation: assure the sender identity, preventing an individual from denying that have effectively signed data;

prevent the unauthorised (or accidental) modification of data;

allow the addition of multiple files to a single signature envelope;

be compliant with European Directive 1999/93/EC [8];

use a PKI infrastructure, if required;

shall contain the signer’s digital X.509 certificate;

shall contain the signing time;

should include information about policy to verify electronic signature. Hence this signature policy is a legal/contractual document and it might not be available for some authorities. The standard shall support both situations, whether the regulator has a signature policy or not;

avoid the use of MD5 or SHA-1;

long term validation is not needed, as signature should be validated in a limited time-frame.

[edit]

6.2.6 Electronic signature to use

The file structure generated by the signature shall be XAdES-BES/EPES as specified in ETSI-XAdES [2];

The algorithm shall be RSA with SHA512:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha512;

XAdES-BES/EPES (which has been built up on W3C XML Digital Signature) shall be implemented according to COMMISSION DECISION of 25 February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market [9].

A signature policy is a legal document that extends the definition of the electronic signature by supplementary properties to respect for signature validation. Depending on the availability of such a signature policy, the file structure to generate shall be:

XAdES-EPES if an explicit signature policy has been defined by the regulator interested in using this standard;

XAdES-BES if no signature policy has been defined by the regulator for use with this standard.

The digital signature for containers will be "SignatureEnveloping", i.e. the output will be an XML file containing as well the signature as the original file. A ds:object element shall contain the Base64 encoding of the file to be signed (if multiple compressed files are needed in the same signature, multiple ds:object elements may be generated). Attributes MimeType, ID, and Encoding shall be included in the ds:object element. ID should be used to store the file-name to enable regeneration of original filename.

Selected signature algorithm for this standard is RSA with SHA-512 as a hash function. The length of the RSA modulus should be at least 2048 , a lower value is disallowed (NIST SP 800-131A [20]). Details on RSA can be found in RFC 3447 [28].

The hash function is SHA-512 as specified in FIPS PUB 180-4 [11]. SHA-512 provides a security strength of 256 bits (NIST SP 800-57 part1 [19]).

[edit]

6.2.7 File name changes upon signature

As the table 2 shows, when a signature is applied to a file that has a reserved extended suffix (or, if there is none, a standard suffix), this reserved extended suffix (or, if there is none, a standard suffix) shall change into .signed.xml.

Similarly, when a signature is applied to a file that has no suffix, the reserved extended suffix .signed.xml shall be added to the filename.

Table 2— Signed file name examples

File to sign	Name of the signed file	Filename inside the XML signature file
Lol	Lol.signed.xml	Same as «File to sign»
Lol.pdf	Lol.signed.xml	Same as «File to sign»
Lol.zip	Lol.signed.xml	Same as «File to sign»
Lol.signed.xml	Lol.signed.xml	Same as «File to sign»
Lol.encrypted.xml	Lol.signed.xml	Same as «File to sign»

[edit]

6.2.8 Validating and extracting a signed file

This operation is the inverse operation of “Signing a file”.

The filename of the extracted file shall become the filename inside the XML signature file.

[edit]

6.3 Creating a submission container

In accordance with the requests from EBA and EIOPA, two main characteristics should be given for the Header that is included in every submission container:

there should be a basic header, which should be small and easy to use;

the basic header should be extensible with fields required by the receiver.

These requirements implied a structure of the Header as described in the present chapter.

[edit]

6.3.1 Header schema structure

The structure of a header as described in this CWA is that of an ExtendedHeader that is to be defined as illustrated in Figure 5. The ExtendedHeader structure shall import the BasicHeader structure and optionally may import other modules like the RegisteredOrganisationVocabulary (continuative work of the « Core Vocabularies » of the EC’s Interoperability Solutions for public Administrations programme) and/or other modules (to be developed in the future).

Figure 5— Extended Header structure importing the BasicHeader structure that optionally imports the RegisteredOrganisationVocabulary (continuative work of the «Core Vocabularies», EC’s Interoperability Solutions for Administrations) and/or other modules (to be developed in the future)

The table 3 describes the structure of such a header.

Table 3— Characteristics of the XML schemas

Header component	Characteristics
BasicHeader	This header structure is the «smallest possible» header structure. It consists only of an identifier of the report (set) as well as of the list of data files composing the submitted report (set). This schema shall be imported into any ExtendedHeader.
ExtendedHeader	This header is an adequate header structure that is to be defined by a receiver (that wants to make use of the present CWA) as the header structure to be used by all senders. As an alternative, if no specific requirements regarding header elements exist, one of the pre-defined standard headers defined in the next chapter may be used.
RegisteredOrganizationVocabulary (RegOrg)	On 28th May 2013 the Core Business Vocabulary (EC’s Interoperability Solutions for Administrations programme) has been formally published on the W3C standards track as a First Public Working Draft. It has been revised and renamed into Registered Organization Vocabulary [24]. The integration of the RegisteredOrganizationVocabulary into the ExtendedHeader is optional, but it should be imported if the usage of any fields defined in the RegisteredOrganizationVocabulary are required in the ExtendedHeader

Every receiver may thus define an ExtendedHeader structure in accordance with the local needs, giving it an adequate namespace.

[edit]

6.3.2 Predefined standard use-cases of ExtendedHeader schema

The following use-cases, presented in table 4, for creating an ExtendedHeader are explicitly defined by the present CWA and may be used «as is».

Table 4— 6.3.2 Predefined standard use-cases for extended headers

ExtendedHeader - pre-defined use-case	Characteristics
BasicHeaderOnly	This header imports the BasicHeader «as is», makes no extensions for it and does not import the RegisteredOrganizationVocabulary as it doesn't use any of its fields. Namespace: http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly XSD URL: http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xsd XML sample instance URL: http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xml
StandardHeaderWithRegOrg	This header structure reflects the survey made within the Eurofiling BestPractices [25]. All fields related to «Transport» issues have been removed as these are out of scope of this CWA. Namespace: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader With RegOrg XSD URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader With RegOrg.xsd XML sample instance URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader With RegOrg.xml
StandardHeaderWithoutRegOrg	This header structure is (with regards to its function and its content) equivalent to the previous “StandardHeaderWithRegOrg”, but it does not import RegOrg and creates the missing fields as equivalent simple XML fields. Namespace: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader Without RegOrg XSD URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader Without RegOrg.xsd XML sample instance URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader Without RegOrg.xml

[edit]

6.3.3 Creating a specific ExtendedHeader schema

The guidelines for the creation of a specific ExtendedHeader schema are given in Annex G.

[edit]

6.3.4 Creating a header file

The creation of a header file consists of the actions:

assembling the data files;

creation of the header file according to the ExtendedHeader XML schema chosen (as defined by the receiver), the BasicHeader part of the ExtendedHeader listing the assembled data files

[edit]

6.4 Creating a response container

The creation of a response container consists of the actions presented in the following paragraphs.

[edit]

6.4.1 Creating a container feedback file

The creation of a container feedback file should take place in accordance with the documentation of the ContainerFeedback schema in Annex D.

[edit]

6.4.2 Creating Instance feedback (Validation, usually only for XBRL)

The creation of an instance feedback file should take place in accordance with the documentation of the InstanceFeedback schema in Annex E.

[edit]

7 Exchange model

This chapter will introduce the exchange model to be used among a sender and a receiver. The receiver should emit instructions on how to use the present CWA for the given exchange of information between a sender and the receiver.

The exchange of information composes of the phases presented in the following paragraphs.

[edit]

7.1 Phase 1: the sender creates a submission container, applies all security mechanisms required and transmits it to the receiver

The sender makes use of the adequate transport mechanism to submit the container with the data instances.

[edit]

7.2 Phase 2: the receiver processes the security layer(s) on the container and all the files within

The receiver removes all encryption layers and verifies all signatures as indicated by the reserved extended suffixes on the container and the files there-in.

Figure 6— Illustration of the security removal at container level (in this example two signatures and one encryption have been applied) as well as on all the files within the container

The container should be reviewed to make sure it has the correct structure (does the header file validate correctly, are all the files announced in the header effectively part of the container, etc.).

[edit]

7.3 Phase 3: receiver generates a positive / negative acknowledgement for the reception of the submission container

As a result of the processing in the preceding phase, it is now identified if the container could be correctly received or if it was invalid (container or files within not decryptable, signature(s) invalid, entity not known or not authenticable, decompression failed, etc.). A container feedback file should be generated that either confirms the validity of all reception steps (like security removal and supplementary checks) and results in a positive acknowledge, or that lists (in the opposite case) the errors that occurred (negative acknowledgement).

The acknowledgement will be included into the response container in phase 5

[edit]

7.4 Phase 4: the receiver processes the contents of the container

In case of a positive acknowledgement, the data files submitted shall go through the following stages of processing.

The standard suffixes of the files shall be used to identify those files that can be further processed. As an example, XBRL or XML instances should now be validated by their respective validator (while unstructured data files like word processor files could be made available to analysts for manual review).

As a result of this phase, the adequate (alternative) instance feedback files for the XBRL instances in the original submission container should have been generated.

[edit]

7.5 Phase 5 (optional): the receiver returns the validation result of the data files in the response container

All feedback files as well as the container feedback file may be added to a response container that should be returned by the receiver to the sender to provide the result of the content processing of the related submission container.

Unlike the submission container, a response container shall not include header information.

The receiver may alternatively make available the result of the processing in a way considered more appropriate (e.g. returning links to external systems etc.).

The exchange model can thus be presented as in figure 7.

Figure 7— Illustration of the exchange model

AnnexA(normative)Items that shall be defined in the instructions

A.1Introduction

These are some questions to which any institution willing to use the CWA has to give clear answers to in its instructions.

A.2Container structure

Table A.1— Common questions and instructions for the container

Item	Typical instruction	Explanations
Use of CWA encryption layer?	YES, one single encryption to be applied on a signed file (container)	should be Yes, may be No in environments using a secure transport
Use of CWA signature layer?	YES, one single signature to be applied on a zip compressed file (container)	should be Yes, may be No in environments using a secure transport
Use of the «Instancefeedback» schema» to inform of the result of the processing of a data instance?	« Use instance feedback to report errors » or « Use Excel files in folder XBRL_Errorsinstead »	«None» or «InstanceFeedback schema» or «explanation of an alternative mechanism (e.g. provision of links to an external system of graphical representations of error conditions)»

A.3Header

These are required precisions on how some tags of the header schema shall be used. These instructions are only required if a standard header schema is used; otherwise the according fields could simply be omitted in a customised header extension.

Table A.2— Common instructions for the header

Item	Typical instruction	Explanations
<ReportReferenceID>	e.g. «Finrep full quarterly consolidated reporting for investment companies» or a code for that reporting	The list of the different reporting identifications covered by the instructions
<AuditStatus>	e.g. «The values «audited» and «not audited» shall be used exclusively»	Either confirm the use of the flag or specify that the value « undetermined » or « in datainstances » is applicable
<ConsolidationStatus>	See <AuditStatus>	See <AuditStatus>
<CapitalCurrency>	Capital Currency shall be used and be EUR mandatorily	This tag may be used for validation purposes in some countries imposing the exclusive use of a single currency
<UpdateStatus>	e.g. «Only use value «Replace»»	If no «update» mechanism is provided, the value «Replace» should be enforced by the instructions, indicating that all prior reports of the same type will be deleted and replaced by the content of the new container In the other case, allowing the values «Update» (keep any values from a prior reporting excepted for those in the data instances of the present container which will be replaced by their new values) and «Delete» (delete any values from prior reports that are in the data instances of the present container) can make sense
<TestFlag>	«All data are production data, do not use <TestFlag>true</TestFlag>»	This tag may be used to flag data instances sent to the receiver’s production infrastructure as test data (to be validated, but not injected into the receiver’s databases)

A.4Lists of codes accepted

A table like table A.3 (defining identifiers accepted both for legal entities and for persons) should explain which codes are allowed.

Table A.3—Identifiers accepted both for legal entities and for persons

Code type	Issuer	Country	URI
<IdentifierType>	<IdentifierIssuingAuthority>	<IssuingAuthorityCountry>	<IssuingAuthorityURI>

AnnexB(informative)Supplementary items that may be useful in the instructions

Table B.1— Supplementary items and explanations

Item	Explanations
Name of the use of the CWA	Examples: «Prudential supervisory reporting», «XBRL reporting only», «NSA to EBA transmissions»
Applicable File naming conventions (if any)	E.g. a link to an external document describing all applicable file naming conventions applicable to containers, folders, data instances, unstructured files
Containers for other regulators to include	Description and destination authorities for the containers etc.
Supplementary rules	Example of a supplementary rule: a certain container inside the container shall contain the same instances (reported instances for second level reporting are the same as for first level reporting)

AnnexC(informative)Explanations on header schema

The present specification allows extensible headers which makes it difficult to choose a certain header to document. For illustration purposes, the present chapter documents the standard extensible header "StandardHeaderWithoutRegOrg".

The XML Schema StandardHeaderWithoutRegOrg is depicted in figures C.1 to C.4.

Figure C.1— StandardHeaderWithoutRegOrg (TechnicalSender, ContentProducer and ReportingEntity)

Figure C.2— ReportingProcessRoleType

Figure C.3— PersonResponsibleReportingType

Figure C.4— StandardHeaderWithoutRegOrg (ReportingDataContext, ReportOperationalContext and File)

Table C.1— StandardHeaderWithoutRegOrg explanations

Item	Type	Explanation
ReportDataContext	ReportDataContextType
File	FileType
TechnicalSender	ReportingProcessRoleType	(Potential) sub-contractor in charge of physically sending the data in respect of the present CWA (aware of containers, encryption, etc.).
ContentProducer	ReportingProcessRoleType	(Potential) sub-contractor in charge of the production of the content of the reporting and responsible for the accuracy of the content.
ReportingEntity	ReportingProcessRoleType	Entity submitted to financial reporting and legally responsible for it (in many cases it uses internal resources to play the role of Content Producer and Technical Sender too). An authority may also play the role of a reporting entity, e.g. when a national authority is providing data to a subsequent European authority as level-2 reporting.
ReportDataContext	ReportDataContextType	Sequence of information that defines the general context of the data in the report i.e. general, common properties applicable to all the reporting files
ReportOperationalContext	ReportOperationalContextType	Sequence of information that defines properties related to the process of submitting data
FileType	sequence
FilePath	relative URI	This field gives the relative Uniform Resource Identifier (URI) to a file in the container (starting from top-level).
TypeOfFile	text enumeration	Potential supplementary file type characterizing each individual file in the container to allow supplementary dedicated processing based of the file type. Possible values: "DataInstance", "OtherFile", "SignedAndEncryptedSubcontainer", "SignedSubcontainer", "CompressedOnlySubcontainer"
Filename	text	Explicit name of the file
Destinee	identifier	Potential destinee for one of the files in the container, e.g. a container inside a container
ReportingProcessRoleType	sequence
LegalIdentifier	LegalIdentifierType	Sequence of properties identifying the reporting entity
MainContactResponsibleReporting	PersonResponsibleReportingType	Human contact for the case of problems with a certain step of the reporting generation and submission process
BackUpContactResponsibleReporting	PersonResponsibleReportingType	Backup person for BackUpContactResponsibleReporting
LegalIdentifierType	sequence
Identifier	identifier	Code identifying the reporting entity
IdentifierType	code	Type of code identifying the reporting entity
IdentifierIssuingAuthority	IdentifierIssuingAuthorityType	Sequence of information that describes the authority having issued the certificate
IssueDate	date	Issuing date of the code
IdentifierIssuingAuthorityType	sequence
IssuingAuthority	text	Name / Identifier of the issuing authority
IssuingAuthorityCountry	code	ISO country code of the issuing authority
IssuingAuthorityURI	URI	URI identifying the issuing authority
PersonResponsibleReportingType	sequence
PersonResponsibleReporting	TypeOfPersonResponsibleReporting	Sequence of information describing the person that is in charge of the reporting
PersonResponsibleReportingIdentifier	LegalIdentifierType	Sequence of information describing the Identifier of the person that is in charge of the reporting
PersonResponsibleReportingContactData	PersonContactDataType	Sequence of information describing means to contact the person that is in charge of the reporting
TypeOfPersonResponsibleReporting	sequence
FamilyName	text	person family name
GivenName	text	person given name
BirthName	text	person birth name
PersonContactDataType	choice element	Choices available: Telephone, Fax, E-Mail
ReportDataContextType	sequence
ReportReferenceID	identifier	This code identifies the data submitted in the container. It can be a set of reports (e.g. code “FINREP_COREP” for Finrep & Corep), a single report (e.g. “QUARTERLY_CONSOLIDATED_FINREP” for the standard Finrep) or a subset of reports (e.g. “TABLE1&2 FINREP” for only the according subset of Finrep)
ReferenceReportingPeriod	date	Main reporting period (end date of the period)
AuditStatus	text enumeration	Data extracted from general ledger ("not audited") or having undergone an external audit already ("audited")
ConsolidationStatus	text enumeration	Consolidated or solo in different flavours. Possible values: "solo head office excluding branches", "solo head office including branches", "solo branch only", "sub-consolidated", "consolidated"
CapitalCurrency	code	Main currency
ReportOperationalContextType	sequence
UpdateStatus	text enumeration	Flag characterizing if this is an entirely new report ("Replace") or if it is an update of a previously sent report ("Update") or if the prior report should be deleted ("Delete")
InstanceCreationDateTime	date	Creation date & time of the instance
TestFlag	Boolean	Flag to characterize if it is actual production data (false, default value) or only test data (true)
TransferSoftwareNameVersion	text	Software or system used to submit the report
ReportingSoftwareNameVersion	text	Software or system used to generate the report
RemarkAboutReport	text	Remark on the report

AnnexD(informative)Documentation of the container feedback schema

The present chapter describes the XML Schema ContainerFeedback that is depicted in figure D.1.

DA.

Figure D.1— Visualisation of the container feedback schema (ContainerFeedback.xsd)

In table D.1, there is supplementary information on the schema describing:

type: the type of the element in the schema and

description and usage: a narrative explanation for the elements and a recommendation for the scenario in which the element should be used.

Table D.1— Container feedback schema element listing and description

Element name	Type	Description and usage
ContainerFeedback		The root element, validation consists of separate validation sections
ContainerName	text	The name of the container that has been received by an authority and for which the container feedback document acknowledging successful / unsuccessful reception
ContainerFeedbackCreationDateTime	dateTime	The creation date and time of the container feedback document
ContainerHashValue	ContainerHashValueType	Hash calculated according to the present specification for the container received in order to assure that both sides make reference to exactly the same file and can verify the file integrity.
ContainerSuccessFlag	boolean	Overall view if the container structure as a whole was correct true = container ok false = errors found in at least 1 phase of the reception of the container
ValidationPhase	ValidationPhase	Usage: only when ContainerSuccessFlag is set "false".
ValidationPhase	sequence
ValidationPhaseType	text	The type of validation phase for instance "decryption" or "decompression".
PhaseSuccessFlag	boolean	true = validation phase successful false = errors found in the validation phase
ValidationErrors	ValidationErrorsType	Lists all the errors found in the validation. Usage: only when PhaseSuccessFlag is set to "false".
ValidationErrorsType	sequence
ValidationError	ErrorType	The error found
ErrorType	sequence	a generic error type that can be used in all validation sections to define errors found
ErrorCode	code	an error code that can be used to identify the error found
ErrorLocation	text	an expression that can be used to locate the error in the instance document, can be an Xpath sentence or line number
ErrorDescription	text	a description of the error found
ErrorSeverity	ErrorSeverityType	The severity of the error
ErrorSeverityType	text enumeration	Possible values: "Info", "Warning", "Error" and "Fatal"
ValidationPhaseType	text	A description of the validation phase for instance decryption, signature verification, authentication, …
ContainerHashValueType	hash/digest	Has an attribute HashAlgorithm with a fixed value "http://www.w3.org/2001/04/xmlenc#sha256 "

AnnexE(informative)Documentation of the instance feedback schema

The present chapter describes the XML Schema InstanceFeedback that is depicted in figure E.1.

Figure E.1— Visualisation of the instance feedback schema (InstanceFeedback.xsd)

In table E.1, there is supplementary information on the schema describing:

type: the type of the element in the schema and

description and usage: a narrative explanation for the elements and a recommendation for the scenario in which the element should be used.

Table E.1— Instance feedback schema element listing and description

Element name	Type	Description and usage
InstanceFeedback		The root element, validation consists of separate validation sections
InstanceRelativeURI	relative URI	shall contain the path to the data instance from the top-level of the submission package in relative URI notation
InstanceHashValue	InstanceHashValueType	Reference to the calculated hash value of the instance document being validated.
InstanceSuccessFlag	boolean	Overall view of all instance validations true = all validations successful false = errors found in at least 1 validation phase
ValidationPhase	ValidationPhase	Any validation: XML, XBRL 2.1 Conformance Suite 1.0 validation, taxonomy validation. Usage: Only when InstanceSuccessFlag is set "false".
ValidationPhase	sequence
ValidationPhaseType	string	The type of validation phase
PhaseSuccessFlag	boolean	true = validation phase successful false = errors found in the validation phase
ValidationErrors	ValidationErrorsType	Lists all the errors found in the validation. Usage: only when PhaseSuccessFlag is set to "false".
ValidationErrorsType	sequence
ValidationError	ErrorType	The error found
ErrorType	sequence	a generic error type that can be used in all validation sections to define errors found
ErrorCode	code	an error code that can be used to identify the error found
ErrorLocation	text	an expression that can be used to locate the error in the instance document, can be an Xpath sentence or line number
ErrorDescription	text	a description of the error found
ErrorSeverity	ErrorSeverityType	The severity of the error
ErrorSeverityType	text enumeration	Possible values: "Info", "Warning", "Error" and "Fatal"
InstanceHashValueType	hash value	Has an attribute HashAlgorithm with a fixed value "http://www.w3.org/2001/04/xmlenc#sha256 "

AnnexF(informative)Guidelines on how to extend the basic header

Step 1

Create your own XSD file, replace the default namespace (http://www.eurofiling.info/eu/fr/esrs/Header/ExtendedBasicHeader) by your own namespace and import the basic header:

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns="http://www.eurofiling.info/eu/fr/esrs/Header/ExtendedBasicHeader" xmlns:bh="http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeader" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.eurofiling.info/eu/fr/esrs/Header/ExtendedBasicHeader" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1">

<xsd:import namespace="http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeader" schemaLocation="http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeader.xsd"/>

Step 2

Create our own elements as an extension of the basic header, for example:

<xsd:element name="MyExtendedHeader" type="MyExtendedHeaderType"/> <xsd:complexType name="MyExtendedHeaderType"> <xsd:sequence>  <xsd:element name="MyNewElement" type="xsd:string"/>  <xsd:element ref="bh:BasicHeader" maxOccurs="1"/> </xsd:sequence> </xsd:complexType>

The basic header elements should be used at the end of the extended schema, and they should only be used once.

AnnexG(informative)Use cases for this CWA

G.1 Reporting entity to supervisor (1st level)

In this use-case, the sender is the reporting entity, the receiver is the supervisor.

The security mechanisms applied to submission containers should be the same (and have the same order of application) as those applied to response containers.

G.2 Reporting entity to National Supervision Authority (NSA) to European Supervision Authority (ESA) (1st and 2nd level)

In this case, the exchange model is used twice in a row with:

1) exchange 1: the sender is the reporting entity, the receiver is the NSA;

2) exchange 2: the sender is the NSA, the receiver is the ESA.

G.2.1 2-layer submission process with forwarding of information

The NSA requires not only data for its own purpose, but also data in a separate container inside the original container in order to be able to forward this data to a subsequent regulator like an ESA. As a consequence, the ESA needs to know all the public key / certificate of the reporting entities (from which data are sent) as communication partners. Figure H.1 shows a 2-layer submission using containers to forward data to subsequent authorities as well as feedback to the respective sender.

FigureHA.H.1— 2-layer submission using containers in containers to forward data to subsequent authorities and as well as feedback to the respective sender

G.2.2 2-layer submission process with repackaging or regeneration

After finishing the submission process from the reporting entity to the NSA, a separate, entirely independent submission process is started using either the original data from the entity (repackaging) or entirely new data prepared by the NSA (open regeneration). The ESA has only one communication partner, the NSA, of which it needs to know the public key / certificate. These approaches are illustrated in figures H.2 and H.3.

Figure H.2— 2-layer submission repackaging data into new containers to send them to subsequent authorities

Figure H.3— 2-layer submission, completely new generation of data from NSA systems for subsequent authorities

Bibliography

[1] ETSI Technical Report 102 038 v1.1.1. Electronic Signatures and Infrastructures; XML format for signature policies. European Telecommunications Standards Institute. April 2004. http://docbox.etsi.org/EC_Files/EC_Files/tr_102038v010101p.pdf

[2] ETSI-XAdES, ETSI Technical Specification 101 903 V1.4.1. XML Advanced Electronic Signatures (XAdES). June 2009. European Telecommunications Standards Institute. http://uri.etsi.org/01903/v1.4.1/

[3] ETSI Technical Specification 102 176-1 v2.0.0, Electronic Signatures and Infrastructures; Algorithms and Parameters for Secure Electronic Signatures; Part 1 Hash functions and asymmetric algorithms.19 November 2007. European Telecommunications Standards Institute. http://www.etsi.org/deliver/etsi_ts/102100_102199/10217601/02.00.00_60/ts_10217601v020000p.pdf

[4] CWA 14170, Security requirements for signature creation applications. May 2004. European Committee for Standardization.

[5] CWA 14167-1, Security requirements for trustworthy systems managing certificates for electronic signatures — Part 1: System Security Requirements. June 2003. European Committee for Standardization.

[6] CWA 14167-2, Security requirements for trustworthy systems managing certificates for electronic signatures — Part 2: cryptographic module for CSP signing operations with backup — Protection Profile - MCSO-PP. May 2004. European Committee for Standardization.

[7] CWA 15579, E-invoices and digital signatures. July 2006. European Committee for Standardization.

[8] Directive 1999/93/EC, Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999. Chapter 13 Volume 038 P. 50 – 58. http://eur-lex.europa.eu/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoc&numdoc=31999L0093&model=guichett.

[9] 2011/130/EU, Commission Decision 2011/130/EU of 25February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.

[10] FIPS PUB 186-3, Digital Signature Standard. National Institute of Standards and Technologies. June 2009. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf

[11] FIPS PUB 180-4, Secure Hash Standards (SHS). March 2012. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

[12] NIST SP 800-107 Revision1 Recommendation for applications using approved hash algorithms. Quynh Dang. August 2012. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf.

[13] XMLDSIG-CORE. XML Signature Syntax and Processing (Second Edition). W3C Recommendation 10 June 2008. http://www.w3.org/TR/xmldsig-core/

[14] XMLENCR-CORE. XML Encryption Syntax and Processing. W3C Recommendation 10 December 2002. http://www.w3.org/TR/xmlenc-core/.

[15] XML Encryption Requirements. W3C Note 4 March 2002. http://www.w3.org/TR/xml-encryption-req

[16] XMLENCR-CORE1 XML Encryption Syntax and Processing Version 1.1. W3C Recommendation. 11 April 2013. http://www.w3.org/TR/xmlenc-core1/.

[17] Extensible Business Reporting Language (XBRL) 2.1 RECOMMENDATION - 2003-12-31. XBRL International (XII). http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31.doc

[18] ZIP File Format Specification Version: 6.3.3, September 1, 2012, PKWARE Inc. http://www.pkware.com/documents/casestudies/APPNOTE.TXT

[19] NIST SP 800-57 part1, Recommendation for Key Management – Part 1: General (Revision 3). Authors: Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid. July 2012. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf.

[20] NIST SP 800 131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. Authors: Elaine Barker and Allen Roginsky. January 2011. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf.

[21] NIST SP 800-56B, Recommendation for Pair-Wise, Key Establishment Schemes Using Integer Factorization Cryptography. Authors: Elaine Barker, Lily Chen, Andrew Regenscheid, and Miles Smid. August 2009. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-56B/sp800-56B.pdf.

[22] RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. February 2003. http://www.ietf.org/rfc/rfc3447.txt.

[23] NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation. Methods and Techniques. Morris Dworkin. 2001. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.

[24] RegOrg Registered Organization Vocabulary. W3C Working Group Note 01 August 2013. http://www.w3.org/TR/vocab-regorg/. This is a continuative work of the EC’s ISA Core Vocabularies, May 2012. https://joinup.ec.europa.eu/asset/core_business/release/100

[25] BestPractices, Best Practices on Common European Reporting Structures. Eurofiling 2013. http://www.wikixbrl.info/index.php?title=Best_Practices_on_Common_European_Reporting_Structures, http://www.xbrlwiki.info/images/c/c0/Eurofiling_header_questionnaire-results.xls.

[26] CEN, the European Committee for Standardization (CEN), Business Plan of the CEN Workshop on XBRL, Improving transparency in financial and business reporting, 30 May 2012, http://cen.eurofiling.info/wp-content/upLoads/data/BusinessPlanCENWorkshoponXBRL20120530.pdf.

[27] NIST SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. Morris Dworkin. 2001. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

[28] RFC 3447. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography. Specifications Version 2.1. J. Jonsson and B. Kaliski. RSA Laboratories. The Internet Society. http://www.ietf.org/rfc/rfc3447.txt

[29] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures

[30] Commission Decision 2011/130/EU of 25February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market

[31] Federal Information Processing Standards Publication 186-3: Digital Signature Standard (National Institute of Standards and Technologies, U.S. Department of Commerce)

[32] Federal Information Processing Standards Publication 180-4: Secure Hash Standards (National Institute of Standards and Technologies, U.S. Department of Commerce)

[33] National Institute of Standards and Technologies, Special Publication 800-107, Recommendation for applications using approved hash algorithms

[34] W3C Recommendation XML Signature Syntax and Processing

[35] W3C Recommendation XML Encryption Syntax and Processing

[36] XBRL International (XII), Extensible Business Reporting Language (XBRL) 2.1, Recommendation – 2003-12-31

[37] PKWARE Inc., APPnotE.TXT - .ZIP File Format Specification

Retrieved from "http://xbrlwiki.info/index.php?title=European_Metadata_Container"

-<span style="font-size:18pt">'''CEN Workshop Agreement'''</span>
+'''CEN WS XBRL Experts''': Elina Koskentalo (XBRL Finland), Eduardo González (Gonblan)
-'''Status''': Working Group Working Draft
+; Foreword
-'''Editing rules'''
+This document has been prepared by CEN/WS XBRL, the secretariat of which is held by NEN.
-Editorial comments should be highlighted as follows:
+This CWA is one of a series of related deliverables. The other deliverables are:
-<span style="background-color:yellow">A comment</span>
-Text or rules in discussion (white):
+CWA XBRL 001 consists of the following parts, under the general title ''Improving transparency in financial and business reporting — Harmonisation topics'':
-<span style="background-color:white">Some text</span>
-Text or rules already aligned (green):
+* ''Part 1: European data point methodology for supervisory reporting.''
-<span style="background-color:#BCF5A9">Some text</span>
-Text or rules to be deleted (red):
+* ''Part 2: Guidelines for data point modelling''
-<span style="background-color:#F5A9A9">Some text</span>
-Text to be delivered (blue):
+* ''Part 3: European XBRL Taxonomy Architecture''
-<span style="background-color:#A9D0F5">Some text</span>
-Foreword
+* ''Part 4: European Filing Rules''
-This document is a working document.
+* ''Part 5: Mapping between DPM and MDM''
-This document is a first draft of the upcoming CWA2 container specification.
+CWA XBRL 003-1 ''Improving transparency in financial and business reporting — Standard regulatory roll-out package for better adoption — Part 1: XBRL Supervisory Roll-out Guide''
-Introduction
+CWA XBRL 003-2 ''Improving transparency in financial and business reporting — Standard regulatory roll-out package for better adoption — Part 2: XBRL Handbook for Declarers''
-CWA2 standardizes two main areas:
-) The way to submit XBRL instances to a regulator, i.e. a container used for the submission of XBRL instances with standardized
+; Introduction
-*  Encryption;
+The present document specifies a standard security envelope and an approach to integrate metadata usable for the European supervision authorities in order to receive reporting data in a standardised way. This standard has been elaborated over the years 2012 and 2013 and has been reviewed in a public consultation in the third quarter of 2013.
-*  Digital signature;
-*  Compression;
+= 1 Scope =
-) The way to transmit the supplementary metadata that determine the context of the XBRL instances, e.g.
+<nowiki>The purpose of this CWA is to propose a standard for submitting data instances to financial regulators in accordance with the chapter describing this CWA in the business plan [26]:</nowiki>
-*  the sender of the document;
+"''"Metadata container" to wrap a submitted XBRL instance document and compliance test. Provide a standard Metadata Container to enable XBRL sourcing, with in addition necessary compliance tools to enable all stakeholders to test and ensure full adherence to the technical standards. ''
-*  contact details;
+''Metadata such as sender of the document, contact details, date and time of submission, version, digital signature, etc.. are not included in the taxonomies, because they really don't belong to the data model. On the other hand, and often for legal reasons, these data are required by national regulators. As a consequence, a variety of national protocols has been engineered, which complicates the life of cross-border institutions, but also prohibit the possibility to create a harmonized European collection system. Metadata are needed as well for financial reporting as for company legal and economical data. For the digital signature, existing solutions from the Business Registers, who have a deep expertise of the topic, may be generalized. In order to ensure compliance with the protocol, this project will deliver online tools for all stakeholders to use and to test compliance with the complete set (metadata container and XBRL instance document. ''
-*  date and time of submission;
+''This CWA will provide standard protocols and mechanisms for digital signature, administrative data such as identification of submitter, feedback parameters, versioning of subsequent submissions and encryption, as well as online collaborative tools to ensure compliance."''
-*  …
+This document specifies:
-=Scope=
+* a '''submission container''' structure to enable financial institutions to submit their regulatory reporting to the respective regulators in a standardised way;
-This document specifies a container structure to enable financial institutions to submit their regulatory XBRL reporting to the respective regulators in a standardized way. The container structure allows the packaging and securitization of XBRL data in a uniform way and should lead to a greater transparency and interoperability between the declaring entities and the National and European Supervisory Authorities. The main targeted authorities are the EBA (European Banking Authority) and EIOPA (European Insurance and Occupational Pensions Authority) as well as their related national supervising agencies, but the standard may also be used by other regulators.
+* a '''metadata''' information structure (called «'''Header'''») that is part of the submission container structure;
-The container will be a standardized structure that can contain multiple XBRL instances. It will support compression, encryption and electronic signature; they all will be on the outer container, not on the individual XBRL instance inside the container.
+* an adequate negative (or positive) acknowledgement to be returned by the regulator to indicate if the submission container was well received by the regulator (or not);
-The container definition will not define any transport protocol; submission of a container may thus be freely combined with any type of transport (submission via e-mail, (s)ftp, web portal, web services, …) in accordance with the local requirements of the data taxonomy owner.
+* a '''response container '''structure to allow the regulator to return content-related error messages for the data instances in case errors occurred during any validation phase.
-The container will not define any file naming conventions, it will only define extensions: XBRL instances will have the .xbrl extension (and not .xml). The signature certificate will be integrated into the container for automatic processing on the authority’s side
+The main targeted authorities are the EBA (European Banking Authority) and EIOPA (European Insurance and Occupational Pensions Authority) as well as their related national supervision agencies, but the standard may also be used by other regulators. All container structures defined allow the packaging and securisation of data in a uniform way, which should lead to a greater transparency and interoperability between the declaring entities and the national and the European supervisory authorities.
-The deliverables foreseen are:
+In the course of the specification process, supplementary requirements were added by stakeholders or authorities concerned, among which:
-) specification of the submission container to an authority and the feedback container from an authority (NORMATIVE);
+* The scope of the data instances to be supported has been extended from pure XBRL instances to any type of structured data instances, including XML, CSV, etc.;
-) file acknowledge schema for submission containers (NORMATIVE);
+* The possibility of a 2-layer (or even multi-layer) submission process: some data instances are to be processed by the receiving authority itself (e.g. a national authority), others may be forwarded to a subsequent authority (e.g. a European one);
-This schema will give all the statuses (positive or negative) indicating if a submission container was well received or if its processing resulted in errors.
+* The possibility of using the structures of the present CWA in a secure environment i.e. an environment that has its own signature and/or encryption facilities;
-Error conditions will include:
+* The possibility of adding non-standard metadata if required (extensibility of the metadata header).
-*  electronic signature not valid;
+An important development approach for this CWA is to be flexible enough to support many different uses in different environments. For this reason some aspects (e.g. types of identifiers for financial institutions) could not be fixed by this standard and they shall be determined for every specific use of this standard via complementary instructions.
-*  certificate used for signature not valid anymore;
+The present specification only defines the structures for the container itself, it does not define any transport aspects; the submission of a container may thus be freely combined with any type of transport protocol (submission via e-mail, (s)ftp, web portal, web services, …) in accordance with the local requirements.
-*  electronic signature valid, but authentication failed (certificate not accepted for the reporting);
-*  decryption failure;
+= 2 Normative references =
-*  decompression failure;
+The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
-*  local file naming convention not respected;
+ETSI Technical Report 102 038 v1.1.1, ''Electronic Signatures and Infrastructures; XML format for signature policies''
-*  …
-) Reply schema for an XBRL instance in a container (NORMATIVE);
+ETSI Technical Specification 101 903 v1.4.1, ''XML Advanced Electronic Signatures (XAdES)''
-This schema will give be used to give the processing result of each XBRL instance in the original submission container, including the status of different phases of the validation (positive or negative) as well as potentially a list of error messages indicating why the validation of an instance failed.
-This schema will contain:
+ETSI Technical Specification 102 176-1 v2.1.1, ''Electronic Signatures and Infrastructures; Algorithms and Parameters for Secure Electronic Signatures; Part 1 Hash functions and asymmetric algorithms''
-*  reference to the XBRL instance referred to (filename, receiving datetime, hash, …);
-*  result of the processing (validation succeeded, validation failed, …);
+= 3 Terms and definitions =
-*  list of validation error messages;
+For the purposes of this document, the following terms and definitions apply.
-*  …
+.1
-) Compliance tools (NON-NORMATIVE) to be provided will include a free testing environment for the preparers and authorities to ensure full compliance of their containers with the present specification.
+reporting entity
-=Normative referentes=
+entity submitted to financial reporting and legally responsible for it
-''The following referenced documents are indispensable for the application 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.''
+<nowiki>Note 1 to entry: (in many cases it uses internal resources to play the role of Content Producer and Technical Sender too). Also known as 'Declarer', 'Sender', '<ReportingEntity>'. </nowiki>
-European Telecommunications Standards Institute (ETSI). Technical Report 102 038 v1.1.1; Electronic Signatures and Infrastructures; XML format for signature policies.
+Note 2 to entry: An authority may also play the role of a reporting entity, e.g. when a national authority is providing data to a subsequent European authority as level-2 reporting.
-European Telecommunications Standards Institute (ETSI). Technical Specification 101 903 v1.4.1; XML Advanced Electronic Signatures (XAdES).
+.2
-European Telecommunications Standards Institute (ETSI). Technical Specification 102 176-1 v2.1.1;
+technical sender
-Electronic Signatures and Infrastructures; Algorithms and Parameters for Secure Electronic Signatures; Part 1
+(potential) sub-contractor in charge of physically sending the data in respect of the present CWA (aware of containers, encryption, etc.)
-Hash functions and asymmetric algorithms.
+<nowiki>Note 1 to entry: Also known as '<TechnicalSender>'.</nowiki>
-CEN Workshop Agreement CWA 14170; Security requirements for signature creation applications.
+.3
-CEN Workshop Agreement CWA 14167-1: Security requirements for trustworthy systems managing certificates for electronic signatures — Part 1: System Security Requirements
+content producer
-CEN Workshop Agreement CWA 14167-2: security requirements for trustworthy systems managing certificates for electronic signatures — Part 2: cryptographic module for CSP signing operations — Protection Profile (MCSO-PP)
+(potential) sub-contractor in charge of the production of the content of the reporting and responsible for the accuracy of the content
-CEN Workshop Agreement CWA 15579: E-invoices and digital signatures
+<nowiki>Note 1 to entry: Also known as '<ContentProducer>'.</nowiki>
-Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures
+.4
-Commission Decision 2011/130/EU of 25 February 2011 establishing minimum requirements for the crossborder processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
+receiver
-Federal Information Processing Standards Publication 186-3: Digital Signature Standard (National Institute of Standards and Technologies, U.S. Department of Commerce).
+entity receiving reported data; also known as 'Authority' or 'Regulator' or 'Supervisor’
-Federal Information Processing Standards Publication 180-4: Secure Hash Standards (National Institute of Standards and Technologies, U.S. Department of Commerce).
+.5
-National Institute of Standards and Technologies, Special Publication 800-107, Recommendation for applications using approved hash algorithms.
+security envelope
-W3C Recommendation XML Signature Syntax and Processing.
+XML structures surrounding the .zip file(s) after encryption and / or signature phase in accordance with the present CWA
-W3C Recommendation XML Encryption Syntax and Processing.
+.6
-W3C Note XML Encryption Requirements
+negative acknowledge
-XBRL International (XII), Extensible Business Reporting Language (XBRL) 2.1, Recommendation – 2003-12-31
+<nowiki>information to the sender that the submission container could not be accepted because of error conditions (usually an instance of the « ContainerFeedback » schema with the tag <ContainerValidationFlag> having the value false</nowiki>
-PKWARE Inc., APPNOTE.TXT - .ZIP File Format Specification
+.7
-=Terms and definitions=
+positive acknowledgement
-For the purposes of this document, the following terms and definitions apply.
+<nowiki>information to the sender that the submission container has been accepted for processing of the data instances (usually an instance of the « ContainerFeedback » schema with the tag <ContainerValidationFlag> having the value true</nowiki>
+.8
+instructions
+supplementary information drafted by the receiver on how exactly to use the present CWA for a determined use.
+.9
+certificate
+a standard IETF X.509 digital certificate
+Note 1 to entry: Public key should be RSA (rsaEncryption) with key length at least 2048.
+.10
+header file
+header file that complies with the « Header » schema
+Note 1 to entry: See chapter 4.3.1.
+.11
+container feedback file
+container feedback file that complies with the « ContainerFeedback » schema
+Note 1 to entry: See chapter 4.3.2.
+.12
+instance feedback file
+An instance feedback file that complies with the « InstanceFeedback » schema
+Note 1 to entry: See chapter 4.3.3.
+.13
+alternative instance feedback file
+instance feedback file that is in another format than that of an instance of the « InstanceFeedback » schema
+= 4 Files in containers =
+== 4.1 Introduction ==
+The present chapter describes the files intervening in this standard, starting with simple files and continuing with the composed ones.
+== 4.2 Data files ==
+Data files are files that contain data, whether these data are structured of not. Data files can be any structured files like XBRL or XML instances, but also unstructured files like spread sheets or word processor files. The container controls files described in the next chapter as well as composed files (files that contain other files) are not part of the data files.
+== 4.3 Container control files ==
+The three types of container control files developed within this CWA are described in the following chapters.
+=== 4.3.1 Header file  ===
+A header file is an XML instance of an XML schema built according to the indications of chapter 6.3.3.
+The function of the header file is to describe the global characteristics of the data files in the submission.
+=== 4.3.2 Container feedback files ===
+A container feedback file is an XML instance of the XML schema located at:
+[http://www.eurofiling.info/eu/fr/esrs/ContainerFeedback/ContainerFeedback.xsd http://www.eurofiling.info/eu/fr/esrs/ContainerFeedback/ContainerFeedback.xsd].
+The function of the container feedback file is to confirm to the sender the success (or not) of the submission.
+=== 4.3.3 Instance feedback files ===
+Instance feedback files are XML instances of the XML schema located at:
+[http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback/InstanceFeedback.xsd http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback/InstanceFeedback.xsd].
+Alternative representations of the error conditions of the data files submitted (e.g. documents with links to external systems representing the errors graphically, spread sheets with “red” cells indicating error locations, …) may be added to a response container, either as a complement or as an alternative to the XML instance feedback file. In that case the term alternative instance feedback file will be used.
+== 4.4 ZIP compressed file  ==
+<nowiki>A Zip compressed file is a set of one or more files compressed together (ZIP [18]). </nowiki>
+== 4.5 Secured files ==
+The following chapters describe the files to which security operations have been applied.
+=== 4.5.1 Encrypted file ===
+<nowiki>An encrypted file is a file embedded and encrypted in an XML instance of the XML schema (XMLENCR-CORE [14]).</nowiki>
+=== 4.5.2 Signed file ===
+<nowiki>A signed file is a file embedded and signed in an XML instance of the XML schema (ETSI-XAdES [2]).</nowiki>
+== 4.6 File naming conventions ==
+The present CWA has defined the minimum required file naming conventions as described in the present chapter. The aim was to give the regulators vast degrees of freedom to define for their own purposes a file naming convention that serves best their requirements. So excepted for the reserved names and suffixes described in this chapter, the receiver’s instructions may define adequate file naming conventions for containers, folders, data files etc.
+=== 4.6.1 Reserved file names ===
+==== 4.6.1.1C:\Users\eduardo\AppData\Local\Temp header.xml ====
+The name «header.xml» is exclusively reserved for files of the type «header file».
+=== 4.6.2 Instance feedback file name ===
+The name and location of instance feedback files and other types of alternative instance feedback files should be chosen in such a way that the reconciliation of the feedback file with the corresponding data instance in the submission container is evident.
+=== 4.6.3 Reserved file name suffixes ===
+All files shall have the « usual » file extension applicable in environments without restriction to the length of the extension: « .xbrl » for XBRL instances, « .xml » for XML instances, « .csv » for comma separated files etc.
+=== 4.6.4 Reserved extended suffixes ===
+==== 4.6.4.1 .signed.xml ====
+The file extension «.signed.xml» is exclusively reserved for signed files.
+==== 4.6.4.2 .encrypted.xml ====
+The file extension «.encrypted.xml» is exclusively reserved for encrypted files.
+==== 4.6.4.3 .containerfeedback.xml ====
+The file extension«.containerfeedback.xml » is exclusively reserved for container feedback files complying with the ContainerFeedback schema.
+==== 4.6.4.4 .instancefeedback.xml ====
+The file extension«.instancefeedback.xml » is exclusively reserved for instance feedback files complying with the InstanceFeedback schema.
+= 5 Container =
+A container is a ZIP compressed file that contains a set of data files to be submitted.
+A container may contain any type of files (e.g. other containers).
+Folders may optionally be used in a container to better structure the files.
+Folder conventions are not defined in this document.
+== 5.1 Submission container ==
+[[Image:clip_image002.jpg]]
+;Figure 1— Submission container example 1: Structure of a simple submission container with only one type of reporting in XBRL format and no use of folders
+A submission container is a container that contains 1 header and 0 or more files and that is to transfer reporting data from the sender to the receiver.
+[[Image:clip_image004.jpg]]
+;Figure 2— Submission container example 2: Advanced structure of a submission container using folders (bold) to structure multiple types of reporting, containers, supplementary information etc.
+== 5.2 Response container ==
+A response container is a container that may be returned by the receiver of a submission container to its sender to inform the sender about the result of the evaluation of its content (e.g. possible errors).
+When applicable (i.e. XBRL instance documents), XML Instances of the InstanceFeedback schema may be used to report the errors that were identified during the validation phase by the receiver, knowing that:
+) alternative instance feedback files are allowed as a replacement or as a supplement to the instance feedback files;
+) instance feedback files should be generated systematically, even if no errors at validation time occurred (not only negative, but also positive feedback should be provided for the data instances in the related submission container).
+A response container is composed of the following files:
+* 0 or 1 container feedback file;
+* 0 to n instance feedback files and / or 0 to n alternative error feedback files.
+[[Image:clip_image006.jpg]]
+;Figure 3— Example of a response container generated on the basis of an incoming submission container with one reporting consisting of three XBRL files. All files in the response container are instances of the XML schema InstanceFeedback
+[[Image:clip_image008.jpg]]
+;Figure4— Example of a response container generated on the basis of an incoming submission container with two different reportings and using folders. All XML files in the response container are instances of the XML schema InstanceFeedback. As a supplement, Excel-type error-diagnostics are returned for Report1
+= 6 Primitive functions =
+The present chapter describes the primitive functions required to put in place the present CWA.
+== 6.1 Compression functions ==
+<nowiki>Compression is made in accordance with the ZIP file format specification [18].</nowiki>
+The minimum feature version is 2.0 as defined in chapter 4.4.3.2 of the present version of the specification (version 6.3.3).
+=== 6.1.1 Creating a ZIP compressed file ===
+Many tools in the market are able to create ZIP compressed files; interoperability problems are not known as long as multi-volume zip is not used. This is why multi-volume ZIP compressed files are not supported by this CWA version.
+In order to avoid problems with senders using features of very recent versions not yet supported by the receiver, the instructions of the receiver may fix further constraints on the compression to use (e.g. a maximum level of the zip standard, as supported by the receiver).
+=== 6.1.2 Expanding a ZIP compressed file ===
+This operation is the inverse operation of “Creating a ZIP compressed file”.
+== 6.2 Security functions ==
+This chapter describes the primitive functions for signing or encrypting files as well as the way to calculate the hash required in schemata InstanceFeedback and ContainerFeedback.
+Within this specification, encryption and / or digital signature shall be applied to a single file (not to a set of files).
+=== 6.2.1 Encrypting a file ===
+<nowiki>As references XMLENCR-CORE [14];</nowiki>
+using key transport RSA-OAEP:
+[http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p]
+and encrypting data with AES256:
+[http://www.w3.org/2009/xmlenc11#aes256-gcm http://www.w3.org/2009/xmlenc11#aes256-gcm]
+The selected encryption uses the W3C XML Encryption to cipher a file, embedding it completely into the XML document that will result of the encryption process (there shall be no references to the file at an external location). Inside the CipherData element, there shall be a CipherValue element, but there shall not be a CipherReference element.
+Basic steps for encryption are:
+* create XML document with the embedded file, using W3C Encryption schema;
+* generate AES-256 key (secret key);
+* get RSA public key (and certificate);
+* cipher secret key with public key, using RSA-OAEP;
+* cipher XML element with the embedded file with AES-256 using secret key;
+* <nowiki>store all in a file using W3C Encryption schema [14].</nowiki>
+<nowiki>The embedded file is encrypted using a symmetric algorithm (AES-256) with a generated secret key. The security strength of AES-256 is 256 (NIST SP 800-57 part1 [19]).</nowiki>
+The key transport algorithm RSA-OAEP with mask generation function MGF1 (MGF1p, padding) <nowiki>is used to cipher the generated AES-256 secret key. Key transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. RSA-OAEP uses the receiver’s public key to encrypt the secret key generated by AES while encrypting the file. This key transport algorithm chosen is SP800-56B compliant [21], using KTS-OAEP-basic, without key confirmation.</nowiki>
+<nowiki>The AES256 has been chosen for encryption and decryption as the algorithm and key length is safe to use and no security risk is currently known (see NIST SP 800 131A [20]). Also, RSA is acceptable, with |n|=2048, for SP800-56B [21] key agreement schemas. Note </nowiki>[[Image:clip_image010.gif]]is the length in bits of the RSA modulus [[Image:clip_image012.gif]], and [[Image:clip_image014.gif]]means [[Image:clip_image010.gif]]is at least 2048.
+AES-256 is a block cipher, being able to encrypt/decrypt messages of a fixed length (called block, in AES it's 128). In order to be able to encrypt/decrypt larger messages (larger than one block size), a mode of operation is required which is an algorithm that describes how to apply the block cipher many times and how to be able to work with larger messages.
+<nowiki>Selected mode of operation is Galois Counter Model (GCM), as recommended in "XMLENCR-CORE1 [16]". For details on GCM, see NIST SP 800-38D [27].</nowiki>
+<nowiki>The certificate used to encrypt shall be X.509 and shall also be included in the XML file (as allowed by W3C encryption schema [14]) to be able to identify the private key corresponding to this certificate (when decrypting).</nowiki>
+Basic steps for decryption are:
+* read XML document (W3C Encryption schema);
+* extract the RSA certificate to ask for (or look for) the corresponding private key;
+* decrypt AES secret key using private key;
+* decrypt XML element (xenc:CipherValue) with the encrypted content using the secret key;
+* as the content of the decrypted element should be the file, store this file externally in the file system.
+=== 6.2.2 File name changes upon encryption ===
+As the table 1 shows, when an encryption is applied to a file that has a reserved extended suffix (or, if there is none, a standard suffix), this reserved extended suffix (or, if there is none, a standard suffix) shall change into .encrypted.xml.
+Similarly, when an encryption is applied to a file that has no suffix, the reserved extended suffix .encrypted.xml shall be added to the filename.
+;Table 1— Encrypted file name examples
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''File to encrypt'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Name of the encrypted file'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Filename inside the XML-enc file'''
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to encrypt»
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.pdf'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to encrypt »
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.zip'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to encrypt »
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.signed.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to encrypt »
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.'''encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.'''encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to encrypt »
+|}
+=== 6.2.3 Decrypting a file ===
+This operation is the inverse operation of “Encrypting a file”.
+The filename of the decrypted file should become the filename inside the XML signature file.
+=== 6.2.4 Signing a file  ===
+The present chapter explains the requirements and determines the standard finally chosen for applying electronic signatures.
+=== 6.2.5 Requirements  ===
+The requirements for the choice of the standard were:
+* provide non-repudiation: assure the sender identity, preventing an individual from denying that have effectively signed data;
+* prevent the unauthorised (or accidental) modification of data;
+* allow the addition of multiple files to a single signature envelope;
+* <nowiki>be compliant with European Directive 1999/93/EC [8];</nowiki>
+* use a PKI infrastructure, if required;
+* shall contain the signer’s digital X.509 certificate;
+* shall contain the signing time;
+* should include information about policy to verify electronic signature. Hence this signature policy is a legal/contractual document and it might not be available for some authorities. The standard shall support both situations, whether the regulator has a signature policy or not;
+* avoid the use of MD5 or SHA-1;
+* long term validation is not needed, as signature should be validated in a limited time-frame.
+=== 6.2.6 Electronic signature to use ===
+<nowiki>The file structure generated by the signature shall be XAdES-BES/EPES as specified in ETSI-XAdES [2];</nowiki>
+The algorithm shall be RSA with SHA512:
+[http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 http://www.w3.org/2001/04/xmldsig-more#rsa-sha512]<nowiki>;</nowiki>
+<nowiki>XAdES-BES/EPES (which has been built up on W3C XML Digital Signature) shall be implemented according to COMMISSION DECISION of 25 February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market [9].</nowiki>
+A signature policy is a legal document that extends the definition of the electronic signature by supplementary properties to respect for signature validation. Depending on the availability of such a signature policy, the file structure to generate shall be:
+* XAdES-EPES if an explicit signature policy has been defined by the regulator interested in using this standard;
+* XAdES-BES if no signature policy has been defined by the regulator for use with this standard.
+The digital signature for containers will be "SignatureEnveloping", i.e. the output will be an XML file containing as well the signature as the original file. A ds:object element shall contain the Base64 encoding of the file to be signed (if multiple compressed files are needed in the same signature, multiple ds:object elements may be generated). Attributes MimeType, ID, and Encoding shall be included in the ds:object element. ID should be used to store the file-name to enable regeneration of original filename.
+Selected signature algorithm for this standard is RSA with SHA-512 as a hash function. The length of the RSA modulus should be at least 2048 [[Image:clip_image016.gif]]<nowiki>, a lower value is disallowed (NIST SP 800-131A [20]). Details on RSA can be found in RFC 3447 [28].</nowiki>
+<nowiki>The hash function is SHA-512 as specified in FIPS PUB 180-4 [11]. SHA-512 provides a security strength of 256 bits (NIST SP 800-57 part1 [19]).</nowiki>
+=== 6.2.7 File name changes upon signature ===
+As the table 2 shows, when a signature is applied to a file that has a reserved extended suffix (or, if there is none, a standard suffix), this reserved extended suffix (or, if there is none, a standard suffix) shall change into .signed.xml.
+Similarly, when a signature is applied to a file that has no suffix, the reserved extended suffix .signed.xml shall be added to the filename.
+;Table 2— Signed file name examples
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''File to sign'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Name of the signed file'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Filename inside the XML signature file'''
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.signed.xml
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to sign»
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.pdf'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.signed.xml
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to sign»
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.zip'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.signed.xml
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to sign»
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.signed.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.signed.xml
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to sign»
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol'''.encrypted.xml'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Lol.signed.xml
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Same as «File to sign»
+|}
+=== 6.2.8 Validating and extracting a signed file ===
+This operation is the inverse operation of “Signing a file”.
+The filename of the extracted file shall become the filename inside the XML signature file.
+== 6.3 Creating a submission container ==
+In accordance with the requests from EBA and EIOPA, two main characteristics should be given for the Header that is included in every submission container:
+* there should be a basic header, which should be small and easy to use;
+* the basic header should be extensible with fields required by the receiver.
+These requirements implied a structure of the Header as described in the present chapter.
-==structural validations==
-XML schema validations and structural XBRL validations (XBRL 2.1, Dimensions 1.0 etc. or higher)
+=== 6.3.1 Header schema structure ===
+The structure of a header as described in this CWA is that of an ExtendedHeader that is to be defined as illustrated in Figure 5. The ExtendedHeader structure shall import the BasicHeader structure and optionally may import other modules like the RegisteredOrganisationVocabulary (continuative work of the « Core Vocabularies » of the EC’s Interoperability Solutions for public Administrations programme) and/or other modules (to be developed in the future).
-==content-related validations==
-validations like calculations or formulas
+[[Image:clip_image018.jpg]]
+;Figure 5— Extended Header structure importing the BasicHeader structure that optionally imports the RegisteredOrganisationVocabulary (continuative work of the «Core Vocabularies», EC’s Interoperability Solutions for Administrations) and/or other modules (to be developed in the future)
-==full container==
-a container submitted to an authority containing XBRL instances containing a full set of reporting data set as defined by the authority; it will not only respect all structural validations, but also all content-related XBRL validations
+The table 3 describes the structure of such a header.
-==partial container==
+;Table 3— Characteristics of the XML schemas
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Header component'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Characteristics'''
-a container submitted to an authority containing XBRL instances covering a subset of the reporting data set defined by the authority; it shall respect all structural validations, but not necessarily all content-related XBRL validations (some of these validations will simply fail because of the lack of some data in the partial container)
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| BasicHeader
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This header structure is the «smallest possible» header structure. It consists only of an identifier of the report (set) as well as of the list of data files composing the submitted report (set). This schema shall be imported into any ExtendedHeader.
-==regulator (aka authority) ==
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ExtendedHeader
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This header is an adequate header structure that is to be defined by a receiver (that wants to make use of the present CWA) as the header structure to be used by all senders. As an alternative, if no specific requirements regarding header elements exist, one of the pre-defined standard headers defined in the next chapter may be used.
-a regulatory body that defines the content and structure of filings for the regulated entities as well as the corresponding XBRL taxonomies
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| RegisteredOrganizationVocabulary
-==declarer==
+(RegOrg)
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| <nowiki>On 28th May 2013 the Core Business Vocabulary (EC’s Interoperability Solutions for Administrations programme) has been formally published on the W3C standards track as a First Public Working Draft. It has been revised and renamed into Registered Organization Vocabulary [24].</nowiki>
-role of an entity legally responsible and submitted to regulatory reporting; this role may be assured either with inhouse resources or with the help of technical and functional senders
+The integration of the RegisteredOrganizationVocabulary into the ExtendedHeader is optional, but it should be imported if the usage of any fields defined in the RegisteredOrganizationVocabulary are required in the ExtendedHeader
-==technical sender==
+|}
+Every receiver may thus define an ExtendedHeader structure in accordance with the local needs, giving it an adequate namespace.
-role of an entity responsible for creating the header, the package, the compression, the signature, the encryption and the submission (transport) to the Authority
-==functional sender==
+=== 6.3.2 Predefined standard use-cases of ExtendedHeader schema ===
+The following use-cases, presented in table 4, for creating an ExtendedHeader are explicitly defined by the present CWA and may be used «as is».
-role of an entity responsible for figures in the reports, i.e. the correct content of XBRL Instance Documents
-==authority==
+;Table 4— 6.3.2 Predefined standard use-cases for extended headers
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ExtendedHeader - pre-defined use-case'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Characteristics'''
-the authority is the receiver of the XBRL Instance documents. The Authority is responsible of receiving of the package, validation and creation of the feedback message to be sent back to the Declarer, with the result of the validations
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| BasicHeaderOnly
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This header imports the BasicHeader «as is», makes no extensions for it and does not import the RegisteredOrganizationVocabulary as it doesn't use any of its fields.
-==initial container==
+'''Namespace:''' [http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly]
-a container submitted to an authority containing an initial set of XBRL instances for a certain period, entity and reporting type; an initial container will be marked as such in the header XML instance
+'''XSD URL:''' [http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xsd http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xsd]
-==updated container==
+'''XML sample instance URL:''' [http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xml http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xml]
-a container submitted to an authority containing XBRL instances covering a correction of the latest initial container sent; it will be marked as such in the header XML instance and is usually a partial container
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| StandardHeader'''With'''RegOrg
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| <nowiki>This header structure reflects the survey made within the Eurofiling BestPractices [25]. </nowiki>
-=Base requirements=
+All fields related to «Transport» issues have been removed as these are out of scope of this CWA.
-XBRL instance documents are created by interested parties (such as banks, investment companies or insurances) mostly because of a legal requirement of declaration. These XBRL instance documents are sent to authorities such as national supervision agencies, national central banks, securities commissions, Business registers, etc.
+'''Namespace: '''[http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg With][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg RegOrg]
-A non empty set of one or more unrepeated XBRL instance documents shall be packed and compressed before submission. Some authorities have reported the need to receive files of about 1GB (uncompressed).
+'''XSD URL: '''[http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xsd http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xsd With][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xsd RegOrg.xsd]
-Additionally, a header shall be added to the container to enable the inclusion of additional information and metadata. This header is also being standardized within the present CWA, but it will be treated in a separate CWA document.
+'''XML sample instance URL: '''[http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xml http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xml With][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xml RegOrg.xml]
-This resulting compressed package shall then be signed to ensure the authenticity of the submitter.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| StandardHeader'''Without'''RegOrg
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This header structure is (with regards to its function and its content) equivalent to the previous “StandardHeader'''With'''RegOrg”, but it does not import RegOrg and creates the missing fields as equivalent simple XML fields.
-The signed and compressed package shall then be ciphered to ensure the confidentiality of the report.
+'''Namespace: '''[http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg Without][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg RegOrg]
-This resulting secured-signed-envelope with the XBRL instance documents and the header is sent to the authority, where it shall be checked in several phases:
+'''XSD URL: '''[http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xsd http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xsd Without][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xsd RegOrg.xsd]
-*  Decryption: From this phase the NSA will obtain the signed envelope;
+'''XML sample instance URL: '''[http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xml http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeader][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xml Without][http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xml RegOrg.xml]
-*  Signature: From this phase the NSA will check the authenticity of the message;
+|}
+=== 6.3.3 Creating a specific ExtendedHeader schema ===
+The guidelines for the creation of a specific ExtendedHeader schema are given in Annex G.
-*  Unpacking and Uncompressing: From this phase the NSA will get the header with the metadata and the XBRL instance documents;
+=== 6.3.4 Creating a header file ===
+The creation of a header file consists of the actions:
-*  XBRL validation: a full XBRL validation will be done for each XBRL instance documents.
+* assembling the data files;
-The authority, after checking the previously defined phases, shall be able to return feedback information about the result of the validation phase, including a hash-code to ensure the non-repudiation of every XBRL instance document validated.
+* creation of the header file according to the ExtendedHeader XML schema chosen (as defined by the receiver), the BasicHeader part of the ExtendedHeader listing the assembled data files
-=XBRL instance documents workflow=
+== 6.4 Creating a response container ==
+The creation of a response container consists of the actions presented in the following paragraphs.
-==Major parts and parties in workflow==
+=== 6.4.1 Creating a container feedback file ===
+The creation of a container feedback file should take place in accordance with the documentation of the ContainerFeedback schema in Annex D.
-The parties intervening physically in the reporting process are the declarers, the technical sender and the functional sender and the regulators as defined in chapter 3.
+=== 6.4.2 Creating Instance feedback (Validation, usually only for XBRL) ===
+The creation of an instance feedback file should take place in accordance with the documentation of the InstanceFeedback schema in Annex E.
-Logically, the communication is limited to an interaction of the declarer with the regulator. There are two ways of that communication:
-* submission of a reporting container to the regulator;
+= 7 Exchange model =
-Figure 1 — Report submission to regulator
+This chapter will introduce the exchange model to be used among a sender and a receiver. The receiver should emit instructions on how to use the present CWA for the given exchange of information between a sender and the receiver.
-* return of a feedback container to the declarer.
+The exchange of information composes of the phases presented in the following paragraphs.
-Figure 2 — Feedback from regulator
+== 7.1 Phase 1: the sender creates a submission container, applies all security mechanisms required and transmits it to the receiver ==
+The sender makes use of the adequate transport mechanism to submit the container with the data instances.
-==Submission of the report by the declarer==
+== 7.2 Phase 2: the receiver processes the security layer(s) on the container and all the files within ==
+The receiver removes all encryption layers and verifies all signatures as indicated by the reserved extended suffixes on the container and the files there-in.
-As explained earlier, the main objective is to send in a standardized way a non-empty set of XBRL instance documents. The sender is the declarer, the part required mostly by a legal requirement to generate XBRL instance documents and to send them to the authority.
+[[Image:clip_image020.jpg]]
+;Figure 6— Illustration of the security removal at container level (in this example two signatures and one encryption have been applied) as well as on all the files within the container
-Figure 3 shows the use cases of issuing XBRL Instance documents to the authority. All these use cases shall be done by the declarer.
-Figure 3 — Use Cases: Issuing (Declarer)
+The container should be reviewed to make sure it has the correct structure (does the header file validate correctly, are all the files announced in the header effectively part of the container, etc.).
-===Use Cases===
-*  Prepare XBRL Instance documents: The declarer shall prepare XBRL instance documents as required by the Authority. These documents shall pass all structural validations and in case of submission of a full container also all content-related XBRL validations. The XBRL Taxonomy shall be provided by the authority;
+== 7.3 Phase 3: receiver generates a positive / negative acknowledgement for the reception of the submission container ==
+As a result of the processing in the preceding phase, it is now identified if the container could be correctly received or if it was invalid (container or files within not decryptable, signature(s) invalid, entity not known or not authenticable, decompression failed, etc.). A container feedback file should be generated that either confirms the validity of all reception steps (like security removal and supplementary checks) and results in a positive acknowledge, or that lists (in the opposite case) the errors that occurred (negative acknowledgement).
-*  Create header: the declarer shall create the header as specified in the second document defined within this CWA;
+The acknowledgement will be included into the response container in phase 5
-*  Pack and Compress XBRL Instance documents and the Header: the XBRL Instance documents and the header shall be packed and compressed together, according to section "Packaging and compression" of the present document;
-*  Sign compressed package: To ensure authenticity, the package from the previous use case shall be signed according to European laws. An advanced form of XML signature (XAdES) is used for this purpose. Section "Signature" of the present document specifies this action;
+== 7.4 Phase 4: the receiver processes the contents of the container ==
+In case of a positive acknowledgement, the data files submitted shall go through the following stages of processing.
-*  Encrypt the signed package: Because of the nature of the data sent to the autority, there is sensitive information that shall be protected by an appropiate security level. Chapter "Encryption" of the present document explains the encryption model, based on W3C-XML Encryption;
+The standard suffixes of the files shall be used to identify those files that can be further processed. As an example, XBRL or XML instances should now be validated by their respective validator (while unstructured data files like word processor files could be made available to analysts for manual review).
-*  Send to authority: The encrypted package shall be sent to the authority;
+As a result of this phase, the adequate (alternative) instance feedback files for the XBRL instances in the original submission container should have been generated.
-*  Receiving feedback: The authority should create a feedback document with results of validation and a hashcode of every XBRL instance document tested, with the results of the validations.
-==Receiving of the report by the authority and return of the feedback container==
+== 7.5 Phase 5 (optional): the receiver returns the validation result of the data files in the response container  ==
+All feedback files as well as the container feedback file may be added to a response container that should be returned by the receiver to the sender to provide the result of the content processing of the related submission container.
-The main objective here is to gain access by the authority of the data inside the XBRL instance documents.
+Unlike the submission container, a response container shall not include header information.
-The access shall be gained in a secure way, so validations shall be done at different levels to guarantee confidentiality, authenticity, data quality and so forth. Feedback should be generated to inform the declarer about the results of the validations.
+The receiver may alternatively make available the result of the processing in a way considered more appropriate (e.g. returning links to external systems etc.).
-Figure 4 presents the use cases for receiving the package. All these use cases shall be done by the authority.
+The exchange model can thus be presented as in figure 7.
-Figure 4 — Use Cases: Receiving (Authority)
-===Use Cases===
+[[Image:clip_image022.jpg]]
+;Figure 7— Illustration of the exchange model
-*  Receiving: Receive the encrypted container from the declarer;
+AnnexA(normative)Items that shall be defined in the instructions
-*  Encryption validation: Decrypt the data to obtain the signed package. Note that this is the security layer;
+A.1Introduction
-*  Electronic signature validation: This validation shall assure the authenticity of the package;
+These are some questions to which any institution willing to use the CWA has to give clear answers to in its instructions.
-*  Uncompress and unpack: By doing this, direct access to XBRL Instance documents can be allowed;
-*  XBRL Validation: Check that the data in every XBRL Instance Document to be valid against specified Taxonomies. Whether the instance is a part of a full or a partial container, the adequate validation mechanisms shall be used to ensure that the data set represented by the combination of the full container with its potential subsequent partial containers always respects all the structural and content related validations as defined in the taxonomy. In case a specific order in the validation of the instances is required, the order inherent in the listing of the instances inside the header shall be used;
+A.2Container structure
-*  Create hash code of validated XBRL instance documents: A hash code of every XBRL instance document will be computed, to allow the declarer to check the integrity of the XBRL instance documents. The results of the XBRL Validation will be together with the hash code of the XBRL instance document being validated;
+;Table A.1— Common questions and instructions for the container
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Item'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Typical instruction'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Explanations'''
-*  Create feedback: An XML feedback file is created for every XBRL instance, reporting the results to the declarer. Section "Feedback" in the chapter "Container format and structure" specifies this part;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Use of CWA encryption layer?
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| YES, one single encryption to be applied on a signed file (container)
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| should be Yes, may be No in environments using a secure transport
-*  Create XML feedback file: The feedback should include the results of the validation;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Use of CWA signature layer?
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| YES, one single signature to be applied on a zip compressed file (container)
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| should be Yes, may be No in environments using a secure transport
-*  Pack and compress feedback.xml: The feedback shall be packed and compressed according to chapter "Packaging and compression" of this document;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Use of the «Instancefeedback» schema» to inform of the result of the processing of a data instance?
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| « Use instance feedback to report errors » or « Use Excel files in folder XBRL_Errorsinstead »
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| «None» or «InstanceFeedback schema» or «explanation of an alternative mechanism (e.g. provision of links to an external system of graphical representations of error conditions)»
-*  Sign packed feedback: The package shall be signed by the Authority to assure authenticity. XAdES shall be used as explained in chapter "Signature" of this document;
+|}
+A.3Header
-*  Encrypt signed-packed feedback: In the feedback there can also be sensitive information, so encryption shall be included. In chapter "Encryption" of the present document the encryption model, based on W3C-XML Encryption, is explained;
+These are required precisions on how some tags of the header schema shall be used. These instructions are only required if a standard header schema is used; otherwise the according fields could simply be omitted in a customised header extension.
-*  Send feedback to the Declarer: The feedback shall be sent to the declarer.
+;Table A.2— Common instructions for the header
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Item'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Typical instruction'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Explanations'''
-==Initial vs. update submissions==
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><ReportReferenceID></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| e.g. «Finrep full quarterly consolidated reporting for investment companies» or a code for that reporting
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The list of the different reporting identifications covered by the instructions
-An authority shall always allow the submission of initial containers, but need not to allow the submission of update containers.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><AuditStatus></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| e.g. «The values «audited» and «not audited» shall be used exclusively»
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Either confirm the use of the flag or specify that the value « undetermined » or « in datainstances » is applicable
-If an authority only allows the submission of initial containers, all of these containers shall be full containers
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><ConsolidationStatus></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki>See <AuditStatus></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| <nowiki>See <AuditStatus></nowiki>
-i.e. they shall contain the full dataset of the reporting as defined by the authority.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><CapitalCurrency></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Capital Currency shall be used and be EUR mandatorily
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This tag may be used for validation purposes in some countries imposing the exclusive use of a single currency
-If an authority allows the submission of initial and update containers, all update containers should be applied to the last initial container sent. An initial container should mostly be a full container, but the authority may also allow a declarer to start with a partial initial container. Resending an initial container should imply that all initial and update containers sent before should be discarded. An authority allowing the sending of update containers shall provide the necessary mechanisms to ensure that in spite of the possibility of the failure of content-related validations on the update container itself, the combination of the latest initial container with all subsequent update containers should guarantee the full respect of all content-related validations (as defined in the taxonomies) as well as an adequate error handling.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><UpdateStatus></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| e.g. «Only use value «Replace»»
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| If no «update» mechanism is provided, the value «Replace» should be enforced by the instructions, indicating that all prior reports of the same type will be deleted and replaced by the content of the new container
-Figure 5 — Example of a timeline of submission of initial and update containers
-=Container format and structure=
+In the other case, allowing the values «Update» (keep any values from a prior reporting excepted for those in the data instances of the present container which will be replaced by their new values) and «Delete» (delete any values from prior reports that are in the data instances of the present container) can make sense
-The container structure shall use the following layers:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><TestFlag></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki>«All data are production data, do not use <TestFlag>true</TestFlag>»</nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This tag may be used to flag data instances sent to the receiver’s production infrastructure as test data (to be validated, but not injected into the receiver’s databases)
-Figure 6 — Layers and structure of a container
+|}
+A.4Lists of codes accepted
-The standards chosen for the different layers will be described as follows:
+A table like table A.3 (defining identifiers accepted both for legal entities and for persons) should explain which codes are allowed.
-*  [[European_Metadata_Container#Packaging_and_compression| Packaging_and_compression]]
+;Table A.3—Identifiers accepted both for legal entities and for persons
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Code type'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Issuer'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Country'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''URI'''
-*  [[European_Metadata_Container#Signature| Signature]]
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><IdentifierType></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><IdentifierIssuingAuthority></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| <nowiki><IssuingAuthorityCountry></nowiki>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| <nowiki><IssuingAuthorityURI></nowiki>
-*  [[European_Metadata_Container#Encryption| Encryption]]
+|}
+AnnexB(informative)Supplementary items that may be useful in the instructions
-No standard naming convention applies to the files (neither to the container nor to the XBRL instances in the container); the regulator should fix file naming conventions according to local needs.
+;Table B.1— Supplementary items and explanations
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Item'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Explanations'''
-Multiple compression packages per security envelope (encryption, signature) are allowed (e.g. for a consolidated reporting for several entities of a group that requires cross-verification)
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Name of the use of the CWA
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Examples: «Prudential supervisory reporting», «XBRL reporting only», «NSA to EBA transmissions»
-Figure 7 — Layers and structure of a container containing several data packages
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Applicable File naming conventions (if any)
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| E.g. a link to an external document describing all applicable file naming conventions applicable to containers, folders, data instances, unstructured files
-The multiple XBRL instance documents in the container will share the metadata of the one XML header file; this header is the only file with a naming convention: “header.xml” and it is located on top-level of the compression package. The header lists the XBRL instances contained in the container (in a certain order).
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Containers for other regulators to include
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Description and destination authorities for the containers etc.
-XBRL instances should always have extension .xbrl (neither .xml nor .XML nor .XBRL)
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Supplementary rules
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Example of a supplementary rule: a certain container inside the container shall contain the same instances (reported instances for second level reporting are the same as for first level reporting)
-The use of folders is optional within the .zip package; in case they are used, all references (in header to XBRL instances; in XBRL instances to taxonomy files) shall respect them. The folder names used above (“Instances”, “Taxonomy”) are given as examples.
+|}
+AnnexC(informative)Explanations on header schema
-Taxonomy files are optional (they are normally unnecessary and will only be used in case taxonomy extensions by the reporter became allowed in Europe)
+The present specification allows extensible headers which makes it difficult to choose a certain header to document. For illustration purposes, the present chapter documents the standard extensible header "StandardHeaderWithoutRegOrg".
-Figure 8 — Dependencies among files in the container
+The XML Schema StandardHeaderWithoutRegOrg is depicted in figures C.1 to C.4.
-==Header==
+[[Image:clip_image024.jpg]]
+;Figure C.1— StandardHeaderWithoutRegOrg (TechnicalSender, ContentProducer and ReportingEntity)
-Defined in the section [[European_Metadata_Header| European_Metadata_Header]] of this CWA ''Improving transparency in financial and business reporting — Metadata container and compliance tools''.
+[[Image:clip_image026.jpg]]
+;Figure C.2— ReportingProcessRoleType
-==XBRL Instance document(s) ==
+[[Image:clip_image028.jpg]]
+;Figure C.3— PersonResponsibleReportingType
-==Feedback==
+[[Image:clip_image030.jpg]]
+;Figure C.4— StandardHeaderWithoutRegOrg (ReportingDataContext, ReportOperationalContext and File)
-In case a correct submission container was received, it shall return a feedback container structured as follows:
-Figure 9 — Feedback container
+;Table C.1— StandardHeaderWithoutRegOrg explanations
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Item'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Type'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Explanation'''
-One XML feedback file per XBRL instance in the original submission container will be packaged to the feedback container.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportDataContext
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportDataContextType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-Feedback files will be generated systematically for every submitted XBRL instance, even if no errors at validation time occurred (also positive acknowledge).
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| File
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| FileType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-The feedback file shall have the same name as the original instance it refers to (but with extension .xml instead of the original .xbrl).
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| TechnicalSender
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportingProcessRoleType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| (Potential) sub-contractor in charge of physically sending the data in respect of the present CWA (aware of containers, encryption, etc.).
-The folder name used here (“Feedback”) is given as an example.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ContentProducer
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportingProcessRoleType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| (Potential) sub-contractor in charge of the production of the content of the reporting and responsible for the accuracy of the content.
-===Scope===
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportingEntity
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportingProcessRoleType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Entity submitted to financial reporting and legally responsible for it (in many cases it uses internal resources to play the role of Content Producer and Technical Sender too). An authority may also play the role of a reporting entity, e.g. when a national authority is providing data to a subsequent European authority as level-2 reporting.
-Two types of feedback shall be given to a container submitted:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportDataContext
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportDataContextType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of information that defines the general context of the data in the report i.e. general, common properties applicable to all the reporting files
-b) Container feedback: a feedback for the entire container (in which either the correct container receiving is acknowledged or in which decompression, decryption, signature verification errors etc. are reported);
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportOperationalContext
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportOperationalContextType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of information that defines properties related to the process of submitting data
-c) XBRL Instance feedback: feedback files for each XBRL instance document that was submitted within the original submission container itself.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''FileType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-For both of these validations to be performed, there is an XML Schema definition that should be used when the receiving side validator finds errors and the errors should be communicated back to the declarer of the container. Two XML Schemas are defined here for the validation processes a) and b) respectively. Definitions and technical issues regarding the XML Schemas are given in the following sections 6.3.2 and 6.3.3.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| FilePath
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| relative URI
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This field gives the relative Uniform Resource Identifier (URI) to a file in the container (starting from top-level).
-===Container feedback===
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| TypeOfFile
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text enumeration
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Potential supplementary file type characterizing each individual file in the container to allow supplementary dedicated processing based of the file type.
-This issue will be treated in a future version of the document
+Possible values: "DataInstance", "OtherFile", "SignedAndEncryptedSubcontainer", "SignedSubcontainer", "CompressedOnlySubcontainer"
-====Namespace====
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Filename
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Explicit name of the file
-The namespace is http://www.eurofiling.info/eu/fr/esrs/containerFeedback
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Destinee
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| identifier
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Potential destinee for one of the files in the container, e.g. a container inside a container
-====Elements and element types====
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ReportingProcessRoleType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-===Instance document feedback XML Schema===
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| LegalIdentifier
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| LegalIdentifierType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of properties identifying the reporting entity
-====Namespace====
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| MainContactResponsibleReporting
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PersonResponsibleReportingType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Human contact for the case of problems with a certain step of the reporting generation and submission process
-The namespace is http://www.eurofiling.info/eu/fr/esrs/instanceFeedback
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| BackUpContactResponsibleReporting
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PersonResponsibleReportingType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Backup person for BackUpContactResponsibleReporting
-====Elements and element types====
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''LegalIdentifierType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-Elements and types defined in the Instance document feedback XML Schema can be found in the table 7-1.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Identifier
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| identifier
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Code identifying the reporting entity
-There is also supplementary information for the elements provided in both tables for:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IdentifierType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| code
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Type of code identifying the reporting entity
-*  Type: the type of the element can be a type defined in the schema or a predefined XML Schema type,
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IdentifierIssuingAuthority
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IdentifierIssuingAuthorityType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of information that describes the authority having issued the certificate
-*  Occurrence: definition for the occurrence of the given element,
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IssueDate
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| date
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Issuing date of the code
-*  Usage: a recommendation for the scenario in which the element should be used and
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''IdentifierIssuingAuthorityType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-*  Description: a narrative explanation for the element.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IssuingAuthority
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Name / Identifier of the issuing authority
-See table 1: Element definitions of the InstanceFeedback XML Schema
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IssuingAuthorityCountry
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| code
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| ISO country code of the issuing authority
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| IssuingAuthorityURI
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| URI
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| URI identifying the issuing authority
-<table border="1">
+|-
-<th width="20%">Element name</th><th width="10%">Type</th><th width="10%"> Occurrence</th><th width="20%"> Usage ''(conditions for occurrence)''</th><th width="30%">Description</th>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''PersonResponsibleReportingType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-<tr><td>'''InstanceFeedback'''</td><td> </td><td> </td><td></td><td>the root element, validation consists of separate validation sections</td></tr>
+|-
-<tr><td>&nbsp;&nbsp;&nbsp; InstanceNameReference</td><td> text</td><td> 1</td><td></td><td> The name of the instance document being validated</td></tr>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PersonResponsibleReporting
-<tr><td>&nbsp;&nbsp;&nbsp; InstanceHashValue</td><td> hash/digest value </td><td>?</td><td></td><td> Reference to the calculated hash value of the instance document being validated, it has the "Hash HashAlgorithm " attribute that can be used to indicate which hash algorithm has been used</td></tr>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| TypeOfPersonResponsibleReporting
-<tr><td>&nbsp;&nbsp;&nbsp; InstanceValidationFlag</td><td> boolean</td><td> 1</td><td></td><td> true = validation successful<br>false = errors found in the validation</td></tr>
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of information describing the person that is in charge of the reporting
-<tr><td>'''XMLValidationResult'''</td><td> ValidationResult Type</td><td>?</td><td> Only when InstanceValidationFlag is set "false"</td><td>The first validation includes, XML, Schema, DTS-validations</td></tr>
-<tr><td>'''XBRLValidationResul'''t</td><td> ValidationResult Type</td><td>?</td><td> Only when InstanceValidationFlag is set "false" and ValidationFlag of XMLValidationResult is set as "true"</td><td>The second validation to be executed, XBRL 2.1 Conformance Suite 1.0 validation, taxonomy validation</td></tr>
-<tr><td>'''TransformationResult'''</td><td> ValidationResult Type</td><td>?</td><td> Only when InstanceValidationFlag is set "false" and ValidationFlag of XMLValidationResult and XBRLValidationResult are set as "true"</td><td>Transformation into human readable format, i.e. HTML (inline xbrl), Requires XSLT transformation</td></tr>
-<tr><td>'''ValidationResultType'''</td><td>sequence</td><td></td><td></td><td></td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp;ValidationFlag</td><td> boolean</td><td> 1</td><td></td><td> true = validation successful<br>false = errors found in the validation</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp;ValidationPhase</td><td> text</td><td> ?</td><td> Only when ValidationFlag is set to "false"</td><td>may be used to indicate which phase of the validation was unsuccessful. For instance, validations against Formula linkbase definitions can tumble in validations against accuracy or aspect rules.</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ValidationErrors</td><td> ValidationErrorsType</td><td>?</td><td> Only when ValidationFlag is set to "false"</td><td>lists all the errors found in the validation</td></tr>
-<tr><td>'''ValidationErrorsType'''</td><td> sequence</td><td></td><td></td><td></td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ValidationError</td><td> ErrorType</td><td> 1+</td><td></td><td> The error found</td></tr>
-<tr><td>'''ErrorType'''</td><td> sequence</td><td></td><td></td><td> a generic error type that can be used in all validation sections to define found errors</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ErrorCode</td><td> identification code</td><td>1</td><td></td><td> an error code that can be used to identify the error found</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ErrorNature</td><td> ErrorNatureType</td><td> ?</td><td></td><td> The nature of the error</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ErrorLocation</td><td> text</td><td> 1</td><td></td><td> an expression that can be used to locate the error in the instance document, can be an Xpath sentence or line number</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ErrorDescription</td><td> text</td><td> 1</td><td></td><td> a description of the found error</td></tr>
-<tr><td>&nbsp;&nbsp;&nbsp; ErrorSeverity</td><td> ErrorSeverityType</td><td>?</td><td></td><td> The severity of the error</td></tr>
-<tr><td>'''ErrorNatureType'''</td><td> text enumeration</td><td></td><td></td><td> Possible values: "Structural" or "Content"</td></tr>
-<tr><td>'''ErrorSeverityType'''</td><td> text enumeration</td><td></td><td></td><td> Possible values: "Info", "Warning", "Error" and "Fatal"</td></tr>
-<tr><td></td><td colspan="3">Occurrence: '''"1"'''=occurs exactly once. '''"?"'''=occurs once or not at all. '''"1+"'''=occurs once or more<td></td></td></tr>
-</table>
-=Packaging and compression=
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PersonResponsibleReportingIdentifier
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| LegalIdentifierType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of information describing the Identifier of the person that is in charge of the reporting
-==Packaging and Compression==
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PersonResponsibleReportingContactData
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PersonContactDataType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Sequence of information describing means to contact the person that is in charge of the reporting
-Users of the CWA Metadata container shall pack and compress the created metadata container by using a method that results in a file format with .zip extension.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''TypeOfPersonResponsibleReporting'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-The metadata container specification defined in here shall not define any specific software to be used in packaging and compression process.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| FamilyName
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| person family name
-==Limitations and performance==
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| GivenName
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| person given name
-The used .zip file format shall support at least the version 2.0 of the APPNOTE.TXT - .ZIP File Format
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| BirthName
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| person birth name
-Specification by PKWARE Inc., APPNOTE.TXT - .ZIP File Format Specification, version 6.3.3, section 4.4.3.2. http://www.pkware.com/documents/casestudies/APPNOTE.TXT
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''PersonContactDataType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| choice element
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Choices available: Telephone, Fax, E-Mail
-The version 2.0 was selected as the minimum level of conformance as the prior versions do not support folder structures that are used in the CWA Metadata container.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ReportDataContextType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-The CWA Metadata container does not impose any other requirements for the compression method to be used. However the report receiving authority should communicate to their reporting entities the highest version of .zip file format specification that is supported by the report receiving system.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportReferenceID
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| identifier
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| This code identifies the data submitted in the container. It can be a set of reports (e.g. code “FINREP_COREP” for Finrep & Corep), a single report (e.g. “QUARTERLY_CONSOLIDATED_FINREP” for the standard Finrep) or a subset of reports (e.g. “TABLE1&2 FINREP” for only the according subset of Finrep)
-=Signature=
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReferenceReportingPeriod
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| date
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Main reporting period (end date of the period)
-An electronic signature is data in electronic form which is attached to or logically associated with other electronic subject data and which serves as a method for authentication.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| AuditStatus
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text enumeration
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Data extracted from general ledger ("not audited") or having undergone an external audit already ("audited")
-A digital signature is one form of electronic signature that uses a cryptographic transformation of the data to allow the recipient of the data to assure the origin and the integrity of the data, and to provide protection against forgery of the data by the recipient.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ConsolidationStatus
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text enumeration
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Consolidated or solo in different flavours.
-Signature is, formally speaking, a value generated by the application of a private key to a message via a cryptographic algorithm such that it has the properties of the signer authentication and message authentication (integrity).
+Possible values: "solo head office excluding branches", "solo head office including branches", "solo branch only", "sub-consolidated", "consolidated"
-The Major parties involved in the business transaction supported by electronic signature are:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| CapitalCurrency
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| code
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Main currency
-*  The signer,
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ReportOperationalContextType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-*  The verifier,
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| UpdateStatus
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text enumeration
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Flag characterizing if this is an entirely new report ("Replace") or if it is an update of a previously sent report ("Update") or if the prior report should be deleted ("Delete")
-*  Trusted Service Providers (TSP) and
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| InstanceCreationDateTime
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| date
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Creation date & time of the instance
-*  The arbitrator.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| TestFlag
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| Boolean
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Flag to characterize if it is actual production data (false, default value) or only test data (true)
-The signer is the entity that creates the electronic signature. When the signer digitally signs over data using the prescribed format, it represents a commitment on behalf of the signing entity to the data being signed.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| TransferSoftwareNameVersion
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Software or system used to submit the report
-The verifier is the entity that validates the electronic signature. It may be a single entity or multiple entities.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ReportingSoftwareNameVersion
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Software or system used to generate the report
-The Trusted Service Providers are one or more entities that help to build trust relationship between the signer and verifier. They support the signer and verifiers by means of supporting services, including:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| RemarkAboutReport
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Remark on the report
-*  User certificates,
+|}
+AnnexD(informative)Documentation of the container feedback schema
-*  Cross-certificates,
+The present chapter describes the XML Schema ContainerFeedback that is depicted in figure D.1.
-*  Time-stamp tokens and
-*  Certificate Revocation Lists (CRLs), Authority revocation list (ARLs), Online Certificate Status Provider
+[[Image:clip_image032.jpg]]DA.
+;Figure D.1— Visualisation of the container feedback schema (ContainerFeedback.xsd)
-(OSCP) responses.
-The Arbitrator is the entity that arbitrates in disputes between a signer and a verifier.
+In table D.1, there is supplementary information on the schema describing:
-== Signature requirements==
+* type: the type of the element in the schema and
-These are the signature requirements that were taken into account:
+* description and usage: a narrative explanation for the elements and a recommendation for the scenario in which the element should be used.
-*  Provide non-repudiation;
+;Table D.1— Container feedback schema element listing and description
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Element name'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Type'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Description and usage'''
-*  Allows the addition of multiple files to a single signature envelope;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ContainerFeedback'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"|
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The root element, validation consists of separate validation sections
-*  Compliant with European Directive 1999/93/EC;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ContainerName
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The name of the container that has been received by an authority and for which the container feedback document acknowledging successful / unsuccessful reception
-*  Shall contain the signer’s digital X.509 v3 certificate;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ContainerFeedbackCreationDateTime
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| dateTime
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The creation date and time of the container feedback document
-*  Shall contain the signing time;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ContainerHashValue
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ContainerHashValueType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Hash calculated according to the present specification for the container received in order to assure that both sides make reference to exactly the same file and can verify the file integrity.
-*  Shall include information about policy to verify electronic signature;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ContainerSuccessFlag
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| boolean
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Overall view if the container structure as a whole was correct
-*  Avoid the use of MD5 or SHA-12) ;
+true = container ok
-*  Long term validation is not needed, as signature should be validated in a limited time-frame.
+false = errors found in at least 1 phase of the reception of the container
-==Signer==
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationPhase
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationPhase
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Usage: only when ContainerSuccessFlag is set "false".
-Signature is done using a Public Key Infrastructure (PKI) schema. PKI ensures the following:
-*  Trusted and efficient management of public and private keys
-*  Anytime you use a public key, you can be sure that the associated private key is indeed owned by the subject whose public key you are using.
-Public-private key combination is at the heart of Public Key Infrastructure, and is based on asymmetric encryption.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ValidationPhase'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-The use of public and private keys in digital signature is illustrated in Figure 10. The signer's private key is used to sign the envelope, and the signer's public key is included in the signed envelope in form of a X.509 v3 certificate.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationPhaseType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The type of validation phase for instance "decryption" or "decompression".
-MD5 was broken in August 2004, so it's better no longer use. The security level of SHA-1 has significantly decreased since February 2005, so may be also phased out. Maybe it must be required to use a SHA-2 family algorithm for the digest. (Probably SHA256 or SHA512 for hash functions and RSA, DSA or ECDSA for signature algorithm)
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PhaseSuccessFlag
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| boolean
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| true = validation phase successful
-Packaged with signer’s public key (certificate)
+false = errors found in the validation phase
-Signed with Signer’s Private key
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationErrors
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationErrorsType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Lists all the errors found in the validation. Usage: only when PhaseSuccessFlag is set to "false".
-Figure 10 — Signer's public and private keys in signature
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ValidationErrorsType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-==Signing process==
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationError
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The error found
-Established requirements involve the usage of an advanced form of W3C XML Digital Signatures (XMLDSIG).
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ErrorType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| a generic error type that can be used in all validation sections to define errors found
-The selected form is XAdES.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorCode
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| code
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| an error code that can be used to identify the error found
-XAdES complaint with European Directive 199/93/EC, and is one of the three form of Advanced Electronic
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorLocation
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| an expression that can be used to locate the error in the instance document, can be an Xpath sentence or line number
-Signautures (AdES) that comply with the technical specifications set in the Annex of the Commission Decision 2011/130/EU (of 25th February 2011, establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorDescription
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| a description of the error found
-In the next sub-chapter specifications about XMLDSIG, XAdES, XAdES-BES and XAdES EPES are included.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorSeverity
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorSeverityType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The severity of the error
-Note that:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ErrorSeverityType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text enumeration
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Possible values: "Info", "Warning", "Error" and "Fatal"
-*  XAdES is an extension of XMLDSIG;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ValidationPhaseType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| A description of the validation phase for instance decryption, signature verification, authentication, …
-*  XAdES BES is an particular form of XAdES;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ContainerHashValueType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| hash/digest
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Has an attribute HashAlgorithm with a fixed value "http://www.w3.org/2001/04/xmlenc#sha256 "
-*  XAdES EPES is an extension to XAdES BES.
+|}
+AnnexE(informative)Documentation of the instance feedback schema
-The selected standard for digital signing the compressed package is XAdES-EPES.
+The present chapter describes the XML Schema InstanceFeedback that is depicted in figure E.1.
-===XMLDSIG===
+[[Image:clip_image034.jpg]]
+;Figure E.1— Visualisation of the instance feedback schema (InstanceFeedback.xsd)
-XML signatures are digital signatures designed to be used in XML transactions. The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary data. Like non-XML digital signatures (as PKCS), XML signature adds authentication, data integrity and support for non-repudiation to the data that they sign. XML signature has been designed to take advantage of the Internet and XML.
+In table E.1, there is supplementary information on the schema describing:
-A fundamental feature of XML Signature is the ability to sign only specific portions of the XML tree, rather than the complete document.
+* type: the type of the element in the schema and
-A XML signature can sign more than one type of resource. For example, a single XML signature might cover character-encoded data (HTML), binary-encoded data (JPG), XML-encoded data, and a specific section of an XML file.
+* description and usage: a narrative explanation for the elements and a recommendation for the scenario in which the element should be used.
-Signatures are related to data objects via URIs. Within a XML document, signatures are related to local data objects via fragment identifiers.
+;Table E.1— Instance feedback schema element listing and description
+{| style="border-spacing:0;"
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Element name'''
+| style="border-top:0.035cm solid #808080;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''Type'''
+| style="border:0.035cm solid #808080;padding:0.049cm;"| '''Description and usage'''
-A signature may be (non-exclusively) described as detached, enveloping or enveloped. Enveloped or enveloping signatures over data within the same XML document as the signature. Detached signatures are over data external to the signature element.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''InstanceFeedback'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"|
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The root element, validation consists of separate validation sections
-Enveloped signature is over the XML content that contains the signature as an element. The content provides the root XML document element. Obviously, enveloped signature shall ensure not to include their own value in the calculation of the signatureValue.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| InstanceRelativeURI
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| relative URI
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| shall contain the path to the data instance from the top-level of the submission package in relative URI notation
-When the signature is over content found within an Object element of the signature itself, we are using enveloping signature. The object (or its content) is defined via a Reference (a URI fragment identifier or transform).
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| InstanceHashValue
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| InstanceHashValueType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Reference to the calculated hash value of the instance document being validated.
-It's easier to see (in XML digital signature), enveloping signature as signature is parent, and enveloped signature when signature is child. In enveloped signature, a signature element is a descendant of the element being signed.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| InstanceSuccessFlag
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| boolean
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Overall view of all instance validations
-Figure 11 summarise the structure of a XML signature.
+true = all validations successful
-Basic steps to create a XML signature include:
+false = errors found in at least 1 validation phase
-d) Determine which resources are to be signed;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationPhase
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationPhase
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Any validation: XML, XBRL 2.1 Conformance Suite 1.0 validation, taxonomy validation. Usage: Only when InstanceSuccessFlag is set "false".
-e) Calculate the digest of each resource. Each referenced resource is specified through a <Reference> element;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ValidationPhase'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-f) Collect the Reference elements (with their associated digest) within a <SignedInfo> element;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationPhaseType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| string
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The type of validation phase
-g) Signing: Compute the signature of the <SignedInfo> element, and put the signature value in a <SignatureValue> element;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| PhaseSuccessFlag
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| boolean
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| true = validation phase successful
-h) Add key information: If keying information (X509 certificate) is to be included, it will be placed in a <KeyInfo> element. The public key needed to verify signature shall be included here and
+false = errors found in the validation phase
-i) Enclose in a <Signature> Element. Place the elements <SignedInfo> <SignatureValue> and <KeyInfo> in a element <Signature>.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationErrors
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationErrorsType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Lists all the errors found in the validation. Usage: only when PhaseSuccessFlag is set to "false".
-Figure 11 — Components of an XML Signature
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ValidationErrorsType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"|
-===XAdES===
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ValidationError
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The error found
-XAdES (XML Advnaced Electronic Signature) is built on a XMLDSIG, incorporating qualifying properties defined in ETSI TS 101 903. These properties will be added to XMLDSIG within one ds:Object acting as the bag for the whole set of qualifying properties, or by using the UnsignedProperties element (this element contains a number of properties that not signed by the XMLDSIG signature).
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| '''ErrorType'''
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| sequence
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| a generic error type that can be used in all validation sections to define errors found
-Main characteristics of XAdES are:
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorCode
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| code
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| an error code that can be used to identify the error found
-*  Enables signing of any data, including jpg, pdf, xml, etc.;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorLocation
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| an expression that can be used to locate the error in the instance document, can be an Xpath sentence or line number
-*  Supports XML package or separate files;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorDescription
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| a description of the error found
-*  Support multiple signatures applied in parallel, serial by repeated signing;
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorSeverity
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorSeverityType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| The severity of the error
-*  Supports a visual signature appearance (depending on the application);
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| ErrorSeverityType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| text enumeration
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Possible values: "Info", "Warning", "Error" and "Fatal"
-*  Provides long-term validity.
+|-
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| InstanceHashValueType
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:none;padding:0.049cm;"| hash value
+| style="border-top:none;border-bottom:0.035cm solid #808080;border-left:0.035cm solid #808080;border-right:0.035cm solid #808080;padding:0.049cm;"| Has an attribute HashAlgorithm with a fixed value "http://www.w3.org/2001/04/xmlenc#sha256 "
-ETSI TS 101 903 defines four forms of XML Advanced Electronic Signatures, namely the Basic Electronic
+|}
+AnnexF(informative)Guidelines on how to extend the basic header
-Signature (XAdES-BES), the Explicit Policy based Electronic Signatre (XAdES-EPES), and the Electronic
+'''Step 1'''
-Signature with Validation Data (XAdES-T and XAdES-C).
+Create your own XSD file, replace the default namespace (http://www.eurofiling.info/eu/fr/esrs/Header/ExtendedBasicHeader) by your own namespace and import the basic header:
-TC XBRL WI XBRL002:2012 (E) 25
+<nowiki><?xml version="1.0" encoding="UTF-8"?></nowiki>
-====XAdES-BES====
+<nowiki><xsd:schema</nowiki> xmlns<nowiki>=</nowiki>"http://www.eurofiling.info/eu/fr/esrs/Header/ExtendedBasicHeader" xmlns:bh<nowiki>=</nowiki>"http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeader" xmlns:xsd<nowiki>=</nowiki>"http://www.w3.org/2001/XMLSchema" targetNamespace<nowiki>=</nowiki>"http://www.eurofiling.info/eu/fr/esrs/Header/ExtendedBasicHeader" elementFormDefault<nowiki>=</nowiki>"qualified" attributeFormDefault<nowiki>=</nowiki>"unqualified" version<nowiki>=</nowiki>"1">
-In XAdES-BES the signature value shall be computed in the usual way of XMLDSIG, over the data objects/s to be signed, and on the whole set of signed properties when present (SignedProperties element).
+<nowiki><xsd:import</nowiki> namespace<nowiki>=</nowiki>"http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeader" schemaLocation<nowiki>=</nowiki>"http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeader.xsd"/>
-Figure 12 — Structure of XAdES-BES
-In XAdES-BES, it's mandatory to protect the certificate with the signature, in one (at least) of the following ways:
+'''Step 2 '''
-*  Incorporating the SigningCertificate signed property. This property shall contain the reference and the digest value of the signing certificate. It MAY contain references and digest values of other certificates (that MAY form a chain up to the point of trust). In the case of ambiguities identfifying the actual signer's certificate, the applicathions SHOULD include the SigningCertificate property;
+Create our own elements as an extension of the basic header, for example:
-*  Incorporating the signing certificate within the ds:KeyInfo element, and signing at least the signing certificate.
+<nowiki><xsd:element</nowiki> name<nowiki>=</nowiki>"MyExtendedHeader" type<nowiki>=</nowiki>"MyExtendedHeaderType"/> <nowiki><xsd:complexType</nowiki> name<nowiki>=</nowiki>"MyExtendedHeaderType"> <nowiki><xsd:sequence></nowiki> <nowiki><!-- My new element --></nowiki> <nowiki><xsd:element</nowiki> name<nowiki>=</nowiki>"MyNewElement" type<nowiki>=</nowiki>"xsd:string"/>  <nowiki><!-- Basic Header elements --></nowiki> <nowiki><xsd:element</nowiki> ref<nowiki>=</nowiki>"bh:BasicHeader" maxOccurs<nowiki>=</nowiki>"1"/> <nowiki></xsd:sequence></nowiki> <nowiki></xsd:complexType></nowiki>
-Remember:
+The basic header elements should be used at the end of the extended schema, and they should only be used once.
-? denotes zero or one.
-+ denotes one or more.
+AnnexG(informative)Use cases for this CWA
-* denotes zero or more.
+G.1 Reporting entity to supervisor (1st level)
-Commission Decision 2011/130/EU states that the 'SigningCertificate' signed signature property shall contain the digest value (CertDigest) and IssuedSerial of the signer's certificate stored in ds:KeyINFO. The optional URI in 'SigningCertificate' field shall not be used. So, applications may look for the signer certificate in ds:KeyInfo on the basis of hash equivalence.
+In this use-case, the sender is the reporting entity, the receiver is the supervisor.
-A XAdES-BES signature MAY also contain the following properties: (copied from [http://uri.etsi.org/01903/v1.4.1/ts_101903v010401p.pdf|  ETSI TS 101 903, Version 1.4.1 (2009-06) page 15]):
-*  The SigningTime signed property;
+The security mechanisms applied to submission containers should be the same (and have the same order of application) as those applied to response containers.
-*  The DataObjectFormat signed property;
+G.2 Reporting entity to National Supervision Authority (NSA) to European Supervision Authority (ESA) (1st and 2nd level)
-*  The CommitmentTypeIndication signed property;
+In this case, the exchange model is used twice in a row with:
-*  The SignerRole signed property;
-*  The SignatureProductionPlace signed property;
+) exchange 1: the sender is the reporting entity, the receiver is the NSA;
-*  One or more IndividualDataObjectsTimeStamp or AllDataObjectTimeStamp signed properties;
+) exchange 2: the sender is the NSA, the receiver is the ESA.
-*  One or more CounterSignature unsigned properties.
+G.2.1 2-layer submission process with forwarding of information
-Figure 12 shows the structure of XAdES-BES.
+The NSA requires not only data for its own purpose, but also data in a separate container inside the original container in order to be able to forward this data to a subsequent regulator like an ESA. As a consequence, the ESA needs to know all the public key / certificate of the reporting entities (from which data are sent) as communication partners. Figure H.1 shows a 2-layer submission using containers to forward data to subsequent authorities as well as feedback to the respective sender.
-XAdES-BES is the minimum format for an electronic signature to be generated by the signer. On its own, it does not provide enough information for it to be verified in the long-term. XAdES-BES provides basic authentication and integrity protection, satisfying the legal requirements for electronic signatures as defined in the European Directive on electronic signatures.
-====XAdES-EPES====
+FigureHA.H.1— 2-layer submission using containers in containers to forward data to subsequent authorities and as well as feedback to the respective sender
-XAdES-EPES is the Explicit Policy based Electronic Signature, and extends the definition of an electronic signature to conform to the identified signature policy. XAdES-EPES incorporates the SignaturePolicyIdentifer element (as shown in Figure 6). This signed property indicates that a signature policy shall be used for signature validation. It MAY explicitly identify the signature policy.
+G.2.2 2-layer submission process with repackaging or regeneration
-Further information on signature policies is provided in ETSI TR 102 038. See above, in CAdES-EPES.
+After finishing the submission process from the reporting entity to the NSA, a separate, entirely independent submission process is started using either the original data from the entity (repackaging) or entirely new data prepared by the NSA (open regeneration). The ESA has only one communication partner, the NSA, of which it needs to know the public key / certificate. These approaches are illustrated in figures H.2 and H.3.
-See detailed specifications on pages 53/68 and 53/69 ''Commission Decission 2011/130/EU establishing minimum requirements for the cross-border processing of documents signed
+[[Image:clip_image038.jpg]]
-electronically'', available at
+Figure H.2— 2-layer submission repackaging data into new containers to send them to subsequent authorities
-[http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF| eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF]
-The properties of XAdES-EPES are summarized in the following figures, taken from [http://www.w3.org/TR/XAdES/#XML_Advanced_Electronic_Signature_Data_Structures|    http://www.w3.org/TR/XAdES/#XML_Advanced_Electronic_Signature_Data_Structures]
-[http://www.w3.org/TR/XAdES/#XML_Advanced_Electronic_Signature_Data_Structures| http://www.w3.org/TR/XAdES/images/XAdES-image001.gif]
+[[Image:clip_image040.jpg]]
+Figure H.3— 2-layer submission, completely new generation of data from NSA systems for subsequent authorities
-Figure: Illustration of a XAdES
-<code>
+Bibliography
-<table class="eg" cellpadding="5" >
-    <tr>
+<nowiki>[1]</nowiki> ETSI Technical Report 102 038 v1.1.1. Electronic Signatures and Infrastructures; XML format for signature policies. European Telecommunications Standards Institute. April 2004. http://docbox.etsi.org/EC_Files/EC_Files/tr_102038v010101p.pdf
-      <td><pre>                              XMLDSIG
-                                   |
-&lt;ds:Signature ID?&gt;- - - - - - - - -+- - - - -+
-  &lt;ds:SignedInfo&gt;                  |         |
-    &lt;ds:CanonicalizationMethod/&gt;   |         |
-    &lt;ds:SignatureMethod/&gt;          |         |
-    (&lt;ds:Reference URI? &gt;          |         |
-      (&lt;ds:Transforms&gt;)?           |         |
-      &lt;ds:DigestMethod&gt;            |         |
-      &lt;ds:DigestValue&gt;             |         |
-    &lt;/ds:Reference&gt;)+              |         |
-  &lt;/ds:SignedInfo&gt;                 |         |
-  &lt;ds:SignatureValue&gt;              |         |
-  (&lt;ds:KeyInfo&gt;)?- - - - - - - - - +         |
-                                             |
-  &lt;ds:Object&gt;                                |
-                                             |
-    &lt;QualifyingProperties&gt;                   |
-                                             |
-      &lt;SignedProperties&gt;                     |
-                                             |
-        &lt;SignedSignatureProperties&gt;          |
-          (SigningTime)                      |
-          (SigningCertificate)               |
-          (SignaturePolicyIdentifier)        |
-          (SignatureProductionPlace)?        |
-          (SignerRole)?                      |
-        &lt;/SignedSignatureProperties&gt;         |
-                                             |
-        &lt;SignedDataObjectProperties&gt;         |
-          (DataObjectFormat)*                |
-          (CommitmentTypeIndication)*        |
-          (AllDataObjectsTimeStamp)*         |
-          (IndividualDataObjectsTimeStamp)*  |
-        &lt;/SignedDataObjectProperties&gt;        |
-                                             |
-      &lt;/SignedProperties&gt;                    |
-                                             |
-      &lt;UnsignedProperties&gt;                   |
-                                             |
-        &lt;UnsignedSignatureProperties&gt;        |
-          (CounterSignature)*                |
-        &lt;/UnsignedSignatureProperties&gt;       |
-                                             |
-      &lt;/UnsignedProperties&gt;                  |
-                                             |
-    &lt;/QualifyingProperties&gt;                  |
-                                             |
-  &lt;/ds:Object&gt;                               |
-                                             |
-&lt;/ds:Signature&gt;- - - - - - - - - - - - - - - +
-                                             |
-                                          XAdES
-? denotes zero or one.
+<nowiki>[2]</nowiki> ETSI-XAdES, ETSI Technical Specification 101 903 V1.4.1. XML Advanced Electronic Signatures (XAdES). June 2009. European Telecommunications Standards Institute. http://uri.etsi.org/01903/v1.4.1/
-+ denotes one or more.
-* denotes zero or more.
-                       </pre>
-      </td>
+<nowiki>[3]</nowiki> ETSI Technical Specification 102 176-1 v2.0.0, Electronic Signatures and Infrastructures; Algorithms and Parameters for Secure Electronic Signatures; Part 1 Hash functions and asymmetric algorithms.19 November 2007. European Telecommunications Standards Institute. http://www.etsi.org/deliver/etsi_ts/102100_102199/10217601/02.00.00_60/ts_10217601v020000p.pdf
-    </tr>
-</table>
+<nowiki>[4]</nowiki> CWA 14170, Security requirements for signature creation applications. May 2004. European Committee for Standardization.
-</code>
-Figure: Structure of XAdES-EPES
-==Receiver==
+<nowiki>[5]</nowiki> CWA 14167-1, Security requirements for trustworthy systems managing certificates for electronic signatures — Part 1: System Security Requirements. June 2003. European Committee for Standardization.
-==Validation of signature==
+<nowiki>[6]</nowiki> CWA 14167-2, Security requirements for trustworthy systems managing certificates for electronic signatures — Part 2: cryptographic module for CSP signing operations with backup — Protection Profile - MCSO-PP. May 2004. European Committee for Standardization.
-Validation of an electronic signature requires:
+<nowiki>[7]</nowiki> CWA 15579, E-invoices and digital signatures. July 2006. European Committee for Standardization.
-*  A XML advanced electronic signature built on the format defined in W3C "XML-Signature Syntax and Processing" and ETSI "TS 101 903" with the incorporation of additional qualifying information. This XML advanced electronic signature will include:
+<nowiki>[8]</nowiki> Directive 1999/93/EC, Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999. Chapter 13 Volume 038 P. 50 – 58. [http://eur-lex.europa.eu/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoc&numdoc=31999L0093&model=guichett http://eur-lex.europa.eu/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoc&numdoc=31999L0093&model=guichett].
-*  references to the signed data object(s) (as specified in W3C "XML-Signature Syntax and Processing" and ETSI "TS 101 903");
+<nowiki>[9]</nowiki> 2011/130/EU, Commission Decision 2011/130/EU of 25February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market.
-*  signed properties (provided by the signer);
+<nowiki>[10]</nowiki> FIPS PUB 186-3, Digital Signature Standard. National Institute of Standards and Technologies. June 2009. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf
-*  the signature itself as defined in W3C "XML-Signature Syntax and Processing" and ETSI "TS 101 903" (see definitions).
+<nowiki>[11]</nowiki> FIPS PUB 180-4, Secure Hash Standards (SHS). March 2012. National Institute of Standards and Technology, U.S. Department of Commerce. [http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf]
-*  Validation data, which is the additional data needed to validate the electronic signature; this includes:
+<nowiki>[12]</nowiki> NIST SP 800-107 Revision1 Recommendation for applications using approved hash algorithms. Quynh Dang. August 2012. National Institute of Standards and Technology, U.S. Department of Commerce. http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf.
-*  certificates;
+<nowiki>[13]</nowiki> XMLDSIG-CORE. XML Signature Syntax and Processing (Second Edition). W3C Recommendation 10 June 2008. [http://www.w3.org/TR/xmldsig-core/ http://www.w3.org/TR/xmldsig-core/]
-*  revocation status information;
+<nowiki>[14]</nowiki> XMLENCR-CORE. XML Encryption Syntax and Processing. W3C Recommendation 10 December 2002. [http://www.w3.org/TR/xmlenc-core/ http://www.w3.org/TR/xmlenc-core/].
-*  time-stamp tokens from Time-Stamping Authorities (TSAs).
+<nowiki>[15]</nowiki> XML Encryption Requirements. W3C Note 4 March 2002. [http://www.w3.org/TR/xml-encryption-req http://www.w3.org/TR/xml-encryption-req]
-Signed data object(s) is the user's data that is signed. Enveloped signature shall be used, so the signature is over XML content found inside the signed (xml) document.
+<nowiki>[16]</nowiki> XMLENCR-CORE1 XML Encryption Syntax and Processing Version 1.1. W3C Recommendation. 11 April 2013. http://www.w3.org/TR/xmlenc-core1/.
-Signed properties include any additional information that shall be signed by the signer to conform to the signature policy or the present document (e.g. signing time).
+<nowiki>[17]</nowiki> Extensible Business Reporting Language (XBRL) 2.1 RECOMMENDATION - 2003-12-31. XBRL International (XII). http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31.doc
-The Validation Data may be collected by the signer and/or the verifier and shall meet the requirements of the signature policy. Additional data includes CA certificates as well as revocation status information in the form of certificate revocation lists (CRLs) or certificate status information provided by an on-line service.
+<nowiki>[18]</nowiki> ZIP File Format Specification Version: 6.3.3, September 1, 2012, PKWARE Inc. [http://www.pkware.com/documents/casestudies/APPNOTE.TXT http://www.pkware.com/documents/casestudies/APPNOTE.TXT]
-Additional data also includes time-stamps and other time related data used to provide evidence of the timing of certain events. It is required, as a minimum, that either the signer or verifier obtains a time-stamp over the signer's signature or a record shall be maintained and cannot be undetectable modified, of the electronic signature and the time when the signature was first validated.
+<nowiki>[19]</nowiki> NIST SP 800-57 part1, Recommendation for Key Management – Part 1: General (Revision 3). Authors: Elaine Barker, William Barker, William Burr, William Polk, and Miles Smid. July 2012. National Institute of Standards and Technology, U.S. Department of Commerce. [http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf].
-The validation process validates an electronic signature. The output status of the validation 8as defined in ETSI TS 101 903 v1.4.1) can be:
+<nowiki>[20]</nowiki> NIST SP 800 131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. Authors: Elaine Barker and Allen Roginsky. January 2011. National Institute of Standards and Technology, U.S. Department of Commerce. [http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf].
-*  Invalid: Either the signature format is incorrect, or the digital signature value fails verification;
+<nowiki>[21]</nowiki> NIST SP 800-56B, Recommendation for Pair-Wise, Key Establishment Schemes Using Integer Factorization Cryptography. Authors: Elaine Barker, Lily Chen, Andrew Regenscheid, and Miles Smid. August 2009. National Institute of Standards and Technology, U.S. Department of Commerce. [http://csrc.nist.gov/publications/nistpubs/800-56B/sp800-56B.pdf http://csrc.nist.gov/publications/nistpubs/800-56B/sp800-56B.pdf].
-*  Incomplete validation: The format and digital signature verifications have not failed, but there is insufficient information to determine if the electronic signature is valid (for example, all the required certificates are not available, or the grace period is not completed);
+<nowiki>[22]</nowiki> RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. February 2003. [http://www.ietf.org/rfc/rfc3447.txt http://www.ietf.org/rfc/rfc3447.txt].
-*  Valid: The signature has passed verification and it complies with the signature validation policy.
+<nowiki>[23]</nowiki> NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation. Methods and Techniques. Morris Dworkin. 2001. National Institute of Standards and Technology, U.S. Department of Commerce. [http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf].
-=Encryption=
+<nowiki>[24]</nowiki> RegOrg Registered Organization Vocabulary. W3C Working Group Note 01 August 2013. [http://www.w3.org/TR/vocab-regorg/ http://www.w3.org/TR/vocab-regorg/]. This is a continuative work of the EC’s ISA Core Vocabularies, May 2012. https://joinup.ec.europa.eu/asset/core_business/release/100
-http://www.w3.org/TR/xmlenc-core/
+<nowiki>[25]</nowiki> BestPractices, Best Practices on Common European Reporting Structures. Eurofiling 2013. http://www.wikixbrl.info/index.php?title=Best_Practices_on_Common_European_Reporting_Structures, [http://www.xbrlwiki.info/images/c/c0/Eurofiling_header_questionnaire-results.xls http://www.xbrlwiki.info/images/c/c0/Eurofiling_header_questionnaire-results.xls].
-This issue will be treated in a future version of the document
+<nowiki>[26]</nowiki> CEN, the European Committee for Standardization (CEN), Business Plan of the CEN Workshop on XBRL, Improving transparency in financial and business reporting, 30 May 2012, [http://cen.eurofiling.info/wp-content/upLoads/data/BusinessPlanCENWorkshoponXBRL20120530.pdf http://cen.eurofiling.info/wp-content/upLoads/data/BusinessPlanCENWorkshoponXBRL20120530.pdf].
-=Handling of file data container=
+<nowiki>[27]</nowiki> NIST SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. Morris Dworkin. 2001. National Institute of Standards and Technology, U.S. Department of Commerce. [http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf]
-This issue will be treated in a future version of the document
+<nowiki>[28]</nowiki> RFC 3447. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography. Specifications Version 2.1. J. Jonsson and B. Kaliski. RSA Laboratories. The Internet Society. [http://www.ietf.org/rfc/rfc3447.txt http://www.ietf.org/rfc/rfc3447.txt]
-=Facts and recommendations=
+<nowiki>[29]</nowiki> Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures
-This issue will be treated in a future version of the document
+<nowiki>[30]</nowiki> Commission Decision 2011/130/EU of 25February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market
-=Schema=
+<nowiki>[31]</nowiki> Federal Information Processing Standards Publication 186-3: Digital Signature Standard (National Institute of Standards and Technologies, U.S. Department of Commerce)
-==Instance feedback XML Schema==
+<nowiki>[32]</nowiki> Federal Information Processing Standards Publication 180-4: Secure Hash Standards (National Institute of Standards and Technologies, U.S. Department of Commerce)
-<code>
- <?xml version="1.0" encoding="utf-8" ?>
- <!--Created with Liquid XML Studio 2012 Developer Edition (Trial) 10.1.7.4256 (http://www.liquid-technologies.com)-->
- <xsd:schema xmlns="http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback" elementFormDefault="qualified" targetNamespace="http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
-    <xsd:element name="InstanceFeedback">
-        <xsd:complexType>
-            <xsd:sequence>
-                <xsd:element name="InstanceNameReference" type="xsd:string" minOccurs="1" maxOccurs="1" />
-                <xsd:element name="InstanceHashValue" type="InstanceHashValueType" minOccurs="0" maxOccurs="1"/>
-                <xsd:element name="InstanceValidationFlag" type="xsd:boolean" minOccurs="1" maxOccurs="1" />
-                <xsd:element name="XMLValidationResult" type="ValidationResultType" minOccurs="0" maxOccurs="1" />
-                <xsd:element name="XBRLValidationResult" type="ValidationResultType" minOccurs="0" maxOccurs="1" />
-                <xsd:element name="TransformationResult" type="ValidationResultType" minOccurs="0" maxOccurs="1" />
-            </xsd:sequence>
-        </xsd:complexType>
-    </xsd:element>
-    <xsd:complexType name="InstanceHashValueType">
-            <xsd:simpleContent>
-              <xsd:extension base="xsd:string">
-              <xsd:attribute name="HashAlgorithm" type="xsd:string" />
-           </xsd:extension>
-           </xsd:simpleContent>
-    </xsd:complexType>
-    <xsd:complexType name="ValidationResultType">
-        <xsd:sequence>
-            <xsd:element name="ValidationFlag" type="xsd:boolean" minOccurs="1" maxOccurs="1" />
-            <xsd:element name="ValidationPhase" type="xsd:string" minOccurs="0" maxOccurs="1" />
-            <xsd:element name="ValidationErrors" type="ValidationErrorsType" minOccurs="0" maxOccurs="1" />
-        </xsd:sequence>
-    </xsd:complexType>
-    <xsd:complexType name="ValidationErrorsType">
-        <xsd:sequence>
-            <xsd:element name="ValidationError" type="ErrorType" minOccurs="1" maxOccurs="unbounded" />
-        </xsd:sequence>
-    </xsd:complexType>
-    <xsd:complexType name="ErrorType">
-        <xsd:sequence>
-            <xsd:element name="ErrorCode" type="xsd:int" minOccurs="1" maxOccurs="1" />
-            <xsd:element name="ErrorNature" type="ErrorNatureType" minOccurs="0" maxOccurs="1" />
-            <xsd:element name="ErrorLocation" type="xsd:string" minOccurs="1" maxOccurs="1" />
-            <xsd:element name="ErrorDescription" type="xsd:string" minOccurs="1" maxOccurs="1" />
-            <xsd:element name="ErrorSeverity" type="ErrorSeverityType" minOccurs="0" maxOccurs="1" />
-        </xsd:sequence>
-    </xsd:complexType>
-    <xsd:simpleType name="ErrorNatureType">
-        <xsd:restriction base="xsd:string">
-            <xsd:enumeration value="Structural" />
-            <xsd:enumeration value="Content" />
-        </xsd:restriction>
-    </xsd:simpleType>
-    <xsd:simpleType name="ErrorSeverityType">
-        <xsd:restriction base="xsd:string">
-            <xsd:enumeration value="Info" />
-            <xsd:enumeration value="Warning" />
-            <xsd:enumeration value="Error" />
-            <xsd:enumeration value="Fatal" />
-        </xsd:restriction>
-    </xsd:simpleType>
- </xsd:schema>
-</code>
-==Instance feedback valid==
+<nowiki>[33]</nowiki> National Institute of Standards and Technologies, Special Publication 800-107, Recommendation for applications using approved hash algorithms
-<code>
-  <?xml version="1.0" encoding="UTF-8"?>
-  <ns:InstanceFeedback xmlns:ns="http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-      xsi:schemaLocation="http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback InstanceFeedback_v5.xsd ">
-     <ns:InstanceNameReference>annualReport2012_12345678.xbrl</ns:InstanceNameReference>
-     <ns:InstanceHashValue HashAlgorithm="md5">
-       d131dd02c5e6eec4 693d9a0698aff95c 2fcab58712467eab 4004583eb8fb7f89 55ad340609f4b302 83e488832571415a 085125e8f7cdc99f d91dbdf280373c5b
-       d8823e3156348f5b ae6dacd436c919c6 dd53e2b487da03fd 02396306d248cda0 e99f33420f577ee8 ce54b67080a80d1e c69821bcb6a88393 96f9652b6ff72a70
-     </ns:InstanceHashValue>
-     <ns:InstanceValidationFlag>true</ns:InstanceValidationFlag>
-  </ns:InstanceFeedback>
-</code>
-==Instance feedback errors==
+<nowiki>[34]</nowiki> W3C Recommendation XML Signature Syntax and Processing
-<code>
-   <?xml version="1.0" encoding="UTF-8"?>
-   <ns:InstanceFeedback xmlns:ns="http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-      xsi:schemaLocation="http://www.eurofiling.info/eu/fr/esrs/InstanceFeedback InstanceFeedback_v5.xsd ">
-      <ns:InstanceNameReference>annualReport2012_12345678.xbrl</ns:InstanceNameReference>
-      <ns:InstanceHashValue HashAlgorithm="md5">
-         d131dd02c5e6eec4 693d9a0698aff95c 2fcab58712467eab 4004583eb8fb7f89 55ad340609f4b302 83e488832571415a 085125e8f7cdc99f d91dbdf280373c5b
-         d8823e3156348f5b ae6dacd436c919c6 dd53e2b487da03fd 02396306d248cda0 e99f33420f577ee8 ce54b67080a80d1e c69821bcb6a88393 96f9652b6ff72a70
-      </ns:InstanceHashValue>
-      <ns:InstanceValidationFlag>false</ns:InstanceValidationFlag>
-      <ns:XMLValidationResult>
-          <ns:ValidationFlag>true</ns:ValidationFlag>
-      </ns:XMLValidationResult>
-      <ns:XBRLValidationResult>
-          <ns:ValidationFlag>false</ns:ValidationFlag>
-          <ns:ValidationErrors>
-             <ns:ValidationError>
-                <ns:ErrorCode>3301</ns:ErrorCode>
-                <ns:ErrorLocation>XBRL Line: 66. XBRL Column: 19953</ns:ErrorLocation>
-                <ns:ErrorDescription>
-                   Invalid content was found starting with element 'uk-gaap- pt:ProfitsLossOnOrdinaryActivitiesBeforeTax'.
-                   One of '{"http://www.xbrl.org/2003/instance":item, "http://www.xbrl.org/2003/instance":tuple, "http://www.xbrl.org/2003/instance":context,
-                   "http://www.xbrl.org/2003/instance":unit, "http://www.xbrl.org/2003/linkbase":footnoteLink}' is expected.
-                </ns:ErrorDescription>
-             </ns:ValidationError>
-          </ns:ValidationErrors>
-      </ns:XBRLValidationResult>
-   </ns:InstanceFeedback>
-</code>
-=Bibliography=
+<nowiki>[35]</nowiki> W3C Recommendation XML Encryption Syntax and Processing
-[1] xxx
+<nowiki>[36]</nowiki> XBRL International (XII), Extensible Business Reporting Language (XBRL) 2.1, Recommendation – 2003-12-31
-[2] xxx
+<nowiki>[37]</nowiki> PKWARE Inc., APPnotE.TXT - .ZIP File Format Specification

European Metadata Container

From XBRLWiki

Current revision

Contents

1 Scope

2 Normative references

3 Terms and definitions

4 Files in containers

4.1 Introduction

4.2 Data files

4.3 Container control files

4.3.1 Header file

4.3.2 Container feedback files

4.3.3 Instance feedback files

4.4 ZIP compressed file

4.5 Secured files

4.5.1 Encrypted file

4.5.2 Signed file

4.6 File naming conventions

4.6.1 Reserved file names

4.6.1.1C:\Users\eduardo\AppData\Local\Temp header.xml

4.6.2 Instance feedback file name

4.6.3 Reserved file name suffixes

4.6.4 Reserved extended suffixes

4.6.4.1 .signed.xml

4.6.4.2 .encrypted.xml

4.6.4.3 .containerfeedback.xml

4.6.4.4 .instancefeedback.xml

5 Container

5.1 Submission container

5.2 Response container

6 Primitive functions

6.1 Compression functions

6.1.1 Creating a ZIP compressed file

6.1.2 Expanding a ZIP compressed file

6.2 Security functions

6.2.1 Encrypting a file

6.2.2 File name changes upon encryption

6.2.3 Decrypting a file

6.2.4 Signing a file

6.2.5 Requirements

6.2.6 Electronic signature to use

6.2.7 File name changes upon signature

6.2.8 Validating and extracting a signed file

6.3 Creating a submission container

6.3.1 Header schema structure

6.3.2 Predefined standard use-cases of ExtendedHeader schema

6.3.3 Creating a specific ExtendedHeader schema

6.3.4 Creating a header file

6.4 Creating a response container

6.4.1 Creating a container feedback file

6.4.2 Creating Instance feedback (Validation, usually only for XBRL)

7 Exchange model

7.1 Phase 1: the sender creates a submission container, applies all security mechanisms required and transmits it to the receiver

7.2 Phase 2: the receiver processes the security layer(s) on the container and all the files within

7.3 Phase 3: receiver generates a positive / negative acknowledgement for the reception of the submission container

7.4 Phase 4: the receiver processes the contents of the container

7.5 Phase 5 (optional): the receiver returns the validation result of the data files in the response container

Views

Personal tools

Navigation

Search

Toolbox