Long-Term Validation for JSON Web Signature (LTV-JWS)

3.1. Diagram

  +---------------------------------------------+
  | SIG-B (Create Base Signature)               |
  | Signature Base level                        |
  +-------------------+-------------------------+
                      |
                      v
  +---------------------------------------------+
  | SIG-T (Add "signature timestamp")           |
  | Signature Timestamp level                   |
  +-------------------+-------------------------+
                      |
                      |    +------------------------------+
                      |    |                              |
                      v    v                              |
  +---------------------------------------------+         |
  | SIG-LTV (Add "validations")                 |         |
  | Signature Long-Term Validation level        |         |
  +---------------------+-----------------------+         |
                        |                                 | renew archive
                        v                                 |
  +---------------------------------------------+         |
  | SIG-LTA (Add "archive timestamp")           |         |
  | Signature Long-Term Archive Timestamp level |         |
  +---------------------+-----------------------+         |
                        |                                 |
                        +---------------------------------+

  +---------------------------------------------------------+
  | signature:                                              |
  +---------------------------+-----------------------------+
                              |           +-----------------+
                              |           | protected:      |
                   (JWS sign) +---------->|   +---------+   |
                              |           |   | "ES256" |   | <= sign alg
                              |           |   +---------+   |
                              v           +-----------------+
  +---------------------------------------------------------+
  | payload:                                                |
  |      refs[0]          refs[1]          refs[2]      ... | <= refs array
  |  +-------------+  +-------------+  +-------------+      |
  |  | "data1.bin" |  | "file.json" |  | "data2.txt" |  ... | <= uri
  |  +-------------+  +-------------+  +-------------+      |
  |  |   "S256"    |  |   "S256"    |  |   "S256"    |  ... | <= hash alg
  |  +-------------+  +-------------+  +-------------+      |
  |  |   "hash1"   |  |   "hash2"   |  |   "hash3"   |  ... | <= hash value
  |  +------+------+  +------+------+  +------+------+      |
  +---------|----------------|----------------|-------------+
            | (hash1)        | (hash2)        | (hash3)
            v                v                v
     +-------------+  +-------------+  +-------------+
     |  data1.bin  |  |  file.json  |  |  data2.txt  |  ...
     +-------------+  +-------------+  +-------------+

  +---------------------+        +---------------------+        +-------+
  | JWS-A (LTV-JWS)     |    +-->| JWS-B (LTV-JWS)     |    +-->| JWS-C |
  | +-----------------+ |    |   | +-----------------+ |    |   |       |
  | | refs[n]         | |    |   | | refs[n]         | |    |   |       |
  | | +-------------+ | |    |   | | +-------------+ | |    |   +-------+
  | | | uri="JWS-B" +--------+   | | | uri="JWS-C" +--------+
  | | +-------------+ | | (hash) | | +-------------+ | | (hash)
  | | | type="jws"  | | |        | | | type="jws"  | | |
  | | +-------------+ | |        | | +-------------+ | |
  | +-----------------+ |        | +-----------------+ |
  +---------------------+        +---------------------+

3.2. Goals

The goals of LTV-JWS are as follows:¶

• To enable long-term validation of JWS signatures over extended periods of time.¶

• To preserve the simple structure and processing model of JWS while adding long-term validation capabilities.¶

• To enable lightweight implementation and interoperability by avoiding JSON canonicalization and by reusing the JWS signing input model.¶

• To support the continued verification of signatures even after certificate expiration or cryptographic algorithm obsolescence through timestamps, validation information, and archive timestamps.¶

• To support indirect signing of multiple arbitrary external files, including non-JSON data, through external references (refs).¶

• To allow validation information and archive timestamps to be incrementally added after signing without modifying the original signature value.¶

• To maintain compatibility with existing JOSE and JWS processing models as much as possible.¶

• To simplify future long-term validation by preserving validation-related information used during validation.¶

3.3. Design Principles

LTV-JWS is designed based on the following principles:¶

• Preserve the core structure and processing model of JWS as defined in [RFC7515].¶

• Minimize additional structures and processing requirements in order to enable lightweight implementation and interoperability.¶

• LTV-JWS avoids JSON canonicalization by reusing deterministic BASE64URL-based JWS signing input and hash input construction models.¶

• Separate integrity-protected information from incrementally added long-term validation information by using protected and unprotected header structures appropriately.¶

• Enable incremental extension of validation information and archive timestamps after signing without modifying the original signature value.¶

• Support long-term preservation of signature validity through timestamps, validation information, and renewable archive protection.¶

• Support indirect signing of multiple arbitrary external files through external references (refs).¶

• Reuse existing JOSE and JWS algorithms, identifiers, and processing models as much as possible.¶

• Maintain compatibility with existing JWS JSON Serialization implementations whenever possible.¶

• Prioritize practical Internet deployment and operational simplicity over introducing complex processing models.¶

3.4. Relationship to JWS

LTV-JWS is an extension specification for JSON Web Signature (JWS) defined in [RFC7515].¶

The relationship between LTV-JWS and JWS is summarized as follows:¶

• LTV-JWS preserves the basic JWS JSON Serialization structure consisting of protected headers, payloads, and signatures.¶

• LTV-JWS adds long-term validation capabilities through additional LTV-related objects.¶

• LTV-JWS reuses the existing JWS signing input model and JOSE algorithms without introducing new signature algorithms or new canonicalization mechanisms.¶

• Long-term validation information, timestamps, and archive structures are added incrementally through unprotected header extensions without modifying the original signature value.¶

• LTV-JWS extends the JWS payload usage model by supporting indirect signing of external data through external references (refs).¶

• Verification of indirect signatures requires both JWS signature validation and external reference hash validation.¶

• LTV-JWS is designed to maintain compatibility with existing JWS processing and implementations whenever possible.¶

BASE64 encoding is used for DER-encoded ASN.1 objects for compatibility with existing PKIX and [RFC7515] x5c processing models.¶

LTV-JWS uses both BASE64URL encoding and BASE64 encoding depending on the type of data being represented.¶

Values participating in JWS signing input construction, hash input construction, external reference hash processing, and hash-based identifiers use BASE64URL encoding consistent with [RFC7515] JWS processing and JOSE thumbprint conventions.¶

DER-encoded PKIX and CMS related binary objects, including certificates, CRLs, OCSP responses, and [RFC3161] TimeStampTokens, use BASE64 encoding consistent with the "x5c" header parameter defined in [RFC7515].¶

