1 Status

This Candidate Recommendation has been approved for publication by the XBRL Standards Board. Candidate Recommendation status indicates that the document meets all relevant requirements and is ready for implementation and testing.

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

2.1 Documentation conventions

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

2.1.2 Non-normative notes

Text in blue boxes provides non-normative explanatory information.

2.1.3 Comments

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

2.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:

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

3 Signed XBRL reports

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

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

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

3.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 4; and
• the JSON Pointer /documentInfo/documentType MUST resolve to a string (d6e:invalidJSONStructure).

The value of this string is handled as follows:

• If it is https://xbrl.org/CR/2025-01-28/d6, then the content of the file the file MUST be a signature header object (d6e:invalidJSONStructure), and it is processed as described in this application;
• If the string corresponds to a URI defined as a document type URI by an XBRL International specification that is supported by the processor, the package MUST be processed according to that specification, and further processing of this specification is not performed; otherwise
• d6e:unsupportedDigitalSignatureHeaderVersion MUST be raised, and further processing of this specification is not performed.

A signed report package MUST contain a digital signature header file named d6.json in the META-INF directory. If this file is not present, a processor MAY either raise the error d6e:packageNotSigned, or it it MAY raise no error and treat the package as an unsigned report package. In either case, no further processing of this specification is performed.

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.

3.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/CR/2025-01-28/d6

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

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

targets (array)

(required) An array of URIs to the report roots or subset selection file that are the subject of this signature.

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.

The targets property MUST be a non-empty array of xs:anyURI values (d6e:invalidJSONStructure) and each entry MUST be a URL that resolves to a report root or subset selection file. Violations of this are handled as follows:

• if the URL does not end with .json, d6e:invalidFileExtension is raised;
• if a file cannot be obtained, d6e:invalidSignatureTarget is raised;
• if the file does not conform to the JSON syntax constraints (Section 4), d6e:invalidJSON is raised;
• if the JSON Pointer /documentInfo/documentType does not resolve to a string, d6e:invalidJSONStructure is raised;
• if the above string is the document type URI for a subset selection file, it is processed as such;
• otherwise, the file is processed as a report root.

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-path reference URIs (d6e:illegalURIReference). Relative URIs are resolved relative to the location of the file in which they appear.

3.1.3 Digital signature header file: example

{
   "documentInfo": {
       "documentType": "https://xbrl.org/CR/2025-01-28/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"]
        }
   ]
}

3.2 Report roots

A report root is a JSON file that is, or identifies, an XBRL or Inline XBRL report.

• The report root for an Inline XBRL report is an Inline XBRL entry point file.
• The report root for an xBRL-XML report is an xBRL-XML entry point file.
• The report root for an xBRL-CSV report is an xBRL-CSV metadata file.
• An xBRL-JSON report serves as its own report root.

A signed XBRL report MAY use other XBRL formats provided that it is, or is identified by, a report root.

A report root MUST:

• have a .json file extension; (d6e:invalidFileExtension)
• conform to the JSON syntax constraints in Section 4 (d6e:invalidJSON); and
• contain a JSON object in which the JSON Pointer /documentInfo/documentType resolves to a string (d6e:invalidJSONStructure).

The above constraints are checked by handling of the targets property in Section 3.1.2, and so no error codes are prescribed here.

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.

3.2.1 Report Packages

The following additional constraints apply to report roots appearing in a signed report packages:

• Inline XBRL entry point files and xBRL-XML entry point files MUST be contained in a subdirectory of META-INF directory named entry-points (d6e:invalidReportRoot).
• xBRL-CSV and xBRL-JSON reports MUST be treated as a report by the report discovery process (d6e:invalidReportRoot).

3.3 Subset selection files

A subset selection file specifies a subset of a report that is the target of a signature.

A subset selection file is a JSON file that conforms to the following format:

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

In the case of a signed report package, subset selection files MUST be in the META-INF/signatures directory (d6e:misplacedSubsetSelectionFile).

The signature subset object is the top-level object of a subset selection file.
The object has the following properties:

documentInfo (object)

(required) A subset selection file documentInfo object.

report (string)

(required) A URI identifying the report root for the report that is the target of the signature.

digest (string)

