RFC 9321 | Signature Validation Token | October 2022 |
Santesson & Housley | Informational | [Page] |
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.¶
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 (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.¶
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:¶
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.¶
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:¶
When these terms are used as defined in this section, they appear with a capitalized first letter.¶
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:¶
The SVT aims to support long-term validation that can be further extended into the future by applying the following strategies:¶
The SVT is carried in a JSON Web Token (JWT) as defined in [RFC7519].¶
The contents of claims in an SVT are specified using the following data types:¶
The SVT MUST contain only JWT claims in the following list:¶
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.¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
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:¶
The following type identifiers are defined:¶
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.¶
The SVT JWT MUST contain the following JSON Object Signing and Encryption (JOSE) header parameters in accordance with Section 5 of [RFC7519]:¶
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.¶
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:¶
A profile MAY also define:¶
The following profiles are defined in appendixes of this document:¶
Other documents MAY define other profiles that MAY complement, amend, or supersede these profiles.¶
Signature verification based on an SVT MUST follow these steps:¶
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.¶
IANA has registered the "sig_val_claims" claim name in the "JSON Web Token Claims" registry established by Section 10.1 of [RFC7519].¶
IANA has registered the "svt" Header Parameter in the "JSON Web Signature and Encryption Header Parameters" registry established by [RFC7515].¶
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.¶
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.¶
This appendix defines a profile for implementing SVTs with a signed XML document and defines the following aspects of SVT usage:¶
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.¶
When referring to elements from the W3C XML Signature namespace (https://www.w3.org/2000/09/xmldsig#), the following syntax is used:¶
When referring to elements from the ETSI XAdES XML Signature namespace (https://uri.etsi.org/01903/v1.3.2#), the following syntax is used:¶
When referring to elements defined in this specification (http://id.swedenconnect.se/svt/1.0/sig-prop/ns), the following syntax is used:¶
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.¶
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>¶
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.¶
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "XML".¶
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:¶
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:¶
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 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:¶
alg
" Header Parameter.¶
This appendix defines a profile for implementing SVTs with a signed PDF document, and it defines the following aspects of SVT usage:¶
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.¶
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.¶
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].¶
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "PDF".¶
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:¶
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:¶
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".¶
Note: The referenced signer certificate MUST match any certificates referenced using ESSCertID or ESSCertIDv2 from [RFC5035].¶
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:¶
alg
" Header
Parameter. The referenced certificate SHOULD be the
same certificate that was used to sign the document timestamp that
contains the SVT.¶
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:¶
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.¶
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.¶
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).¶
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.¶
When this profile is used, the SigValidation object MUST contain a "profile" claim with the value "JWS".¶
The SVT Signature object MUST contain a "sig_ref" claim (SigReference object) with the following elements:¶
The SVT Signature object MUST contain one instance of the "sig_data" claim (SignedData object) with the following elements:¶
This parameter MUST hold one of the following three possible values:¶
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 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:¶
alg
" Header Parameter.¶
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¶
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" } } } }¶
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" } }¶