4.1. JWS Structure

LTV-JWS is based on the JWS JSON Serialization defined in [RFC7515] and consists of protected headers, unprotected headers, payloads, and signatures.¶

LTV-JWS stores long-term validation related information as "ltv" objects distributed across these structures.¶

• The "ltv" object in the protected header contains integrity-protected information included in the JWS signature.¶

• The "ltv" object in the unprotected header contains timestamps, validation information, and archive information incrementally added after signing.¶

• The "ltv.refs" array in the payload contains external references used for indirect signing of external data.¶

This structure enables long-term validation information to be incrementally added without modifying the original signature value.¶

LTV-JWS supports both Flattened JWS JSON Serialization and General JWS JSON Serialization defined in [RFC7515].¶

If the payload contains the "ltv.refs" array, all signatures associated with the same payload MUST be processed as LTV-JWS signatures.¶

In such cases, all corresponding protected headers MUST contain the "ltv" Header Parameter and MUST include "ltv" in the "crit" Header Parameter.¶

This requirement prevents inconsistent interpretation of external reference semantics among signatures sharing the same payload.¶

4.2. Protected Header

In LTV-JWS, the protected header MUST contain the following elements:¶

• "alg": the signature algorithm¶

• "crit": an array containing "ltv"¶

• "ltv": the LTV extension object¶

By including "ltv" in the "crit" parameter, implementations that do not understand this specification MUST reject the JWS.¶

The "ltv" object in the protected header is included in the JWS signature input and its integrity is protected.¶

4.3. Unprotected Header

In LTV-JWS, validation information and timestamps added after signing are stored in the unprotected header.¶

The "ltv" object in the unprotected header is not included in the JWS signature input and therefore MUST NOT be trusted independently.¶

Such information is indirectly protected through timestamps or archive structures.¶

4.4. Payload

The payload contains the signed target data.¶

LTV-JWS supports the following payload models:¶

1. Attached payload model: The payload contains BASE64URL-encoded signed data.¶

2. Indirect signing model: The payload contains a JSON object including "ltv.refs" used for indirect signing of external data.¶

Detached payloads as defined in [RFC7515] are allowed but NOT RECOMMENDED for LTV-JWS, since long-term validation benefits from preserving payload or external reference information together with the signature.¶

If detached payloads are used, implementations and operational environments SHOULD ensure long-term availability and consistent preservation of the detached payload data associated with the signature.¶

Loss, modification, or ambiguity of detached payload data may result in failure of signature validation, timestamp validation, archive validation, or long-term validation.¶

If the payload contains the "ltv.refs" array, the payload itself still participates in JWS signature input construction.¶

Externally referenced data identified by "ltv.refs" is validated separately through external reference hash validation.¶

4.5. Signature

The signature contains the JWS signature value generated using the protected header and payload according to [RFC7515].¶

LTV-JWS does not define new signature algorithms and reuses existing JOSE signature algorithms.¶

5.1. ltv Protected Header Object

The "ltv" object in the protected header contains integrity-protected information included in the JWS signature input. This object contains information bound to the original signature at signing time.¶

5.2. ltv Unprotected Header Object

5.3. ltv Payload Object

The payload "ltv" object is OPTIONAL.¶

If the "ltv" object exists, it contains external reference information used for indirect signing of external data.¶

6.1. Signature Input and Timestamp Hash Inputs

LTV-JWS constructs signature inputs and timestamp hash inputs by concatenating BASE64URL-encoded values using the "." character.¶

The following simplified LTV-JWS structure illustrates how signature inputs and timestamp hash inputs are constructed across each signature level.¶

The values "AAAAAA" and similar values represent BASE64URL-encoded element values.¶

{
  "payload": "AAAAAA",
  "protected": "BBBBBB",
  "signature": "CCCCCC",
  "header":
  {
    "ltv":
    {
      "timestamp": "DDDDDD",
      "signing": "EEEEEE",
      "archive":
      {
        "timestamp": "FFFFFF",
        "archive":
        {
          "rehashes": "GGGGGG",
          "timestamp": "HHHHHH"
        }
      }
    }
  }
}

Where:¶

• "DDDDDD" is the signature timestamp with validations¶

• "EEEEEE" contains validations for the signing certificate¶

• "FFFFFF" is the 1st archive timestamp with validations¶

• "GGGGGG" contains renewal hashes for refs¶

• "HHHHHH" is the 2nd archive timestamp (with validations)¶

The following table shows the corresponding signature and timestamp hash inputs.¶

For timestamp generation, the resulting concatenated string is hashed and used as the [RFC3161] messageImprint value.¶

The strings above represent the exact concatenated BASE64URL-encoded values used as signature input or timestamp hash inputs.¶

6.2. SIG-B (Signature Base level) Creation Processing

SIG-B is the initial signature level of LTV-JWS and represents the signature-only extension level of JWS.¶

SIG-B binds signed target data and the signing certificate using a JWS signature and a signing certificate hash.¶

SIG-B can be used both as a normal JWS signature and as an indirect signing model using external references ("refs").¶

External references are OPTIONAL. If no external references exist, SIG-B is processed as a normal JWS signature.¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature)

BASE64URL(protected) || "." ||
BASE64URL(payload)

6.3. SIG-T (Signature Timestamp level) Creation Processing

SIG-T is the signature level that adds a signature timestamp to SIG-B.¶

SIG-T provides trusted proof that the signature existed prior to a specific point in time.¶

SIG-T is used to prove that the signature existed before expiration or revocation of the signing certificate.¶

The SIG-T signature timestamp is generated over a hash input constructed from the JWS "protected", "payload", and "signature".¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature)

6.4. SIG-LTV (Signature Long-Term Validation level) Creation Processing

SIG-LTV is the signature level that validates SIG-T or SIG-LTA and adds validation information.¶

SIG-LTV MAY be constructed after validation of SIG-T or SIG-LTA.¶

SIG-LTV preserves validation information used for validation of signing certificates and all timestamp TSA certificates in order to enable Long-Term Validation of signatures in the future without depending on external validation services or network access.¶

6.5. SIG-LTA (Signature Long-Term Archive Timestamp level) Creation Processing

SIG-LTA is the signature level that adds an archive timestamp to SIG-LTV.¶

When SIG-LTA is generated for the first time, the first "archive" object is added as header.ltv.archive.¶

If an "archive" object already exists, long-term validity is continuously preserved by recursively adding the next "archive" object within the existing "archive" object.¶

