1 Introduction

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.

1.1 Documentation conventions

1.1.1 Error codes

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.

1.1.2 Non-normative notes

Text in blue boxes provides non-normative explanatory information.

1.1.3 Comments

Text in yellow boxes provide editorial notes and questions on a draft specification. These will not appear in the final specification.

1.2 Namespaces and namespace prefixes

This specification makes use of QNames to represent values, such as error codes. The following prefixes are used in this specification:

1.3 Data types

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.

2 Signed XBRL reports

A signed XBRL report is a report package that additionally conforms to the constraints of this specification.

A signed XBRL report 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.

example-report/
├─ META-INF/
│  ├─ reportPackage.json
│  ├─ d6.json
│  ├─ manifest.json
│  └─ signatures/
│     ├─ ixbrl-entry-point.json
│     ├─ signature-target.json
│     └─ signature.xml
└─ reports/
   └─ ixbrl-report.xhtml

2.1 Digital signature header file

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:

• the file MUST conform to the JSON syntax constraints in Section 3;
• the content of the file MUST be a signature header object (d6e:invalidJSONStructure).

A signed XBRL report 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)

(required) A header file documentInfo object.

signatures (array)

(required) An array of signature objects. The array MAY be empty if there are no signatures.

2.1.1 Digital signature header file: documentInfo

A header file documentInfo object provides document-level information for a digital signature header file. The object has a single property:

documentType (string)

(required) The fixed value https://xbrl.org/PWD/2024-02-14/d6

2.1.2 Digital signature header file: signature object

A signature object provides the type and location of a signature. The object has the following properties:

type (string)

(required) A signature type URI (see Section 2.8).

filename (string)

(required) The name of a file within the signatures directory. The filename MUST be a valid xs:NCName (d6e:invalidFilename). The specified file MUST exist in the signatures directory (d6e:missingSignature).

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).

2.1.3 Digital signature header file: example

{
   "documentInfo": {
       "documentType": "https://xbrl.org/PWD/2024-02-14/d6"
   },
   "signatures": [
        {
            "filename": "signature1.xml",
            "type": "https://xbrl.org/d6/xades"
        },
        {
            "filename": "signature2.xml",
            "type": "https://xbrl.org/d6/xades"
        }
   ]
}

2.2 Manifest file

The manifest file is a JSON file that provides cryptographic digests for a collection of files.

The manifest file is a JSON file that conforms to the following format:

• the file MUST conform to the JSON syntax constraints in Section 3;
• the content of the file MUST be a manifest object (d6e:invalidJSONStructure).

A signed XBRL report MUST contain a manifest file named manifest.json in the META-INF directory.

The manifest object is the top-level object of a manifest file. The object has the following properties:

documentInfo (object)

(required) A manifest file documentInfo object.

digests (object)

(required) A digests object.

2.2.1 Manifest file: documentInfo

A manifest file documentInfo object provides document-level information for a manifest file. The object has a single property:

documentType (string)

(required) The fixed value https://xbrl.org/PWD/2024-02-14/d6/manifest

2.2.2 Signature manifest file: digests

A digests object provides cryptographic digests for files within a report package.

Each key of the object MUST:

• be an xs:anyURI (d6e:invalidJSONStructure);
• be a relative URI (d6e:illegalAbsoluteURI); and
• resolve to a file within the ZIP file (d6e:missingFileForDigest).

The URI MUST NOT resolve to the name of a directory in the ZIP (d6e:illegalDigestForDirectory).

The values of the object are digest strings representing the digest for the corresponding file.

A digest string is a string encapsulating a digest algorithm and digest value. A digest string MUST conform to the hash-expression rule of section 3.5 of Subresource Integrity.

sha256-tpPUvQJroVFe2sq8rb1nhUVLCOyUaGZeTcM/Ad+Mxlk=

The digests object MUST contain an entry for every file within the ZIP, except for those in the META-INF/signatures/ directory, META-INF/d6.json and META-INF/manifest.json (d6e:invalidManifestFileContents).

2.2.3 Manifest file: example

{
   "documentInfo": {
       "documentType": "https://xbrl.org/PWD/2024-02-14/d6/manifest"
   },
   "digests": {
       "example-report/reports/my-report.xhtml": "sha256-tpPUvQJroVFe2sq8rb1nhUVLCOyUaGZeTcM/Ad+Mxlk=",
       "example-report/reports/image.png": "sha256-dowxg2NoMsR5pJ1b/QJ4S6ja1/O2xx4FHqbrhtG6Txk=",
       "example-report/META-INF/reportPackage.json": "sha256-DusyLCLoNEpXXOeS1plU/FexmHLTnWqlja2l/9HBwVg="
   }
}

2.3 Signature target files

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:

