SWT3 Protocol Specification

1. Scope Normative

This specification defines the SWT3 (Sovereign Witness Traceability) protocol for generating, signing, and verifying cryptographic witness anchors. A witness anchor is a deterministic, independently verifiable attestation record computed from observed operational facts.

This specification covers:

• The anchor token format and its constituent fields
• The fingerprint computation algorithm
• The three-factor evidence schema
• Clearing levels that control information density on the wire
• Signing and verification algorithms
• The witness payload JSON schema
• Lifecycle chain identifiers for multi-stage operations
• Provider-deployer evidence chain delegation
• Conformity requirements for implementations

This specification does NOT cover:

• Policy frameworks, risk assessment methodologies, or organizational governance structures
• Verdict evaluation logic (procedure-specific; defined by the implementing platform)
• Platform infrastructure (ingestion endpoints, storage, analytics, dashboards)
• Compliance passport generation, OSCAL export, or report formatting
• Trust mesh credential exchange protocol (specified separately)

The SWT3 protocol is industry-agnostic, framework-neutral, and designed for cross-language interoperability. It operates independently of any specific AI provider, cloud platform, or regulatory regime.

2. Normative References Normative

The following documents are referenced normatively in this specification. For dated references, only the edition cited applies. For undated references, the latest edition applies.

3. Terms and Definitions Normative

For the purposes of this specification, the following terms and definitions apply. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

4. Status of This Document Informative

This is version 1.0 of the SWT3 Protocol Specification, published August 2026 by Tenable Nova LLC.

Normative sections of this specification are versioned. Breaking changes to normative sections increment the major version number. Additive extensions that do not alter existing normative requirements increment the minor version number. The UCT Registry governance process is documented in Section 19.

The fingerprint algorithm (Section 7), anchor format (Section 6), and clearing level definitions (Section 9) are locked as of this version. Implementations conforming to version 1.0 will remain compatible with all future 1.x versions of this specification.

This specification is published by Tenable Nova LLC as the protocol's originating organization. As multi-stakeholder adoption progresses, governance of the SWT3 protocol, UCT Registry, and test vector suite is expected to transition to a multi-stakeholder body. Organizations contributing to the protocol's development, implementation, or adoption are invited to participate in shaping its governance structure.

Patent pending.

5. Protocol Overview Informative

The SWT3 protocol operates in three phases:

Phase 1: Witness. An observed operational fact (e.g., an AI inference, a guardrail evaluation, a model integrity check) is captured as three numeric factors with associated metadata.

Phase 2: Mint. A witness anchor is deterministically computed from the factors, tenant identity, procedure identifier, and timestamp. The anchor is optionally signed with HMAC-SHA256 or ML-DSA-65. Clearing is applied to remove metadata according to the specified level before transmission.

Phase 3: Verify. Any party with knowledge of the input components can independently recompute the fingerprint using standard SHA-256 and compare it to the anchor's claimed fingerprint. No proprietary tooling, API access, or platform account is required for verification.

The protocol is architecturally neutral. It does not prescribe how evidence is collected, where anchors are stored, or how verdicts are evaluated. These concerns are delegated to the implementing platform.

6. Anchor Format Normative

A witness anchor token is a hyphen-delimited string with the following structure:

SWT3-{TIER}-{PROVIDER}-{UCT}-{PROCEDURE}-{VERDICT}-{EPOCH}-{FINGERPRINT}

6.1 Field Definitions

6.2 Normalization Rules

• The PROCEDURE field MUST be normalized by removing hyphens and periods from the original procedure identifier.
• Provider codes MUST be uppercase alphanumeric.
• UCT domain codes MUST be uppercase alphanumeric, 2-4 characters.

6.3 Example

SWT3-E-VULTR-AI-AIINF1-PASS-1774800000-2e16e2fe92dd

Decomposition:

7. Fingerprint Algorithm Normative

7.1 Canonical Formula

The fingerprint MUST be computed as follows:

fingerprint = SHA256("WITNESS:{tenant_id}:{procedure_id}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}").hex()[:12]

Where:

7.2 Computation Steps

1. Construct the input string by concatenating all components with colon (:, U+003A) separators.
2. Encode the input string as UTF-8.
3. Compute the SHA-256 digest (per RFC 6234).
4. Encode the digest as lowercase hexadecimal.
5. Truncate to the first 12 characters.
6. The result is the anchor fingerprint.