A newly added "archive" object MAY contain "rehashes", which stores renewed hash values for external references ("refs").¶

A newly added "archive" object also contains an archive timestamp "timestamp" parameter used to protect information contained within the existing archive structure.¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature) || "." ||
BASE64URL(header.ltv.timestamp) || "." ||
BASE64URL(header.ltv.signing)

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature) || "." ||
BASE64URL(header.ltv.timestamp) || "." ||
BASE64URL(header.ltv.signing) || "." ||
BASE64URL(header.ltv.archive.timestamp)

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature) || "." ||
BASE64URL(header.ltv.timestamp) || "." ||
BASE64URL(header.ltv.signing) || "." ||
BASE64URL(header.ltv.archive.timestamp) || "." ||
BASE64URL(header.ltv.archive.archive.rehashes)

7.1. Validation Reference Time

LTV-JWS validation uses the validation reference time shown in the following table.¶

If no corresponding timestamp exists, the current time is used as the validation reference time.¶

If SIG-B does not contain a valid Signature Timestamp and the applicable validation policy permits use of signingTime, signingTime MAY be used as the validation reference time.¶

The determination of validation reference time and validation results depends on the applicable validation policy.¶

7.2. SIG-B Validation Processing

SIG-B is the base validation level that validates the JWS signature and the signing certificate.¶

SIG-B validation performs JWS signature verification, PKIX validation of the signing certificate, and external reference ("refs") hash validation.¶

The validation result of SIG-B is determined as Valid, Invalid, or Indeterminate.¶

7.3. SIG-T Validation Processing

During SIG-T validation, implementations MUST also validate SIG-B.¶

7.4. SIG-LTV Validation Processing

SIG-LTV validation MUST enable offline validation of SIG-B, SIG-T, and all existing SIG-LTA levels.¶

7.5. SIG-LTA Validation Processing

During SIG-LTA validation, implementations MUST validate SIG-B, SIG-T, and all existing SIG-LTA levels.¶

8.1. JSON Object Processing

Implementations MUST reject JSON objects containing duplicate member names.¶

This requirement applies to all JSON objects defined in this specification, including:¶

• protected headers¶

• unprotected headers¶

• payload "ltv" objects¶

• "validations" objects¶

• "archive" objects¶

• decoded JSON objects contained in "signing", "timestamp", and "rehashes" parameters¶

Duplicate member names may cause inconsistent interpretation between implementations and may result in incorrect signature validation, timestamp validation, archive validation, or external reference validation.¶

8.2. Trust Model of Unprotected Header Information

LTV-JWS stores timestamps, validation information, and archive-related information in the unprotected header.¶

Information stored in the unprotected header is not directly protected by the JWS signature.¶

However, most validation information and timestamp-related information stored in the unprotected header are protected by existing PKIX/CMS signatures generated by CAs, OCSP responders, or TSAs.¶

In addition, unprotected header information is subject to long-term integrity protection through archive timestamps.¶

Implementations MUST NOT treat unprotected header information as trusted solely because such information is present in the JWS object.¶

If archive timestamp validation fails, the associated unprotected header information MUST be treated as untrusted.¶

8.3. Detached Payload Considerations

Detached payload usage may complicate long-term preservation and validation because the payload data required for JWS signature validation is stored outside the JWS object.¶

Implementations and operational environments SHOULD ensure long-term preservation, availability, and integrity of detached payload data associated with LTV-JWS objects.¶

Loss or ambiguity of detached payload data may result in failure of signature validation, timestamp validation, archive validation, or long-term validation.¶

8.4. Validation Requirements for External References

LTV-JWS supports indirect signing of externally referenced data through the "refs" array.¶

Implementations MUST validate all external reference hash values associated with the signature.¶

Successful JWS signature validation alone does not guarantee the integrity or authenticity of externally referenced data.¶

If the recalculated hash value of externally referenced data does not match the corresponding "hashValue" parameter, the validation result MUST be treated as Invalid.¶

LTV-JWS external references are limited to a single-level reference structure using the "refs" array within the payload, and recursive or multi-level external reference structures are not defined.¶

This restriction simplifies external reference validation processing and prevents reference loops, complex dependency relationships, and ambiguity regarding validation scope.¶

Implementations SHOULD carefully consider the trust model, retrieval method, and persistence of externally referenced data.¶

The security and availability of externally referenced data are outside the scope of this specification.¶

8.5. External Reference Retrieval Security

Implementations SHOULD carefully control retrieval of externally referenced data identified by "uri" parameters.¶

Retrieval of external references may introduce security and operational risks including:¶

• Server-Side Request Forgery (SSRF)¶

• unintended access to internal network resources¶

• loopback or local file access¶

• retrieval of mutable or replaced content¶

• excessive resource consumption¶

• denial-of-service conditions¶

• retrieval timeouts¶

• unexpected URI scheme handling¶

Implementations SHOULD restrict permitted URI schemes, network locations, retrieval methods, object sizes, and timeout behavior according to the applicable security policy.¶

Implementations SHOULD NOT automatically trust externally retrieved data solely because the corresponding hash value matches.¶

The security, trustworthiness, persistence, availability, and retrieval policy of externally referenced data are outside the scope of this specification.¶

8.6. Signature Timestamp and Archive Timestamp Validation

LTV-JWS uses [RFC3161] timestamps to prove that signatures, validation information, and archive information existed prior to a specific point in time.¶

A signature timestamp proves that the signed state consisting of the JWS protected header, payload, and signature existed prior to a specific point in time.¶

An archive timestamp protects signatures, timestamps, validation information, and archive information existing prior to it, and enables continued long-term validation.¶

Implementations MUST reconstruct the hash input of signature timestamps and archive timestamps according to the methods defined in this specification and verify that it matches the messageImprint contained in the TimeStampToken.¶

Implementations MUST perform signature validation of all TimeStampTokens and PKIX validation of TSA certificates.¶

If signature timestamp validation fails, the proof of existence (signature time) of the corresponding SIG-B based on that signature timestamp is not established.¶

If archive timestamp validation fails, the proof of existence of the protected contents covered by the corresponding archive timestamp is not established.¶

For long-term validation, implementations MUST perform timestamp and certificate validation using an appropriate validation reference time according to the long-term signature approach.¶

The time of the signature timestamp MUST be used as the validation reference time for SIG-B signature validation.¶

For validation of each validations object, the time of the nearest protecting archive timestamp for the corresponding validation information MUST be used as the validation reference time. If no corresponding archive timestamp exists, the current time MUST be used as the validation reference time.¶