• the file MUST conform to the JSON syntax constraints in Section 3; and
• the content of the file MUST be a signature target object (d6e:invalidJSONStructure).

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)

(required) A signature target file documentInfo object.

report (string)

(required) A relative URI to the report that is the target of the signature.

selection (object)

(optional) A report subset selection object.

manifestDigest (string)

(required) A digest string containing a digest of the manifest file.

The report property MUST:

• be an xs:anyURI (d6e:invalidJSONStructure);
• be a relative URI (d6e:illegalAbsoluteURI); and
• resolve to a file within the report package in which it appears (rpe:invalidReportProperty).

The value is resolved relative to the location of the file in which it appears.

The file MUST (rpe:invalidReportProperty):

• be an Inline XBRL entry point file in the META-INF directory of the report package; or
• be an xBRL-XML entry point file in the META-INF directory of the report package; or
• be a file with a .json or .xbrl file extension that is treated as a report by the report discovery process.

If present the selection property denotes that the target of the signature is a subset of a full report (see Section 2.3.2). If absent, the target of the signature is the whole report.

2.3.1 Signature target file: documentInfo

A signature target file documentInfo object provides document-level information for a signature target file. The object has the following properties:

documentType (string)

(required) The fixed value https://xbrl.org/PWD/2024-02-14/d6/target

2.3.2 Report subsets

A 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)

(optional) An array of fact IDs, identifying the facts that are to be targeted by this signature.

cssSelectors (object)

(optional) A CSS report subset selection object, identifying parts of an Inline XBRL report that are to be targeted by this signature.

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.

2.3.3 CSS report subsets

A CSS report subset selection object identifies parts of Inline XBRL Documents that are to be targeted by a signature using CSS selectors.

The name of each property in this object MUST:

• be an xs:anyURI (d6e:invalidJSONStructure);
• be a relative URI (d6e:illegalAbsoluteURI); and
• resolve to an Inline XBRL Document that is included in the ixds property of the Inline XBRL entry point object of the Inline XBRL entry point file for the report (d6e:invalidSubsetDocument).

The URI is resolved relative to the file in which it appears.

The value of each property is an array of strings, each containing a CSS selector identifying a subset of the Inline XBRL Document.

2.3.4 Example signature target file

{
   "documentInfo": {
       "documentType": "https://xbrl.org/PWD/2024-02-14/d6/target"
   },
   "report": "sample-ixr.json",
   "manifestDigest": "sha256-tpPUvQJroVFe2sq8rb1nhUVLCOyUaGZeTcM/Ad+Mxlk=",
   "selection": {
        "facts": [ 
            "f-3", 
            "f-32", 
            "f-239" 
        ],
        "cssSelectors": {
            "../../reports/report1.xhtml": [
                "div#auditors-report"
            ]
        }
   }
}

2.4 Inline XBRL entry point files

Inline 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:

• the file MUST conform to the JSON syntax constraints in Section 3;
• the JSON Pointer /documentInfo/documentType MUST resolve to the string https://xbrl.org/PWD/2024-02-14/ixr (oimceUnsupportedDocumentType); and
• the content of the file MUST be an Inline XBRL entry point object (d6e:invalidJSONStructure).

The 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)

(required) An Inline XBRL entry point documentInfo object.

ixds (array)

(required) An array of relative URIs.

target (string)

(required) This property MUST either be the name of a target document in the Inline XBRL Document Set defined by the ixds property, or the empty string, denoting the default target document (d6e:invalidTargetProperty).

d6:supportingDocuments (object)

(optional) A supporting documents object.

Each entry in the ixds property MUST:

• be an xs:anyURI (d6e:invalidJSONStructure);
• be a relative URI (d6e:illegalAbsoluteURI); and
• resolve to an Inline XBRL Document in the reports directory of the report package or a sub-directory of the reports directory (d6e:invalidIXDSProperty).

The URI is resolved relative to the file in which it appears.

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.11 for information on the optional d6:supportingDocuments property.

2.4.1 Inline XBRL entry point file: documentInfo

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)

(required) The fixed value https://xbrl.org/PWD/2024-02-14/ixr

namespaces (object)

(optional) a URI map object that provides the prefix map for any QNames in this JSON document.

2.4.2 Example Inline XBRL entry point file

{
   "documentInfo": {
       "documentType": "https://xbrl.org/PWD/2024-02-14/ixr"
   },
   "ixds": [
       "a.html",
       "b.html"
   ],
   "target": "t1"
}

2.5 xBRL-XML entry point files

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:

• the file MUST conform to the JSON syntax constraints in Section 3;
• the JSON Pointer /documentInfo/documentType MUST resolve to the string https://xbrl.org/PWD/2024-02-14/xbrl-xml (oimceUnsupportedDocumentType); and
• the content of the file MUST be an xBRL-XML entry point object (d6e:invalidJSONStructure).

