European Metadata Container
From XBRLWiki
Revision as of 17:57, 16 March 2013 (edit) Iboixo (Talk | contribs) (→Container format and structure) ← Previous diff |
Current revision (11:13, 20 January 2014) (edit) Iboixo (Talk | contribs) |
||
Line 1: | Line 1: | ||
- | <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: | ||
- | 1) 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 = |
- | 2) 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: |
- | 1) 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.; |
- | 2) 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'' |
- | * … | ||
- | 3) 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. |
- | * … | + | 3.1 |
- | 4) 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). | + | 3.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.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 | + | 3.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). | + | 3.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. | + | 3.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 | + | 3.7 |
- | =Terms and definitions= | + | positive acknowledgement |
+ | |||
+ | <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> | ||
+ | |||
+ | 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 | ||
+ | |||
+ | |||
+ | = 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: | ||
+ | |||
+ | 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. | ||
+ | |||
+ | [[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. | ||
- | For the purposes of this document, the following terms and definitions apply. | ||
- | ==structural validations== | + | === 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). | ||
- | XML schema validations and structural XBRL validations (XBRL 2.1, Dimensions 1.0 etc. or higher) | ||
- | ==content-related validations== | + | [[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) | ||
- | validations like calculations or formulas | ||
- | ==full container== | + | The table 3 describes the structure of such a header. |
- | 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 | + | ;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''' | ||
- | ==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. | ||
- | 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;"| 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. | ||
- | ==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;"| RegisteredOrganizationVocabulary | ||
- | a regulatory body that defines the content and structure of filings for the regulated entities as well as the corresponding XBRL taxonomies | + | (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> | ||
- | ==declarer== | + | 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 |
- | 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 | + | |} |
+ | Every receiver may thus define an ExtendedHeader structure in accordance with the local needs, giving it an adequate namespace. | ||
- | ==technical sender== | ||
- | role of an entity responsible for creating the header, the package, the compression, the signature, the encryption and the submission (transport) to the Authority | + | === 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». | ||
- | ==functional sender== | ||
- | role of an entity responsible for figures in the reports, i.e. the correct content of XBRL Instance Documents | + | ;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''' | ||
- | ==authority== | + | |- |
+ | | 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. | ||
- | 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 | + | '''Namespace:''' [http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly] |
- | ==initial container== | + | '''XSD URL:''' [http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xsd http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xsd] |
- | 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 | + | '''XML sample instance URL:''' [http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xml http://www.eurofiling.info/eu/fr/esrs/Header/BasicHeaderOnly.xml] |
- | ==updated 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> | ||
- | 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 | + | All fields related to «Transport» issues have been removed as these are out of scope of this CWA. |
- | =Base requirements= | + | '''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] |
- | 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. | + | '''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] |
- | 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). | + | '''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] |
- | 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. | + | |- |
+ | | 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. | ||
- | This resulting compressed package shall then be signed to ensure the authenticity of the submitter. | + | '''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] |
- | The signed and compressed package shall then be ciphered to ensure the confidentiality of the report. | + | '''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] |
- | 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: | + | '''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] |
- | * Decryption: From this phase the NSA will obtain the signed envelope; | + | |} |
+ | === 6.3.3 Creating a specific ExtendedHeader schema === | ||
+ | The guidelines for the creation of a specific ExtendedHeader schema are given in Annex G. | ||
- | * Signature: From this phase the NSA will check the authenticity of the message; | + | === 6.3.4 Creating a header file === |
+ | The creation of a header file consists of the actions: | ||
- | * Unpacking and Uncompressing: From this phase the NSA will get the header with the metadata and the XBRL instance documents; | + | * assembling the data files; |
- | * XBRL validation: a full XBRL validation will be done for each XBRL instance documents. | + | * 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 |
- | 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. | + | == 6.4 Creating a response container == |
+ | The creation of a response container consists of the actions presented in the following paragraphs. | ||
- | =XBRL instance documents 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. | ||
- | ==Major parts and parties in workflow== | + | === 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. | ||
- | 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. | ||
- | Logically, the communication is limited to an interaction of the declarer with the regulator. There are two ways of that communication: | + | = 7 Exchange model = |
- | * submission of a reporting container to the 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. |
- | Figure 1 — Report submission to regulator | + | The exchange of information composes of the phases presented in the following paragraphs. |
- | * return of a feedback container to the declarer. | + | == 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. | ||
- | Figure 2 — Feedback from regulator | + | == 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. | ||
- | ==Submission of the report by the declarer== | + | [[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 | ||
- | 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. | ||
- | Figure 3 shows the use cases of issuing XBRL Instance documents to the authority. All these use cases shall be done by the 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.). |
- | Figure 3 — Use Cases: Issuing (Declarer) | ||
- | ===Use Cases=== | + | == 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). | ||
- | * 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; | + | The acknowledgement will be included into the response container in phase 5 |
- | * Create header: the declarer shall create the header as specified in the second document defined within this CWA; | ||
- | * 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; | + | == 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. | ||
- | * 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; | + | 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). |
- | * 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; | + | 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. |
- | * Send to authority: The encrypted package shall be sent to the authority; | ||
- | * 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. | + | == 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. | ||
- | ==Receiving of the report by the authority and return of the feedback container== | + | Unlike the submission container, a response container shall not include header information. |
- | The main objective here is to gain access by the authority of the data inside the XBRL instance documents. | + | 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 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 exchange model can thus be presented as in figure 7. |
- | Figure 4 presents the use cases for receiving the package. All these use cases shall be done by the authority. | ||
- | Figure 4 — Use Cases: Receiving (Authority) | + | [[Image:clip_image022.jpg]] |
+ | ;Figure 7— Illustration of the exchange model | ||
- | ===Use Cases=== | + | AnnexA(normative)Items that shall be defined in the instructions |
- | * Receiving: Receive the encrypted container from the declarer; | + | A.1Introduction |
- | * Encryption validation: Decrypt the data to obtain the signed package. Note that this is the security layer; | + | These are some questions to which any institution willing to use the CWA has to give clear answers to in its instructions. |
- | * Electronic signature validation: This validation shall assure the authenticity of the package; | ||
- | * Uncompress and unpack: By doing this, direct access to XBRL Instance documents can be allowed; | + | A.2Container structure |
- | * 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; | + | ;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 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; | + | |- |
+ | | 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 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 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 | ||
- | * 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 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)» | ||
- | * Pack and compress feedback.xml: The feedback shall be packed and compressed according to chapter "Packaging and compression" of this document; | + | |} |
+ | A.3Header | ||
- | * 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; | + | 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. |
- | * 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; | + | ;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''' | ||
- | * Send feedback to the Declarer: The feedback shall be sent to the declarer. | + | |- |
+ | | 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 | ||
- | ==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><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 | ||
- | 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><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> | ||
- | 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><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 | ||
- | 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><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 | ||
- | 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. | ||
- | Figure 5 — Example of a timeline of submission of initial and update containers | + | 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 |
- | =Container format and structure= | + | |- |
+ | | 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) | ||
- | The container structure shall use the following layers: | + | |} |
+ | A.4Lists of codes accepted | ||
- | Figure 6 — Layers and structure of a container | + | A table like table A.3 (defining identifiers accepted both for legal entities and for persons) should explain which codes are allowed. |
- | The standards chosen for the different layers will be described as follows: | + | ;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''' | ||
- | * [[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;"| <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> | ||
- | * signature: chapter 8; | + | |} |
+ | AnnexB(informative)Supplementary items that may be useful in the instructions | ||
- | * encryption: chapter 9. | + | ;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''' | ||
- | 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. | + | |- |
+ | | 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» | ||
- | 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;"| 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 | ||
- | 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;"| 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. | ||
- | 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;"| 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) | ||
- | XBRL instances should always have extension .xbrl (neither .xml nor .XML nor .XBRL) | + | |} |
+ | AnnexC(informative)Explanations on header schema | ||
- | 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. | + | 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". |
- | 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 XML Schema StandardHeaderWithoutRegOrg is depicted in figures C.1 to C.4. |
- | Figure 8 — Dependencies among files in the container | + | [[Image:clip_image024.jpg]] |
+ | ;Figure C.1— StandardHeaderWithoutRegOrg (TechnicalSender, ContentProducer and ReportingEntity) | ||
- | ==Header== | + | [[Image:clip_image026.jpg]] |
+ | ;Figure C.2— ReportingProcessRoleType | ||
- | Defined in the "Improving transparency in financial and business reporting — Metadata container and compliance tools — Part 1 Header". | + | [[Image:clip_image028.jpg]] |
+ | ;Figure C.3— PersonResponsibleReportingType | ||
- | ==XBRL Instance document(s) == | + | [[Image:clip_image030.jpg]] |
+ | ;Figure C.4— StandardHeaderWithoutRegOrg (ReportingDataContext, ReportOperationalContext and File) | ||
- | ==Feedback== | ||
- | In case a correct submission container was received, it shall return a feedback container structured as follows: | + | ;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''' | ||
- | Figure 9 — 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;"| | ||
- | 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;"| 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;"| | ||
- | 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;"| 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 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;"| 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. | ||
- | 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;"| 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. | ||
- | ===Scope=== | + | |- |
+ | | 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 | ||
- | 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;"| 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 | ||
- | 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;"| '''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;"| | ||
- | 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;"| 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). | ||
- | 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;"| 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. | ||
- | ===Container feedback=== | + | Possible values: "DataInstance", "OtherFile", "SignedAndEncryptedSubcontainer", "SignedSubcontainer", "CompressedOnlySubcontainer" |
- | This issue will be treated in a future version of the document | + | |- |
+ | | 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 | ||
- | ====Namespace==== | + | |- |
+ | | 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 | ||
- | 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;"| '''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;"| | ||
- | ====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;"| 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 | ||
- | ===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;"| 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 | ||
- | ====Namespace==== | + | |- |
+ | | 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 | ||
- | 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;"| '''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 element types==== | + | |- |
+ | | 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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 | ||
- | * 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;"| 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 | ||
- | * 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;"| '''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;"| | ||
- | * 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;"| 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 | ||
- | * 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;"| 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 | ||
- | 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;"| 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 | ||
+ | |- | ||
+ | | 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;"| | ||
- | <table border="1"> | + | |- |
- | <th width="20%">Element name</th><th width="10%">Type</th><th width="10%"> Occurrence</th><th width="20%"> Usage</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;"| PersonResponsibleReporting |
+ | | 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:0.035cm solid #808080;padding:0.049cm;"| Sequence of information describing the person that is in charge of the reporting | ||
- | <tr><td>InstanceFeedback</td><td> </td><td> </td><td></td><td>the root element, validation consists of separate validation sections</td></tr> | + | |- |
- | <tr><td>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;"| PersonResponsibleReportingIdentifier |
- | <tr><td>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;"| LegalIdentifierType |
- | <tr><td>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 Identifier of 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>XBRLValidationResult</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> 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> 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> 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> 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> 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> ErrorNature</td><td> ErrorNatureType</td><td> ?</td><td></td><td> The nature of the error</td></tr> | + | |
- | <tr><td> 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> ErrorDescription</td><td> text</td><td> 1</td><td></td><td> a description of the found error</td></tr> | + | |
- | <tr><td> 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;"| 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 | ||
- | ==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;"| '''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;"| | ||
- | 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;"| 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 | ||
- | 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;"| 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 | ||
- | ==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;"| 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 | ||
- | 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;"| '''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 | ||
- | 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;"| '''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 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;"| 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) | ||
- | 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;"| 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) | ||
- | =Signature= | + | |- |
+ | | 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") | ||
- | 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;"| 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. | ||
- | 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. | + | Possible values: "solo head office excluding branches", "solo head office including branches", "solo branch only", "sub-consolidated", "consolidated" |
- | 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). | + | |- |
+ | | 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 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;"| '''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 signer, | + | |- |
+ | | 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") | ||
- | * The verifier, | + | |- |
+ | | 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 | ||
- | * 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;"| 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 arbitrator. | + | |- |
+ | | 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 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;"| 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 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;"| 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 | ||
- | 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: | + | |} |
+ | AnnexD(informative)Documentation of the container feedback schema | ||
- | * User certificates, | + | The present chapter describes the XML Schema ContainerFeedback that is depicted in figure D.1. |
- | * Cross-certificates, | ||
- | * Time-stamp tokens and | + | [[Image:clip_image032.jpg]]DA. |
+ | ;Figure D.1— Visualisation of the container feedback schema (ContainerFeedback.xsd) | ||
- | * Certificate Revocation Lists (CRLs), Authority revocation list (ARLs), Online Certificate Status Provider | ||
- | (OSCP) responses. | + | In table D.1, there is supplementary information on the schema describing: |
- | The Arbitrator is the entity that arbitrates in disputes between a signer and a verifier. | + | * type: the type of the element in the schema and |
- | == Signature requirements== | + | * description and usage: a narrative explanation for the elements and a recommendation for the scenario in which the element should be used. |
- | These are the signature requirements that were taken into account: | + | ;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''' | ||
- | * Provide non-repudiation; | + | |- |
+ | | 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 | ||
- | * 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;"| 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 | ||
- | * 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;"| 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 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;"| 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 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;"| 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 | ||
- | * Shall include information about policy to verify electronic signature; | + | true = container ok |
- | * Avoid the use of MD5 or SHA-12) ; | + | false = errors found in at least 1 phase of the reception of the container |
- | * Long term validation is not needed, as signature should be validated in a limited time-frame. | + | |- |
+ | | 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". | ||
- | ==Signer== | ||
- | 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. | + | |- |
+ | | 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;"| | ||
- | 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;"| 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". | ||
- | 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;"| 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 | ||
- | 2 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) | + | false = errors found in the validation phase |
- | Packaged with signer’s public key (certificate) | + | |- |
+ | | 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". | ||
- | 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;"| '''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;"| | ||
- | 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;"| 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 | ||
- | ==Signing process== | + | |- |
+ | | 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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 | ||
- | 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;"| '''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" | ||
- | Note that: | + | |- |
+ | | 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 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;"| '''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 BES is an particular form of XAdES; | + | |} |
+ | AnnexE(informative)Documentation of the instance feedback schema | ||
- | * XAdES EPES is an extension to XAdES BES. | + | The present chapter describes the XML Schema InstanceFeedback that is depicted in figure E.1. |
- | The selected standard for digital signing the compressed package is XAdES-EPES. | + | [[Image:clip_image034.jpg]] |
+ | ;Figure E.1— Visualisation of the instance feedback schema (InstanceFeedback.xsd) | ||
- | ===XMLDSIG=== | + | In table E.1, there is supplementary information on the schema describing: |
- | 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. | + | * type: the type of the element in the schema and |
- | A fundamental feature of XML Signature is the ability to sign only specific portions of the XML tree, rather than the complete document. | + | * description and usage: a narrative explanation for the elements and a recommendation for the scenario in which the element should be used. |
- | 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. | + | ;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''' | ||
- | Signatures are related to data objects via URIs. Within a XML document, signatures are related to local data objects via fragment identifiers. | + | |- |
+ | | 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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. | ||
- | 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;"| 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 | ||
- | 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. | + | true = all validations successful |
- | Figure 11 summarise the structure of a XML signature. | + | false = errors found in at least 1 validation phase |
- | Basic steps to create a XML signature include: | + | |- |
+ | | 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". | ||
- | 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;"| 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;"| | ||
- | e) Calculate the digest of each resource. Each referenced resource is specified through a <Reference> | + | |- |
+ | | 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 | ||
- | 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 | ||
- | f) Collect the Reference elements (with their associated digest) within a <SignedInfo> element; | + | false = errors found in the validation phase |
- | g) Signing: Compute the signature of the <SignedInfo> element, and put the signature value in a | + | |- |
+ | | 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". | ||
- | <SignatureValue> element; | + | |- |
+ | | 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;"| | ||
- | h) Add key information: If keying information (X509 certificate) is to be included, it will be placed in a | + | |- |
+ | | 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 | ||
- | <KeyInfo> element. The public key needed to verify signature shall be included here and | + | |- |
+ | | 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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 | ||
- | ===XAdES=== | + | |- |
+ | | 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 | ||
- | 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;"| 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 | ||
- | 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;"| 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" | ||
- | * 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;"| 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 " | ||
- | * Supports XML package or separate files; | + | |} |
+ | AnnexF(informative)Guidelines on how to extend the basic header | ||
- | * Support multiple signatures applied in parallel, serial by repeated signing; | + | '''Step 1''' |
- | * Supports a visual signature appearance (depending on the application); | + | 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: |
- | * Provides long-term validity. | + | <nowiki><?xml version="1.0" encoding="UTF-8"?></nowiki> |
- | ETSI TS 101 903 defines four forms of XML Advanced Electronic Signatures, namely the Basic Electronic | + | <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"> |
- | Signature (XAdES-BES), the Explicit Policy based Electronic Signatre (XAdES-EPES), and the Electronic | + | <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"/> |
- | Signature with Validation Data (XAdES-T and XAdES-C). | ||
- | TC XBRL WI XBRL002:2012 (E) 25 | + | '''Step 2 ''' |
- | ====XAdES-BES==== | + | Create our own elements as an extension of the basic header, for example: |
- | 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: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> |
- | Figure 12 — Structure of XAdES-BES | + | The basic header elements should be used at the end of the extended schema, and they should only be used once. |
- | In XAdES-BES, it's mandatory to protect the certificate with the signature, in one (at least) of the following ways: | ||
- | * 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; | + | AnnexG(informative)Use cases for this CWA |
- | * Incorporating the signing certificate within the ds:KeyInfo element, and signing at least the signing certificate. | + | G.1 Reporting entity to supervisor (1st level) |
- | Remember: | + | In this use-case, the sender is the reporting entity, the receiver is the supervisor. |
- | ? denotes zero or one. | ||
- | + denotes one or more. | + | The security mechanisms applied to submission containers should be the same (and have the same order of application) as those applied to response containers. |
- | * denotes zero or more. | + | G.2 Reporting entity to National Supervision Authority (NSA) to European Supervision Authority (ESA) (1st and 2nd 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 case, the exchange model is used twice in a row with: |
- | 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; | + | 1) exchange 1: the sender is the reporting entity, the receiver is the NSA; |
- | * The DataObjectFormat signed property; | + | 2) exchange 2: the sender is the NSA, the receiver is the ESA. |
- | * The CommitmentTypeIndication signed property; | + | G.2.1 2-layer submission process with forwarding of information |
- | * The SignerRole signed property; | + | 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. |
- | * The SignatureProductionPlace signed property; | ||
- | * One or more IndividualDataObjectsTimeStamp or AllDataObjectTimeStamp signed properties; | + | 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 |
- | * One or more CounterSignature unsigned properties. | + | G.2.2 2-layer submission process with repackaging or regeneration |
- | Figure 12 shows the structure of XAdES-BES. | + | 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. |
- | 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. | + | [[Image:clip_image038.jpg]] |
+ | Figure H.2— 2-layer submission repackaging data into new containers to send them to subsequent authorities | ||
- | ====XAdES-EPES==== | ||
- | 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. | + | [[Image:clip_image040.jpg]] |
+ | Figure H.3— 2-layer submission, completely new generation of data from NSA systems for subsequent authorities | ||
- | Further information on signature policies is provided in ETSI TR 102 038. See above, in CAdES-EPES. | ||
- | 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 | + | Bibliography |
- | electronically'', available at | + | |
- | [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] | + | <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 |
- | [http://www.w3.org/TR/XAdES/#XML_Advanced_Electronic_Signature_Data_Structures| http://www.w3.org/TR/XAdES/images/XAdES-image001.gif] | + | <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/ |
- | Figure: Illustration of a XAdES | + | <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 |
- | <code> | + | <nowiki>[4]</nowiki> CWA 14170, Security requirements for signature creation applications. May 2004. European Committee for Standardization. |
- | <table class="eg" cellpadding="5" > | + | |
- | <tr> | + | <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. |
- | <td><pre> XMLDSIG | + | |
- | | | + | |
- | <ds:Signature ID?>- - - - - - - - -+- - - - -+ | + | |
- | <ds:SignedInfo> | | | + | |
- | <ds:CanonicalizationMethod/> | | | + | |
- | <ds:SignatureMethod/> | | | + | |
- | (<ds:Reference URI? > | | | + | |
- | (<ds:Transforms>)? | | | + | |
- | <ds:DigestMethod> | | | + | |
- | <ds:DigestValue> | | | + | |
- | </ds:Reference>)+ | | | + | |
- | </ds:SignedInfo> | | | + | |
- | <ds:SignatureValue> | | | + | |
- | (<ds:KeyInfo>)?- - - - - - - - - + | | + | |
- | | | + | |
- | <ds:Object> | | + | |
- | | | + | |
- | <QualifyingProperties> | | + | |
- | | | + | |
- | <SignedProperties> | | + | |
- | | | + | |
- | <SignedSignatureProperties> | | + | |
- | (SigningTime) | | + | |
- | (SigningCertificate) | | + | |
- | (SignaturePolicyIdentifier) | | + | |
- | (SignatureProductionPlace)? | | + | |
- | (SignerRole)? | | + | |
- | </SignedSignatureProperties> | | + | |
- | | | + | |
- | <SignedDataObjectProperties> | | + | |
- | (DataObjectFormat)* | | + | |
- | (CommitmentTypeIndication)* | | + | |
- | (AllDataObjectsTimeStamp)* | | + | |
- | (IndividualDataObjectsTimeStamp)* | | + | |
- | </SignedDataObjectProperties> | | + | |
- | | | + | |
- | </SignedProperties> | | + | |
- | | | + | |
- | <UnsignedProperties> | | + | |
- | | | + | |
- | <UnsignedSignatureProperties> | | + | |
- | (CounterSignature)* | | + | |
- | </UnsignedSignatureProperties> | | + | |
- | | | + | |
- | </UnsignedProperties> | | + | |
- | | | + | |
- | </QualifyingProperties> | | + | |
- | | | + | |
- | </ds:Object> | | + | |
- | | | + | |
- | </ds:Signature>- - - - - - - - - - - - - - - + | + | |
- | | | + | |
- | XAdES | + | |
- | ? denotes zero or one. | + | <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. |
- | + denotes one or more. | + | |
- | * denotes zero or more. | + | |
- | </pre> | + | |
- | </td> | + | <nowiki>[7]</nowiki> CWA 15579, E-invoices and digital signatures. July 2006. European Committee for Standardization. |
- | </tr> | + | |
- | </table> | + | <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]. |
- | </code> | + | |
- | Figure: Structure of XAdES-EPES | + | |
- | ==Receiver== | + | <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. |
- | ==Validation of signature== | + | <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 |
- | Validation of an electronic signature requires: | + | <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] |
- | * 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>[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. |
- | * references to the signed data object(s) (as specified in W3C "XML-Signature Syntax and Processing" and ETSI "TS 101 903"); | + | <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/] |
- | * signed properties (provided by the signer); | + | <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/]. |
- | * the signature itself as defined in W3C "XML-Signature Syntax and Processing" and ETSI "TS 101 903" (see definitions). | + | <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] |
- | * Validation data, which is the additional data needed to validate the electronic signature; this includes: | + | <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/. |
- | * certificates; | + | <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 |
- | * revocation status information; | + | <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] |
- | * time-stamp tokens from Time-Stamping Authorities (TSAs). | + | <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]. |
- | 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>[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]. |
- | 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>[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]. |
- | 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>[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]. |
- | 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>[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]. |
- | 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>[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 |
- | * Invalid: Either the signature format is incorrect, or the digital signature value fails verification; | + | <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]. |
- | * 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>[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]. |
- | * Valid: The signature has passed verification and it complies with the signature validation policy. | + | <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] |
- | =Encryption= | + | <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] |
- | http://www.w3.org/TR/xmlenc-core/ | + | <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 |
- | =Handling of file data container= | + | <nowiki>[31]</nowiki> Federal Information Processing Standards Publication 186-3: Digital Signature Standard (National Institute of Standards and Technologies, U.S. Department of Commerce) |
- | This issue will be treated in a future version of the document | + | <nowiki>[32]</nowiki> Federal Information Processing Standards Publication 180-4: Secure Hash Standards (National Institute of Standards and Technologies, U.S. Department of Commerce) |
- | =Facts and recommendations= | + | <nowiki>[33]</nowiki> National Institute of Standards and Technologies, Special Publication 800-107, Recommendation for applications using approved hash algorithms |
- | This issue will be treated in a future version of the document | + | <nowiki>[34]</nowiki> W3C Recommendation XML Signature Syntax and Processing |
- | =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 |
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 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.
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
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
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.
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.
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
A Zip compressed file is a set of one or more files compressed together (ZIP [18]).
4.5 Secured files
The following chapters describe the files to which security operations have been applied.
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]).
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]).
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
- 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.
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
6 Primitive functions
The present chapter describes the primitive functions required to put in place the present CWA.
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).
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
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.
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 » |
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;
- 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.
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]).
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» |
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.
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.
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/StandardHeaderWithRegOrg XSD URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.xsd XML sample instance URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithRegOrg.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/StandardHeaderWithoutRegOrg XSD URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xsd XML sample instance URL: http://www.eurofiling.info/eu/fr/esrs/Header/StandardHeaderWithoutRegOrg.xml |
6.3.3 Creating a specific ExtendedHeader schema
The guidelines for the creation of a specific ExtendedHeader schema are given in Annex G.
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
6.4 Creating a response container
The creation of a response container consists of the actions presented in the following paragraphs.
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.
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.
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.
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.
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.).
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
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.
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
|
<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.
- 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> <!-- My new element --> <xsd:element name="MyNewElement" type="xsd:string"/> <!-- Basic Header elements --> <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