Improper timestamp validation or incorrect use of validation reference time may result in incorrect long-term validation results.¶

8.7. Validation Policy and Trust Anchors

Validation results of LTV-JWS depend on the applicable validation policy and trust anchors.¶

Even for the same LTV-JWS object, validation results may differ depending on the trust anchors used, revocation information, permitted cryptographic algorithms, timestamp validation conditions, determination of validation reference time, or policies regarding the use of external validation information.¶

Implementations MUST appropriately manage trust anchors, certificate validation conditions, revocation checking conditions, timestamp validation conditions, and long-term validation requirements according to the applicable validation policy.¶

During long-term validation, the retention period and availability of certificates, CRLs, OCSP responses, TimeStampTokens, and other validation information may affect validation results.¶

Changes, removal, or revocation of trust anchors, or changes in validation policy, may cause an LTV-JWS object previously determined as Valid to later be determined as Indeterminate or Invalid.¶

8.8. Encoding Confusion Between BASE64URL and BASE64

LTV-JWS uses both BASE64URL encoding and BASE64 encoding depending on the purpose of the represented data.¶

Values used for JWS signing input construction, timestamp hash input construction, external reference hash input construction, and hash-based identifiers use BASE64URL encoding.¶

In contrast, DER-encoded ASN.1 binary objects such as certificates, CRLs, OCSP responses, and [RFC3161] TimeStampTokens use BASE64 encoding consistent with the "x5c" parameter defined in [RFC7515].¶

BASE64URL encoding and BASE64 encoding are not interchangeable and differ in character sets and padding rules.¶

Implementations MUST use the correct encoding for each parameter and hash input construction defined in this specification.¶

Incorrect encoding processing, incorrect decoding processing, or confusion between BASE64URL encoding and BASE64 encoding may result in signature validation failure, timestamp validation failure, external reference hash mismatch, or long-term validation failure.¶

8.9. Recursive Archive Validation

LTV-JWS preserves long-term signature validity by continuously adding archive timestamps using a recursive archive structure.¶

Each archive timestamp protects signatures, timestamps, validation information, and archive information existing prior to it.¶

Implementations MUST reconstruct the hash input corresponding to each archive timestamp according to the method defined in this specification and verify that it matches the messageImprint contained in the TimeStampToken.¶

For validation of each archive timestamp, the time of the corresponding nearest protecting archive timestamp MUST be used as the validation reference time. If no nearest protecting archive timestamp exists, the current time MUST be used as the validation reference time.¶

Archive timestamp validation may be performed from outermost to innermost, or from innermost to outermost, depending on implementation or validation policy. However, implementations SHOULD apply validation processing consistently.¶

If recursive archive validation fails, the long-term validation state protected by the corresponding archive timestamp MUST be treated as untrusted.¶

Implementations and operational environments SHOULD avoid excessive nesting of recursive archive structures.¶

8.10. Cryptographic Algorithm Agility

LTV-JWS adopts a long-term signature approach that assumes cryptographic algorithm migration in order to address cryptographic algorithm obsolescence, weakening, or compromise.¶

Cryptographic algorithms used for signatures, timestamps, certificate validation, and external reference hashes may lose security over time.¶

Implementations and operational environments MUST migrate to cryptographic algorithms providing sufficient security according to the applicable security policy.¶

By continuously adding archive timestamps, past signatures, timestamps, validation information, and archive information can continue to be protected using newer cryptographic algorithms.¶

For external references, before the currently used hash algorithm becomes weak or compromised, overlapping assurance using both old and new hash algorithms can be maintained by adding "rehashes".¶

In the long-term signature approach, even cryptographic algorithms that are currently considered weak or deprecated may still be considered valid if the corresponding signatures, timestamps, or hash values were generated at a time when those algorithms were considered sufficiently secure.¶

Therefore, implementations and operational environments MUST appropriately manage the validity period, security evaluation, and applicable usage period of each cryptographic algorithm.¶

Implementations MUST appropriately identify weak or deprecated cryptographic algorithms and determine validation results according to the applicable validation policy.¶

Failure of cryptographic algorithm migration, inappropriate algorithm selection, or insufficient archive timestamp renewal may result in loss of long-term signature validity.¶

8.11. Canonicalization and Deterministic Inputs

LTV-JWS achieves deterministic signature inputs and hash inputs without using JSON canonicalization by reusing the JWS signing input model defined in [RFC7515].¶

JWS signature inputs, signature timestamp hash inputs, and archive timestamp hash inputs are constructed by concatenating BASE64URL-encoded values using the "." character.¶

For external references, the external reference hash input uses the externally referenced binary data itself as the hash input by default. If type=jws is used, the same BASE64URL concatenation model as the JWS signing input model is used.¶

This approach avoids differences caused by JSON serialization order, whitespace, indentation, or other variations in JSON textual representation.¶

Even in recursive archive structures, hash inputs are deterministically reconstructed without requiring JSON canonicalization because the hash inputs are constructed as ordered concatenations of BASE64URL-encoded values.¶

Implementations MUST reconstruct signature inputs and hash inputs according to the exact input construction methods defined in this specification.¶

Incorrect JSON re-serialization, misuse of JSON canonicalization, incorrect BASE64URL processing, or incorrect input construction ordering may result in signature validation failure, timestamp validation failure, or long-term validation failure.¶

In particular, archive timestamp validation requires exact reconstruction of hash inputs including prior archive structures, and incorrect input reconstruction may cause failure of the entire long-term signature validation.¶

8.12. Local Signing Time Considerations

The "signingTime" parameter in LTV-JWS represents the local system time used at the time of signing.¶

The "signingTime" value is informational and does not by itself provide cryptographically protected proof of signing time.¶

Trusted signing time is generally established using trusted timestamp mechanisms such as [RFC3161] timestamps.¶

Implementations MUST NOT treat "signingTime" as trusted signing time. However, this restriction does not apply if the applicable validation policy permits the use of trusted local system time.¶

The "signingTime" value may contain incorrect values due to system clock manipulation, timezone misconfiguration, incorrect local time configuration, or malicious signers.¶

If the "signingTime" value significantly differs from the trusted timestamp time, the validation policy should treat the difference as a suspicious time discrepancy warning.¶

For long-term validation, validation reference times should generally be based on trusted timestamps.¶

8.13. Validation Information Applicability

For long-term validation in LTV-JWS, appropriate validation information MUST be used for the applicable validation reference time.¶

