doc: Add RFC documents

1 files changed, 1801 insertions, 0 deletions

diff --git a/doc/rfc/rfc9321.txt b/doc/rfc/rfc9321.txt
new file mode 100644
index 0000000..fec9c3c
--- /dev/null
+++ b/doc/rfc/rfc9321.txt
@@ -0,0 +1,1801 @@
+
+
+
+
+Independent Submission                                      S. Santesson
+Request for Comments: 9321                               IDsec Solutions
+Category: Informational                                       R. Housley
+ISSN: 2070-1721                                           Vigil Security
+                                                            October 2022
+
+
+                       Signature Validation Token
+
+Abstract
+
+   Electronic signatures have a limited lifespan with respect to the
+   time period that they can be validated and determined to be
+   authentic.  The Signature Validation Token (SVT) defined in this
+   specification provides evidence that asserts the validity of an
+   electronic signature.  The SVT is provided by a trusted authority,
+   which asserts that a particular signature was successfully validated
+   according to defined procedures at a certain time.  Any future
+   validation of that electronic signature can be satisfied by
+   validating the SVT without any need to also validate the original
+   electronic signature or the associated digital certificates.  The SVT
+   supports electronic signatures in Cryptographic Message Syntax (CMS),
+   XML, PDF, and JSON documents.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9321.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Definitions
+   3.  Signature Validation Token
+     3.1.  Signature Validation Token Function
+     3.2.  Signature Validation Token Syntax
+       3.2.1.  Data Types
+       3.2.2.  Signature Validation Token JWT Claims
+       3.2.3.  SigValidation Object Class
+       3.2.4.  Signature Claims Object Class
+       3.2.5.  SigReference Claims Object Class
+       3.2.6.  SignedDataReference Claims Object Class
+       3.2.7.  PolicyValidation Claims Object Class
+       3.2.8.  TimeValidation Claims Object Class
+       3.2.9.  CertReference Claims Object Class
+       3.2.10. SVT JOSE Header
+   4.  Profiles
+     4.1.  Defined Profiles
+   5.  Signature Verification with an SVT
+   6.  IANA Considerations
+     6.1.  Claim Names Registration
+       6.1.1.  Registry Contents
+     6.2.  Header Parameter Names Registration
+       6.2.1.  Registry Contents
+   7.  Security Considerations
+     7.1.  Level of Reliance
+     7.2.  Aging Algorithms
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Appendix A.  XML Signature Profile
+     A.1.  Notation
+       A.1.1.  References to XML Elements from XML Schemas
+     A.2.  SVT in XML Documents
+       A.2.1.  SignatureValidationToken Signature Property
+       A.2.2.  Multiple SVTs in an XML Signature
+     A.3.  XML Signature SVT Claims
+       A.3.1.  XML Profile Identifier
+       A.3.2.  XML Signature Reference Data
+       A.3.3.  XML Signed Data Reference Data
+       A.3.4.  XML Signer Certificate References
+     A.4.  JOSE Header
+       A.4.1.  SVT Signing Key Reference
+   Appendix B.  PDF Signature Profile
+     B.1.  SVTs in PDF Documents
+       B.1.1.  SVT Extension to Timestamp Tokens
+     B.2.  PDF Signature SVT Claims
+       B.2.1.  PDF Profile Identifier
+       B.2.2.  PDF Signature Reference Data
+       B.2.3.  PDF Signed Data Reference Data
+       B.2.4.  PDF Signer Certificate References
+     B.3.  JOSE Header
+       B.3.1.  SVT Signing Key Reference
+   Appendix C.  JWS Profile
+     C.1.  SVT in JWS
+       C.1.1.  "svt" Header Parameter
+       C.1.2.  Multiple SVTs in a JWS Signature
+     C.2.  JWS Signature SVT Claims
+       C.2.1.  JWS Profile Identifier
+       C.2.2.  JWS Signature Reference Data
+       C.2.3.  JWS Signed Data Reference Data
+       C.2.4.  JWS Signer Certificate References
+     C.3.  SVT JOSE Header
+       C.3.1.  SVT Signing Key Reference
+   Appendix D.  Schemas
+     D.1.  Concise Data Definition Language (CDDL)
+     D.2.  JSON Schema
+   Appendix E.  Examples
+   Authors' Addresses
+
+1.  Introduction
+
+   Electronic signatures have a limited lifespan regarding when they can
+   be validated and determined to be authentic.  Many factors make it
+   more difficult to validate electronic signatures over time.  For
+   example:
+
+   *  Trusted information about the validity of the certificate
+      containing the signer's public key is not available.
+
+   *  Trusted information about the time when the signature was actually
+      created is not available.
+
+   *  Algorithms used to create the electronic signature may no longer
+      be considered secure at the time of validation and may therefore
+      no longer be available in software libraries.
+
+   *  Services necessary to validate the signature are no longer
+      available at the time of validation.
+
+   *  Supporting evidence such as certification authority (CA)
+      certificates, Online Certificate Status Protocol (OCSP) responses,
+      Certificate Revocation Lists (CRLs), or timestamps is not
+      available or can't be validated.
+
+   The challenges to validation of an electronic signature increase over
+   time, and eventually it may simply be impossible to verify the
+   signature with a sufficient level of assurance.
+
+   Existing standards, such as the ETSI XAdES [XADES] profile for XML
+   signatures [XMLDSIG11], ETSI PAdES [PADES] profile for PDF signatures
+   [ISOPDF2], and ETSI CAdES [CADES] profile for CMS signatures
+   [RFC5652], can be used to extend the time within which a signature
+   can be validated at the cost of significant complexity, which
+   involves storing and validating significant amounts of external
+   evidence data such as revocation data, signature time stamps, and
+   archival time stamps.
+
+   The Signature Validation Token (SVT) defined in this specification
+   takes a trusted signature validation process as an input and
+   preserves the validation result for the associated signature and
+   signed document.  The SVT asserts that a particular electronic
+   signature was successfully validated by a trusted authority according
+   to defined procedures at a certain time.  Those procedures MUST
+   include checks that the signature match the signed document, checks
+   that the signature can be validated by the signing certificate, and
+   checks that the signing certificate pass certificate path validation
+   [RFC5280].  Those procedures MAY also include checks associated with
+   a particular trust policy such as that an acceptable certificate
+   policy [RFC5280] [RFC3647] was used to issue the signer's certificate
+   and checks that an acceptable signature policy was used by the signer
+   [RFC3125].
+
+   Once the SVT is issued by a trusted authority, any future validation
+   of that electronic signature can be satisfied by validating the SVT
+   without any need to also revalidate the original electronic
+   signature.
+
+   As the SVT is used to preserve validation results obtained through
+   applying existing standards for signature validation, it is
+   complementary to and not a replacement for such standards, including
+   the ETSI standards for long-term validation listed above.  The SVT
+   does, however, have the potentially positive effect that it may
+   significantly reduce the need to apply complex long-term validation
+   and preservation techniques for signature validation if an SVT is
+   issued and applied to the signed document at an early stage where the
+   signature can be validated without support of large amounts of
+   external evidence.  The use of SVTs may therefore drastically reduce
+   the complexity of revalidation of old archived electronic signatures.
+
+   The SVT can be signed with private keys and algorithms that provide
+   confidence for a considerable time period.  In fact, multiple SVTs
+   can be used to offer greater assurance.  For example, one SVT could
+   be produced with a large RSA private key, a second one with a strong
+   elliptic curve, and a third one with a quantum safe digital signature
+   algorithm to protect against advances in computing power and
+   cryptanalytic capabilities.  Further, the trusted authority can add
+   additional SVTs in the future using fresh private keys and signatures
+   to extend the lifetime of the SVTs if necessary.
+
+2.  Definitions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   This document use the following terms:
+
+   Signed Data:  The data covered by a particular electronic signature.
+      This is typically equivalent to the signed content of a document,
+      and it represents the data that the signer intended to sign.  In
+      some cases, such as in some XML signatures, the Signed Data can be
+      the collection of several data fragments each referenced by the
+      signature.  In the case of PDF, this is the data covered by the
+      "ByteRange" parameter in the signature dictionary.  In JSON Web
+      Signature (JWS), this is the unencoded payload data (before
+      base64url encoding).
+
+   Signed Bytes:  These are the actual bytes of data that were hashed
+      and signed by the digital signature algorithm.  In most cases,
+      this is not the actual Signed Data but a collection of signature
+      metadata that includes references (hash) of the Signed Data as
+      well as information about algorithms and other data bound to a
+      signature.  In XML, this is the canonicalized SignedInfo element.
+      In CMS and PDF signatures, this is the DER-encoded
+      SignedAttributes structure.  In JWS, this is the protected header
+      and payload data formatted according to [RFC7515].
+
+   When these terms are used as defined in this section, they appear
+   with a capitalized first letter.
+
+3.  Signature Validation Token
+
+3.1.  Signature Validation Token Function
+
+   The Signature Validation Token (SVT) is created by a trusted service
+   to assert evidence of successful electronic signature validation
+   using a well-defined and trustworthy signature validation process.
+   The SVT binds the validation result to the validated signature, the
+   document signed by the signature, and the certificate of the signer.
+   This allows a relying party to verify the validity of a signed
+   document without having to revalidate the original signature or to
+   reuse any of its associated cryptographic algorithms for as long as
+   the SVT itself can be validated.  The SVT achieves this by binding
+   the following information to a specific electronic signature:
+
+   *  A unique identification of the electronic signature.
+
+   *  The data and metadata signed by the electronic signature.
+
+   *  The signer's certificate that was validated as part of electronic
+      signature verification.
+
+   *  The certification path that was used to validate the signer's
+      certificate.
+
+   *  An assertion providing evidence of signature verification, the
+      time the verification was performed, the procedures used to verify
+      the electronic signature, and the outcome of the verification.
+
+   *  An assertion providing evidence of the time at which the signature
+      is known to have existed, the procedures used to validate the time
+      of existence, and the outcome of the validation.
+
+   The SVT aims to support long-term validation that can be further
+   extended into the future by applying the following strategies:
+
+   *  by using secure algorithms with long life expectancy when signing
+      the SVT
+
+   *  by reissuing the SVT before it becomes insecure or is considered
+      expired
+
+   *  optionally, by issuing multiple SVTs with different algorithms to
+      provide redundancy in case one algorithm is broken
+
+3.2.  Signature Validation Token Syntax
+
+   The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519].
+
+3.2.1.  Data Types
+
+   The contents of claims in an SVT are specified using the following
+   data types:
+
+   String:  JSON Data Type of string that contains an arbitrary case-
+      sensitive string value.
+
+   Base64Binary:  JSON Data Type of string that contains a
+      Base64-encoded byte array of binary data.
+
+   StringOrURI:  JSON Data Type of string that contains an arbitrary
+      string or a URI as defined in [RFC7519].  It is REQUIRED to
+      contain the colon character (":") to be a URI.
+
+   URI:  JSON Data Type of string that contains a URI as defined in
+      [RFC7519].
+
+   Integer:  JSON Data Type of number that contains a 32-bit signed
+      integer value (from -2^31 to 2^31-1).
+
+   Long:  JSON Data Type of number that contains a 64-bit signed integer
+      value (from -2^63 to 2^63-1).
+
+   NumericDate:  JSON Data Type of number that contains data as defined
+      in [RFC7519], which is the number of seconds from
+      1970-01-01T00:00:00Z UTC until the specified UTC date/time,
+      ignoring leap seconds.
+
+   Boolean:  JSON Data Type of boolean that contains the explicit value
+      of true or false.
+
+   Object<Class>:  A JSON object holding a claims object of a class
+      defined in this specification (see Section 3.2.2).
+
+   Map<Type>:  A JSON object with name-value pairs where the value is an
+      object of the specified Type in the notation.  For example,
+      Map<String> is a JSON object with name-value pairs where all
+      values are of type String.
+
+   Array:  A JSON array of a specific data type as defined in this
+      section.  An array is expressed in this specification by square
+      brackets.  For example, [String] indicates an array of String
+      values, and [Object<DocHash>] indicates an array of DocHash
+      objects.
+
+   Null:  A JSON null that represents an absent value.  A claim with a
+      null value is equivalent with an absent claim.
+
+3.2.2.  Signature Validation Token JWT Claims
+
+   The SVT MUST contain only JWT claims in the following list:
+
+   "jti":  A String data type that is a "JWT ID" registered claim
+      according to [RFC7519].  It is RECOMMENDED that the identifier
+      holds a hexadecimal string representation of a 128-bit unsigned
+      integer.  An SVT MUST contain one "JWT ID" claim.
+
+   "iss":  A StringOrURI data type that is an "Issuer" registered claim
+      according to [RFC7519], which is an arbitrary unique identifier of
+      the SVT issuer.  This value SHOULD have the value of a URI based
+      on a domain owned by the issuer.  An SVT MUST contain one "Issuer"
+      claim.
+
+   "iat":  A NumericDate data type that is an "Issued At" registered
+      claim according to [RFC7519], which expresses the time when this
+      SVT was issued.  An SVT MUST contain one "Issued At" claim.
+
+   "aud":  A [StringOrURI] data type or a StringOrURI data type that is
+      an "Audience" registered claim according to [RFC7519].  The
+      audience claim is an array of one or more identifiers, identifying
+      intended recipients of the SVT.  Each identifier MAY identify a
+      single entity, a group of entities, or a common policy adopted by
+      a group of entities.  If only one value is provided, it MAY be
+      provided as a single StringOrURI data type value instead of as an
+      array of values.  Inclusion of the "Audience" claim in an SVT is
+      OPTIONAL.
+
+   "exp":  A NumericDate data type that is an "Expiration Time"
+      registered claim according to [RFC7519], which expresses the time
+      when services and responsibilities related to this SVT are no
+      longer provided by the SVT issuer.  The precise meaning of the
+      expiration time claim is defined by local policies.  See
+      implementation note below.  Inclusion of the "Expiration Time"
+      claim in an SVT is OPTIONAL.
+
+   "sig_val_claims":  An Object<SigValidation> data type that contains
+      signature validation claims for this SVT extending the standard
+      registered JWT claims above.  An SVT MUST contain one
+      sig_val_claims claim.
+
+   Note: An SVT asserts that a particular validation process was
+   undertaken at a stated time.  This fact never changes and never
+   expires.  However, some other aspects of the SVT such as liability
+   for false claims or service provision related to a specific SVT may
+   expire after a certain period of time, such as a service where an old
+   SVT can be upgraded to a new SVT signed with fresh keys and
+   algorithms.
+
+3.2.3.  SigValidation Object Class
+
+   The sig_val_claims JWT claim uses the SigValidation object class.  A
+   SigValidation object holds all custom claims, and a SigValidation
+   object contains the following parameters:
+
+   "ver":  A String data type representing the version.  This parameter
+      MUST be present and the version in this specification indicated by
+      the value "1.0".
+
+   "profile":  A StringOrURI data type representing the name of a
+      profile that defines conventions followed for specific claims and
+      any extension points used by the SVT issuer.  This parameter MUST
+      be present.
+
+   "hash_algo":  A URI data type that identifies the hash algorithm used
+      to compute the hash values within the SVT.  The URI identifier
+      MUST be one defined in [RFC9231] or in the IANA registry defined
+      by this specification.  This parameter MUST be present.
+
+   "sig":  An [Object<Signature>] data type that gives information about
+      validated electronic signatures as an array of Signature objects.
+      If the SVT contains signature validation evidence for more than
+      one signature, then each signature is represented by a separate
+      Signature object.  At least one Signature object MUST be present.
+
+   "ext":  A Map<String> data type that provides additional claims
+      related to the SVT.  Extension claims are added at the discretion
+      of the SVT issuer; however, extension claims MUST follow any
+      conventions defined in a profile of this specification (see
+      Section 4).  Inclusion of this parameter is OPTIONAL.
+
+3.2.4.  Signature Claims Object Class
+
+   The sig parameter in the SigValidation object class uses the
+   Signature object class.  The Signature object contains claims related
+   to signature validation evidence for one signature, and it contains
+   the following parameters:
+
+   "sig_ref":  An Object<SigReference> data type that contains reference
+      information identifying the target signature.  This parameter MUST
+      be present.
+
+   "sig_data_ref":  An [Object<SignedDataReference>] data type that
+      contains an array of references to Signed Data that was signed by
+      the target electronic signature.  At least one SignedDataReference
+      object MUST be present.
+
+   "signer_cert_ref":  An Object<CertReference> data type that
+      references the signer's certificate and optionally references a
+      supporting certification path that was used to verify the target
+      electronic signature.  This parameter MUST be present.
+
+   "sig_val":  An [Object<PolicyValidation>] data type that contains an
+      array of results of signature verification according to defined
+      procedures.  At least one PolicyValidation object MUST be present.
+
+   "time_val":  An [Object<TimeValidation>] data type that contains an
+      array of time verification results showing that the target
+      signature has existed at a specific time in the past.  Inclusion
+      of this parameter is OPTIONAL.
+
+   "ext":  A MAP<String> data type that provides additional claims
+      related to the target signature.  Extension claims are added at
+      the discretion of the SVT issuer; however, extension claims MUST
+      follow any conventions defined in a profile of this specification
+      (see Section 4).  Inclusion of this parameter is OPTIONAL.
+
+3.2.5.  SigReference Claims Object Class
+
+   The sig_ref parameter in the Signature object class uses the
+   SigReference object class.  The SigReference object provides
+   information used to match the Signature claims object to a specific
+   target electronic signature and to verify the integrity of the target
+   signature value and Signed Bytes, and it contains the following
+   parameters:
+
+   "id":  A String data type that contains an identifier assigned to the
+      target signature.  Inclusion of this parameter is OPTIONAL.
+
+   "sig_hash":  A Base64Binary data type that contains a hash value of
+      the target electronic signature value.  This parameter MUST be
+      present.
+
+   "sb_hash":  A Base64Binary data type that contains a hash value of
+      the Signed Bytes of the target electronic signature.  This
+      parameter MUST be present.
+
+3.2.6.  SignedDataReference Claims Object Class
+
+   The sig_data_ref parameter in the Signature object class uses the
+   SignedDataReference object class.  The SignedDataReference object
+   provides information used to verify the target electronic signature
+   references to Signed Data as well as to verify the integrity of all
+   data that is signed by the target signature, and it contains the
+   following parameters:
+
+   "ref":  A String data type that contains a reference identifier for
+      the data or data fragment covered by the target electronic
+      signature.  This parameter MUST be present.
+
+   "hash":  A Base64Binary data type that contains the hash value for
+      the data covered by the target electronic signature.  This
+      parameter MUST be present.
+
+3.2.7.  PolicyValidation Claims Object Class
+
+   The sig_val parameter in the Signature object class uses the
+   PolicyValidation object class.  The PolicyValidation object provides
+   information about the result of a validation process according to a
+   specific policy, and it contains the following parameters:
+
+   "pol":  A StringOrURI data type that contains the identifier of the
+      policy governing the electronic signature verification process.
+      This parameter MUST be present.
+
+   "res":  A String data type that contains the result of the electronic
+      signature verification process.  The value MUST be one of
+      "PASSED", "FAILED", or "INDETERMINATE" as defined by
+      [ETSI319102-1].  This parameter MUST be present.
+
+   "msg":  A String data type that contains a message describing the
+      result.  Inclusion of this parameter is OPTIONAL.
+
+   "ext":  A MAP<String> data type that provides additional claims
+      related to the target signature.  Extension claims are added at
+      the discretion of the SVT issuer; however, extension claims MUST
+      follow any conventions defined in a profile of this specification
+      (see Section 4).  Inclusion of this parameter is OPTIONAL.
+
+3.2.8.  TimeValidation Claims Object Class
+
+   The time_val parameter in the Signature object class uses the
+   TimeValidation object class.  The TimeValidation claims object
+   provides information about the result of validating evidence of time
+   asserting that the target signature existed at a particular time in
+   the past.  Evidence of time is typically a timestamp according to
+   [RFC3161], but other types of evidence may be used such as a
+   previously issued SVT for this signature.  The TimeValidation claims
+   object contains the following parameters:
+
+   "time":  A NumericDate data type that contains the verified time.
+      This parameter MUST be present.
+
+   "type":  A StringOrURI data type that contains an identifier of the
+      type of evidence of time.  This parameter MUST be present.
+
+   "iss":  A StringOrURI data type that contains an identifier of the
+      entity that issued the evidence of time.  This parameter MUST be
+      present.
+
+   "id":  A String data type that contains an unique identifier assigned
+      to the evidence of time.  Inclusion of this parameter is OPTIONAL.
+
+   "hash":  A Base64Binary data type that contains the hash value of the
+      validated evidence of time.  Inclusion of this parameter is
+      OPTIONAL.
+
+   "val":  An [Object<PolicyValidation>] data type that contains an
+      array of results of the time evidence validation according to
+      defined validation procedures.  Inclusion of this parameter is
+      OPTIONAL.
+
+   "ext":  A MAP<String> data type that provides additional claims
+      related to the target signature.  Extension claims are added at
+      the discretion of the SVT issuer; however, extension claims MUST
+      follow any conventions defined in a profile of this specification
+      (see Section 4).  Inclusion of this parameter is OPTIONAL.
+
+3.2.9.  CertReference Claims Object Class
+
+   The signer_cert_ref parameter in the Signature object class uses the
+   CertReference object class.  The CertReference object references a
+   single X.509 certificate or a X.509 certification path either by
+   providing the certificate data or by providing hash references for
+   certificates that can be located in the target electronic signature,
+   and it contains the following parameters:
+
+   "type":  A StringOrURI data type that contains an identifier of the
+      type of reference.  The type identifier MUST be one of the
+      identifiers defined below, an identifier specified by the selected
+      profile, or a URI identifier.  This parameter MUST be present.
+
+   "ref":  A [String] data type that contains an array of string
+      parameters according to conventions defined by the type
+      identifier.  At least one parameter MUST be present.
+
+   The following type identifiers are defined:
+
+   "chain":  The ref contains an array of Base64-encoded X.509
+      certificates [RFC5280].  The certificates MUST be provided in the
+      order starting with the end entity certificate.  Any following
+      certificate must be able to validate the signature on the previous
+      certificate in the array.
+
+   "chain_hash":  The ref contains an array of one or more
+      Base64-encoded hash values where each hash value is a hash over a
+      X.509 certificate [RFC5280] used to validate the signature.  The
+      certificates MUST be provided in the order starting with the end
+      entity certificate.  Any following certificate must be able to
+      validate the signature on the previous certificate in the array.
+      This option MUST NOT be used unless all hashed certificates are
+      present in the target electronic signature.
+
+   Note: All certificates referenced using the identifiers above are
+   X.509 certificates.  Profiles of this specification MAY define
+   alternative types of public key containers; however, a major function
+   of these referenced certificates is not just to reference the public
+   key but also to provide the subject name of the signer.  It is
+   therefore important for the full function of an SVT that the
+   referenced public key container also provides the means to identify
+   the signer.
+
+3.2.10.  SVT JOSE Header
+
+   The SVT JWT MUST contain the following JSON Object Signing and
+   Encryption (JOSE) header parameters in accordance with Section 5 of
+   [RFC7519]:
+
+   "typ":  This parameter MUST have the string value "JWT" (upper case).
+
+   "alg":  This parameter identifies the algorithm used to sign the SVT
+      JWT.  The algorithm identifier MUST be specified in [RFC7518] or
+      the IANA "JSON Web Signature and Encryption Algorithms" registry
+      [IANA-JOSE-REG].  The specified signature hash algorithm MUST be
+      identical to the hash algorithm specified in the hash_algo
+      parameter of the SigValidation object within the sig_val_claims
+      claim.
+
+   The SVT header MUST contain a public key or a reference to a public
+   key used to verify the signature on the SVT in accordance with
+   [RFC7515].  Each profile, as discussed in Section 4, MUST define the
+   requirements for how the key or key reference is included in the
+   header.
+
+4.  Profiles
+
+   Each signed document and signature type will have to define the
+   precise content and use of several claims in the SVT.
+
+   At a minimum, each profile MUST define:
+
+   *  The identifier of the profile
+
+   *  How to reference the Signed Data content of the signed document
+
+   *  How to reference the target electronic signature and the Signed
+      Bytes of the signature
+
+   *  How to reference certificates supporting each electronic signature
+
+   *  How to include public keys or references to public keys in the SVT
+
+   *  Whether each electronic signature is supported by a single SVT, or
+      one SVT may support multiple electronic signatures of the same
+      document
+
+   A profile MAY also define:
+
+   *  Explicit information on how to perform signature validation based
+      on an SVT
+
+   *  How to attach an SVT to an electronic signature or signed document
+
+4.1.  Defined Profiles
+
+   The following profiles are defined in appendixes of this document:
+
+   Appendix A:  XML Signature Profile
+
+   Appendix B:  PDF Signature Profile
+
+   Appendix C:  JWS Profile
+
+   Other documents MAY define other profiles that MAY complement, amend,
+   or supersede these profiles.
+
+5.  Signature Verification with an SVT
+
+   Signature verification based on an SVT MUST follow these steps:
+
+   1.  Locate all available SVTs available for the signed document that
+       are relevant for the target electronic signature.
+
+   2.  Select the most recent SVT that can be successfully validated and
+       meets the requirement of the relying party.
+
+   3.  Verify the integrity of the signature and the Signed Bytes of the
+       target electronic signature using the sig_ref claim.
+
+   4.  Verify that the Signed Data reference in the original electronic
+       signature matches the reference values in the sig_data_ref claim.
+
+   5.  Verify the integrity of referenced Signed Data using provided
+       hash values in the sig_data_ref claim.
+
+   6.  Obtain the verified certificates supporting the asserted
+       electronic signature verification through the signer_cert_ref
+       claim.
+
+   7.  Verify that signature validation policy results satisfy the
+       requirements of the relying party.
+
+   8.  Verify that verified time results satisfy the context for the use
+       of the signed document.
+
+   After successfully performing these steps, signature validity is
+   established as well as the trusted signer certificate binding the
+   identity of the signer to the electronic signature.
+
+6.  IANA Considerations
+
+6.1.  Claim Names Registration
+
+   IANA has registered the "sig_val_claims" claim name in the "JSON Web
+   Token Claims" registry established by Section 10.1 of [RFC7519].
+
+6.1.1.  Registry Contents
+
+   Claim Name:  sig_val_claims
+
+   Claim Description:  Signature Validation Token
+
+   Change Controller:  IESG
+
+   Specification Document(s):  Section 3.2.3 of RFC 9321
+
+6.2.  Header Parameter Names Registration
+
+   IANA has registered the "svt" Header Parameter in the "JSON Web
+   Signature and Encryption Header Parameters" registry established by
+   [RFC7515].
+
+6.2.1.  Registry Contents
+
+   Header Parameter Name:  svt
+
+   Header Parameter Description:  Signature Validation Token
+
+   Header Parameter Usage Location(s):  JWS
+
+   Change Controller:  IESG
+
+   Specification Document(s):  Appendix C.1.1 of RFC 9321
+
+7.  Security Considerations
+
+7.1.  Level of Reliance
+
+   An SVT allows a signature verifier to still validate the original
+   signature using the original signature data and to use the
+   information in the SVT selectively to confirm the validity and
+   integrity of the original data, such as confirming the integrity of
+   Signed Data or the validity of the signer's certificate, etc.
+
+   Another way to use an SVT is to completely rely on the validation
+   conclusion provided by the SVT and to omit revalidation of the
+   original signature value and original certificate status checking
+   data.
+
+   This choice is a decision made by the verifier according to its own
+   policy and risk assessment.
+
+   However, even when relying on the SVT validation conclusion of an
+   SVT, it is vital to still verify that the present SVT is correctly
+   associated with the document and signature that is being validated by
+   validating the hashed reference data in the SVT of the signature,
+   signing certificate chain, Signed Data, and the Signed Bytes.
+
+7.2.  Aging Algorithms
+
+   Even if the SVT provides protection against algorithms becoming
+   weakened or broken over time, this protection is only valid for as
+   long as the algorithms used to sign the SVT are still considered
+   secure.  It is advisable to reissue SVTs in cases where an algorithm
+   protecting the SVT is getting close to its end of life.
+
+   One way to increase the resistance of algorithms becoming insecure,
+   is to issue multiple SVTs for the same signature with different
+   algorithms and key lengths where one algorithm could still be secure
+   even if the corresponding algorithm used in the alternative SVT is
+   broken.
+
+8.  References
+
+8.1.  Normative References
+
+   [CADES]    ETSI, "Electronic Signatures and Infrastructures (ESI);
+              CAdES digital signatures; Part 1: Building blocks and
+              CAdES baseline signatures", v1.1.1, ETSI EN 319 122-1,
+              April 2016.
+
+   [ETSI319102-1]
+              ETSI, "Electronic Signatures and Infrastructures (ESI);
+              Procedures for Creation and Validation of AdES Digital
+              Signatures; Part 1: Creation and Validation", v1.1.1, ETSI
+              EN 319 102-1, May 2016.
+
+   [IANA-JOSE-REG]
+              IANA, "JSON Object Signing and Encryption (JOSE)",
+              <https://www.iana.org/assignments/jose/>.
+
+   [ISOPDF2]  ISO, "Document management -- Portable document format --
+              Part 2: PDF 2.0", ISO 32000-2:2020, December 2020.
+
+   [PADES]    ETSI, "Electronic Signatures and Infrastructures (ESI);
+              PAdES digital signatures; Part 1: Building blocks and
+              PAdES baseline signatures", v1.1.1, ETSI EN 319 142-1,
+              April 2016.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3125]  Ross, J., Pinkas, D., and N. Pope, "Electronic Signature
+              Policies", RFC 3125, DOI 10.17487/RFC3125, September 2001,
+              <https://www.rfc-editor.org/info/rfc3125>.
+
+   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+              "Internet X.509 Public Key Infrastructure Time-Stamp
+              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
+              2001, <https://www.rfc-editor.org/info/rfc3161>.
+
+   [RFC3647]  Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
+              Wu, "Internet X.509 Public Key Infrastructure Certificate
+              Policy and Certification Practices Framework", RFC 3647,
+              DOI 10.17487/RFC3647, November 2003,
+              <https://www.rfc-editor.org/info/rfc3647>.
+
+   [RFC5035]  Schaad, J., "Enhanced Security Services (ESS) Update:
+              Adding CertID Algorithm Agility", RFC 5035,
+              DOI 10.17487/RFC5035, August 2007,
+              <https://www.rfc-editor.org/info/rfc5035>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <https://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
+              2015, <https://www.rfc-editor.org/info/rfc7515>.
+
+   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
+              DOI 10.17487/RFC7518, May 2015,
+              <https://www.rfc-editor.org/info/rfc7518>.
+
+   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+              <https://www.rfc-editor.org/info/rfc7519>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC9231]  Eastlake 3rd, D., "Additional XML Security Uniform
+              Resource Identifiers (URIs)", RFC 9231,
+              DOI 10.17487/RFC9231, July 2022,
+              <https://www.rfc-editor.org/info/rfc9231>.
+
+   [XADES]    ETSI, "Electronic Signatures and Infrastructures (ESI);
+              XAdES digital signatures; Part 1: Building blocks and
+              XAdES baseline signatures", v1.1.1, ETSI EN 319 132-1,
+              April 2016.
+
+   [XMLDSIG11]
+              Eastlake 3rd, D., Reagle, J., Solo, D., Hirsch, F.,
+              Nystrom, M., Roessler, T., and K. Yiu, "XML Signature
+              Syntax and Processing Version 1.1", W3C Proposed
+              Recommendation, April 2013.  Latest version available at
+              https://www.w3.org/TR/xmldsig- core1/.
+
+8.2.  Informative References
+
+   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
+              Definition Language (CDDL): A Notational Convention to
+              Express Concise Binary Object Representation (CBOR) and
+              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
+              June 2019, <https://www.rfc-editor.org/info/rfc8610>.
+
+Appendix A.  XML Signature Profile
+
+   This appendix defines a profile for implementing SVTs with a signed
+   XML document and defines the following aspects of SVT usage:
+
+   *  How to include reference data related to XML signatures and XML
+      documents in an SVT
+
+   *  How to add an SVT token to an XML signature
+
+   XML documents can have any number of signature elements, signing an
+   arbitrary number of fragments of XML documents.  The actual signature
+   element may be included in the signed XML document (enveloped),
+   include the Signed Data (enveloping), or may be separate from the
+   signed content (detached).
+
+   To provide a generic solution for any type of XML signature, an SVT
+   is added to each XML signature element within the XML signature
+   <ds:Object> element.
+
+A.1.  Notation
+
+A.1.1.  References to XML Elements from XML Schemas
+
+   When referring to elements from the W3C XML Signature namespace
+   (https://www.w3.org/2000/09/xmldsig#), the following syntax is used:
+
+   *  <ds:Signature>
+
+   When referring to elements from the ETSI XAdES XML Signature
+   namespace (https://uri.etsi.org/01903/v1.3.2#), the following syntax
+   is used:
+
+   *  <xades:CertDigest>
+
+   When referring to elements defined in this specification
+   (http://id.swedenconnect.se/svt/1.0/sig-prop/ns), the following
+   syntax is used:
+
+   *  <svt:Element>
+
+A.2.  SVT in XML Documents
+
+   When SVTs are provided for XML signatures, then one SVT MUST be
+   provided for each XML signature.
+
+   An SVT embedded within the XML signature element MUST be placed in a
+   <svt:SignatureValidationToken> element as defined in Appendix A.2.1.
+
+A.2.1.  SignatureValidationToken Signature Property
+
+   The <svt:SignatureValidationToken> element MUST be placed in a
+   <ds:SignatureProperty> element in accordance with [XMLDSIG11].  The
+   <ds:SignatureProperty> element MUST be placed inside a
+   <ds:SignatureProperties> element inside a <ds:Object> element inside
+   a <ds:Signature> element.
+
+   Note: [XMLDSIG11] requires the Target attribute to be present in
+   <ds:SignatureProperty>, referencing the signature targeted by this
+   signature property.  If an SVT is added to a signature that does not
+   have an Id attribute, implementations SHOULD add an Id attribute to
+   the <ds:Signature> element and reference that Id in the Target
+   attribute.  This Id attribute and Target attribute value matching is
+   required by the [XMLDSIG11] standard, but it is redundant in the
+   context of SVT validation as the SVT already contains information
+   that uniquely identifies the target signature.  Validation
+   applications SHOULD NOT reject an SVT token because of Id and Target
+   attribute mismatch and MUST rely on matching against a signature
+   using signed information in the SVT itself.
+
+   The <svt:SignatureValidationToken> element is defined by the
+   following XML Schema:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
+       elementFormDefault="qualified"
+       targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
+       xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">
+
+     <xs:element name="SignatureValidationToken"
+         type="svt:SignatureValidationTokenType" />
+
+     <xs:complexType name="SignatureValidationTokenType">
+       <xs:simpleContent>
+         <xs:extension base="xs:string">
+         </xs:extension>
+       </xs:simpleContent>
+     </xs:complexType>
+
+   </xs:schema>
+
+   The SVT token MUST be included as a string representation of the SVT
+   JWT.  Note that this is the string representation of the JWT without
+   further encoding.  The SVT MUST NOT be represented by the
+   Base64-encoded bytes of the JWT string.
+
+   Example:
+
+   <ds:Signature Id="MySignatureId">
+     ...
+     <ds:Object>
+       <ds:SignatureProperties>
+         <ds:SignatureProperty Target="#MySignatureId">
+           <svt:SignatureValidationToken>
+                 eyJ0eXAiOiJKV1QiLCJhb...2aNZ
+           </svt:SignatureValidationToken>
+         </ds:SignatureProperty>
+       </ds:SignatureProperties>
+     </ds:Object>
+   </ds:Signature>
+
+A.2.2.  Multiple SVTs in an XML Signature
+
+   If a new SVT is stored in a signature that already contains a
+   previously issued SVT, implementations can choose either to replace
+   the existing SVT or to store the new SVT in addition to the existing
+   SVT.
+
+   If the new SVT is stored in addition to the old SVT, it SHOULD be
+   stored in a new <ds:SignatureProperty> element inside the existing
+   <ds:SignatureProperties> element where the old SVT is located.
+
+   For interoperability robustness, signature validation applications
+   MUST be able to handle signatures where the new SVT is located in a
+   new <ds:Object> element.
+
+A.3.  XML Signature SVT Claims
+
+A.3.1.  XML Profile Identifier
+
+   When this profile is used, the SigValidation object MUST contain a
+   "profile" claim with the value "XML".
+
+A.3.2.  XML Signature Reference Data
+
+   The SVT Signature object MUST contain a "sig_ref" claim (SigReference
+   object) with the following elements:
+
+   "id":  The Id-attribute of the XML signature, if present.
+
+   "sig_hash":  The hash over the signature value bytes.
+
+   "sb_hash":  The hash over the canonicalized <ds:SignedInfo> element
+      (the bytes the XML signature algorithm has signed to generate the
+      signature value).
+
+A.3.3.  XML Signed Data Reference Data
+
+   The SVT Signature object MUST contain one instance of the "sig_data"
+   claim (SignedData object) for each <ds:Reference> element in the
+   <ds:SignedInfo> element.  The "sig_data" claim MUST contain the
+   following elements:
+
+   "ref":  The value of the URI attribute of the corresponding
+      <ds:Reference> element.
+
+   "hash":  The hash of all bytes that were identified by the
+      corresponding <ds:Reference> element after applying all identified
+      canonicalization and transformation algorithms.  These are the
+      same bytes that are hashed by the hash value in the
+      <ds:DigestValue> element inside the <ds:Reference> element.
+
+A.3.4.  XML Signer Certificate References
+
+   The SVT Signature object MUST contain a "signer_cert_ref" claim
+   (CertReference object).  The "type" parameter of the
+   "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
+
+   *  The "chain" type MUST be used when signature validation was
+      performed using one or more certificates where some or all of the
+      certificates in the chain are not present in the target signature.
+
+   *  The "chain_hash" type MUST be used when signature validation was
+      performed using one or more certificates where all of the
+      certificates are present in the target signature.
+
+A.4.  JOSE Header
+
+A.4.1.  SVT Signing Key Reference
+
+   The SVT JOSE header for XML signatures must contain one of the
+   following header parameters in accordance with [RFC7515] for storing
+   a reference to the public key used to verify the signature on the
+   SVT:
+
+   "x5c":  Holds an X.509 certificate [RFC5280] or a chain of
+      certificates.  The certificate holding the public key that
+      verifies the signature on the SVT MUST be the first certificate in
+      the chain.
+
+   "kid":  A key identifier holding the Base64-encoded hash value of the
+      certificate that can verify the signature on the SVT.  The hash
+      algorithm MUST be the same hash algorithm used when signing the
+      SVT as specified by the "alg" Header Parameter.
+
+Appendix B.  PDF Signature Profile
+
+   This appendix defines a profile for implementing SVTs with a signed
+   PDF document, and it defines the following aspects of SVT usage:
+
+   *  How to include reference data related to PDF signatures and PDF
+      documents in an SVT.
+
+   *  How to add an SVT token to a PDF document.
+
+   PDF document signatures are added as incremental updates to the
+   signed PDF document and signs all data of the PDF document up until
+   the current signature.  When more than one signature is added to a
+   PDF document the previous signature is signed by the next signature
+   and can not be updated with additional data after this event.
+
+   To minimize the impact on PDF documents with multiple signatures and
+   to stay backwards compatible with PDF software that does not
+   understand SVTs, PDF documents add one SVT token for all signatures
+   of the PDF as an extension to a document timestamp added to the
+   signed PDF as an incremental update.  This SVT covers all signatures
+   of the signed PDF.
+
+B.1.  SVTs in PDF Documents
+
+   The SVT for a signed PDF document MAY provide signature validation
+   information about any of the present signatures in the PDF.  The SVT
+   MUST contain a separate "sig" claim (Signature object) for each
+   signature on the PDF that is covered by the SVT.
+
+   An SVT added to a signed PDF document MUST be added to a document
+   timestamp in accordance with ISO 32000-2:2020 [ISOPDF2].
+
+   The document timestamp contains an [RFC3161] timestamp token
+   (TSTInfo) in EncapsulatedContentInfo of the CMS signature.  The SVT
+   MUST be added to the timestamp token (TSTInfo) as an Extension object
+   as defined in Appendix B.1.1.
+
+B.1.1.  SVT Extension to Timestamp Tokens
+
+   The SVT extension is an Extension suitable to be included in TSTInfo
+   as defined by [RFC3161].
+
+   The SVT extension is identified by the Object Identifier (OID)
+   1.2.752.201.5.2.
+
+   This extension data (OCTET STRING) holds the bytes of SVT JWT,
+   represented as a UTF-8-encoded string.
+
+   This extension MUST NOT be marked critical.
+
+   Note: Extensions in timestamp tokens according to [RFC3161] are
+   imported from the definition of the X.509 certificate extensions
+   defined in [RFC5280].
+
+B.2.  PDF Signature SVT Claims
+
+B.2.1.  PDF Profile Identifier
+
+   When this profile is used, the SigValidation object MUST contain a
+   "profile" claim with the value "PDF".
+
+B.2.2.  PDF Signature Reference Data
+
+   The SVT Signature object MUST contain a "sig_ref" claim (SigReference
+   object) with the following elements:
+
+   "id":  Absent or a Null value.
+
+   "sig_hash":  The hash over the signature value bytes.
+
+   "sb_hash":  The hash over the DER-encoded SignedAttributes in
+      SignerInfo.
+
+B.2.3.  PDF Signed Data Reference Data
+
+   The SVT Signature object MUST contain one instance of the "sig_data"
+   claim (SignedData object) with the following elements:
+
+   "ref":  The string representation of the ByteRange value of the PDF
+      signature dictionary of the target signature.  This is a sequence
+      of integers separated by space where each integer pair specifies
+      the start index and length of a byte range.
+
+   "hash":  The hash of all bytes identified by the ByteRange value.
+      This is the concatenation of all byte ranges identified by the
+      ByteRange value.
+
+B.2.4.  PDF Signer Certificate References
+
+   The SVT Signature object MUST contain a "signer_cert_ref" claim
+   (CertReference object).  The "type" parameter of the
+   "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
+
+   *  The "chain" type MUST be used when signature validation was
+      performed using one or more certificates where some or all of the
+      certificates in the chain are not present in the target signature.
+
+   *  The "chain_hash" type MUST be used when signature validation was
+      performed using one or more certificates where all of the
+      certificates are present in the target signature.
+
+   Note: The referenced signer certificate MUST match any certificates
+   referenced using ESSCertID or ESSCertIDv2 from [RFC5035].
+
+B.3.  JOSE Header
+
+B.3.1.  SVT Signing Key Reference
+
+   The SVT JOSE header must contain one of the following header
+   parameters in accordance with [RFC7515] for storing a reference to
+   the public key used to verify the signature on the SVT:
+
+   "x5c":  Holds an X.509 certificate [RFC5280] or a chain of
+      certificates.  The certificate holding the public key that
+      verifies the signature on the SVT MUST be the first certificate in
+      the chain.
+
+   "kid":  A key identifier holding the Base64-encoded hash value of the
+      certificate that can verify the signature on the SVT.  The hash
+      algorithm MUST be the same hash algorithm used when signing the
+      SVT as specified by the "alg" Header Parameter.  The referenced
+      certificate SHOULD be the same certificate that was used to sign
+      the document timestamp that contains the SVT.
+
+Appendix C.  JWS Profile
+
+   This appendix defines a profile for implementing SVTs with a JWS
+   signed payload according to [RFC7515], and it defines the following
+   aspects of SVT usage:
+
+   *  How to include reference data related to JWS signatures in an SVT.
+
+   *  How to add an SVT token to JWS signatures.
+
+   A JWS may have one or more signatures, depending on its serialization
+   format, signing the same payload data.  A JWS either contains the
+   data to be signed (enveloping) or may sign any externally associated
+   payload data (detached).
+
+   To provide a generic solution for JWS, an SVT is added to each
+   present signature as a JWS Unprotected Header.  If a JWS includes
+   multiple signatures, then each signature includes its own SVT.
+
+C.1.  SVT in JWS
+
+   An SVT token MAY be added to any signature of a JWS to support
+   validation of that signature.  If more than one signature is present,
+   then each present SVT MUST provide information exclusively related to
+   one associated signature and MUST NOT include information about any
+   other signature in the JWS.
+
+   Each SVT is stored in its associated signature's "svt" header as
+   defined in Appendix C.1.1.
+
+C.1.1.  "svt" Header Parameter
+
+   The "svt" (Signature Validation Token) Header Parameter is used to
+   contain an array of SVT tokens to support validation of the
+   associated signature.  Each SVT token in the array has the format of
+   a JWT as defined in [RFC7519] and is stored using its natural string
+   representation without further wrapping or encoding.
+
+   The "svt" Header Parameter, when used, MUST be included as a JWS
+   Unprotected Header.
+
+   Note: A JWS Unprotected Header is not supported with JWS Compact
+   Serialization.  A consequence of adding an SVT token to a JWS is
+   therefore that JWS JSON Serialization MUST be used either in the form
+   of general JWS JSON Serialization (for one or more signatures) or in
+   the form of flattened JWS JSON Serialization (optionally used when
+   only one signature is present in the JWS).
+
+C.1.2.  Multiple SVTs in a JWS Signature
+
+   If a new SVT is stored in a signature that already contains a
+   previously issued SVT, implementations can choose either to replace
+   the existing SVT or to store the new SVT in addition to the existing
+   SVT.
+
+   If a JWS signature already contains an array of SVTs and a new SVT is
+   to be added, then the new SVT MUST be added to the array of SVT
+   tokens in the existing "svt" Header Parameter.
+
+C.2.  JWS Signature SVT Claims
+
+C.2.1.  JWS Profile Identifier
+
+   When this profile is used, the SigValidation object MUST contain a
+   "profile" claim with the value "JWS".
+
+C.2.2.  JWS Signature Reference Data
+
+   The SVT Signature object MUST contain a "sig_ref" claim (SigReference
+   object) with the following elements:
+
+   "sig_hash":  The hash over the associated signature value (the bytes
+      of the base64url-decoded signature parameter).
+
+   "sb_hash":  The hash over all bytes signed by the associated
+      signature (the JWS Signing Input according to [RFC7515]).
+
+C.2.3.  JWS Signed Data Reference Data
+
+   The SVT Signature object MUST contain one instance of the "sig_data"
+   claim (SignedData object) with the following elements:
+
+   "ref":  This parameter MUST hold one of the following three possible
+      values:
+
+      1.  The explicit string value "payload" if the signed JWS Payload
+          is embedded in a "payload" member of the JWS.
+
+      2.  The explicit string value "detached" if the JWS signs detached
+          payload data without explicit reference.
+
+      3.  A URI that can be used to identify or fetch the detached
+          Signed Data.  The means to determine the URI for the detached
+          Signed Data is outside the scope of this specification.
+
+   "hash":  The hash over the JWS Payload data bytes (not its base64url-
+      encoded string representation).
+
+C.2.4.  JWS Signer Certificate References
+
+   The SVT Signature object MUST contain a "signer_cert_ref" claim
+   (CertReference object).  The "type" parameter of the
+   "signer_cert_ref" claim MUST be either "chain" or "chain_hash".
+
+   *  The "chain" type MUST be used when signature validation was
+      performed using one or more certificates where some or all of the
+      certificates in the chain are not present in the target signature.
+
+   *  The "chain_hash" type MUST be used when signature validation was
+      performed using one or more certificates where all of the
+      certificates are present in the target signature JOSE header using
+      the "x5c" Header Parameter.
+
+C.3.  SVT JOSE Header
+
+C.3.1.  SVT Signing Key Reference
+
+   The SVT JOSE header must contain one of the following header
+   parameters in accordance with [RFC7515] for storing a reference to
+   the public key used to verify the signature on the SVT:
+
+   "x5c":  Holds an X.509 certificate [RFC5280] or a chain of
+      certificates.  The certificate holding the public key that
+      verifies the signature on the SVT MUST be the first certificate in
+      the chain.
+
+   "kid":  A key identifier holding the Base64-encoded hash value of the
+      certificate that can verify the signature on the SVT.  The hash
+      algorithm MUST be the same hash algorithm used when signing the
+      SVT as specified by the "alg" Header Parameter.
+
+Appendix D.  Schemas
+
+D.1.  Concise Data Definition Language (CDDL)
+
+   The following informative CDDL [RFC8610] expresses the structure of
+   an SVT token:
+
+   svt = {
+     jti: text
+     iss: text
+     iat: uint
+     ? aud: text / [* text]
+     ? exp: uint
+     sig_val_claims: SigValClaims
+   }
+
+   SigValClaims = {
+     ver: text
+     profile: text
+     hash_algo: text
+     sig: [+ Signature]
+     ? ext: Extension
+   }
+
+   Signature = {
+     sig_ref: SigReference
+     sig_data_ref: [+ SignedDataReference]
+     signer_cert_ref: CertReference
+     sig_val: [+ PolicyValidation]
+     ? time_val: [* TimeValidation]
+     ? ext: Extension
+   }
+
+   SigReference = {
+     ? id: text / null
+     sig_hash: binary-value
+     sb_hash: binary-value
+   }
+
+   SignedDataReference = {
+     ref: text
+     hash: binary-value
+   }
+
+
+   CertReference = {
+     type: "chain" / "chain_hash"
+     ref: [+ text]
+   }
+
+   PolicyValidation = {
+     pol: text
+     res: "PASSED" / "FAILED" / "INDETERMINATE"
+     ? msg: text / null
+     ? ext: Extension
+   }
+
+   TimeValidation = {
+     "time": uint
+     type: text
+     iss: text
+     ? id: text / null
+     ? hash: binary-value / null
+     ? val: [* PolicyValidation]
+     ? ext: Extension
+   }
+
+
+   Extension = {
+     + text => text
+   } / null
+
+   binary-value = text             ; base64 classic with padding
+
+D.2.  JSON Schema
+
+   The following informative JSON schema describes the syntax of the SVT
+   token payload.
+
+   {
+       "$schema": "https://json-schema.org/draft/2020-12/schema",
+       "title": "Signature Validation Token JSON Schema",
+       "description": "Schema defining the payload format for SVTs",
+       "type": "object",
+       "required": [
+           "jti",
+           "iss",
+           "iat",
+           "sig_val_claims"
+       ],
+       "properties": {
+           "jti": {
+               "description": "JWT ID",
+               "type": "string"
+           },
+           "iss": {
+               "description": "Issuer",
+               "type": "string"
+           },
+           "iat": {
+               "description": "Issued At",
+               "type": "integer"
+           },
+           "aud": {
+               "description": "Audience",
+               "type": [
+                   "string",
+                   "array"
+               ],
+               "items": {"type": "string"}
+           },
+           "exp": {
+               "description": "Expiration time (seconds since epoch)",
+               "type": "integer"
+           },
+           "sig_val_claims": {
+               "description": "Signature validation claims",
+               "type": "object",
+               "required": [
+                   "ver",
+                   "profile",
+                   "hash_algo",
+                   "sig"
+               ],
+               "properties": {
+                   "ver": {
+                       "description": "Version",
+                       "type": "string"
+                   },
+                   "profile": {
+                       "description": "Implementation profile",
+                       "type": "string"
+                   },
+                   "hash_algo": {
+                       "description": "Hash algorithm URI",
+                       "type": "string"
+                   },
+                   "sig": {
+                       "description": "Validated signatures",
+                       "type": "array",
+                       "items": {
+                           "$ref": "#/$def/Signature"
+                       },
+                       "minItems": 1
+                   },
+                   "ext": {
+                       "description": "Extension map",
+                       "$ref": "#/$def/Extension"
+                   }
+               },
+               "additionalProperties": false
+           }
+       },
+   "additionalProperties": false,
+   "$def": {
+            "Signature":{
+                "type": "object",
+                "required": [
+                    "sig_ref",
+                    "sig_data_ref",
+                    "signer_cert_ref",
+                    "sig_val"
+                ],
+                "properties": {
+                    "sig_ref": {
+                        "description": "Signature Reference",
+                        "$ref": "#/$def/SigReference"
+                    },
+                    "sig_data_ref": {
+                        "description": "Signed data array",
+                        "type": "array",
+                        "items": {
+                            "$ref" : "#/$def/SignedDataReference"
+                        },
+                        "minItems": 1
+                    },
+                    "signer_cert_ref": {
+                        "description": "Signer certificate reference",
+                        "$ref": "#/$def/CertReference"
+                    },
+                    "sig_val": {
+                        "description": "Signature validation results",
+                        "type": "array",
+                        "items": {
+                            "$ref": "#/$def/PolicyValidation"
+                        },
+                        "minItems": 1
+                    },
+                    "time_val": {
+                        "description": "Time validations",
+                        "type": "array",
+                        "items": {
+                            "$ref": "#/$def/TimeValidation"
+                        }
+                    },
+                   "ext": {
+                       "description": "Extension map",
+                       "$ref": "#/$def/Extension"
+                   }
+                },
+                "additionalProperties": false
+            },
+            "SigReference":{
+                "type": "object",
+                "required": [
+                    "sig_hash",
+                    "sb_hash"
+                ],
+                "properties": {
+                    "sig_hash": {
+                        "description": "Hash of the signature value",
+                        "type": "string",
+                        "format": "base64"
+                    },
+                    "sb_hash": {
+                        "description": "Hash of the Signed Bytes",
+                        "type": "string",
+                        "format": "base64"
+                    },
+                    "id": {
+                        "description": "Signature ID reference",
+                        "type": ["string","null"]
+                    }
+                },
+               "additionalProperties": false
+            },
+            "SignedDataReference": {
+                "type": "object",
+                "required": [
+                    "ref",
+                    "hash"
+                ],
+                "properties": {
+                    "ref": {
+                        "description": "Reference to the signed data",
+                        "type": "string"
+                    },
+                    "hash": {
+                        "description": "Signed data hash",
+                        "type": "string",
+                        "format": "base64"
+                    }
+                },
+               "additionalProperties": false
+            },
+            "CertReference":{
+                "type": "object",
+                "required": [
+                    "type",
+                    "ref"
+                ],
+                "properties": {
+                    "type": {
+                        "description": "Type of certificate reference",
+                        "type": "string",
+                        "enum": ["chain","chain_hash"]
+                    },
+                    "ref": {
+                        "description": "Certificate reference data",
+                        "type": "array",
+                        "items": {
+                            "type": "string",
+                            "format": "base64"
+                        },
+                        "minItems": 1
+                    }
+                },
+               "additionalProperties": false
+            },
+            "PolicyValidation":{
+                "type": "object",
+                "required": [
+                    "pol",
+                    "res"
+                ],
+                "properties": {
+                    "pol": {
+                        "description": "Policy identifier",
+                        "type": "string"
+                    },
+                    "res": {
+                        "description": "Signature validation result",
+                        "type": "string",
+                        "enum": ["PASSED","FAILED","INDETERMINATE"]
+                    },
+                    "msg": {
+                        "description": "Message",
+                        "type": ["string","null"]
+                    },
+                    "ext": {
+                       "description": "Extension map",
+                       "$ref": "#/$def/Extension"
+                   }
+                },
+               "additionalProperties": false
+            },
+            "TimeValidation":{
+                "type": "object",
+                "required": [
+                    "time",
+                    "type",
+                    "iss"
+                ],
+                "properties": {
+                    "time": {
+                        "description": "Verified time",
+                        "type": "integer"
+                    },
+                    "type": {
+                        "description": "Type of time validation proof",
+                        "type": "string"
+                    },
+                    "iss": {
+                        "description": "Issuer of the time proof",
+                        "type": "string"
+                    },
+                    "id": {
+                        "description": "Time evidence identifier",
+                        "type": ["string","null"]
+
+                    },
+                    "hash": {
+                        "description": "Hash of time evidence",
+                        "type": ["string","null"],
+                        "format": "base64"
+                    },
+                    "val": {
+                        "description": "Validation result",
+                        "type": "array",
+                        "items": {
+                            "$ref": "#/$def/PolicyValidation"
+                        }
+                    },
+                    "ext": {
+                       "description": "Extension map",
+                       "$ref": "#/$def/Extension"
+                   }
+                },
+               "additionalProperties": false
+            },
+            "Extension": {
+              "description": "Extension map",
+              "type": ["object","null"],
+              "required": [],
+              "additionalProperties": {
+                  "type": "string"
+              }
+            }
+        }
+   }
+
+Appendix E.  Examples
+
+   The following example illustrates a basic SVT according to this
+   specification issued for a signed PDF document.
+
+   Note: Line breaks in the decoded example are inserted for
+   readability.  Line breaks are not allowed in valid JSON data.
+
+   Signature validation token JWT:
+
+   eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
+   QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
+   PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
+   eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
+   bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
+   Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
+   eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
+   Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv
+   bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp
+   Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht
+   SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE
+   dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx
+   MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6
+   QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3
+   SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh
+   SmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4
+   XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa
+   S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv
+   THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN
+   Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu
+   SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo
+   In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj
+   UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl
+   SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x
+   MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2
+   UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl
+   ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh
+   bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi
+   aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu
+   YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX
+   mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN
+   n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_
+   3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM
+   rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk
+   kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY
+   Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A
+   qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc
+   Cr0hUK_kvREqjD2Z
+
+   Decoded JWT Header:
+
+   {
+     "kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
+            1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
+     "typ":"JWT",
+     "alg":"RS512"
+   }
+
+   Decoded JWT Claims:
+
+   {
+     "aud" : "http://example.com/audience1",
+     "iss" : "https://swedenconnect.se/validator",
+     "iat" : 1603458421,
+     "jti" : "4d1396f1ff728f40d52403b61c574486",
+     "sig_val_claims" : {
+       "sig" : [ {
+         "ext" : null,
+         "sig_val" : [ {
+           "msg" : "OK",
+           "ext" : null,
+           "res" : "PASSED",
+           "pol" : "http://id.swedenconnect.se/svt/sigval-policy/
+                    ts-pkix/01"
+         } ],
+         "sig_ref" : {
+           "sig_hash" : "ycePVLIzdcpK97IYOhFIf1ny79HmICbSVzIeZNbizo7rGIw
+                         HNN0zXISyKGjCvnonOaQGfL/P3vDtB88yKSWeXg==",
+           "id" : "id-73989c6fc063636ab5e753f10f757467",
+           "sb_hash" : "BoPV4WCA9sAIahjK1HajfFxi+AzC4JGTuf39W3ZWjczDCURx
+                        dc9YeteHtcxGVeggpxHJ75/cQ7HN1dDdliyIwg=="
+         },
+         "signer_cert_ref" : {
+           "ref" : [ "1+aaJetg7relERlUDYEiU4ZIZhT4RUviIQZuK7o1GFKaTPQ6y+
+                      kx/PNtDrpuqQ6XfrkH9wYDK4ey0y4WrNErnw==",
+                     "h4PDxb5ZKmx1eTSqvVvYG8g33s05JzwB+NgEHFU4gc9tqG0kgH
+                      kf6W3oLzkTwwurIh6Y9AafZYqc2zP2pE2p4Q==",
+                     "Dd2C5sB0IOQeMVnEBkM5Q9W96mBHNwwa2tzXMs+LwuYcOUvPkr
+                      yGR0aPG8O9nIP3lbw6KjQ1hDmRk6zC8x2jdg==" ],
+           "type" : "chain_hash"
+         },
+         "sig_data_ref" : [ {
+           "ref" : "",
+           "hash" : "FcGpOOf8ilcPt21GDd2cGnLGDxRS5j7svM4app2H41dDELm2Czc
+                     eTY02ndeJfWjintmQ376IlXTOAr31yzYzsg=="
+         }, {
+           "ref" : "#xades-11a155d92bf55774613bb7b661477cfd",
+           "hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb
+                     pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
+         } ],
+         "time_val" : [ ]
+       } ],
+       "ext" : null,
+       "ver" : "1.0",
+       "profile" : "XML",
+       "hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
+     }
+   }
+
+Authors' Addresses
+
+   Stefan Santesson
+   IDsec Solutions AB
+   Forskningsbyn Ideon
+   SE-223 70 Lund
+   Sweden
+   Email: sts@aaa-sec.com
+
+
+   Russ Housley
+   Vigil Security, LLC
+   516 Dranesville Road
+   Herndon, VA 20170
+   United States of America
+   Email: housley@vigilsec.com