7.3 Encoding Rules

• Integer factors MUST be rendered without leading zeros, decimal points, or thousands separators. The integer 0 is rendered as "0". The integer 5000 is rendered as "5000".
• The timestamp MUST be in milliseconds. Seconds-precision timestamps MUST be multiplied by 1000.
• The domain separation prefix WITNESS MUST be uppercase.
• The procedure_id MUST preserve its original punctuation (hyphens, periods). Normalization (Section 6.2) applies only to the anchor token string, not to the fingerprint input.

7.4 Legacy Formula

Implementations MUST also support verification against the legacy formula for backward compatibility with anchors minted before version 1.0:

fingerprint_legacy = SHA256("{procedure_id}:{tenant_id}:{factor_a}:{factor_b}:{factor_c}:{timestamp_ms}").hex()[:12]

The legacy formula differs from the canonical formula in two ways: (1) the WITNESS: domain separation prefix is absent, and (2) the procedure_id and tenant_id fields are in reversed order.

When verifying an anchor, implementations MUST attempt the canonical formula first. If verification fails, implementations MUST attempt the legacy formula before reporting a verification failure.

When minting new anchors, implementations MUST use the canonical formula exclusively.

7.5 Determinism

The fingerprint algorithm is fully deterministic. Given identical inputs, any conforming implementation in any programming language MUST produce an identical fingerprint. This property is verified by the test vectors in Section 18.

8. Factor Schema Normative

8.1 Structure

Every witness anchor contains exactly three factors:

8.2 Semantics

Factor semantics are procedure-specific. This specification defines the factor structure but does not prescribe procedure-level semantics. Procedure-specific factor definitions are maintained in the UCT Registry (Section 15).

The following common evaluation patterns are observed across procedures:

Pattern 1: Threshold Comparison

• factor_a = required/expected value
• factor_b = measured/observed value
• factor_c = additional context (delta, method code, or boolean flag)
• Typical verdict rule: factor_b >= factor_a implies PASS

Pattern 2: Presence/Verification

• factor_a = count of items (e.g., adapters, chunks, guardrails)
• factor_b = verification status (1 = verified, 0 = not verified)
• factor_c = method or context code
• Typical verdict rule: factor_b >= 1 implies PASS

Pattern 3: Inverse Threshold

• factor_a = maximum allowed value (e.g., latency threshold)
• factor_b = observed value
• factor_c = context
• Typical verdict rule: factor_b <= factor_a implies PASS

8.3 Constraints

• All factors MUST be integers. Floating-point values MUST be scaled to integers before anchoring (e.g., a relevance score of 0.82 is encoded as 820 with a documented scale factor of 1000).
• Negative integers are permitted.
• There is no upper bound on factor values.
• A factor value of 0 is semantically valid and distinct from absent.

9. Clearing Protocol Normative

9.1 Clearing Levels

The clearing protocol defines four levels of information density control. Higher levels progressively remove metadata from the witness payload before transmission.

9.2 Field Survival Matrix

The following table specifies which payload fields survive each clearing level. "Y" = retained, "N" = destroyed before transmission.

9.3 CJT Field Guarantee

The following Compliance Jurisdiction and Traceability (CJT) fields MUST survive all clearing levels (0 through 3):

• jurisdiction (ISO 3166-1 alpha-2 country code)
• legal_basis (e.g., GDPR legal basis reference)
• purpose_class (processing purpose classification)
• agent_id (AI agent identity string)
• cycle_id (multi-agent interaction chain link)

Implementations MUST NOT clear CJT fields regardless of clearing level. These fields are required for regulatory traceability across jurisdictions.

9.4 Hash Formulas

When hashing prompt, response, or system prompt content for inclusion in the witness payload:

hash = SHA256(text).hex()[:16]

The hash MUST be the first 16 characters of the lowercase hexadecimal SHA-256 digest of the UTF-8 encoded text.

When hashing ai_model_id at clearing level 3:

hashed_model_id = SHA256(ai_model_id).hex()[:16]

9.5 Irreversibility

