The solution support must support signing of Inline XBRL, xBRL-XML, xBRL-CSV, and xBRL-JSON reports. Signatures must include all files that form part of the report, including:
It must be possible for a signature to include external dependencies, including:
It must also be possible for a signature to not include such external dependencies.
There is not agreement within the Working Group on this requirement, particularly regarding base taxonomy files. There is general agreement that resources (graphics, CSS) supporting an Inline XBRL Report should be included in a report package, and included in the signature.
In the case of base taxonomy files, one view is that a signature is not meaningfully complete, if the taxonomy on which it is built can change without invalidating the report's signature. An alternative view is that the base taxonomy is typically published by a "trusted" authority, and that the data collector does not require the contents of the taxonomy to be covered by the signature.
The signature should not prescribe a specific format or standard of digital signature. Instead, the solution should prescribe how to apply existing digital signature standards to XBRL reports.
There could be multiple digital signature formats or standards that could work depending on the circumstances, and the solution should be compatible with different signature formats wherever reasonably possible. From a European perspective the *AdES standards (ETSI EN 319 102) are relevant and include profiles for XAdES, CAdES, PAdES and JAdES. Other relevant technologies include the verifiable LEI (vLEI) developed by GLEIF.
For other jurisdictions other formats or standards might be relevant.
The format/standard of digital signatures should follow the applicable regulatory framework for digital signatures of the region in which is applied.
The solution should be compatible with existing standards wherever possible.
One potential issue identified during requirements gathering is that the ASiC container standard,
which forms part of the European *AdES standards, as defined by ETSI,
prescribes that signatures in a container must be placed in a top-level
META-INF directory. This is at odds with current drafts of the Report Package
specification, which has a META-INF directory in a different location, and
prohibits additional top-level directories.
The solution MUST NOT require any modification of Inline XBRL reports, or prescribe any syntactic constraints on its representation.
It is often desirable to create Inline XBRL reports that render correctly when treated as HTML as well as XHTML. Doing so requires control over XML-insignificant syntax details, such as whether tags are self-closed or not, and how characters are escaped in different contexts. An approach that requires any modification of Inline XBRL reports, such as to embed a signature, would risk losing such syntax details (or place an unreasonable burden on tools to maintain them).
Similarly, requiring that reports be represented in XML canonicalised form would remove necessary control over the syntactic representation.
The solution should use signatures that are external to the XBRL/Inline XBRL report. The preceding requirement rules out embedding signatures within Inline XBRL reports. Using detached signatures are generally preferable because:
These requirements do not impose any constraints on whether multiple signatures appear in a single file or multiple files.
The solution must allow for a signature that only pertains to part of a report.
It must be possible to constrain such a partial signature to specific XBRL facts.
When signing an Inline XBRL report, it must be possible to constrain such a partial signature to fragments of the presented (HTML) report.
Any modification to a report that is within the scope of a partial signature must invalidate that signature. It is acceptable that any modification to a report invalidates all signatures of it, even if the modification only affects parts of the report that were outside of the scope of partial signatures.
The solution must allow for multiple signatures by different signatories. Such signatures may cover all or part of the report (see Section 1.6). The parts of a report covered by different signatures may be the same, different or overlapping.
It must be possible for different signatures to be added at different times.
This requirement is necessary to support use case of audited financial reports, which will need to be signed by both representatives of the entity that is the subject of the report, and its auditors.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (https://www.xbrl.org/legal).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (https://www.xbrl.org/legal).