The 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)

(required) An xBRL-XML entry point documentInfo object.

report (string)

(required) A relative URI that resolves to an xBRL-XML Report.

d6:supportingDocuments (object)

(optional) A supporting documents object.

The report property MUST:

• be an xs:anyURI (d6e:invalidJSONStructure);
• be a relative URI (d6e:illegalAbsoluteURI); and
• resolve to a file that is treated as an XBRL v2.1 report by the report discovery process defined in the Report Package Specification (d6e:invalidReportProperty).

The value is resolved relative to the file in which it appears.

See Section 2.11 for information on the optional d6:supportingDocuments property.

2.5.1 xBRL-XML entry point file: documentInfo

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)

(required) The fixed value https://xbrl.org/PWD/2024-02-14/xbrl-xml

namespaces (object)

(optional) a URI map object that provides the prefix map for any QNames in this JSON document.

2.5.2 Example xBRL-XML entry point file

{
   "documentInfo": {
       "documentType": "https://xbrl.org/PWD/2024-02-14/xbrl-xml"
   },
   "report": "sample-report.xbrl"
}

2.6 Digital signature file

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.8) that is supported by the processor, but does not provide a valid signature of a signature target file.

2.7 Supported digest types

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.

Future specifications may define additional permitted digest methods.

2.8 Signature types

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/PWD/2024-02-14/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.

2.9 Test signature type

In addition to the above, this specification defines a signature type that is to be used for conformance testing purposes only:

• https://xbrl.org/PWD/2024-02-14/d6/conformance/sha256

When this signature type is specified, the corresponding digital signature file MUST be a test signature file.

2.10 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)

(required) A test signature file documentInfo object.

signatureTarget (string)

(required) The name of the signature target file that is the target of this test signature.

targetDigest (string)

(required) The SHA256 digest of the file specified in signatureTarget expressed as a digest string.

The d6e:invalidSignature error code specified in {#sec-digital-signature-file} MUST be raised if:

• the file specified by signatureTarget does not exist or is not a signature target file; or
• the digest in targetDigest 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)

(required) The fixed value https://xbrl.org/PWD/2024-02-14/d6/conformance/sha256

2.10.1 Example test signature file

{
  "documentInfo": {
    "documentType": "https://xbrl.org/PWD/2024-02-14/conformance/sha256"
  },
  "signatureTarget": "foo-target.json",
  "targetDigest": "sha256-tpPUvQJroVFe2sq8rb1nhUVLCOyUaGZeTcM/Ad+MxlF="
}

2.11 XBRL dependencies

Signed XBRL reports may optionally include digests for external XBRL dependencies ("base taxonomies") in order to allow users of a report to ensure that they are consuming the report using exactly the same dependencies as the report author used.

Information on dependencies is defined by include a supporting documents object in either an Inline XBRL entry point file or the root JSON file of a JSON-rooted report.

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 property:

taxonomyPackages (object)

(required) A supporting taxonomy packages 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.

2.11.1 Supporting taxonomy packages

A supporting taxonomy packages object provides digests and location hints for taxonomy packages. The object has the following properties:

digests (array)

(required) An array of digest strings.

locationHints (object)

(required) A location hints 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.

2.11.2 Location hints

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.

2.11.3 Supporting documents example

An example supporting documents object is shown below:

{
   "d6:supportingDocuments": {
       "taxonomyPackages": {
         "digests": [ "sha256-tpPUvQJroVFe2sq8rb1nhUVLCOyUaGZeTcM/Ad+Mxlk=" ],
         "locationHints": {
           "sha256-tpPUvQJroVFe2sq8rb1nhUVLCOyUaGZeTcM/Ad+Mxlk=": ["http://example.com/xbrl-json/taxonomy/example.zip"]
         }
       }
   }
}

3 JSON syntax constraints

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.

3.1 URI maps

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.

4 Restricting access to external resources from XHTML

Inline XBRL reports may reference other resources from XHTML, including CSS, images, and fonts. In order to ensure that all such are dependencies are covered by a signature, they MUST be included in the report package containing the report.

In order to simplify validation of this requirement, signed Inline XBRL reports are required to use a Content Security Policy that restricts access to external resources. All signed Inline XBRL Documents:

• MUST contain a <xhtml:meta> tag with the following attributes:
  • http-equiv with value Content-Security-Policy
  • content with value default-src 'self'
• The tag MUST be within the <xhtml:head> element of all Inline XBRL Documents and MUST appear before any <xhtml:link>, <xhtml:style> or <xhtml:script> elements.
• MUST NOT contain any other <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. Processors are not otherwise required but are not otherwise required to check the dependencies of the XHTML.

Appendix A Intellectual property status (non-normative)

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).