Clearing is irreversible. Once metadata is destroyed at the source, it cannot be recovered, reconstructed, or reverse-engineered from the remaining fields. This property is by design and provides a sovereignty guarantee: raw evidence (prompts, responses, operational data) never leaves the developer's infrastructure at clearing level 1 or above.

10. Signing Protocol Normative

10.1 HMAC-SHA256 (Default)

The default signing algorithm is HMAC-SHA256 (per RFC 2104).

Without agent identity binding:

signature = HMAC-SHA256(signing_key, anchor_fingerprint)

With agent identity binding:

signature = HMAC-SHA256(signing_key, anchor_fingerprint + ":" + agent_id)

Where + denotes string concatenation and ":" is the literal colon character (U+003A).

The signing_key is a shared secret known to the minting party. It MUST NOT be transmitted in the witness payload.

The signing_key_id field in the payload identifies which key was used, enabling key rotation without invalidating existing anchors.

10.2 ML-DSA-65 (Post-Quantum)

Implementations MAY support ML-DSA-65 (FIPS 204) as an alternative signing algorithm for post-quantum resistance.

• Algorithm identifier: ml-dsa-65
• Key derivation: Deterministic from a 32-byte seed
• Public key size: 1952 bytes (3904 hexadecimal characters)
• Signatures are non-deterministic (randomized per FIPS 204)

When signing_algorithm is ml-dsa-65:

signature = ML-DSA-65-Sign(private_key, message)

Where message follows the same construction rules as HMAC-SHA256 (fingerprint alone, or fingerprint:agent_id).

Verification is performed using the public key derived from the same seed:

valid = ML-DSA-65-Verify(public_key, message, signature)

Because ML-DSA-65 signatures are non-deterministic, cross-implementation parity is verified by round-trip testing (sign with implementation A, verify with implementation B) rather than exact signature comparison.

10.3 Profile Signing

Model trust profiles MUST be signed using the following canonical message format:

message = "PROFILE:{model_id}:{model_hash}:{generated_at}:{valid_until}:{sorted_procedures}:{coverage_score_3dp}"

Where:

• sorted_procedures is a comma-separated list of procedure IDs sorted lexicographically
• coverage_score_3dp is the coverage score rounded to 3 decimal places (e.g., 0.667)

10.4 Key Management

• Signing keys MUST be stored securely and MUST NOT appear in witness payloads, logs, or error messages.
• Key rotation SHOULD be performed periodically. The signing_key_id and signing_key_version fields enable rotation without invalidating existing anchors.
• Implementations SHOULD support at least two concurrent active keys during rotation periods.

11. Verification Algorithm Normative

11.1 Single Anchor Verification

To verify a single witness anchor:

1. Obtain the anchor's claimed fingerprint (the last segment of the anchor token).
2. Obtain the original input components: tenant_id, procedure_id, factor_a, factor_b, factor_c, fingerprint_timestamp_ms.
3. Compute the fingerprint using the canonical formula (Section 7.1).
4. If the computed fingerprint matches the claimed fingerprint, the anchor is VERIFIED.
5. If not, compute the fingerprint using the legacy formula (Section 7.4).
6. If the legacy-computed fingerprint matches, the anchor is VERIFIED (legacy).
7. If neither formula produces a match, the anchor is TAMPERED.

No API access, platform account, or proprietary tooling is required for verification. Any party with knowledge of the input components can perform verification using standard SHA-256.

11.2 Enclave Integrity Verification

To verify the integrity of an entire enclave (collection of anchors):

1. Collect all anchor fingerprints in the enclave.
2. Sort the fingerprints lexicographically (ascending).
3. Join the sorted fingerprints with colon separators: "fp1:fp2:fp3:...".
4. Compute SHA256(joined_string).hex() (full 64-character hexadecimal digest).
5. The result is the enclave integrity signature.

The enclave integrity signature has the following property: identical anchors in an identical state always produce an identical signature. Any addition, removal, or modification of any anchor changes the signature.

11.3 Signature Verification

If the witness payload includes a payload_signature:

1. Determine the signing algorithm from the signing_algorithm field (default: hmac-sha256).
2. Construct the message: anchor_fingerprint (or anchor_fingerprint:agent_id if agent_id is present).
3. Verify the signature using the appropriate algorithm and the signing key identified by signing_key_id.
4. If verification succeeds, the anchor's provenance is AUTHENTICATED.
5. If verification fails, the anchor's provenance is UNAUTHENTICATED.

