Emile Bartolé CEN/WS XBRL: Improving transparency in financial and business reporting CWA2 final deliveries 1CWA2

Objectives of CWA2 Dual objective of CWA2: standardize The way of submitting instances, a container with standardized Encryption Digital signature Compression … The way of transmitting the usual metadata that determine the context of an xbrl reporting instance the sender of the document contact details date and time of submission … Page 2CWA2

Exchange model Subnission container Receiver encrypted (optional) signed (optional) Response container Sender Containerfeedback file Rest of the Feedback container encrypted (optional) signed (optional)

Submission container examples

Standards used: Compression & Hash Zip as defined in SHA256 as defined in

Standards used: Digital signature The file structure generated by the signature SHALL be XAdES-BES/EPES using RSA with SHA512 implemented in accordance with 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

Standards used: Encryption W3C Encryption using key transport RSA-OAEP and encrypting data with AES256.

Reserved names & suffixes NAME: header.xml exclusively reserved for headers in accordance with the present CWA SUFFIX:.signed.xml exclusively reserved for signed files SUFFIX:.encrypted.xml exclusively reserved for encrypted files SUFFIX:.containerfeedback.xml exclusively reserved for files complying with the ContainerFeedback schema SUFFIX:.instancefeedback.xml exclusively reserved for files complying with the InstanceFeedback schema.

File name change upon signature (equivalent for encryption) File to signName of the signed fileFilename inside the XML signature file LolLol.signed.xml Same as « File to sign » Lol.pdfLol.signed.xml Same as « File to sign » Lol.zipLol.signed.xml Same as « File to sign » Lol.signed.xml Same as « File to sign » Lol.encrypted.xmlLol.signed.xml Same as « File to sign »

Container.signed.xml Container.zip Sign with a first signature and replace extension header.xml file1.xbrl file2.xbrl file3.xbrl Compress Container.encrypted.xml Encrypt and replace extension Container.signed.xml Sign with a second signature and replace extension Filename in XML: Container.zip Filename in XML: Container.signed.xml Container creation example

Container.encrypted.xml Container.signed.xml Decrypt and extract file Container.signed.xml Validate first signature and extract file Container.zip Validate second signature and extract file header.xml file1.encrypted.xml file2.signed.xml file3.xbrl container.zip Uncompress Filename in XML: Container.zip Filename in XML: Container.signed.xml header.xml file1.xbrl file2.xbrl file3.xbrl container.zip header.xml file1.signed.xml file2.xbrl file3.xbrl container.zip Container reception example

Extensible Header BasicHeader RegisteredOrganizationVocabulary ExtendedHeader OtherModule(s) See also Core Business Vocabulary as an XBRL taxonomy at

BasicHeader

Standard vs customized Headers Use-caseCharacteristics StandardHeader BasicHeaderOnly This header imports the BasicHeader « as is », makes no extensions of it and does not import the RegisteredOrganizationVocabulary as it uses none of its fields. Namespace: XSD URL: XML sample instance URL: StandardHeader WithRegOrg This header structure reflects the survey made within the Eurofiling BestPractices efforts which had given the results documented in All fields related to « Transport » issues have been removed as these are out of scope of this CWA. Namespace: XSD URL: XML sample instance URL: StandardHeader WithoutRegOrg This header 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: XSD URL: Sample instance URL: Fully customizedExtend it according to your own needs !

Response containers Response container Response.containerfeedback.xml Report1_Feedback instance_1.instancefeedback.xml instance_2.instancefeedback.xml … instance_n.instancefeedback.xml Report1_Feedback_Visual instance_1.xls instance_2.xls … instance_n.xls Report2_Feedback instance_1.instancefeedback.xml instance_2.instancefeedback.xml … instance_m.instancefeedback.xml Submission container header.xml Report1_XBRL instance_1.xbrl instance_2.xbrl … instance_n.xbrl Report2_XML instance_1.xml instance_2.xml … instance_m.xml

Feedback files Container feedback files - confirming (or not) the success of the reception of a submission container Instance feedback files - Result of the (XBRL-) validation of every submitted data file

Selected comments from consultation Why not to use XBRL for header / containerfeedback / instancefeedback -integrating RegOrg is technically not possible -container supports multiple formats (e.g. XML, CSV etc.), not only XBRL instances -XML more appropriate to carry that type of information Why not to restrict the CWA to only « stable, system-relevant » parts (envelope) and leave out unstable, business-related parts (header) -The CWA’s definition required « metadata » to be covered -The chosen aproach (extensible header) should give enough flexibility to deal with unstable business-related parts CWA2 specification unnecessarily restricts the algorithms used (to AES-256 in this case). Commonly available implementations support a much wider range of algorithms, and in principle, it should be up to the receiver to specify an acceptable set of algorithms. As the specification currently stands, it will need to be modified whenever AES-256 is no longer considered secure. The proposition to allow a choice of different algorithms was submitted to the coordination of this project as well as to the NEN. Both confirmed that in order to prevent confusion on how the standard is used, there shall be an exact requirement on how the standard is used; the algorithms shall be determined in a clear, unique way. The algorithms were chosen to respect the state of the art security considerations. Should security issues occur, a follow-up CWA may be required. The Registered Organization Vocabulary is very large, with no clear alignment with the metadata that receivers wish to collect. While its use is optional, it is doubtful that it's ever an appropriate choice. If this level of detail were required along with the main submission, XBRL would be a much more robust solution. With the mechanism of extensible headers, no one is forced to use registered organisation vocabulary. As it is an official standard supported by the European Union, we produced a header version enabling its use.

Thanks for your attention Page 18 Comments or questions? CWA2