Certificates, CRLs, OCSP responses, TimeStampTokens, and other validation information should be valid and applicable at the corresponding validation reference time.¶

Implementations MUST appropriately validate certificate validity periods, CRL issuance times, nextUpdate values, OCSP response validity, timestamp times, and other validation-related time information.¶

Use of inappropriate validation information for a given validation reference time may result in incorrect revocation status determination or incorrect validation results.¶

In the long-term signature approach, validation information itself also needs to be continuously protected by archive timestamps.¶

Missing, corrupted, or inapplicable validation information for a given validation reference time may cause long-term validation results to become Indeterminate.¶

Implementations and operational environments should appropriately preserve validation information required for long-term validation and continue adding archive timestamps appropriately.¶

9.1. Registration of the "ltv" JOSE Header Parameter

This specification defines the "ltv" JOSE Header Parameter for use in JWS Protected Headers and Unprotected Headers.¶

This specification also uses an "ltv" object within the payload for external reference ("refs") structures.¶

The "ltv" Header Parameter contains long-term validation related information including signature extension information, timestamps, validation information, and archive information.¶

This specification requests registration of the "ltv" parameter in the "JSON Web Signature and Encryption Header Parameters" registry.¶

The registration is as follows:¶

• Header Parameter Name: "ltv"¶

• Header Parameter Description: Long-Term Validation information container for JWS¶

• Header Parameter Usage Location(s): JWS Protected Header, JWS Unprotected Header¶

• Change Controller: IETF¶

• Specification Document(s): This specification¶

The "ltv" Header Parameter MAY be included in the "crit" Header Parameter defined in [RFC7515].¶

Implementations that do not understand the "ltv" Header Parameter and encounter "ltv" in "crit" MUST reject the JWS.¶

9.2. LTV-JWS External Reference Type Identifiers

This specification defines external reference "type" identifiers used by LTV-JWS.¶

These identifiers are used to identify external reference hash input construction methods and external reference signing models.¶

This specification defines the following initial values:¶

• "raw": uses externally referenced binary data directly as the hash input¶

• "jws": uses the same BASE64URL concatenation model as the JWS signing input model for externally referenced JWS objects¶

Additional external reference type identifiers may be defined by future specifications.¶

9.3. LTV-JWS Timestamp Type Identifiers

This specification defines timestamp "type" identifier used by LTV-JWS.¶

These identifiers are used to identify the timestamp format contained in timestamp objects.¶

This specification defines the following initial value:¶

• "rfc3161": [RFC3161] TimeStampToken¶

Additional timestamp type identifiers may be defined by future specifications.¶

9.4. Hash Algorithm Identifiers

This specification defines "S256", "S384", and "S512" as hash algorithm identifiers.¶

These are shorthand identifiers representing SHA-256, SHA-384, and SHA-512 respectively.¶

Additional hash algorithm identifiers may be defined by future specifications.¶

9.5. No New Cryptographic Algorithms

This specification does not define new signature algorithms, hash algorithms, timestamp algorithms, or cryptographic primitives.¶

LTV-JWS reuses existing algorithms and processing models defined in [RFC7515], [RFC7518], [RFC3161], and existing PKIX/CMS related specifications.¶

A.1. Example SIG-B (examples/sig-b.json)

This example shows a SIG-B LTV-JWS object.¶

The example demonstrates:¶

• JWS JSON Serialization¶

• crit usage for "ltv"¶

• signingTime¶

• signingCertHash¶

• indirect signing using ltv.refs¶

• external references (test1.txt and test2.json)¶

• optional signer validation information using header.ltv.signing¶

For minimal SIG-B objects, the header.ltv.signing parameter MAY be omitted if signer validation information is not embedded.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "eyJsdHYiOnsicmVmcyI6W3sidXJpIjoidGVzdDEudHh0IiwiaGFzaEFsZyI6IlMyNTYiLCJoYXNoVmFsdWUiOiJxVFZ2S3pVLTFHeFRpcmN4dkdTbTQ1bGUyb2Ixdks3cHVBemJYdVhWYm9vIn0seyJ1cmkiOiJ0ZXN0Mi5qc29uIiwiaGFzaEFsZyI6IlMyNTYiLCJoYXNoVmFsdWUiOiIzWURVZ2xGNDF4dmdmSUF2OFRxYS03OTVxaG8zaUlKaXB2LXYzS1JtMldBIn1dfX0",
  "protected": "eyJhbGciOiJSUzI1NiIsImNyaXQiOlsibHR2Il0sImx0diI6eyJzaWduaW5nVGltZSI6IjIwMjYtMDUtMThUMDE6NDg6MDVaIiwic2lnbmluZ0NlcnRIYXNoIjp7Imhhc2hBbGciOiJTMjU2IiwiaGFzaFZhbHVlIjoibnhsWDFtOXRycEFkN1dTMjN5OEV2TG5PTlppVEZoLWtKQlpTRkdyNXZ4NCJ9fX0",
  "signature": "SD1LmkNPQFotnNvmkdymyrMTWVb_NTYjnY_VZ8Od5GGroA0RH3acuHhqjH9Yw46BnDPfr5Fjb996QBU8NhMzvrrBT38BBCFzyTMlChq_EkaRXeZyb3Ag1AClAe0Wz1g41tpQxnzWGRR8v6ozymb6g-T17Z_3I0SZlMKbmPdHVY0uFwYsgRpntqxM9_mG1kSZjyvYfrk-ZufyPuwgj8_l08-mN1Us6Gp6csqJJ8-QTd5-JPdKAFnj14QfYuEeyQcx5ZZaizDlEQnXghstkEJJ-dUIhlx5Pl0waAQvSp5H65bx0PDmVASfHQUIoy_Y3z5zqrGHRpJqPgAxOh770CzaQtF_yjujHWeVNqpgdX36zPl4f18jKbGRgEggl5iszoNWu-IVAFMVBQdR7vwXfdbuetjttfYuqo5Yk3Gw2bv7T3YeV2_7_1yGwByc8SXcP3PkStpDqIz_SRJ6sQ9K0cvwR6araBXpbkRqCECfG8DFfwlZqyPwgXG10B8N-2ABbPro",
  "header": {
    "ltv": {
      "signing": "eyJ2YWxpZGF0aW9ucyI6eyJjZXJ0cyI6WyJNSUlGaXpDQ0Ez..."
    }
  }
}

This example shows a SIG-B LTV-JWS object including optional signer validation information.¶