Signature verification is independent of fingerprint verification. An anchor can be VERIFIED (fingerprint matches) but UNAUTHENTICATED (signature does not match), or vice versa.

12. Witness Payload Schema Normative

12.1 Required Fields

The following fields MUST be present in every witness payload:

12.2 Optional Fields

12.3 Revocation Reason Codes

12.4 Validation Rules

• procedure_id MUST be a valid UCT procedure identifier.
• clearing_level MUST be an integer in the range [0, 3].
• anchor_fingerprint MUST be exactly 12 lowercase hexadecimal characters.
• anchor_epoch MUST be a positive integer.
• fingerprint_timestamp_ms MUST be a positive integer.
• lifecycle_chain_id, if present, MUST match the pattern ^LC-[0-9a-f]{16}$.

13. Lifecycle Chains Normative

13.1 Chain Identifier Formula

A lifecycle chain identifier links multiple witness anchors into a single operational sequence. The chain ID is computed as:

chain_id = "LC-" + SHA256("LIFECYCLE:{tenant_id}:{procedure_id}:{initiator_fingerprint}:{timestamp_ms}").hex()[:16]

Where:

• tenant_id is the tenant that initiates the chain
• procedure_id is the procedure of the initiating anchor
• initiator_fingerprint is the fingerprint of the first anchor in the chain
• timestamp_ms is the millisecond timestamp of the initiating anchor

The chain ID is a fixed-length string: the literal prefix LC- followed by 16 lowercase hexadecimal characters.

13.2 Lifecycle Stages

The following canonical stage codes are defined:

• The first anchor in a lifecycle chain MUST have lifecycle_stage set to initiated.
• Subsequent anchors in the chain MUST reference the lifecycle_chain_id of the initiating anchor.
• The lifecycle_parent field SHOULD contain the fingerprint of the immediately preceding anchor in the chain.
• A chain is considered closed when any anchor in the chain has a terminal stage.
• No further non-terminal anchors SHOULD be minted for a closed chain.

13.3 Cross-Chain Escalation

When an event in one lifecycle chain triggers a new chain (e.g., a drift detection escalates to an emergency override), the new chain's initiating anchor SHOULD include the escalation_chain_id field referencing the originating chain.

14. Provider-Deployer Evidence Chains Normative

14.1 Problem Statement

Organizations that provide AI models to third parties (whether through open-weight distribution, API access, cloud platform hosting, or embedded integration) face a common challenge: demonstrating that downstream deployers are operating the model with appropriate controls, without accessing the deployer's infrastructure or proprietary data.

14.2 Delegation Anchors

A model provider MAY mint delegation anchors (procedure AI-DEL.1) to formally record the relationship between the provider's tenant and one or more deployer tenants.

The delegation anchor encodes:

• factor_a: Number of deployer tenants in the delegation scope
• factor_b: Number of required procedures in the delegation policy
• factor_c: Delegation type code (0 = open-weight, 1 = API, 2 = cloud platform, 3 = embedded)

14.3 Deployer Attestation Flow

1. The deployer integrates the SWT3 SDK and witnesses operations under their own tenant identity.
2. Anchors flow to the deployer's own tenant, maintaining tenant isolation.
3. The provider queries aggregated coverage metrics across deployer tenants via the platform API.
4. The provider sees anchor fingerprints, procedure coverage percentages, verdict distributions, and clearing levels. The provider never sees raw deployer data.

14.4 Evidence Aggregation Without Data Access

The evidence aggregation model preserves deployer sovereignty:

• Providers see: procedure coverage percentage, verdict distribution (PASS/FAIL counts), clearing level distribution, anchor count, most recent anchor timestamp.
• Providers do not see: raw factors, prompt/response hashes, model identifiers, agent identifiers, contextual metadata, or any field subject to clearing.
• Deployers control: their own clearing level, which procedures they witness, and whether they participate in provider-aggregated reporting.

14.5 Cross-Provider Interoperability

A deployer building applications on models from multiple providers uses a single SWT3 integration. The same anchors, minted under the deployer's tenant, can be referenced by any provider with an established delegation relationship. This eliminates the need for deployers to maintain separate compliance systems per provider.