(required) The digest of the report root identified by the report property.

selection (object)

(required) A report subset selection object.

The report property MUST be an xs:anyURI (d6e:invalidJSONStructure) and MUST resolve to a report root (d6e:invalidReportProperty is raised if the URI does not resolve to a file, otherwise the file is processed as per Section 3.2).

In the case of a signed report package the report property MUST be a relative-path reference URI (d6e:illegalURIReference).

Relative URIs are resolved relative to the location of the file in which they appear.

The digest property MUST:

• be a digest string (d6e:invalidDigestString); and
• be the digest of the report root identified by the report property (d6e:invalidReportRootDigest).

3.3.1 Subset selection file: documentInfo

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

documentType (string)

(required) The fixed value https://xbrl.org/CR/2025-01-28/d6/subset

3.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 subset object MUST resolve to an Inline XBRL entry point file (d6e:invalidUseOfCSSSelectors).

At least one of facts and cssSelectors MUST be present (d6e:invalidJSONStructure).

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

In the case of a signed report package, the URIs MUST be relative-path reference URIs (d6e:illegalURIReference). 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 3.3.5.

The default namespace for CSS selectors is http://www.w3.org/1999/xhtml. No other namespaces are available for use in CSS selectors.

3.3.4 Example signature subset selection file

{
   "documentInfo": {
       "documentType": "https://xbrl.org/CR/2025-01-28/d6/subset"
   },
   "report": "../entry-points/sample-ixr.json",
   "manifestDigest": "sha256-7dfe895602f53469e010afd7446c07030eb5d35839b6e6a321f52dbb5f8e2b4b",
   "selection": {
        "facts": [ 
            "f-3", 
            "f-32", 
            "f-239" 
        ],
        "cssSelectors": {
            "../../reports/report1.xhtml": [
                "div#auditors-report"
            ]
        }
   }
}

3.3.5 CSS selector constraints

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

• Type selectors
• Universal selectors
• Attribute selectors
• Class selectors
• ID selectors
• The :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-classes
• The negation pseudo-class

3.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 4;
• the JSON Pointer /documentInfo/documentType MUST resolve to the string https://xbrl.org/CR/2025-01-28/ixr (oimce:UnsupportedDocumentType); 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 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:resources (object)

(required) A resources object.

Each entry in the ixds property MUST:

• be an xs:anyURI (d6e:invalidJSONStructure); and
• be included in the documents object of d6:resources object (d6e:missingDigestForReport).

In the case of a signed report package:

• each URI MUST:
  • be a relative-path reference URI (d6e:illegalURIReference); 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); and
• the set of files identified by the URIs 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).

Relative URIs are resolved relative to the location of the file in which they appear.

The set of files identified by the URIs MUST form a valid Inline XBRL Document Set, but processors of this specification are not required to validate this as part of signature validation. Appropriate errors from the Inline XBRL Specification MUST be raised when the report is opened.

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 3.10 for information on the d6:resources property.

3.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/CR/2025-01-28/ixr

namespaces (object)

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

3.4.2 Example Inline XBRL entry point file

{
   "documentInfo": {
       "documentType": "https://xbrl.org/CR/2025-01-28/ixr",
       "namespaces": {
            "d6": "https://xbrl.org/CR/2025-01-28/d6"
       }
   },
   "ixds": [
       "../../reports/ixds1/a.xhtml",
       "../../reports/ixds1/b.xhtml"
   ],
   "target": "t1",
   "d6:resources": {
       "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"
       }
   }
}

3.5 xBRL-XML entry point files

In order to permit the use of a resources 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 4;
• the JSON Pointer /documentInfo/documentType MUST resolve to the string https://xbrl.org/CR/2025-01-28/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 URI that resolves to an xBRL-XML Report.

d6:resources (object)

(required) A resources object.

The report property MUST:

• be an xs:anyURI (d6e:invalidJSONStructure); and
• be included in the documents object of the d6:resources object (d6e:missingDigestForReport).

In the case of a signed report package, the URI MUST:

• be MUST be a relative-path reference URI (d6e:illegalURIReference); 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).

Relative URIs are resolved relative to the location of the file in which they appear.