Decoded payload:¶

{
  "ltv": {
    "refs": [
      {
        "uri": "test1.txt",
        "hashAlg": "S256",
        "hashValue": "qTVvKzU-1GxTircxvGSm45le2ob1vK7puAzbXuXVboo"
      },
      {
        "uri": "test2.json",
        "hashAlg": "S256",
        "hashValue": "3YDUglF41xvgfIAv8Tqa-795qho3iIJipv-v3KRm2WA"
      }
    ]
  }
}

Decoded protected header:¶

{
  "alg": "RS256",
  "crit": ["ltv"],
  "ltv": {
    "signingTime": "2026-05-18T01:48:05Z",
    "signingCertHash": {
      "hashAlg": "S256",
      "hashValue": "nxlX1m9trpAd7WS23y8EvLnONZiTFh-kJBZSFGr5vx4"
    }
  }
}

Decoded BASE64URL value of header.ltv.signing:¶

{
  "validations": {
    "certs": [
      "MIIFizCCA3OgAwIBAgIDEAAXMA0GCSqGSIb3DQEBCwUAME4x..."
    ]
  }
}

The header.ltv.signing value itself is a BASE64URL-encoded JSON object.¶

The embedded certificate values use BASE64 encoding because they are DER-encoded ASN.1 objects.¶

The JWS Signing Input for this example is constructed as:¶

BASE64URL(protected) || "." ||
BASE64URL(payload)

This example uses indirect signing through the ltv.refs array.¶

The externally referenced files identified by ltv.refs are:¶

• test1.txt¶

• test2.json¶

The hashValue of each reference is calculated over the externally referenced binary data itself because the default external reference type is raw.¶

{
  "payload": "(same as SIG-B example)",
  "protected": "(same as SIG-B example)",
  "signature": "(same as SIG-B example)",
  "header": {
    "x5c":["MIIFizCCA3OgAwIBAgIDEAAXMA0GCSqGSIb3DQEBCwUAME4x..."]
  }
}

A.2. Example SIG-T (examples/sig-t.json)

This example shows a SIG-T LTV-JWS object generated by adding a signature timestamp to the previous SIG-B example.¶

The example demonstrates:¶

• [RFC3161] signature timestamp¶

• header.ltv.timestamp¶

• signature timestamp hash input construction¶

The header.ltv.timestamp value itself is a BASE64URL-encoded JSON object.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "(same as SIG-B example)",
  "protected": "(same as SIG-B example)",
  "signature": "(same as SIG-B example)",
  "header": {
    "ltv": {
      "signing": "(same as SIG-B example)",
      "timestamp": "eyJ0c3QiOiJNSUlQRVFZSktvWklodmNOQVFjQ29JSVBBakND..."
    }
  }
}

Decoded BASE64URL value of header.ltv.timestamp:¶

{
  "tst": "MIIPEQYJKoZIhvcNAQcCoIIPAjCCDv4CAQMxCzAJBgUrDgMCGgUAMIHU..."
}

The tst value contains a BASE64-encoded [RFC3161] TimeStampToken in DER format.¶

The Signature Timestamp Input for this example is constructed as:¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature)

The [RFC3161] messageImprint value is calculated from the hash value of the Signature Timestamp Input.¶

If the type parameter is omitted, the timestamp type defaults to "rfc3161".¶

The decoded BASE64URL value of header.ltv.timestamp MAY additionally contain a validations object preserving validation information for the TSA certificate.¶

A.3. Example SIG-LTV (examples/sig-ltv.json)

This example shows a SIG-LTV LTV-JWS object generated by adding validation information to the previous SIG-T example.¶

The example demonstrates:¶

• validation information embedding¶

• header.ltv.signing¶

• validations within the decoded BASE64URL value of header.ltv.timestamp¶

• preservation of certificates and CRLs for long-term validation¶

The header.ltv.signing and header.ltv.timestamp values are BASE64URL-encoded JSON objects.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "(same as SIG-T example)",
  "protected": "(same as SIG-T example)",
  "signature": "(same as SIG-T example)",
  "header": {
    "ltv": {
      "signing": "eyJ2YWxpZGF0aW9ucyI6eyJjZXJ0cyI6WyJNSUlGMlRDQ0E4...",
      "timestamp": "eyJ0c3QiOiJNSUlQRVFZSktvWklodmNOQVFjQ29JSVBBakND..."
    }
  }
}

Decoded BASE64URL value of header.ltv.signing:¶

{
  "validations": {
    "certs": [
      "MIIF2TCCA8GgAwIBAgIHA41+pMaABTANBgkqhkiG9w0BAQsF...",
      "MIIFizCCA3OgAwIBAgIDEAAXMA0GCSqGSIb3DQEBCwUAME4x..."
    ],
    "crls": [
      "MIICrDCBlTANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQGEwJK..."
    ]
  }
}

Decoded BASE64URL value of header.ltv.timestamp:¶

{
  "tst": "MIIPEQYJKoZIhvcNAQcCoIIPAjCCDv4CAQMxCzAJBgUrDgMC...",
  "validations": {
    "certs": [
      "MIIF2TCCA8GgAwIBAgIHA41+pMaABjANBgkqhkiG9w0BAQsF...",
      "MIIFozCCA4ugAwIBAgIDIAAwMA0GCSqGSIb3DQEBCwUAME4x..."
    ],
    "crls": [
      "MIICrDCBlTANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQGEwJK..."
    ]
  }
}

The validations.certs array within the decoded BASE64URL value of header.ltv.signing contains the signing certificate and certificates required for PKIX validation of the signing certificate.¶

The validations.certs array within the decoded BASE64URL value of header.ltv.timestamp contains the TSA certificate and certificates required for PKIX validation of the TSA certificate associated with the [RFC3161] timestamp.¶

The embedded certificate values use BASE64 encoding because they are DER-encoded ASN.1 certificate objects.¶

The embedded CRL values use BASE64 encoding because they are DER-encoded ASN.1 CRL objects.¶

The tst value contains a BASE64-encoded [RFC3161] TimeStampToken in DER format.¶

Validation information preserved in SIG-LTV MAY include certificates, CRLs, OCSP responses and other validation-related information required for Long-Term Validation.¶

SIG-LTV validation can be performed using only the preserved validation information without requiring external validation services or network access.¶

A.4. Example SIG-LTA (examples/sig-lta.json)

This example shows a SIG-LTA LTV-JWS object generated by adding an archive timestamp to the previous SIG-LTV example.¶