14.6 Distribution Model Neutrality

The delegation mechanism is identical regardless of how the model reaches the deployer:

15. Universal Control Taxonomy Informative

15.1 Overview

The Universal Control Taxonomy (UCT) defines the namespace for all valid procedure identifiers. As of version 1.0, the taxonomy contains 114 AI-specific procedures organized across 62 namespaces.

15.2 Namespace Registry

Procedure identifiers follow the format AI-{NAMESPACE}.{NUMBER} for AI-specific procedures. The following namespaces are defined:

INF, MDL, GRD, SEC, RAG, SKILL, TOOL, ID, ACC, REV, FAIR, DATA, HITL, EXPL, CHAIN, VIO, CHR, SAFE, HW, TRUST, FIN, GOV, ENV, MARK, BASE, LIC, SBOM, REDTEAM, CONSENT, MULTI, DRIFT, AUDIT, INCIDENT, PMM, PERF, ROBUST, CYBER, TRANS, WATERMARK, DPIA, AUTO, DUALUSE, SUPPLY, METAGOV, DEL, CAP, COST, JUR, LCM, LOG, IMPACT, MOB, EMRG, ASSESS, ENG, REACH, DECOM, RECOMM, FREEZE

Non-AI procedures use domain-specific prefixes (e.g., SC-7.6 for network security, AC-2.1 for access control).

15.3 Namespace Governance

Published namespace codes are never removed, renamed, or redefined. New namespace codes require demonstrated need across two or more regulatory frameworks. The UCT Registry is the authoritative source for all procedure definitions and is publicly available.

15.4 Framework Crosswalks

Each procedure in the UCT Registry is mapped to one or more regulatory framework requirements through bidirectional crosswalks. As of version 1.0, crosswalks are maintained for 36 regulatory frameworks across 12 jurisdictions.

16. Conformity Requirements Normative

16.1 Conformance Levels

This specification defines three conformance levels:

16.2 Conformity Statement

An implementation conforms to this specification at a given level if and only if it satisfies all MUST-level requirements for that level and all levels below it. Conformance is independently verifiable via the test vectors in Section 18.

16.3 Partial Conformance

An implementation that satisfies some but not all requirements of a given level MUST NOT claim conformance at that level. It MAY claim conformance at the highest level for which all requirements are satisfied.

17. Security Considerations Informative

17.1 Fingerprint Properties

Fingerprints are 12 hexadecimal characters (48 bits of entropy from the SHA-256 output). This truncation is intentional: fingerprints serve as evidence identifiers, not as security tokens. The full SHA-256 digest is not needed because:

• Fingerprints are not secrets. They appear in anchor tokens, payloads, and verification interfaces.
• Collision resistance at 48 bits is sufficient for evidence identification within a single tenant's anchor population.
• The full SHA-256 is recoverable by any party with knowledge of the inputs.

17.2 Signing Key Security

• HMAC-SHA256 signing keys provide payload authentication but not non-repudiation. A party with the signing key can mint anchors indistinguishable from the original.
• ML-DSA-65 keys provide both authentication and non-repudiation.
• Ed25519 keys used for W3C Verifiable Credential signing are higher sensitivity than HMAC keys. Compromise of an Ed25519 private key enables universal forgery of verifiable credentials that will pass any external verifier.

17.3 Clearing as Privacy Mechanism

Clearing levels provide information density control, not encryption. Clearing at level 1+ ensures that raw prompts, responses, and operational data never leave the developer's infrastructure. However, the metadata that does survive (hashes, factors, model identifiers at levels 0-2) could be correlated with external data sources by a sufficiently motivated adversary.

Organizations processing highly sensitive data SHOULD use clearing level 2 or 3.

17.4 Domain Separation

The WITNESS: prefix in the fingerprint formula provides domain separation, preventing cross-protocol collision. The following domain separation prefixes are reserved by this specification:

Implementations MUST NOT use these prefixes for other purposes.

18. Test Vectors Normative

All conforming implementations MUST produce identical outputs for the following test vectors. The complete test vector suite is available at test-vectors.json in the reference implementation repository.

18.1 Fingerprint Vectors

Formula: SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]