The file identified by the URI MUST be a valid XBRL v2.1 report, but processors of this specification are not required to validate this as part of signature validation. Validation against the XBRL v2.1 specification MUST be applied when the report is opened.

See Section 3.10 for information on the d6:resources property.

3.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/CR/2025-01-28/xbrl-xml

namespaces (object)

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

3.5.2 Example xBRL-XML entry point file

{
   "documentInfo": {
       "documentType": "https://xbrl.org/CR/2025-01-28/xbrl-xml"
   },
   "report": "../../reports/sample-report.xbrl"
}

3.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 subset selection file. d6e:invalidSignature MUST be raised for any signature that is of a type (see Section 3.7) that is supported by the processor, but does not provide a valid signature of a subset selection file.

3.7 Signature types

This specification does not constrain the mechanism used to sign the subset selection 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/2025-01-28/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.

3.8 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/CR/2025-01-28/d6/conformance/sha256

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

3.9 Test signature file

A test signature file is a simple JSON file containing a digest of the subset selection 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.

If a test signature file does not conform to any of the constraints in, or referenced from, this section, then the error code d6e:invalidSignature MUST be raised, as per Section 3.1.2. Other error codes defined in this section are optional, and if used MUST be in addition to d6e:invalidSignature.

Test signature files MUST have a .json extension, MUST conform to the JSON syntax constraints in Section 4 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 subset selection file that is the target of this test signature.

targetDigest (string)

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

The digest in targetDigest MUST:

• use the SHA256 algorithm; and
• be 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/CR/2025-01-28/d6/conformance/sha256

3.9.1 Example test signature file

{
  "documentInfo": {
    "documentType": "https://xbrl.org/CR/2025-01-28/d6/conformance/sha256"
  },
  "signatureTarget": "foo-target.json",
  "targetDigest": "sha256-78ca0fa3de1cfc450c2b623a8e98420d16f203a6e6103ad08a32a2a6c2ca3543"
}

3.10 Report dependencies

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 resources object in the report root.

A resources object is a JSON object with the name d6:resources and provides digests and location hints for XBRL documents and their dependencies. The object has the following properties:

documents (object)

(required) A documents object. This provides digests of files that are to be included in the signature.

taxonomyPackages (object)

(required) A supporting taxonomy packages object.

Note that the name d6:resources is a QName, and the d6 prefix MUST be declared in namespaces object in the file in which it appears.

3.10.1 Documents

A documents object provides cryptographic digests for individual files that are covered by a signature.

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. The error code d6e:invalidDocumentDigest is raised if the value is not the correct digest for the file.

3.10.1.1 Report packages

All files in a signed report package MUST fall into one of three categories (d6e:unknownOrUnsignedFile):

• A report root or subset selection file that appears as the target of a signature (see Section 3.1.2);
• A report or supporting document – a file referenced by a relative-path reference URI in the resources object of one of the above report roots; or
• A 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-path reference URIs:

• MUST resolve to a file within the ZIP file (d6e:missingFileForDigest); and
• MUST NOT resolve to the name of a directory in the ZIP (d6e:illegalDigestForDirectory).

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

3.10.3 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. Users MAY use taxonomy packages with the correct digest obtained from other locations.

3.10.4 Resources example

An example resources object is shown below:

{
   "d6:resources": {
      "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"]
        }
      }
   }
}

3.10.5 Completeness of dependencies

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 3.2), processors are not required to validate the completeness of all dependencies. Data collectors can ensure the completeness of signature coverage for dependencies by:

• collecting signed report packages so that the constraints of Section 3.10.1.1 ensure that all files within the report package are signed, and the constraints of Section 6 prevent access to external HTML dependencies; and
• restricting access to XBRL dependencies other than via taxonomy packages for prescribed base taxonomies.

3.11 Digest strings

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 3.12) (d6e:unsupportedDigestType).

The hexadecimal value MUST be of the correct length for the digest type (d6e:invalidDigestValue).

sha256-7b7fd29647c0ced9a71541ca2eb041d07fdbafb46d1f193d2c4b02ac0a059f7e

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

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

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

5 Relative-path reference URIs

The term relative-path reference URI refers to a Relative URI with a relative path component, as defined in section 4.2 of RFC 3986.

6 Restricting access to external resources from XHTML

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:

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