The example demonstrates:¶

• archive timestamp protection¶

• header.ltv.archive.timestamp¶

• long-term preservation of validation information¶

• renewable archive protection¶

The header.ltv.archive.timestamp value is a BASE64URL-encoded JSON object.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "(same as SIG-LTV example)",
  "protected": "(same as SIG-LTV example)",
  "signature": "(same as SIG-LTV example)",
  "header": {
    "ltv": {
      "signing": "(same as SIG-LTV example)",
      "timestamp": "(same as SIG-LTV example)",
      "archive": {
        "timestamp": "eyJ0c3QiOiJNSUlQRUFZSktvWklodmNOQVFjQ29JSVBBVEND..."
      }
    }
  }
}

Decoded BASE64URL value of header.ltv.archive.timestamp:¶

{
  "tst": "MIIPEAYJKoZIhvcNAQcCoIIPATCCDv0CAQMxCzAJBgUrDgMC..."
}

The tst value contains a BASE64-encoded [RFC3161] TimeStampToken in DER format.¶

The Archive Timestamp Input for this example is constructed as:¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature) || "." ||
BASE64URL(header.ltv.timestamp) || "." ||
BASE64URL(header.ltv.signing)

The [RFC3161] messageImprint value of the archive timestamp is calculated from the hash value of the Archive Timestamp Input.¶

The archive timestamp protects the accumulated long-term validation state existing at the time of archive timestamp generation.¶

• the JWS signature¶

• the external reference hashes¶

• the signature timestamp¶

• the preserved validation information¶

Additional archive timestamps MAY be added recursively for long-term renewal protection.¶

A.5. Example SIG-LTV 2nd (examples/sig-ltv-2nd.json)

This example shows a second-generation SIG-LTV object generated by adding validation information for the archive timestamp TSA certificate to the previous SIG-LTA example.¶

The example demonstrates:¶

• preservation of archive timestamp TSA validation information¶

• recursive long-term validation state accumulation¶

• second-generation long-term validation information¶

The header.ltv.archive.timestamp value is a BASE64URL-encoded JSON object.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "(same as SIG-LTA example)",
  "protected": "(same as SIG-LTA example)",
  "signature": "(same as SIG-LTA example)",
  "header": {
    "ltv": {
      "signing": "(same as SIG-LTV example)",
      "timestamp": "(same as SIG-LTV example)",
      "archive": {
        "timestamp": "eyJ0c3QiOiJNSUlQRUFZSktvWklodmNOQVFjQ29JSVBBVEND..."
      }
    }
  }
}

Decoded BASE64URL value of header.ltv.archive.timestamp:¶

{
  "tst": "MIIPEAYJKoZIhvcNAQcCoIIPATCCDv0CAQMxCzAJBgUrDgMC...",
  "validations": {
    "certs": [
      "MIIF2TCCA8GgAwIBAgIHA41+pMaABjANBgkqhkiG9w0BAQsF...",
      "MIIE..."
    ],
    "crls": [
      "MIICrDCBlTANBgkqhkiG9w0BAQsFADBOMQswCQYDVQQGEwJK..."
    ]
  }
}

The header.ltv.archive.timestamp.validations.certs array contains the archive TSA certificate and certificates required for PKIX validation of the archive TSA certificate associated with the [RFC3161] archive timestamp.¶

The embedded certificate values use BASE64 encoding because they are DER-encoded ASN.1 certificate objects.¶

The embedded CRL values use BASE64 encoding because they are DER-encoded ASN.1 CRL objects.¶

The tst value contains a BASE64-encoded [RFC3161] TimeStampToken in DER format.¶

The archive timestamp validation information becomes part of the accumulated long-term validation state protected by subsequent archive timestamps.¶

Additional archive timestamps MAY be added recursively for long-term renewal protection.¶

A.6. Example SIG-LTA 2nd (examples/sig-lta-2nd.json)

This example shows a second-generation SIG-LTA object generated by adding a new archive timestamp to the previous SIG-LTV 2nd example.¶

The example demonstrates:¶

• recursive archive timestamp protection¶

• second-generation archive timestamps¶

• preservation of accumulated long-term validation state¶

• renewable archive timestamp protection¶

The header.ltv.archive.archive.timestamp value is a BASE64URL-encoded JSON object.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "(same as SIG-LTV 2nd example)",
  "protected": "(same as SIG-LTV 2nd example)",
  "signature": "(same as SIG-LTV 2nd example)",
  "header": {
    "ltv": {
      "signing": "(same as SIG-LTV example)",
      "timestamp": "(same as SIG-LTV example)",
      "archive": {
        "timestamp": "(same as SIG-LTV 2nd example)",
        "archive": {
          "timestamp": "eyJ0c3QiOiJNSUlQRUFZSktvWklodmNOQVFjQ29JSVBBVEND..."
        }
      }
    }
  }
}

Decoded BASE64URL value of header.ltv.archive.archive.timestamp:¶

{
  "tst": "MIIPEAYJKoZIhvcNAQcCoIIPATCCDv0CAQMxCzAJBgUrDgMC..."
}

The tst value contains a BASE64-encoded [RFC3161] TimeStampToken in DER format.¶

The second-generation archive timestamp protects the accumulated long-term validation state existing at the time of archive timestamp generation, including:¶

• the previous archive timestamp¶

• the JWS signature¶

• the external reference hashes¶

• the signature timestamp¶

• the embedded validation information¶

The Archive Timestamp Input for this example is constructed as:¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature) || "." ||
BASE64URL(header.ltv.timestamp) || "." ||
BASE64URL(header.ltv.signing) || "." ||
BASE64URL(header.ltv.archive.timestamp)

Additional archive timestamps MAY be added recursively for long-term renewal protection.¶

A.7. Example SIG-LTA refs renew hashes (examples/sig-rehash.json)

This example shows a SIG-LTA archive object containing renewed hash information for external references (refs).¶

The example demonstrates:¶

• renewal of external reference hash algorithms¶

• preservation of original external reference ordering¶

• archive protection of renewed hash values¶

• continued verification after cryptographic algorithm updates¶

The header.ltv.archive.archive.rehashes value is a BASE64URL-encoded JSON object.¶