The complete test vector suite contains 55 fingerprint vectors covering edge cases (all-zero factors, large values, multiple tenant types, all clearing levels). See test-vectors.json for the full set.

18.2 Signing Vectors

Algorithm: HMAC-SHA256. Key: test-signing-key

Vector 1 message: 019eaf85fcba:agent-007

Vector 2 message: 019eaf85fcba

18.3 Hash Vectors

Formula: SHA256(input).hex()[:16]

18.4 Profile Signing Vectors

Signing key: test-key-123

Expected HMAC-SHA256: bdce7111c3a6e9968a5de1973f3a977aadb42c2d7327f38de79729019c7baa42

Note: Procedures in the message MUST be sorted lexicographically.

18.5 ML-DSA-65 Vectors

ML-DSA-65 signatures are non-deterministic. Conformance is verified by round-trip testing:

1. Generate a keypair from seed 60ef3bf0e31e764953cf67c6806d0c6512ce54a6e83a9328b7042b3896cf8f40 (32 bytes, hex).
2. The derived public key MUST be 1952 bytes (3904 hex characters).
3. Sign message 019eaf85fcba:agent-007. The signature will differ on each invocation.
4. Verify the signature using the derived public key. Verification MUST succeed.
5. Sign message 019eaf85fcba (without agent_id). Verification MUST succeed.
6. Verify that the public key derived from the same seed is identical across implementations.

18.6 Lifecycle Chain Vectors

Formula: "LC-" + SHA256("LIFECYCLE:{tenant}:{proc}:{fp}:{ts_ms}").hex()[:16]

19. Registry Considerations Informative

19.1 Reserved Prefixes

The following domain separation prefixes are reserved by this specification and MUST NOT be used by implementations for other purposes:

19.2 UCT Registry Governance

The UCT Registry is maintained as a public JSON document (uct-registry.json) in the reference implementation repository. Changes to the registry follow these rules:

• Published procedure identifiers are never removed, renamed, or redefined.
• New procedures require demonstrated need across two or more regulatory frameworks.
• New namespaces require review and approval through the governance process described in Section 4.
• Registry versions are tagged and immutable once published.

19.3 Provider Code Registration

Provider codes (Section 6.1) are not centrally registered. Implementations MAY use any uppercase alphanumeric string as a provider code. The following codes are in common use: VULTR, AWS, AZURE, GCP, HYBRID, ON-PREM.

20. Protocol Adoption Rationale Informative

This section describes the considerations that motivate adoption of an open, standardized witness protocol rather than proprietary alternatives.

Assessor portability. When multiple assessment bodies (Notified Bodies, C3PAOs, auditors) understand a common evidence format, conformity assessments are faster and less expensive. A proprietary evidence format requires each assessment body to learn and maintain custom verification tooling per provider.

Deployer interoperability. A deployer building applications on models from multiple providers needs one compliance system, not N proprietary formats. SWT3 is provider-neutral and distribution-model-neutral. A single SDK integration produces evidence that is valid across all provider relationships.

Verification independence. Any party can recompute a fingerprint using standard SHA-256 with no proprietary SDK, API access, or platform account. Verification requires only the input components and a conforming SHA-256 implementation, both of which are universally available.

Cross-provider network effects. Each new provider that adopts SWT3 reduces compliance cost for every deployer already using it, and each new deployer reduces the marginal cost of the next provider's adoption. This creates a positive-sum dynamic where early adoption yields compounding returns.

Governance participation. Organizations implementing and deploying SWT3 are positioned to participate in the governance of the protocol as it matures. Early adopters of open protocols shape the standards that follow.

Historical precedent supports this pattern. TLS (formerly SSL) began as a single-vendor protocol and became the universal transport security layer. SWIFT began as a cooperative of 239 banks and became the global financial messaging standard. XBRL began at a single accounting body and became the international standard for regulatory financial reporting. In each case, the protocol's value derived from its neutrality and universal adoption, not from any single vendor's implementation.

21. Reference Implementations Informative

Conforming reference implementations are available in seven programming languages. All implementations achieve 100% parity on the test vectors in Section 18.

A Model Context Protocol (MCP) server implementation is also available:

22. Bibliography Informative

The following documents are referenced informatively in this specification: