This specification defines a standard approach for applying digital signatures to XBRL and Inline XBRL reports. The approach makes use of XBRL Report Packages to combine signatures with the report being signed.
The specification does not prescribe the use of any specific standards or technologies for creating the signatures, in order to enable the re-use of existing infrastructure for digital signatures, and to permit the use of any legally recognised digital signature technology.
QNames in parenthetical red text after a "MUST" or "MUST NOT" statement prescribe standardised error codes to be used if the associated condition is violated.
Text in blue boxes provides non-normative explanatory information.
Text in yellow boxes provide editorial notes and questions on a draft specification. These will not appear in the final specification.
This specification makes use of QNames to represent values, such as error codes. The following prefixes are used in this specification:
| Prefix | Namespace URI |
|---|---|
| d6 | https://xbrl.org/CR/2024-05-15/d6 |
| d6e | https://xbrl.org/CR/2024-05-15/d6/error |
| xs | http://www.w3.org/2001/XMLSchema |
Certain values in this specification are required to be valid values for specified XML Schema datatypes. Such datatypes are identified using a QName with a prefix of xs.
A signed XBRL report is an XBRL or Inline XBRL report that is accompanied by a digital signature that conforms to the constraints of this specification. The digital signature is defined by a digital signature header file named d6.json. The specification supports a range of report formats, including Inline XBRL, xBRL-XML, xBRL-JSON, and xBRL-CSV (see Section 2.3).
A signed report package is a signed XBRL report that is contained within a report package, and which conforms to the constraints of this specification.
A signed report package is identified by the presence of a d6.json file within the report package's META-INF. If the d6.json file is not present, the report package is treated as an unsigned report, and further processing defined by this specification is not applied.
An example file structure for a signed report package is shown below:
example-report/
├─ META-INF/
│ ├─ reportPackage.json
│ ├─ d6.json
│ ├─ signatures/
│ │ ├─ signature-target.json
│ │ └─ signature.xml
│ └─ entry-points/
│ └─ ixbrl-entry-point.json
└─ reports/
└─ ixbrl-report.xhtml
The additional files defined by this specification are:
d6.json – a digital signature header file (identifies the specification version)signature-target.json – a signature target file (name is an example, may be repeated). This points to a report root, and optionally identifies a subset of that report that is the subject of the signature.ixbrl-entry-point.json – an Inline XBRL entry point file (name is an example, may be repeated). This is one type of report root, and provides digests of all dependencies of the report, and in the case of an Inline XBRL entry point file, selects the Inline XBRL target document to be included in a signature.signature.xml – a digital signature file (name and extension are an example, may be repeated). This is a digital signature of a signature target file or a report root.The digital signature header file is a JSON file that identifies the specification version that the signed XBRL report conforms to, and provides a list of the signatures that have been applied to the report.
The digital signature header file is a JSON file that conforms to the following format:
A signed report package MUST contain a digital signature header file named d6.json in the META-INF directory.
The signature header object is the top-level object of a digital signature header file. The object has the following properties:
documentInfo (object)signatures (array)A header file documentInfo object provides document-level information for a digital signature header file. The object has a single property:
documentType (string)https://xbrl.org/CR/2024-05-15/d6A signature object provides the type and location of a signature. The object has the following properties:
type (string)filename (string)signatures directory. The filename MUST be a valid xs:NCName (d6e:invalidFilename). The specified file MUST exist in the signatures directory (d6e:missingSignature).targets (array)If the file specified by filename does not contain a signature that is valid according to the specified type, processors MUST raise d6e:invalidSignature. Processors MAY additionally raise more specific codes from specifications that define the signature format.
Signatures MUST sign one or more signature target files (d6e:invalidSignatureTarget).
The targets property MUST be a non-empty array of xs:anyURI values (d6e:invalidJSONStructure) and each entry MUST be a URI that resolves to a report root or signature target file (d6e:invalidTargetProperty). If the digital signature file provides a mechanism for identifying the subject or subjects of the signature then this MUST be the same set of files as those identified by this property (d6e:signatureTargetMismatch).
In the case of a signed report package, the URIs MUST be relative URIs (d6e:illegalAbsoluteURI). Relative URIs are resolved relative to the location of the file in which they appear.
The d6e:invalidSignature and d6e:invalidSignatureTarget error codes are only raised for supported signature types. Where a processor does not support the signature type, it must raise d6e:unsupportedSignatureType as per Section 2.7.
A signature target file is used when a signature only pertains to part of a report. Where a signature covers the whole report, a report root may be signed directly, although it is also acceptable to use a signature target file with no selection property.
{
"documentInfo": {
"documentType": "https://xbrl.org/CR/2024-05-15/d6"
},
"signatures": [
{
"filename": "signature1.xml",
"type": "https://xbrl.org/d6/xades",
"targets": ["ixbrl-target-1.json"]
},
{
"filename": "signature2.xml",
"type": "https://xbrl.org/d6/xades",
"targets": ["ixbrl-target-2.json"]
}
]
}
The target of an XBRL digital signature is defined by a signature target file.
The signature target file specifies the XBRL or Inline XBRL Report covered by the
signature. The signature target file may optionally specify a subset of
the report that is the target of the signature.
A signature target file is a JSON file that conforms to the following format:
Signature target files are placed in the META-INF/signatures directory.
The signature target object is the top-level object of a signature target file.
The object has the following properties:
documentInfo (object)report (string)digest (string)report property.selection (object)The report property MUST be an xs:anyURI (d6e:invalidJSONStructure) and MUST resolve to a report root (d6e:invalidReportProperty).
In the case of a signed report package the report property MUST be a relative URI (d6e:illegalAbsoluteURI).
Relative URIs are resolved relative to the location of the file in which they appear.
The digest property MUST:
report property (d6e:invalidReportRootDigest).If present, the selection property denotes that the target of the signature is
a subset of a full report (see Section 2.3.3). If absent, the
target of the signature is the whole report.
A report root is a JSON file that is, or identifies, an XBRL or Inline XBRL report.
A signed XBRL report MAY use other XBRL formats provided that it is, or is identified by, a report root.
A report root MUST:
.json file extension; (d6e:invalidReportRoot)/documentInfo/documentType resolves to a string.The documentType string is treated as described in Open Information Model Common Definitions Section 2.
If /documentInfo/documentType does not resolve to a string, it should be
treated as if a "document type is not present".
Processors of this specification MUST apply the above validation, but are not required to support any specific report formats.
The following additional constraints apply to report roots appearing in a signed report packages:
META-INF directory named entry-points (d6e:invalidReportRoot).A signature target file documentInfo object provides document-level information for a signature target file. The object has the following properties:
documentType (string)https://xbrl.org/CR/2024-05-15/d6/targetA signature may optionally target a subset of a report. A report subset selection object describes the subset of a report that is the target of a signature. The object has the following properties:
facts (array)cssSelectors (object)If cssSelectors is present, then the report property of the enclosing signature target object MUST resolve to an Inline XBRL entry point file (d6e:invalidUseOfCSSSelectors).
At least one of facts and cssSelectors MUST be present (d6e:invalidJSONStructure) if the report subset selection object is present.
This specification does not constrain how fact ID selections and CSS selections
are used. If both cssSelectors and facts are present there is no
requirement that the subsets of XHTML selected by CSS selectors has any
relationship to the XBRL facts selected by fact IDs. Collectors of Inline XBRL
Reports may impose specific requirements on how these features are
used.
The name of each property in this object MUST:
xs:anyURI (d6e:invalidJSONStructure); andixds property of the Inline XBRL entry point object of the Inline XBRL entry point file for the report (d6e:invalidSubsetDocument). In the case of a signed report package, the URIs MUST be relative URIs (d6e:illegalAbsoluteURI). Relative URIs are resolved relative to the location of the file in which they appear.
The value of each property is an array of strings, each containing a CSS selector identifying a subset of the Inline XBRL Document.
The CSS selectors MUST conform to the constraints defined in Section 2.3.6.
The default namespace for CSS selectors is http://www.w3.org/1999/xhtml. No other namespaces are available for use in CSS selectors.
{
"documentInfo": {
"documentType": "https://xbrl.org/CR/2024-05-15/d6/target"
},
"report": "../entry-points/sample-ixr.json",
"manifestDigest": "sha256-7dfe895602f53469e010afd7446c07030eb5d35839b6e6a321f52dbb5f8e2b4b",
"selection": {
"facts": [
"f-3",
"f-32",
"f-239"
],
"cssSelectors": {
"../../reports/report1.xhtml": [
"div#auditors-report"
]
}
}
}
CSS selectors used in a CSS report subset selection object MUST be valid selector, as defined in Selectors Level 3 and MUST only contain the following constructs (d6e:invalidCSSSelector):
:root, :nth-child(), :nth-last-child(), :nth-of-type(), :nth-last-of-type(), :first-child, :last-child, :first-of-type, :last-of-type, :only-child, :only-of-type and :empty structural pseudo-classesInline XBRL reports can comprise one or more Inline XBRL Documents (an Inline XBRL Document Set), and can define multiple, distinct XBRL reports ("target documents").
This specification uses an Inline XBRL entry point file to unambiguously identify the Inline XBRL Documents and target documents included in a signature.
An Inline XBRL entry point file is a JSON file that conforms to the following format:
/documentInfo/documentType MUST resolve to the string https://xbrl.org/CR/2024-05-15/ixr (oimceUnsupportedDocumentType); andThe Inline XBRL entry point object is the top-level object of a Inline XBRL entry point file.
The object has the following properties:
documentInfo (object)ixds (array)target (string)ixds property, or the empty string, denoting the default target document (d6e:invalidTargetProperty).d6:supportingDocuments (object)Each entry in the ixds property MUST:
xs:anyURI (d6e:invalidJSONStructure); andreports directory of the report package or a sub-directory of the reports directory (d6e:invalidIXDSProperty). In the case of a signed report package, the URIs MUST be relative URIs (d6e:illegalAbsoluteURI). Relative URIs are resolved relative to the location of the file in which they appear.
The set of files identified by the ixds property MUST correspond exactly to a set of files that are treated as an Inline XBRL Document Set by the report discovery process defined in the Report Package Specification (d6e:invalidIXDSProperty).
A signed XBRL report MAY include multiple Inline XBRL entry point files for the same Inline XBRL Document Set, in order to allow signatures covering different target documents.
See Section 2.10 for information on the d6:supportingDocuments property.
An Inline XBRL entry point documentInfo object provides document-level information for an Inline XBRL entry point file. The object has the following properties:
documentType (string)https://xbrl.org/CR/2024-05-15/ixrnamespaces (object){
"documentInfo": {
"documentType": "https://xbrl.org/CR/2024-05-15/ixr",
"namespaces": {
"d6": "https://xbrl.org/CR/2024-05-15/d6"
}
},
"ixds": [
"../../reports/ixds1/a.xhtml",
"../../reports/ixds1/b.xhtml"
],
"target": "t1",
"d6:supportingDocuments": {
"documents": {
"../../reports/ixds1/a.xhtml": "sha256-2b213cf87c748e574cfcd06ee8a1f530b356315e87b36e40b73c4c31c037511c",
"../../reports/ixds1/b.xhtml": "sha256-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"../../reports/ixds1/styles.css": "sha256-c373c697c20c98a745b0659ad5884c4b3b572a97ab28301366291345cf24caa5",
"../../reports/ixds1/image.png": "sha256-41600933328d6735e18c10553662e69b2d6e021c93628bf92d9d7c3d7dbe54b3"
}
}
}
In order to permit the use of a supporting documents object to capture the dependencies of an xBRL-XML report, this specification defines an xBRL-XML entry point file format.
An xBRL-XML entry point file is a JSON file that conforms to the following format:
/documentInfo/documentType MUST resolve to the string https://xbrl.org/CR/2024-05-15/xbrl-xml (oimceUnsupportedDocumentType); andThe xBRL-XML entry point object is the top-level object of a xBRL-XML entry point file.
The object has the following properties:
documentInfo (object)report (string)d6:supportingDocuments (object)The report property MUST:
xs:anyURI (d6e:invalidJSONStructure); andIn the case of a signed report package, the URI MUST be a relative URI (d6e:illegalAbsoluteURI). Relative URIs are resolved relative to the location of the file in which they appear.
See Section 2.10 for information on the d6:supportingDocuments property.
An xBRL-XML entry point documentInfo object provides document-level information for an xBRL-XML entry point file. The object has the following properties:
documentType (string)https://xbrl.org/CR/2024-05-15/xbrl-xmlnamespaces (object){
"documentInfo": {
"documentType": "https://xbrl.org/CR/2024-05-15/xbrl-xml"
},
"report": "../../reports/sample-report.xbrl"
}
A digital signature file contains a digital signature for one or more reports or report subsets in a signed XBRL report. The format of digital signature files is not prescribed by this specification.
A digital signature file MUST provide a signature of one or more signature target files. d6e:invalidSignature MUST be raised for any signature that is of a type (see Section 2.7) that is supported by the processor, but does not provide a valid signature of a signature target file.
This specification does not constrain the mechanism used to sign the signature target file. The type of signature is specified by a signature type URI (see signature object).
A signature type URI is a URI that uniquely identifies a signature type.
This specification defines a single signature type for production use:
https://xbrl.org/CR/2024-05-15/d6/xades – indicates that the signature has been created in accordance with XML Advanced Electronic Signatures (XAdES).Users of the specification MAY use other signature mechanisms, and should choose appropriate URIs to identify them. Signature URIs MUST NOT use the xbrl.org domain, unless they are defined by XBRL International.
Processors MUST raise d6e:unsupportedSignatureType if a signature uses a signature type URI that is not supported by the processor. Processors are not required to support XAdES signatures.
In addition to the above, this specification defines a signature type that is to be used for conformance testing purposes only:
https://xbrl.org/CR/2024-05-15/d6/conformance/sha256When this signature type is specified, the corresponding digital signature file MUST be a test signature file.
A test signature file is a simple JSON file containing a digest of the signature target file, and is used for conformance testing of processors. Note that this signature type provides no security, and exists purely for testing purposes. Processors MUST support this signature type, but MUST ensure that it is not accepted as a valid signature in production systems.
Test signature files MUST have a .json extension (d6e:invalidSignature), MUST conform to the JSON
syntax constraints in Section 3 and MUST contain an object with the following
properties: (d6e:invalidJSONStructure)
documentInfo (object)signatureTarget (string)targetDigest (string)signatureTarget expressed as a digest string.The d6e:invalidSignature error code specified in {#sec-digital-signature-file} MUST be raised if:
signatureTarget does not exist or is not a signature target file; ortargetDigest is not the correct digest of the target file.A test signature file documentInfo object is a JSON object with the following property:
documentType (string)https://xbrl.org/CR/2024-05-15/d6/conformance/sha256{
"documentInfo": {
"documentType": "https://xbrl.org/CR/2024-05-15/conformance/sha256"
},
"signatureTarget": "foo-target.json",
"targetDigest": "sha256-78ca0fa3de1cfc450c2b623a8e98420d16f203a6e6103ad08a32a2a6c2ca3543"
}
Signed XBRL reports SHOULD include digests for all dependencies. This includes all XBRL taxonomy files required to consume the report, and in the case of Inline XBRL reports, this SHOULD also include HTML dependencies, such as images, stylesheets and fonts.
This allows users of a report to ensure that they are consuming the report using exactly the same dependencies as the report author used.
Digests can either be provided directly for each dependency, or by providing a digest of a taxonomy package that provides the dependency.
Information on dependencies is defined by including a supporting documents object in the report root.
A supporting documents object is a JSON object with the name d6:supportingDocuments and provides digests and location hints for external XBRL documents. The object has the following properties:
documents (object)taxonomyPackages (object)Note that the name d6:supportingDocuments is a QName, and the d6 prefix MUST be declared in namespaces object in the file in which it appears.
Each key of the object MUST be an xs:anyURI (d6e:invalidJSONStructure). Relative URIs are resolved relative to the location of the file in which they appear.
The values of the object are digest strings representing the digest for the file identified by the key.
All files in a signed report package MUST fall into one of three categories (d6e:unknownOrUnsignedFile):
supportingDocuments object of a report root; orA package metadata document – a document in the META-INF directory defined or sanctioned by an XBRL specification.
Where a documents object is used within a signed report package, any keys that are relative URIs:
MUST resolve to a file within the ZIP file (d6e:missingFileForDigest); and
A supporting taxonomy packages object provides digests and location hints for taxonomy packages. The object has the following properties:
digests (array)locationHints (object)Each value in the digests property is the digest of a taxonomy package containing XBRL dependencies that were used when preparing the report.
Processors are not required to perform any validation of the contents of the supporting taxonomy packages object as part of validating signed XBRL report signatures. When opening a signed XBRL report, a processor SHOULD raise a warning if it cannot find a taxonomy package with any of the specified digests (using either the location hints or other means), or if the report's DTS includes files that are not available in the supporting taxonomy packages.
A location hints object provides location hints for taxonomy packages.
The keys of the object are digest strings. Each key MUST appear in the digests property of the supporting taxonomy packages object. It is not required that all entries in the digests property are included in the location hints object.
Each value in the object is an array of strings. The array MUST contain at least one string, and each string MUST be an xs:anyURI (d6e:invalidJSONStructure).
The values are URLs where a taxonomy package matching the digest string of the key may be obtained. Users MAY use taxonomy packages with the correct digest obtained from other locations.
An example supporting documents object is shown below:
{
"d6:supportingDocuments": {
"documents": {
"../../reports/style.css": "sha256-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"../../reports/image1.png": "sha256-4ad4c718c7f2d34b81ee169d2a5eb997288a5b16ef9492260a428bdbc667538f",
"../../taxonomy/www.example.com/extension.xsd": "sha256-c373c697c20c98a745b0659ad5884c4b3b572a97ab28301366291345cf24caa5"
},
"taxonomyPackages": {
"digests": [ "sha256-41600933328d6735e18c10553662e69b2d6e021c93628bf92d9d7c3d7dbe54b3" ],
"locationHints": {
"sha256-41600933328d6735e18c10553662e69b2d6e021c93628bf92d9d7c3d7dbe54b3": ["http://example.com/xbrl-json/taxonomy/example.zip"]
}
}
}
}
All dependencies of a signed XBRL report SHOULD be included in either the documents object, or be available in a taxonomy package with a digest that matches an entry in the supporting taxonomy packages object.
Due the complexity of determining all dependencies of a report, including the support for different XBRL report formats (see Section 2.3), processors are not required to validate the completeness of all dependencies. Data collectors can ensure the completeness of signature coverage for dependencies by:
A digest string is a string encapsulating a digest algorithm and digest value. A digest string consists of a digest algorithm prefix and a lower case hexadecimal digest value, separated by the - character (d6e:invalidDigestString).
The digest algorithm prefix MUST be the prefix for a supported digest type (see Section 2.12) (d6e:unsupportedDigestType).
The hexadecimal value MUST be of the correct length for the digest type (d6e:invalidDigestValue).
Example digest string:
sha256-7b7fd29647c0ced9a71541ca2eb041d07fdbafb46d1f193d2c4b02ac0a059f7e
The supported digest methods are SHA-256, SHA-384 and SHA-512 (SHA-2, as defined in FIPS PUB 180-4). These are denoted by the prefixes sha256, sha384 and sha512 respectively in a digest string. Digest values for these methods represented in hexadecimal are 64, 96 and 128 bytes in length respectively.
Future specifications may define additional permitted digest methods.
JSON files defined by this specification MUST be valid JSON, per RFC 8259 (d6e:invalidJSON).
In order to avoid interoperability issues, objects within JSON documents defined by this specification MUST have unique keys (d6e:invalidJSON).
Such JSON documents MUST use the UTF-8 character encoding (d6e:invalidJSON), and MAY include a Unicode Byte Order Mark, although this is neither required nor recommended.
A URI map object is a JSON object providing a map of URI aliases to full URIs. The content of the URI map MUST conform to the constraints defined in OIM Common for URI maps.
The keys of the object provide the URI alias to be defined, and the values provide the URI to be associated with the alias.
Inline XBRL reports may reference other resources from XHTML, including CSS, images, and fonts. Where an Inline XBRL Report is included in a signed report package all such dependencies MUST be included in the report package containing the report. This ensures that such dependencies are covered by the signature or signatures.
In order to simplify validation of this requirement, Inline XBRL reports that are included in a signed report package are required to use a Content Security Policy that restricts access to external resources. All such Inline XBRL Documents:
<xhtml:meta> tag with the following attributes:http-equiv with value Content-Security-Policycontent with value default-src 'self'<xhtml:head> element of all Inline XBRL Documents and MUST appear before any <xhtml:link>, <xhtml:style> or <xhtml:script> elements.<xhtml:meta> tags with an http-equiv attribute of Content-Security-Policy.Processors MUST raise (d6e:invalidContentSecurityPolicy) if any of the above constraints are not met but are not otherwise required to check the dependencies of the XHTML.
The Content Security Policy defined above only guarantees that any referenced resources have the same "origin". For example, where Inline XBRL files are extracted from a package and served on a web server, the policy would not prevent access to other files on the same server, even if they were not included in the package. One possible mitigation for this problem would be to serve the files on a dedicated subdomain for the filing.
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).