The decoded JSON object preserves the same external references and ordering as the payload ltv.refs array while updating only the hashAlg and hashValue parameters.¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "(same as SIG-LTV example)",
  "protected": "(same as SIG-LTV example)",
  "signature": "(same as SIG-LTV example)",
  "header": {
    "ltv": {
      "signing": "(same as SIG-LTV example)",
      "timestamp": "(same as SIG-LTV example)",
      "archive": {
        "timestamp": "(same as SIG-LTV example)",
        "archive": {
          "rehashes": "eyJsdHYiOnsicmVmcyI6W3sidXJpIjoidGVzdDEudHh0...",
          "timestamp": "eyJ0c3QiOiJNSUlQRVFZSktvWklodmNOQVFjQ29JSVBB..."
        }
      }
    }
  }
}

Decoded BASE64URL value of header.ltv.archive.archive.rehashes:¶

{
  "ltv": {
    "refs": [
      {
        "uri": "test1.txt",
        "hashAlg": "S512",
        "hashValue": "eNAei4m6TiNr3Uuf57rMw82b4JQs3GvFGCRGsiFJi6ViuWV0lQWCbIi9oY_WT-SqK7B3SnLcaw7bQY1XJKJBLQ"
      },
      {
        "uri": "test2.json",
        "hashAlg": "S512",
        "hashValue": "lJjoF-6wuQ-OcrC6MGWBQvY1WfAFnX60El-HDejKCYQWt0Pa0qs8zWHJ5XdyuraN0c96IgE3wDIIfAdIIBGcWw"
      }
    ]
  }
}

The renewed ltv.refs array preserves the same external references and the same ordering as the payload ltv.refs array.¶

Only the hashAlg and hashValue parameters are updated.¶

The Archive Timestamp Input for this example is constructed as:¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature) || "." ||
BASE64URL(header.ltv.timestamp) || "." ||
BASE64URL(header.ltv.signing) || "." ||
BASE64URL(header.ltv.archive.timestamp) || "." ||
BASE64URL(header.ltv.archive.archive.rehashes)

The resulting archive timestamp is stored in header.ltv.archive.archive.timestamp.¶

The generated archive timestamp protects:¶

• the original JWS signature¶

• the signature timestamp¶

• the signing validation information¶

• the previous archive timestamp¶

• the renewed external reference hashes¶

Additional archive timestamps and renewed hash information MAY be added recursively for continued long-term preservation.¶

A.8. Example Chained Signing (examples/sig-chained.json)

This example shows a chained signing model using external references.¶

The example demonstrates:¶

• signing of external data using refs¶

• indirect signing of another JWS object¶

• chained verification using referenced JWS signatures¶

• use of mixed external reference types¶

The payload contains two external references:¶

• test1.txt¶

  • referenced as raw external data¶

• sig-b.json¶

  • referenced as a JWS object using "type": "jws"¶

Some long BASE64URL and BASE64 values are shortened for readability.¶

{
  "payload": "eyJsdHYiOnsicmVmcyI6W3sidXJpIjoidGVzdDEudHh0IiwiaGFzaEFsZyI6IlMyNTYiLCJoYXNoVmFsdWUiOiJxVFZ2S3pVLTFHeFRpcmN4dkdTbTQ1bGUyb2Ixdks3cHVBemJYdVhWYm9vIn0seyJ1cmkiOiJzaWctYi5qc29uIiwiaGFzaEFsZyI6IlMyNTYiLCJoYXNoVmFsdWUiOiJuVlFTblF1M2YwMlI2cURmdURkaV9LWkY1YjRLeDVHUWtNTjRWdXdiSjNVIiwidHlwZSI6Imp3cyJ9XX19",
  "protected": "eyJhbGciOiJSUzI1NiIsImNyaXQiOlsibHR2Il0sImx0diI6eyJzaWduaW5nVGltZSI6IjIwMjYtMDUtMThUMDE6NDg6MDVaIiwic2lnbmluZ0NlcnRIYXNoIjp7Imhhc2hBbGciOiJTMjU2IiwiaGFzaFZhbHVlIjoibnhsWDFtOXRycEFkN1dTMjN5OEV2TG5PTlppVEZoLWtKQlpTRkdyNXZ4NCJ9fX0",
  "signature": "Fot99xm-cHhZlAE5uR9sTfeOmsTPx-ozWVpAI0PEUHILsbNcKNr4lVfUQtB3vWkQy2iOkgr5Xi_tCXPYgMa2noWXN7BPBfA2ObTGy05tEZvFLc1TkkGgpeaQg0rOZbdkxAYgD8V6HPx7V1FZNz3sL-GQGLEXQ8CTjSmyapjt4Pq03OQhiFHxc3cnuD7euBBXfUwwPIF1RALAaAjqxQfWUQ9yuyLnUZsBoIVv_UqTGQBHS3DoKGD7klwDswGIU-4xVU0i4GUaRyLM4hs4IZkHizowMasS-i4765UIy6jXiEpCJQz0-UBKzCkwyQAS8qagM8hzXPrPC9wt3VJoFDVWCjONItdR1b9l6nudRDjiQ4w6hr3niuDnIGNk46YN5n9IHOyQb-V6ZQ9BP0STyjoAQ-VX379E9J7iOTY_HDr6Sm7rNjPVADA-QVNRHCctk9-Elw3Lk3qEAtHfAs8FSHl3cfMhYjpa9Q2VsNRD1dOTg19sue6YGFnNlDK9b95Gf0MK",
  "header": {
    "ltv": {
      "signing": "eyJ2YWxpZGF0aW9ucyI6eyJjZXJ0cyI6WyJNSUl..."
    }
  }
}

Decoded BASE64URL value of payload:¶

{
  "ltv": {
    "refs": [
      {
        "uri": "test1.txt",
        "hashAlg": "S256",
        "hashValue": "qTVvKzU-1GxTircxvGSm45le2ob1vK7puAzbXuXVboo"
      },
      {
        "uri": "sig-b.json",
        "hashAlg": "S256",
        "hashValue": "nVQSnQu3f02R6qDfuDdi_KZF5b4Kx5GQkMN4VuwbJ3U",
        "type": "jws"
      }
    ]
  }
}

The test1.txt reference is verified as raw external data.¶

The sig-b.json reference is verified as a JWS object.¶

For "type": "jws", the referenced hash input is constructed as:¶

BASE64URL(protected) || "." ||
BASE64URL(payload) || "." ||
BASE64URL(signature)

The verifier computes the hash value of the referenced JWS signing input and compares it with the hashValue parameter.¶

This model allows chained signing and indirect protection of previously signed JWS objects while preserving the original JWS signatures.¶

The signing parameter is optional for SIG-B.¶