Diff: rfc9321xml2.original.xml

	rfc9321xml2.original.xml	rfc9321.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="US-ASCII"?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>	<!DOCTYPE rfc [
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.5 (Ruby
	2.6.8) -->

	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">


	<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.2119.xml">
	<!ENTITY RFC3125 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3125.xml">
	<!ENTITY RFC3161 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3161.xml">
	<!ENTITY RFC3647 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.3647.xml">
	<!ENTITY RFC5035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5035.xml">
	<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.8174.xml">
	<!ENTITY RFC5280 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5280.xml">
	<!ENTITY RFC5652 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.5652.xml">
	<!ENTITY RFC6931 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.6931.xml">
	<!ENTITY RFC7515 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.7515.xml">
	<!ENTITY RFC7518 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.7518.xml">
	<!ENTITY RFC7519 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.7519.xml">
	<!ENTITY RFC8610 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
	nce.RFC.8610.xml">
	]>	]>


	<rfc ipr="trust200902" docName="draft-santesson-svt-08" category="info" submissi	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	onType="independent" tocInclude="true" sortRefs="true" symRefs="true">	-santesson-svt-08" number="9321" submissionType="independent" category="info" to
		cInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang=
		"en" version="3">

	<front>	<front>
	<title>Signature Validation Token</title>	<title>Signature Validation Token</title>

		<seriesInfo name="RFC" value="9321"/>
	<author initials="S." surname="Santesson" fullname="Stefan Santesson">	<author initials="S." surname="Santesson" fullname="Stefan Santesson">
	<organization abbrev="IDsec Solutions">IDsec Solutions AB</organization>	<organization abbrev="IDsec Solutions">IDsec Solutions AB</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Forskningsbyn Ideon</street>	<street>Forskningsbyn Ideon</street>
	<city>Lund</city>	<city>Lund</city>
	<code>223 70</code>	<code>223 70</code>

	<country>SE</country>	<country>Sweden</country>
	</postal>	</postal>
	<email>sts@aaa-sec.com</email>	<email>sts@aaa-sec.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="R." surname="Housley" fullname="Russ Housley">	<author initials="R." surname="Housley" fullname="Russ Housley">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address>	<address>
	<postal>	<postal>
	<street>516 Dranesville Road</street>	<street>516 Dranesville Road</street>

	<city>Herndon, VA</city>	<city>Herndon</city>
		<region>VA</region>
	<code>20170</code>	<code>20170</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>housley@vigilsec.com</email>	<email>housley@vigilsec.com</email>
	</address>	</address>
	</author>	</author>

		<date year="2022" month="October"/>


	<date year="2022" month="May" day="17"/>	<keyword>digital signature</keyword>
		<keyword>electronic signature</keyword>
	<area>Security</area>	<keyword>long-term archive</keyword>

	<keyword>Internet-Draft</keyword>

	<abstract>	<abstract>


	<t>Electronic signatures have a limited lifespan with respect to the time period that they	<t>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)	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	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	electronic signature. The SVT is provided by a trusted authority, which asserts that
	a particular signature was successfully validated according to defined procedure s at	a particular signature was successfully validated according to defined procedure s at
	a certain time. Any future validation of that electronic signature can be satisf ied by	a certain time. Any future validation of that electronic signature can be satisf ied by
	validating the SVT without any need to also validate the original electronic sig nature or	validating the SVT without any need to also validate the original electronic sig nature or

	the associated digital certificates. SVT supports electronic signatures in CMS,	the associated digital certificates. The SVT supports electronic signatures in C
	XML,	ryptographic Message Syntax (CMS), XML,
	PDF and JSON documents.</t>	PDF, and JSON documents.</t>

	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

		<section anchor="intro">
	<section anchor="intro"><name>Introduction</name>	<name>Introduction</name>
		<t>Electronic signatures have a limited lifespan regarding when they can b
	<t>Electronic signatures have a limited lifespan regarding when they can be vali	e validated
	dated
	and determined to be authentic. Many factors make it more difficult to validate	and determined to be authentic. Many factors make it more difficult to validate
	electronic signatures over time. For example:</t>	electronic signatures over time. For example:</t>

		<ul spacing="normal">
		<li>Trusted information about the validity of the certificate containing
		the signer's public key is not available.</li>
		<li>Trusted information about the time when the signature was actually c
		reated is not available.</li>
		<li>Algorithms used to create the electronic signature may no longer be
		considered secure at the time of validation and may therefore no longer be avail
		able in software libraries.</li>
		<li>Services necessary to validate the signature are no longer available
		at the time of validation.</li>
		<li>Supporting evidence such as certification authority (CA) certificate
		s, Online Certificate Status Protocol (OCSP) responses, Certificate Revocation L
		ists (CRLs), or timestamps is not available or can't be validated.</li>


	<t><list style="symbols">	</ul>
	<t>Trusted information about the validity of the certificate containing the si	<t>The challenges to validation of an electronic signature increase
	gner's public key is not available.</t>
	<t>Trusted information about the date and time when the signature was actually
	created is not available.</t>
	<t>Algorithms used to create the electronic signature may no longer be conside
	red secure at the time of validation and may therefore no longer be available in
	software libraries.</t>
	<t>Services necessary to validate the signature are no longer available at the
	time of validation.</t>
	<t>Supporting evidence such as CA certificates, OCSP responses, CRLs, or times
	tamps.</t>
	</list></t>

	<t>The challenges to validation of an electronic signature increases
	over time, and eventually it may simply be impossible to verify the	over time, and eventually it may simply be impossible to verify the
	signature with a sufficient level of assurance.</t>	signature with a sufficient level of assurance.</t>

		<t>Existing standards, such as the ETSI XAdES <xref target="XADES"/> profi
	<t>Existing standards, such as the ETSI XAdES <xref target="XADES"/> profile for	le for XML
	XML
	signatures <xref target="XMLDSIG11"/>, ETSI PAdES <xref target="PADES"/> profile for PDF signatures	signatures <xref target="XMLDSIG11"/>, ETSI PAdES <xref target="PADES"/> profile for PDF signatures
	<xref target="ISOPDF2"/>, and ETSI CAdES <xref target="CADES"/> profile for CMS signatures	<xref target="ISOPDF2"/>, and ETSI CAdES <xref target="CADES"/> profile for CMS signatures

	<xref target="RFC5652"/> can be used to extend the time within which a signature	<xref target="RFC5652"/>, can be used to extend the time within which a signatur
	can be	e can be
	validated at the cost of significant complexity which involves storing and	validated at the cost of significant complexity, which involves storing and
	validating significant amounts of external evidence data such as revocation data ,	validating significant amounts of external evidence data such as revocation data ,

	signature time stamps and archival time stamps.</t>	signature time stamps, and archival time stamps.</t>


	<t>The Signature Validation token (SVT) defined in this specification takes a	<t>The Signature Validation Token (SVT) defined in this specification takes a
	trusted signature validation process as an input and preserves the validation re sult	trusted signature validation process as an input and preserves the validation re sult
	for the associated signature and signed document. The SVT asserts that a particu lar	for the associated signature and signed document. The SVT asserts that a particu lar
	electronic signature was successfully validated by a trusted authority according to	electronic signature was successfully validated by a trusted authority according to

	defined procedures at a certain date and time. Those procedures MUST include che cks	defined procedures at a certain time. Those procedures <bcp14>MUST</bcp14> inclu de checks
	that the signature match the signed document, checks that the signature can be v alidated by	that the signature match the signed document, checks that the signature can be v alidated by

	the signing certificate and checks that the signing certificate pass certificate	the signing certificate, and checks that the signing certificate pass certificat e
	path validation <xref target="RFC5280"/>.	path validation <xref target="RFC5280"/>.

	Those procedures MAY also include checks associated with a particular trust poli cy such as	Those procedures <bcp14>MAY</bcp14> also include checks associated with a partic ular trust policy such as
	that an acceptable certificate policy <xref target="RFC5280"/> <xref target="RFC 3647"/> was used to issue the	that an acceptable certificate policy <xref target="RFC5280"/> <xref target="RFC 3647"/> was used to issue the
	signer's certificate and checks that an acceptable signature policy was used by	signer's certificate and checks that an acceptable signature policy was used by
	the signer <xref target="RFC3125"/>.</t>	the signer <xref target="RFC3125"/>.</t>

		<t>Once the SVT is issued by a trusted
	<t>Once the SVT is issued by a trusted
	authority, any future validation of that electronic signature can be satisfied b y validating	authority, any future validation of that electronic signature can be satisfied b y validating

	the SVT, without any need to also re-validate the original electronic signature. </t>	the SVT without any need to also revalidate the original electronic signature.</ t>


	<t>As SVT is used to preserve validation result obtained through applying existi ng	<t>As the SVT is used to preserve validation results obtained through applying e xisting
	standards for signature validation, it is complementary to and not a replacement for such standards,	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.	including the ETSI standards for long-term validation listed above.
	SVT do however have the potentially positive effect that it may significantly re	The SVT does, however, have the potentially positive effect that it may signific
	duce the need to	antly reduce the need to
	apply complex long-term validation and preservation techniques for signature val idation	apply complex long-term validation and preservation techniques for signature val idation
	if an SVT is issued and applied to the signed document at an early stage where t he signature	if an SVT is issued and applied to the signed document at an early stage where t he signature
	can be validated without support of large amounts of external evidence.	can be validated without support of large amounts of external evidence.

	The use of SVT may therefore drastically reduce the complexity of re-validation of old	The use of SVTs may therefore drastically reduce the complexity of revalidation of old
	archived electronic signatures.</t>	archived electronic signatures.</t>

		<t>The SVT can be signed with private keys and algorithms that
	<t>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	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	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 q uantum	private key, a second one with a strong elliptic curve, and a third one with a q uantum
	safe digital signature algorithm to protect against advances in computing power and	safe digital signature algorithm to protect against advances in computing power and
	cryptanalytic capabilities. Further, the trusted authority can add additional SV Ts	cryptanalytic capabilities. Further, the trusted authority can add additional SV Ts

	in the future using fresh private keys and signatures to extend the lifetime of	in the future using fresh private keys and signatures to extend the lifetime of
	the,	the SVTs if necessary.</t>
	if necessary.</t>


	</section>	</section>
	<section anchor="defs"><name>Definitions</name>	<section anchor="defs">
		<name>Definitions</name>


	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",	<t>
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	xref target="RFC8174"/>	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	when, and only when, they appear in all capitals, as shown here.</t>	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
		be interpreted as
		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>


	<t>This document use the following terms:</t>	<t>This document use the following terms:</t>


	<t><list style="symbols">	<dl>
	<t>Signed Data -- The data covered by a particular electronic signature. This	<dt>Signed Data:
	is typically	</dt>
	equivalent to the signed content of a document, and it represents the data that	<dd>The data covered by a particular electronic signature. This is
	the	typically equivalent to the signed content of a document, and it
	signer intended to sign. In some cases, such as in some XML signatures, the sign	represents the data that the signer intended to sign. In some cases,
	ed data	such as in some XML signatures, the Signed Data can be the collection
	can be the collection of several data fragments each referenced by the signature	of several data fragments each referenced by the signature. In the
	. In the	case of PDF, this is the data covered by the "ByteRange" parameter in
	case of PDF, this is the data covered by the "ByteRange" parameter in the signat	the signature dictionary. In JSON Web Signature (JWS), this is the
	ure	unencoded payload data (before base64url encoding).
	dictionary. In JWS, this is the unencoded payload data (before base64url encodin	</dd>
	g).</t>
	<t>Signed Bytes -- These are the actual bytes of data that were hashed and sig	<dt>Signed Bytes:
	ned by the	</dt>
	digital signature algorithm. In most cases, this is not the actual Signed Data,	<dd>These are the actual bytes of data that were hashed and signed by
	but a	the digital signature algorithm. In most cases, this is not the actual
	collection of signature metadata that includes references (hash) of the Signed D	Signed Data but a collection of signature metadata that includes
	ata as	references (hash) of the Signed Data as well as information about
	well as information about algorithms and other data bound to a signature. In XML	algorithms and other data bound to a signature. In XML, this is the
	, this	canonicalized SignedInfo element. In CMS and PDF signatures, this is
	is the canonicalized SignedInfo element. In CMS and PDF signatures, this is the	the DER-encoded SignedAttributes structure. In JWS, this is the
	DER-encoded SignedAttributes structure. In JWS, this is the protected header and	protected header and payload data formatted according to <xref
	payload	target="RFC7515"/>.
	data formatted according to <xref target="RFC7515"/>.</t>	</dd>
	</list></t>	</dl>

	<t>When these terms are used as defined in this section, they appear with a	<t>When these terms are used as defined in this section, they appear with a
	capitalized first letter.</t>	capitalized first letter.</t>

		</section>
		<section anchor="svt">
		<name>Signature Validation Token</name>


	</section>	<section anchor="svt-function">
	<section anchor="svt"><name>Signature Validation Token</name>	<name>Signature Validation Token Function</name>
		<t>The Signature Validation Token (SVT) is created by a trusted service
	<section anchor="svt-function"><name>Signature Validation Token Function</name>	to assert

	<t>Signature Validation Token (SVT) is created by a trusted service to assert
	evidence of successful electronic signature validation using a well-defined and	evidence of successful electronic signature validation using a well-defined and
	trustworthy signature validation process. The SVT binds the validation result to	trustworthy signature validation process. The SVT binds the validation result to

	the validated signature, the document signed by the signature and the certificat e of the signer.	the validated signature, the document signed by the signature, and the certifica te of the signer.
	This allows a relying party to verify the validity of a signed document	This allows a relying party to verify the validity of a signed document

	without having to re-validate the original signature or to re-use any of its ass ociated	without having to revalidate the original signature or to reuse any of its assoc iated
	cryptographic algorithms for as long as the SVT itself can be validated.	cryptographic algorithms for as long as the SVT itself can be validated.
	The SVT achieves this by binding the following information to	The SVT achieves this by binding the following information to
	a specific electronic signature:</t>	a specific electronic signature:</t>

		<ul spacing="normal">
		<li>A unique identification of the electronic signature.</li>
		<li>The data and metadata signed by the electronic signature.</li>
		<li>The signer's certificate that was validated as part of electronic
		signature verification.</li>
		<li>The certification path that was used to validate the signer's cert
		ificate.</li>
		<li>An assertion providing evidence of signature verification, the tim
		e the verification was performed, the procedures used to verify the electronic s
		ignature, and the outcome of the verification.</li>
		<li>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.</li>
		</ul>
		<t>The SVT aims to support long-term validation that can be further exte
		nded into the future by applying the following strategies:</t>
		<ul spacing="normal">
		<li>by using secure algorithms with long life expectancy when signing
		the SVT</li>
		<li>by reissuing the SVT before it becomes insecure or is considered e
		xpired</li>
		<li>optionally, by issuing multiple SVTs with different algorithms to
		provide redundancy in case one algorithm is broken</li>
		</ul>
		</section>
		<section anchor="svt-syntax">
		<name>Signature Validation Token Syntax</name>
		<t>The SVT is carried in a JSON Web Token (JWT) as defined in <xref targ
		et="RFC7519"/>.</t>
		<section anchor="svt-syntax-dt">
		<name>Data Types</name>
		<t>The contents of claims in an SVT are specified using the following
		data types:</t>


	<t><list style="symbols">	<dl>
	<t>A unique identification of the electronic signature.</t>
	<t>The data and metadata signed by the electronic signature.</t>
	<t>The signer's certificate that was validated as part of electronic signature
	verification.</t>
	<t>The certification path that was used to validate the signer's certificate.<
	/t>
	<t>An assertion providing evidence of that the signature was verified, the dat
	e and time the verification was performed, the procedures used to verify the ele
	ctronic signature, and the outcome of the verification.</t>
	<t>An assertion providing evidence of the date and time at which the signature
	is known to have existed, the procedures used to validate the date and time of
	existence, and the outcome of the validation.</t>
	</list></t>


	<t>The SVT aims to support long term validation that can be further extended int	<dt>String:
	o the future by applying the following strategies:</t>	</dt>
		<dd>JSON Data Type of string that contains an arbitrary
		case-sensitive string value.
		</dd>


	<t><list style="symbols">	<dt>Base64Binary:
	<t>By using secure algorithms with long life exepectancy when signing the SVT.	</dt>
	</t>	<dd>JSON Data Type of string that contains a Base64-encoded byte
	<t>By re-issuing the SVT before it becomes insecure or is considered expired.<	array of binary data.
	/t>	</dd>
	<t>Optionally, by issuing multipple SVT:s with different algorithms to provide
	redundancy in case one algorithm is broken.</t>
	</list></t>


	</section>	<dt>StringOrURI:
	<section anchor="svt-syntax"><name>Signature Validation Token Syntax</name>	</dt>
		<dd>JSON Data Type of string that contains an arbitrary string or
		a URI as defined in <xref target="RFC7519"/>. It is <bcp14>REQUIRED</
		bcp14> to contain the colon character (":") to be a URI.
		</dd>


	<t>The SVT is carried in a JSON Web Token (JWT) as defined in <xref target="RFC7	<dt>URI:
	519"/>.</t>	</dt>
		<dd>JSON Data Type of string that contains a URI as defined in
		<xref target="RFC7519"/>.
		</dd>


	<section anchor="svt-syntax-dt"><name>Data Types</name>	<dt>Integer:
		</dt>
		<dd>JSON Data Type of number that contains a 32-bit signed integer value (from
		-2<sup>31</sup> to 2<sup>31</sup>-1).
		</dd>


	<t>The contents of claims in an SVT are specified using the following data types	<dt>Long:
	:</t>	</dt>
		<dd>JSON Data Type of number that contains a 64-bit signed integer value (from
		-2<sup>63</sup> to 2<sup>63</sup>-1).
		</dd>


	<t><list style="symbols">	<dt>NumericDate:
	<t>String -- JSON Data Type of string that contains an arbitrary case sensitiv	</dt>
	e string value.</t>	<dd>JSON Data Type of number that contains data as defined in <xref
	<t>Base64Binary -- JSON Data Type of string that contains of Base64 encoded by	target="RFC7519"/>, which is the number of seconds from 1970-01-01T00:00:00Z UTC
	te array of binary data.</t>	until the specified
	<t>StringOrURI -- JSON Data Type of string that contains an arbitrary string o	UTC date/time, ignoring leap seconds.
	r an URI as defined in <xref target="RFC7519"/>, which REQUIRES a value containi	</dd>
	ng the colon character (":") to be a URI.</t>
	<t>URI -- JSON Data Type of string that contains an URI as defined in <xref ta
	rget="RFC7519"/>.</t>
	<t>Integer -- JSON Data Type of number that contains a 32-bit signed integer v
	alue (from -2^31 to 2^31-1).</t>
	<t>Long -- JSON Data Type of number that contains a 64-bit signed integer valu
	e (from -2^63 to 2^63-1).</t>
	<t>NumericDate -- JSON Data Type of number that contains a data as defined in
	<xref target="RFC7519"/>, which is the number of seconds from 1970-01-01T00:00:0
	0Z UTC until the specified UTC date/time, ignoring leap seconds.</t>
	<t>Boolean -- JSON Data Type of boolean that contains explicit value of true o
	r false.</t>
	<t>Object<Class> -- A JSON object holding a claims object of a class def
	ined in this specification (see <xref target="svt-syntax-claim"/>).</t>
	<t>Map<Type> -- A JSON object with name-value pairs where the value is a
	n object of the specified Type in the notation. For example, Map<String> i
	s a JSON object with name value pairs where all values are of type String.</t>
	<t>Array -- A JSON array of a specific data type as defined in this section. A
	n array is expressed in this specification by square brackets. For example, [Str
	ing] indicates an array of String values, and [Object<DocHash>] indicates
	an array of DocHash objects.</t>
	<t>Null -- A JSON null that represents an absent value. A claim with a null va
	lue is equivalent with an absent claim.</t>
	</list></t>


	</section>	<dt>Boolean:
	<section anchor="svt-syntax-claim"><name>Signature Validation Token JWT Claims</	</dt>
	name>	<dd> JSON Data Type of boolean that contains the explicit value of true or
		false.
		</dd>


	<t>The SVT MUST contain only JWT claims in the following list:</t>	<dt>Object<Class>:
		</dt>
		<dd>A JSON object holding a claims object of a class defined in this
		specification (see <xref target="svt-syntax-claim"/>).
		</dd>


	<t><list style="symbols">	<dt>Map<Type>:
	<t>jti -- A String data type that is a "JWT ID" registered claim according to	</dt>
	<xref target="RFC7519"/>. It is RECOMMENDED that the identifier holds a hexadeci	<dd>A JSON object with name-value pairs where the value is an object of the
	mal string representation of a 128-bit unsigned integer. A SVT MUST contain one	specified Type in the notation. For example, Map<String> is a JSON
	"JWT ID" claim.</t>	object with name-value pairs where all values are of type String.
	<t>iss -- A StringOrURI data type that is an "Issuer" registered claim accord	</dd>
	ing to <xref target="RFC7519"/>, which is an arbitrary unique identifier of the
	SVT issuer. This value SHOULD have the value of an URI based on a domain owned b
	y the issuer. A SVT MUST contain one "Issuer" claim.</t>
	<t>iat -- A NumericDate data type that is an "Issued At" registered claim acco
	rding to <xref target="RFC7519"/>, which expresses the date and time when this S
	VT was issued. A SVT MUST contain one "Issued At" claim.</t>
	<t>aud -- A [StringOrURI] data type or a StringOrURI data type that is an "Aud
	ience" registered claim according to <xref target="RFC7519"/>. The audience clai
	m 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 com
	mon 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 va
	lues. Inclusion of the "Audience" claim in a SVT is OPTIONAL.</t>
	<t>exp -- A NumericDate data type that is an "Expiration Time" registered clai
	m according to <xref target="RFC7519"/>, which expresses the date and time when
	services and responsibilities related to this SVT is no longer provided by the S
	VT issuer. The precise meaning of the expiration time claim is defined by local
	policies. See implementation note below. Inclusion of the "Expiration Time" clai
	m in a SVT is OPTIONAL.</t>
	<t>sig_val_claims -- A Object<SigValidation> data type that contains sig
	nature validation claims for this SVT extending the standard registered JTW clai
	ms above. A SVT MUST contain one sig_val_claims claim.</t>
	</list></t>


	<t>Note: An SVT asserts that a particular validation process was undertaken at a	<dt>Array:
	stated	</dt>
	date and time. This fact never changes and never expires. However, some other as	<dd>A JSON array of a specific data type as defined in this section. An array
	pects	is expressed in this specification by square brackets. For example, [String]
	of the SVT such as liability for false claims or service provision related to a	indicates an array of String values, and [Object<DocHash>] indicates an
	specific	array of DocHash objects.
	SVT may expire after a certain period of time, such as a service where an old SV	</dd>
	T can be
	upgraded to a new SVT signed with fresh keys and algorithms.</t>


	</section>	<dt>Null:
	<section anchor="sigvalidation-obj-class"><name>SigValidation Object Class</name	</dt>
	>	<dd>A JSON null that represents an absent value. A claim with a null value is
		equivalent with an absent claim.
		</dd>


	<t>The sig_val_claims JWT claim uses the SigValidation object class. A SigValida	</dl>
	tion object
	holds all custom claims, and a SigValidation object contains the following param
	eters:</t>


	<t><list style="symbols">	</section>
	<t>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".</t>
	<t>profile -- A StringOrURI data type representing the name of a profile that
	defines conventions followed for specific claims and any extension points used b
	y the SVT issuer. This parameter MUST be present.</t>
	<t>hash_algo -- A URI data type that identifies the hash algorithm used to com
	pute the hash values within the SVT. The URI identifier MUST be one defined in <
	xref target="RFC6931"/> or in the IANA registry defined by this specification. T
	his parameter MUST be present.</t>
	<t>sig -- A [Object<Signature>] data type that gives information about v
	alidated electronic signatures as an array of Signature objects. If the SVT cont
	ains signature validation evidence for more than one signature, then each signat
	ure is represented by a separate Signature object. At least one Signature object
	MUST be present.</t>
	<t>ext -- A Map<String> data type that provides additional claims relate
	d to the SVT. Extension claims are added at the discretion of the SVT issuer; ho
	wever, extension claims MUST follow any conventions defined in a profile of this
	specification (see <xref target="profiles"/>). Inclusion of this parameter is O
	PTIONAL.</t>
	</list></t>


	</section>	<section anchor="svt-syntax-claim">
	<section anchor="signature-obj-class"><name>Signature Claims Object Class</name>	<name>Signature Validation Token JWT Claims</name>
		<t>The SVT <bcp14>MUST</bcp14> contain only JWT claims in the followin
		g list:</t>


	<t>The sig parameter in the SigValidation object class uses the Signature object	<dl>
	class. The Signature object contains claims related to signature validation
	evidence for one signature, and it contains the following parameters:</t>


	<t><list style="symbols">	<dt>"jti":
	<t>sig_ref -- A Object<SigReference> data type that contains reference i	</dt>
	nformation identifying the target signature. This parameter MUST be present.</t>	<dd> A String data type that is a "JWT ID" registered claim according to
	<t>sig_data_ref -- A [Object<SignedDataReference>] data type that contai	<xref target="RFC7519"/>. It is <bcp14>RECOMMENDED</bcp14> that the
	ns an array of references to Signed Data that was signed by the target electroni	identifier holds a hexadecimal string representation of a 128-bit unsigned
	c signature. At least one SignedDataReference object MUST be present.</t>	integer. An SVT <bcp14>MUST</bcp14> contain one "JWT ID" claim.
	<t>signer_cert_ref -- A Object<CertReference> data type that references	</dd>
	the signer's certificate and optionally reference to a supporting certification
	path that was used to verify the target electronic signature. This parameter MUS
	T be present.</t>
	<t>sig_val -- A [Object<PolicyValidation>] data type that contains an ar
	ray of results of signature verification according to defined procedures. At lea
	st one PolicyValidation object MUST be present.</t>
	<t>time_val -- A [Object<TimeValidation>] data type that contains an arr
	ay of time verification results that the target signature has existed at a speci
	fic date and time in the past. Inclusion of this parameter is OPTIONAL.</t>
	<t>ext -- A MAP<String> data type that provides additional claims relate
	d to the target signature. Extension claims are added at the discretion of the S
	VT Issuer; however, extension claims MUST follow any conventions defined in a pr
	ofile of this specification (see <xref target="profiles"/>). Inclusion of this p
	arameter is OPTIONAL.</t>
	</list></t>


	</section>	<dt>"iss":
	<section anchor="sigreference-obj-class"><name>SigReference Claims Object Class<	</dt>
	/name>	<dd>A StringOrURI data type that is an "Issuer" registered claim according
		to <xref target="RFC7519"/>, which is an arbitrary unique identifier of the
		SVT issuer. This value <bcp14>SHOULD</bcp14> have the value of a URI based
		on a domain owned by the issuer. An SVT <bcp14>MUST</bcp14> contain one
		"Issuer" claim.
		</dd>


	<t>The sig_ref parameter in the Signature object class uses the SigReference obj	<dt>"iat":
	ect	</dt>
	class. The SigReference object provides information used to match the Signature	<dd>A NumericDate data type that is an "Issued At" registered claim
	claims object to a specific target electronic signature and to verify the integr	according to <xref target="RFC7519"/>, which expresses the time
	ity	when this SVT was issued. An SVT <bcp14>MUST</bcp14> contain one "Issued At"
	of the target signature value and Signed Bytes, and it contains the following pa	claim.
	rameters:</t>	</dd>


	<t><list style="symbols">	<dt>"aud":
	<t>id -- A String data type that contains an identifier assigned to the target	</dt>
	signature. Inclusion of this parameter is OPTIONAL.</t>	<dd>A [StringOrURI] data type or a StringOrURI data type that is an
	<t>sig_hash -- A Base64Binary data type that contains a hash value of the targ	"Audience" registered claim according to <xref target="RFC7519"/>. The
	et electronic signature value. This parameter MUST be present.</t>	audience claim is an array of one or more identifiers, identifying intended
	<t>sb_hash -- A Base64Binary data type that contains a hash value of the Signe	recipients of the SVT. Each identifier <bcp14>MAY</bcp14> identify a single
	d Bytes of the target electronic signature. This parameter MUST be present.</t>	entity, a group of entities, or a common policy adopted by a group of
	</list></t>	entities. If only one value is provided, it <bcp14>MAY</bcp14> 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
		<bcp14>OPTIONAL</bcp14>.
		</dd>


	</section>	<dt>"exp":
	<section anchor="signeddatareference-obj-class"><name>SignedDataReference Claims	</dt>
	Object Class</name>	<dd>A NumericDate data type that is an "Expiration Time" registered claim
		according to <xref target="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 <bcp14>OPTIONAL</bcp14>.
		</dd>


	<t>The sig_data_ref parameter in the Signature object class uses the SignedDataR	<dt>"sig_val_claims":
	eference object	</dt>
	class. The SignedDataReference object provides information used to verify the ta	<dd>An Object<SigValidation> data type that contains signature
	rget electronic	validation claims for this SVT extending the standard registered JWT claims
	signature references to Signed Data as well as to verify the integrity of all da	above. An SVT <bcp14>MUST</bcp14> contain one sig_val_claims claim.
	ta that	</dd>
	is signed by the target signature, and it contains the following parameters:</t>


	<t><list style="symbols">	</dl>
	<t>ref -- A String data type that contains a reference identifier for the data
	or data fragment covered by the target electronic signature. This parameter MUS
	T be present.</t>
	<t>hash -- A Base64Binary data type that contains the hash value for the data
	covered by the target electronic signature. This parameter MUST be present.</t>
	</list></t>


	</section>	<t>Note: An SVT asserts that a particular validation process was under
	<section anchor="policyval-obj-class"><name>PolicyValidation Claims Object Class	taken at a stated
	</name>	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 SV
		T can be
		upgraded to a new SVT signed with fresh keys and algorithms.</t>
		</section>
		<section anchor="sigvalidation-obj-class">
		<name>SigValidation Object Class</name>


	<t>The sig_val parameter in the Signature object class uses the PolicyValidation	<t>The sig_val_claims JWT claim uses the SigValidation object class. A
	object	SigValidation object
	class. The PolicyValidation object provides information about the result of a va	holds all custom claims, and a SigValidation object contains the following param
	lidation	eters:</t>
	process according to a spefific policy, and it contains the following parameters
	:</t>


	<t><list style="symbols">	<dl>
	<t>pol -- A StringOrURI data type that contains the identifier of the policy g	<dt>"ver":
	overning the electronic signature verification process. This parameter MUST be p	</dt>
	resent.</t>	<dd>A String data type representing the version. This parameter
	<t>res -- A String data type that contains the result of the electronic signat	<bcp14>MUST</bcp14> be present and the version in this specification
	ure verification process. The value MUST be one of "PASSED", "FAILED" or "INDETE	indicated by the value "1.0".
	RMINATE" as defined by <xref target="ETSI319102-1"/>. This parameter MUST be pre	</dd>
	sent.</t>
	<t>msg -- A String data type that contains a message describing the result. In
	clusion of this parameter is OPTIONAL.</t>
	<t>ext -- A MAP<String> data type that provides additional claims relate
	d to the target signature. Extension claims are added at the discretion of the S
	VT Issuer; however, extension claims MUST follow any conventions defined in a pr
	ofile of this specification (see <xref target="profiles"/>). Inclusion of this p
	arameter is OPTIONAL.</t>
	</list></t>


	</section>	<dt>"profile":
	<section anchor="timever-obj-class"><name>TimeValidation Claims Object Class</na	</dt>
	me>	<dd>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 <bcp14>MUST</bcp14> be present.
		</dd>


	<t>The time_val parameter in the Signature object class uses the TimeValidation	<dt>"hash_algo":
	object	</dt>
	class. The TimeValidation claims object provides information about the result of	<dd>A URI data type that identifies the hash algorithm used to compute the
	validating evidence of time asserting that the target signature existed at a par	hash values within the SVT. The URI identifier <bcp14>MUST</bcp14> be one
	ticular	defined in <xref target="RFC9231"/> or in the IANA registry defined by this
	date and time in the past. Evidence of time is typically a timestamp according t	specification. This parameter <bcp14>MUST</bcp14> be present.
	o <xref target="RFC3161"/> but other types of evidence may be used such as a pre	</dd>
	viously issued SVT for this signature. The TimeValidation claims object contains
	the following parameters:</t>


	<t><list style="symbols">	<dt>"sig":
	<t>time -- A NumericDate data type that contains the verified time. This param	</dt>
	eter MUST be present.</t>	<dd>An [Object<Signature>] data type that gives information about
	<t>type -- A StringOrURI data type that contains an identifier of the type of	validated electronic signatures as an array of Signature objects. If the SVT
	evidence of time. This parameter MUST be present.</t>	contains signature validation evidence for more than one signature, then each
	<t>iss -- A StringOrURI data type that contains an identifier of the entity th	signature is represented by a separate Signature object. At least one
	at issued the evidence of time. This parameter MUST be present.</t>	Signature object <bcp14>MUST</bcp14> be present.
	<t>id -- A String data type that contains an unique identifier assigned to the	</dd>
	evidence of time. Inclusion of this parameter is OPTIONAL.</t>
	<t>hash -- A Base64Binary data type that contains the hash value of the valida
	ted evidence of time. Inclusion of this parameter is OPTIONAL.</t>
	<t>val -- A [Object<PolicyValidation>] data type that contains an array
	of results of the time evidence validation according to defined validation proce
	dures. Inclusion of this parameter is OPTIONAL.</t>
	<t>ext -- A MAP<String> data type that provides additional claims relate
	d to the target signature. Extension claims are added at the discretion of the S
	VT Issuer; however, extension claims MUST follow any conventions defined in a pr
	ofile of this specification (see <xref target="profiles"/>). Inclusion of this p
	arameter is OPTIONAL.</t>
	</list></t>


	</section>	<dt>"ext":
	<section anchor="certref-obj-class"><name>CertReference Claims Object Class</nam	</dt>
	e>	<dd>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 <bcp14>MUST</bcp14> follow any conventions defined
		in a profile of this specification (see <xref target="profiles"/>). Inclusion
		of this parameter is <bcp14>OPTIONAL</bcp14>.
		</dd>


	<t>The signer_cert_ref parameter in the Signature object class uses the CertRefe	</dl>
	rence 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 has
	h
	references for certificates that can be located in the target electronic signatu
	re, and
	it contains the following parameters:</t>


	<t><list style="symbols">	</section>
	<t>type -- A StringOrURI data type that contains an identifier of the type of	<section anchor="signature-obj-class">
	reference. The type identifier MUST be one of the identifiers defined below, an	<name>Signature Claims Object Class</name>
	identifier specified by the selected profile, or a URI identifier. This paramete	<t>The sig parameter in the SigValidation object class uses the Signat
	r MUST be present.</t>	ure object
	<t>ref -- A [String] data type that contains an array of string parameters acc	class. The Signature object contains claims related to signature validation
	ording to conventions defined by the type identifier. At least one parameter MUS	evidence for one signature, and it contains the following parameters:</t>
	T be present.</t>
	</list></t>


	<t>The following type identifiers are defined:</t>	<dl>


	<t><list style="symbols">	<dt>"sig_ref":
	<t>chain -- The ref contains an array of Base64 encoded X.509 certificates <xr	</dt>
	ef target="RFC5280"/>. The certificates MUST be provided in the order starting w	<dd>An Object<SigReference> data type that contains reference
	ith the end entity certificate. Any following certificate must be able to valida	information identifying the target signature. This parameter
	te the signature on the previous certificate in the array.</t>	<bcp14>MUST</bcp14> be present.
	<t>chain_hash -- The ref contains an array of one or more Base64 encoded hash	</dd>
	values where each hash value is a hash over a X.509 certificate <xref target="RF
	C5280"/> used to validate the signature. The certificates MUST be provided in t
	he order starting with the end entity certificate. Any following certificate mu
	st be able to validate the signature on the previous certificate in the array. T
	his option MUST NOT be used unless all hashed certificates are present in the ta
	rget electronic signature.</t>
	</list></t>


	<t>Note: All certificates referenced using the identifiers above are X.509 certi	<dt>"sig_data_ref":
	ficates.	</dt>
	Profiles of this specification MAY define alternative types of public key contai	<dd>An [Object<SignedDataReference>] data type that contains an array of
	ners;	references to Signed Data that was signed by the target electronic
	however, a major function of these referenced certificates is not just to refere	signature. At least one SignedDataReference object <bcp14>MUST</bcp14> be
	nce	present.
	the public key, but also to provide the subject name of the signer. It is theref	</dd>
	ore
	important for the full function of an SVT that the referenced public key contain
	er also
	provides the means to identify of the signer.</t>


	</section>	<dt>"signer_cert_ref":
	<section anchor="svt-jose-header"><name>SVT JOSE Header</name>	</dt>
		<dd>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
		<bcp14>MUST</bcp14> be present.
		</dd>


	<t>The SVT JWT MUST contain the following JOSE header parameters in accordance w	<dt>"sig_val":
	ith	</dt>
	Section 5 of <xref target="RFC7519"/>:</t>	<dd>An [Object<PolicyValidation>] data type that contains an array of
		results of signature verification according to defined procedures. At least
		one PolicyValidation object <bcp14>MUST</bcp14> be present.
		</dd>


	<t><list style="symbols">	<dt>"time_val":
	<t>typ -- This parameter MUST have the string value "JWT" (upper case).</t>	</dt>
	<t>alg -- This parameter identifies the algorithm used to sign the SVT JWT. Th	<dd>An [Object<TimeValidation>] data type that contains an array of time
	e algorithm identifier MUST be specified in <xref target="RFC7518"/> or the IANA	verification results showing that the target signature has existed at a specific
	JSON Web Signature and Encryption Algorithms Registry [ add a ref ]. The specif	time in the past. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
	ied signature hash algorithm MUST be identical to the hash algorithm specified i	</dd>
	n the hash_algo parameter of the SigValidation object within the sig_val_claims
	claim.</t>
	</list></t>


	<t>The SVT header MUST contain a public key or a reference to a public key used	<dt>"ext":
	to verify the signature on the SVT in accordance with <xref target="RFC7515"/>.	</dt>
	Each profile, as discussed in <xref target="profiles"/>, MUST define the require	<dd>A MAP<String> data type that provides additional claims related to
	ments for how the key or key reference is included in the header.</t>	the target signature. Extension claims are added at the discretion of the SVT
		issuer; however, extension claims <bcp14>MUST</bcp14> follow any conventions
		defined in a profile of this specification (see <xref
		target="profiles"/>). Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
		</dd>


	</section>	</dl>
	</section>
	</section>
	<section anchor="profiles"><name>Profiles</name>


	<t>Each signed document and signature type will have to define the precise conte	</section>
	nt and	<section anchor="sigreference-obj-class">
	use of several claims in the SVT.</t>	<name>SigReference Claims Object Class</name>
		<t>The sig_ref parameter in the Signature object class uses the SigRef
		erence object
		class. The SigReference object provides information used to match the Signature
		claims object to a specific target electronic signature and to verify the integr
		ity
		of the target signature value and Signed Bytes, and it contains the following pa
		rameters:</t>


	<t>Each profile MUST as a minimum define:</t>	<dl>


	<t><list style="symbols">	<dt>"id":
	<t>The identifier of the profile.</t>	</dt>
	<t>How to reference the Signed Data content of the signed document.</t>	<dd>A String data type that contains an identifier assigned to the target
	<t>How to reference to the target electronic signature and the Signed Bytes of	signature. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
	the signature.</t>	</dd>
	<t>How to reference certificates supporting each electronic siganture.</t>
	<t>How to include public keys or references to public keys in the SVT.</t>
	<t>Whether each electronic signature is supported by a single SVT, or whether
	one SVT may support multiple electronic signatures of the same document.</t>
	</list></t>


	<t>A profile MAY also define:</t>	<dt>"sig_hash":
		</dt>
		<dd>A Base64Binary data type that contains a hash value of the target
		electronic signature value. This parameter <bcp14>MUST</bcp14> be present.
		</dd>


	<t><list style="symbols">	<dt>"sb_hash":
	<t>Explicit information on how to perform signature validation based on an SVT	</dt>
	.</t>	<dd>A Base64Binary data type that contains a hash value of the Signed Bytes of
	<t>How to attach an SVT to an electronic signature or signed document.</t>	the target electronic signature. This parameter <bcp14>MUST</bcp14> be
	</list></t>	present.
		</dd>


	<section anchor="defined-profiles"><name>Defined Profiles</name>	</dl>


	<t>The following profiles are defined in Appendixes of this document:</t>	</section>
		<section anchor="signeddatareference-obj-class">
		<name>SignedDataReference Claims Object Class</name>
		<t>The sig_data_ref parameter in the Signature object class uses the S
		ignedDataReference object
		class. The SignedDataReference object provides information used to verify the ta
		rget electronic
		signature references to Signed Data as well as to verify the integrity of all da
		ta that
		is signed by the target signature, and it contains the following parameters:</t>


	<t><list style="symbols">	<dl>
	<t><xref target="appendix-xml-profile"/>: XML Profile</t>	<dt>"ref":
	<t><xref target="appendix-pdf-profile"/>: PDF Profile</t>	</dt>
	<t><xref target="appendix-jws-profile"/>: JWS Profile</t>	<dd>A String data type that contains a reference identifier for the data or
	</list></t>	data fragment covered by the target electronic signature. This parameter
		<bcp14>MUST</bcp14> be present.
		</dd>


	<t>Other documents MAY define other profiles that MAY complement, ammend or supe	<dt>"hash":
	rsede these profiles.</t>	</dt>
		<dd>A Base64Binary data type that contains the hash value for the data covered
		by the target electronic signature. This parameter <bcp14>MUST</bcp14> be
		present.
		</dd>
		</dl>


	</section>	</section>
	</section>	<section anchor="policyval-obj-class">
	<section anchor="signature-verification-with-a-svt"><name>Signature Verification	<name>PolicyValidation Claims Object Class</name>
	with a SVT</name>	<t>The sig_val parameter in the Signature object class uses the Policy
		Validation object
		class. The PolicyValidation object provides information about the result of a va
		lidation
		process according to a specific policy, and it contains the following parameters
		:</t>


	<t>Signature verification based on an a SVT MUST follow these steps:</t>	<dl>


	<t><list style="numbers">	<dt>"pol":
	<t>Locate all available SVTs available for the signed document that are releva	</dt>
	nt for the target electronic signature.</t>	<dd>A StringOrURI data type that contains the identifier of the policy
	<t>Select the most recent SVT that can be successfully validated and meets the	governing the electronic signature verification process. This parameter
	requirement of the relying party.</t>	<bcp14>MUST</bcp14> be present.
	<t>Verify the integrity of the signature and the Signed Bytes of the target el	</dd>
	ectronic signature using the sig_ref claim.</t>
	<t>Verify that the Signed Data reference in the original electronic signature
	matches the reference values in the sig_data_ref claim.</t>
	<t>Verify the integrity of referenced Signed Data using provided hash values i
	n the sig_data_ref claim.</t>
	<t>Obtain the verified certificates supporting the asserted electronic signatu
	re verification through the signer_cert_ref claim.</t>
	<t>Verify that signature validation policy results satisfy the requirements of
	the relying party.</t>
	<t>Verify that verified time results satisfy the context for the use of the si
	gned document.</t>
	</list></t>


	<t>After successfully performing these steps, signature validity is established	<dt>"res":
	as well as	</dt>
	the trusted signer certificate binding the identity of the signer to the electro	<dd>A String data type that contains the result of the electronic signature
	nic	verification process. The value <bcp14>MUST</bcp14> be one of "PASSED",
	signature.</t>	"FAILED", or "INDETERMINATE" as defined by <xref
		target="ETSI319102-1"/>. This parameter <bcp14>MUST</bcp14> be present.
		</dd>


	</section>	<dt>"msg":
	<section anchor="iana"><name>IANA Considerations</name>	</dt>
		<dd>A String data type that contains a message describing the
		result. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
		</dd>


	<section anchor="claim-names-reg"><name>Claim Names Registration</name>	<dt>"ext":
		</dt>
		<dd>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 <bcp14>MUST</bcp14> follow any
		conventions defined in a profile of this specification (see <xref
		target="profiles"/>). Inclusion of this parameter is
		<bcp14>OPTIONAL</bcp14>.
		</dd>
		</dl>


	<t>This section registers the "sig_val_claims" claim name in the IANA "JSON Web	</section>
	Token Claims" registry established by Section 10.1 in <xref target="RFC7519"/>.<	<section anchor="timever-obj-class">
	/t>	<name>TimeValidation Claims Object Class</name>
		<t>The time_val parameter in the Signature object class uses the TimeV
		alidation object
		class. The TimeValidation claims object provides information about the result of
		validating evidence of time asserting that the target signature existed at a par
		ticular
		time in the past. Evidence of time is typically a timestamp according to <xref t
		arget="RFC3161"/>, but other types of evidence may be used such as a previously
		issued SVT for this signature. The TimeValidation claims object contains the fol
		lowing parameters:</t>


	<section anchor="clname-reg-contents"><name>Registry Contents</name>	<dl>
		<dt>"time":
		</dt>
		<dd>A NumericDate data type that contains the verified time. This parameter
		<bcp14>MUST</bcp14> be present.
		</dd>


	<t><list style="symbols">	<dt>"type":
	<t>Claim Name: "sig_val_claims"</t>	</dt>
	<t>Claim Description: Signature Validation Token</t>	<dd>A StringOrURI data type that contains an identifier of the type of
	<t>Change Controller: IESG</t>	evidence of time. This parameter <bcp14>MUST</bcp14> be present.
	<t>Specification Document(s): <xref target="sigvalidation-obj-class"/> of {thi	</dd>
	s document}</t>
	</list></t>


	<t>NOTE to RFC editor: Please replace {this document} with its assigned RFC numb	<dt>"iss":
	er.</t>	</dt>
		<dd>A StringOrURI data type that contains an identifier of the entity that
		issued the evidence of time. This parameter <bcp14>MUST</bcp14> be present.
		</dd>


	</section>	<dt>"id":
	</section>	</dt>
	<section anchor="iana-header-params"><name>Header Parameter Names Registration</	<dd>A String data type that contains an unique identifier assigned to the
	name>	evidence of time. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
		</dd>


	<t>This section registers the "svt" Header Parameter in the IANA "JSON Web Signa	<dt>"hash":
	ture and Encryption Header Parameters" registry established by <xref target="RFC	</dt>
	7515"/>.</t>	<dd>A Base64Binary data type that contains the hash value of the validated
		evidence of time. Inclusion of this parameter is <bcp14>OPTIONAL</bcp14>.
		</dd>


	<section anchor="iana-header-params-reg"><name>Registry Contents</name>	<dt>"val":
		</dt>
		<dd>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 <bcp14>OPTIONAL</bcp14>.
		</dd>


	<t><list style="symbols">	<dt>"ext":
	<t>Header Parameter Name: "svt"</t>	</dt>
	<t>Header Parameter Description: Signature Validation Token</t>	<dd>A MAP<String> data type that provides additional claims related to
	<t>Header Parameter Usage Location(s): JWS</t>	the target signature. Extension claims are added at the discretion of the
	<t>Change Controller: IESG</t>	SVT issuer; however, extension claims <bcp14>MUST</bcp14> follow any
	<t>Specification Document(s): <xref target="svt-header"/> of {this document}</	conventions defined in a profile of this specification (see <xref
	t>	target="profiles"/>). Inclusion of this parameter is
	</list></t>	<bcp14>OPTIONAL</bcp14>.
		</dd>


	<t>NOTE to RFC editor: Please replace {this document} with its assigned RFC numb er.</t>	</dl>


	</section>	</section>
	</section>
	</section>
	<section anchor="seccons"><name>Security Considerations</name>


	<section anchor="seccon-lvl-of-reliance"><name>Level of reliance</name>	<section anchor="certref-obj-class">
		<name>CertReference Claims Object Class</name>
		<t>The signer_cert_ref parameter in the Signature object class uses th
		e 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 signatu
		re, and
		it contains the following parameters:</t>


	<t>An SVT allows a signature verifier to still validate the original signature u	<dl>
	sing
	the original signature data and to use the information in the SVT selectively to
	either just confirm the validity and integrity of the original data, such as con
	firming the integrity of signed data or the validity of the signer's certificate
	etc.</t>


	<t>Another way to use an SVT is to completely rely on the validation conclusion	<dt>"type":
	provided	</dt>
	by the SVT and to omit re-validation of the original signature value and origina	<dd>A StringOrURI data type that contains an identifier of the type of
	l	reference. The type identifier <bcp14>MUST</bcp14> be one of the
	certificate status checking data.</t>	identifiers defined below, an identifier specified by the selected profile,
		or a URI identifier. This parameter <bcp14>MUST</bcp14> be present.
		</dd>


	<t>This choice is a decision made by the verifier according to its own policy an	<dt>"ref":
	d risk assessment.</t>	</dt>
		<dd>A [String] data type that contains an array of string parameters
		according to conventions defined by the type identifier. At least one
		parameter <bcp14>MUST</bcp14> be present.
		</dd>


	<t>However, even when relying on the SVT validation conclusion of an SVT it is v	</dl>
	ital 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 certif
	icate chain,
	signed data and the signed bytes.</t>


	</section>	<t>The following type identifiers are defined:</t>
	<section anchor="seccon-aging-algos"><name>Aging algorithms</name>


	<t>Even if the SVT provides protection against algorithms becoming weakened or b roken over time, this protection is only valid for as long as the algorithms use d to sign the SVT are still considered secure. It is advisable to re-issue SVT i n cases where an algorithm protecting the SVT is getting close to its end of lif e.</t>	<dl>


	<t>One way to increase the resistance of algorithms becoming insecure, is to iss	<dt>"chain":
	ue multiple SVT for the same signature with different algorithms and key lengths	</dt>
	where one algorithm could still be secure even if the corresponding algorithm u	<dd>The ref contains an array of Base64-encoded X.509 certificates <xref
	sed in the alternative SVT is broken.</t>	target="RFC5280"/>. The certificates <bcp14>MUST</bcp14> 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.
		</dd>


	</section>	<dt>"chain_hash":
	</section>	</dt>
		<dd>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 <xref
		target="RFC5280"/> used to validate the signature. The certificates
		<bcp14>MUST</bcp14> 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 <bcp14>MUST
		NOT</bcp14> be used unless all hashed certificates are present in the target
		electronic signature.
		</dd>
		</dl>


	</middle>	<t>Note: All certificates referenced using the identifiers above are X
		.509 certificates.
		Profiles of this specification <bcp14>MAY</bcp14> define alternative types of pu
		blic key containers;
		however, a major function of these referenced certificates is not just to refere
		nce
		the public key but also to provide the subject name of the signer. It is therefo
		re
		important for the full function of an SVT that the referenced public key contain
		er also
		provides the means to identify the signer.</t>
		</section>
		<section anchor="svt-jose-header">
		<name>SVT JOSE Header</name>
		<t>The SVT JWT <bcp14>MUST</bcp14> contain the following JSON Object S
		igning and Encryption (JOSE) header parameters in accordance with
		<xref target="RFC7519" sectionFormat="of" section="5"/>:</t>


	<back>	<dl>


	<references title='Normative References'>	<dt>"typ":
		</dt>
		<dd>This parameter <bcp14>MUST</bcp14> have the string value "JWT" (upper
		case).
		</dd>


	&RFC2119;	<dt>"alg":
	&RFC3125;	</dt>
	&RFC3161;	<dd>This parameter identifies the algorithm used to sign the SVT JWT. The
	&RFC3647;	algorithm identifier <bcp14>MUST</bcp14> be specified in <xref
	&RFC5035;	target="RFC7518"/> or the IANA "JSON Web Signature and Encryption Algorithms"
	&RFC8174;	registry <xref target="IANA-JOSE-REG"/>. The specified signature hash
	&RFC5280;	algorithm <bcp14>MUST</bcp14> be identical to the hash algorithm specified in
	&RFC5652;	the hash_algo parameter of the SigValidation object within the sig_val_claims
	&RFC6931;	claim.
	&RFC7515;	</dd>
	&RFC7518;
	&RFC7519;
	<reference anchor="ETSI319102-1" >
	<front>
	<title>ETSI - Electronic Signatures and Infrastructures (ESI); Procedures fo
	r Creation and Validation of AdES Digital Signatures; Part 1: Creation and Valid
	ation</title>
	<author >
	<organization>ETSI</organization>
	</author>
	<date year="2016" month="May"/>
	</front>
	<seriesInfo name="ETSI" value="EN 319 102-1 v1.1.1"/>
	</reference>
	<reference anchor="XMLDSIG11" >
	<front>
	<title>XML Signature Syntax and Processing Version 1.1</title>
	<author initials="D." surname="Eastlake" fullname="Donald Eastlake">
	<organization></organization>
	</author>
	<author initials="J." surname="Reagle" fullname="Joseph Reagle">
	<organization></organization>
	</author>
	<author initials="D." surname="Solo" fullname="David Solo">
	<organization></organization>
	</author>
	<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
	<organization></organization>
	</author>
	<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
	<organization></organization>
	</author>
	<author initials="T." surname="Roessler" fullname="Thomas Roessler">
	<organization></organization>
	</author>
	<author initials="K." surname="Yiu" fullname="Kelvin Yiu">
	<organization></organization>
	</author>
	<date year="2013" month="April" day="11"/>
	</front>
	<seriesInfo name="W3C" value="Proposed Recommendation"/>
	</reference>
	<reference anchor="ISOPDF2" >
	<front>
	<title>Document management -- Portable document format -- Part 2: PDF 2.0</t
	itle>
	<author >
	<organization>ISO</organization>
	</author>
	<date year="2017" month="July"/>
	</front>
	<seriesInfo name="ISO" value="32000-2"/>
	</reference>
	<reference anchor="XADES" >
	<front>
	<title>Electronic Signatures and Infrastructures (ESI); XAdES digital signat
	ures; Part 1: Building blocks and XAdES baseline signatures</title>
	<author >
	<organization>ETSI</organization>
	</author>
	<date year="2016" month="April"/>
	</front>
	<seriesInfo name="ETSI" value="EN 319 132-1 v1.1.1"/>
	</reference>
	<reference anchor="PADES" >
	<front>
	<title>Electronic Signatures and Infrastructures (ESI); PAdES digital signat
	ures; Part 1: Building blocks and PAdES baseline signatures</title>
	<author >
	<organization>ETSI</organization>
	</author>
	<date year="2016" month="April"/>
	</front>
	<seriesInfo name="ETSI" value="EN 319 142-1 v1.1.1"/>
	</reference>
	<reference anchor="CADES" >
	<front>
	<title>Electronic Signatures and Infrastructures (ESI); CAdES digital signat
	ures; Part 1: Building blocks and CAdES baseline signatures</title>
	<author >
	<organization>ETSI</organization>
	</author>
	<date year="2016" month="April"/>
	</front>
	<seriesInfo name="ETSI" value="EN 319 122-1 v1.1.1"/>
	</reference>


	</references>	</dl>


	<references title='Informative References'>	<t>The SVT header <bcp14>MUST</bcp14> contain a public key or a refere
		nce to a public key used to verify the signature on the SVT in accordance with <
		xref target="RFC7515"/>. Each profile, as discussed in <xref target="profiles"/>
		, <bcp14>MUST</bcp14> define the requirements for how the key or key reference i
		s included in the header.</t>
		</section>
		</section>
		</section>


	&RFC8610;	<section anchor="profiles">
		<name>Profiles</name>
		<t>Each signed document and signature type will have to define the precise
		content and
		use of several claims in the SVT.</t>
		<t>At a minimum, each profile <bcp14>MUST</bcp14> define:</t>
		<ul spacing="normal">
		<li>The identifier of the profile</li>
		<li>How to reference the Signed Data content of the signed document</li>
		<li>How to reference the target electronic signature and the Signed Byte
		s of the signature</li>
		<li>How to reference certificates supporting each electronic signature</
		li>
		<li>How to include public keys or references to public keys in the SVT</
		li>
		<li>Whether each electronic signature is supported by a single SVT, or o
		ne SVT may support multiple electronic signatures of the same document</li>
		</ul>
		<t>A profile <bcp14>MAY</bcp14> also define:</t>
		<ul spacing="normal">
		<li>Explicit information on how to perform signature validation based on
		an SVT</li>
		<li>How to attach an SVT to an electronic signature or signed document</
		li>
		</ul>
		<section anchor="defined-profiles">
		<name>Defined Profiles</name>
		<t>The following profiles are defined in appendixes of this document:</t
		>


	</references>	<dl>
		<dt> <xref target="appendix-xml-profile"/>:
		</dt>
		<dd>XML Signature Profile
		</dd>


	<section anchor="appendix-xml-profile"><name>Appendix: XML signature profile</na	<dt><xref target="appendix-pdf-profile"/>:
	me>	</dt>
		<dd>PDF Signature Profile
		</dd>


	<t>This appendix defines a profile for implementing SVT with a signed XML docume	<dt><xref target="appendix-jws-profile"/>:
	nt, and defines the following aspects of SVT usage:</t>	</dt>
		<dd>JWS Profile
		</dd>
		</dl>


	<t><list style="symbols">	<t>Other documents <bcp14>MAY</bcp14> define other profiles that <bcp14>
	<t>How to include reference data related to XML signatures and XML documents i	MAY</bcp14> complement, amend, or supersede these profiles.</t>
	n an SVT.</t>	</section>
	<t>How to add an SVT token to a XML signature.</t>	</section>
	</list></t>	<section anchor="signature-verification-with-a-svt">
		<name>Signature Verification with an SVT</name>
		<t>Signature verification based on an SVT <bcp14>MUST</bcp14> follow these
		steps:</t>
		<ol spacing="normal" type="1"><li>Locate all available SVTs available for
		the signed document that are relevant for the target electronic signature.</li>
		<li>Select the most recent SVT that can be successfully validated and me
		ets the requirement of the relying party.</li>
		<li>Verify the integrity of the signature and the Signed Bytes of the ta
		rget electronic signature using the sig_ref claim.</li>
		<li>Verify that the Signed Data reference in the original electronic sig
		nature matches the reference values in the sig_data_ref claim.</li>
		<li>Verify the integrity of referenced Signed Data using provided hash v
		alues in the sig_data_ref claim.</li>
		<li>Obtain the verified certificates supporting the asserted electronic
		signature verification through the signer_cert_ref claim.</li>
		<li>Verify that signature validation policy results satisfy the requirem
		ents of the relying party.</li>
		<li>Verify that verified time results satisfy the context for the use of
		the signed document.</li>
		</ol>
		<t>After successfully performing these steps, signature validity is establ
		ished as well as
		the trusted signer certificate binding the identity of the signer to the electro
		nic
		signature.</t>
		</section>
		<section anchor="iana">
		<name>IANA Considerations</name>
		<section anchor="claim-names-reg">
		<name>Claim Names Registration</name>
		<t>IANA has registered the "sig_val_claims" claim name in the "JSON Web
		Token Claims" registry established by <xref target="RFC7519" sectionFormat="of"
		section="10.1"/>.</t>
		<section anchor="clname-reg-contents">
		<name>Registry Contents</name>


	<t>XML documents can have any number of signature elements, signing an arbitrary number of fragments of XML documents. The actual signature element may be inclu ded in the signed XML document (enveloped), include the signed data (enveloping) or may be separate from the signed content (detached).</t>	<dl>


	<t>To provide a generic solution for any type of XML signature an SVT is added t	<dt>Claim Name:
	o each XML signature element within the XML signature <ds:Object> element.	</dt>
	</t>	<dd>sig_val_claims
		</dd>


	<section anchor="notation"><name>Notation</name>	<dt>Claim Description:
		</dt>
		<dd>Signature Validation Token
		</dd>


	<section anchor="ref-to-xml-elements"><name>References to XML Elements from XML	<dt>Change Controller:
	Schemas</name>	</dt>
		<dd>IESG
		</dd>


	<t>When referring to elements from the W3C XML Signature namespace	<dt>Specification Document(s):
	(http://www.w3.org/2000/09/xmldsig#) the following syntax is used:</t>	</dt>
		<dd><xref target="sigvalidation-obj-class"/> of RFC 9321
		</dd>


	<t><list style="symbols">	</dl>
	<t><ds:Signature></t>
	</list></t>


	<t>When referring to elements from the ETSI XAdES XML Signature namespace	</section>
	(http://uri.etsi.org/01903/v1.3.2#) the following syntax is used:</t>	</section>
		<section anchor="iana-header-params">
		<name>Header Parameter Names Registration</name>
		<t>IANA has registered the "svt" Header Parameter in the "JSON Web Signa
		ture and Encryption Header Parameters" registry established by <xref target="RFC
		7515"/>.</t>
		<section anchor="iana-header-params-reg">
		<name>Registry Contents</name>


	<t><list style="symbols">	<dl>
	<t><xades:CertDigest></t>	<dt>Header Parameter Name:
	</list></t>	</dt>
		<dd>svt
		</dd>


	<t>When referring to elements defined in this specification	<dt>Header Parameter Description:
	(http://id.swedenconnect.se/svt/1.0/sig-prop/ns) the following syntax is used:</	</dt>
	t>	<dd> Signature Validation Token
		</dd>


	<t><list style="symbols">	<dt>Header Parameter Usage Location(s):
	<t><svt:Element></t>	</dt>
	</list></t>	<dd>JWS
		</dd>


	</section>	<dt>Change Controller:
	</section>	</dt>
	<section anchor="svt-in-xml"><name>SVT in XML Documents</name>	<dd>IESG
		</dd>


	<t>When SVT is provided for XML signatures then one SVT MUST be provided for eac	<dt>Specification Document(s):
	h XML signature.</t>	</dt>
		<dd><xref target="svt-header"/> of RFC 9321
		</dd>
		</dl>


	<t>An SVT embedded within the XML signature element MUST be placed in a <svt	</section>
	:SignatureValidationToken> element as defined in <xref target="signaturevalid	</section>
	ationtoken-signature-property"/>.</t>	</section>


	<section anchor="signaturevalidationtoken-signature-property"><name>SignatureVal	<section anchor="seccons">
	idationToken Signature Property</name>	<name>Security Considerations</name>
		<section anchor="seccon-lvl-of-reliance">
		<name>Level of Reliance</name>


	<t>The <svt:SignatureValidationToken> element MUST be placed in a <ds:S	<t>An SVT allows a signature verifier to still validate the original sig
	ignatureProperty> element in accordance with <xref target="XMLDSIG11"/>. The	nature using
	<ds:SignatureProperty> element MUST be placed inside a <ds:SignaturePro	the original signature data and to use the information in the SVT selectively to
	perties> element inside a <ds:Object> element inside a <ds:Signature	confirm the validity and integrity of the original data, such as confirming the
	> element.</t>	integrity of Signed Data or the validity of the signer's certificate, etc.</t>
		<t>Another way to use an SVT is to completely rely on the validation con
		clusion provided
		by the SVT and to omit revalidation of the original signature value and original
		certificate status checking data.</t>
		<t>This choice is a decision made by the verifier according to its own p
		olicy and risk assessment.</t>
		<t>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 certif
		icate chain,
		Signed Data, and the Signed Bytes.</t>
		</section>
		<section anchor="seccon-aging-algos">
		<name>Aging Algorithms</name>
		<t>Even if the SVT provides protection against algorithms becoming weake
		ned or broken over time, this protection is only valid for as long as the algori
		thms used to sign the SVT are still considered secure. It is advisable to reissu
		e SVTs in cases where an algorithm protecting the SVT is getting close to its en
		d of life.</t>
		<t>One way to increase the resistance of algorithms becoming insecure, i
		s to issue multiple SVTs for the same signature with different algorithms and ke
		y lengths where one algorithm could still be secure even if the corresponding al
		gorithm used in the alternative SVT is broken.</t>
		</section>
		</section>


	<t>Note: <xref target="XMLDSIG11"/> requires the Target attribute to be present in <ds:SignatureProperty>, referencing the signature targeted by this sign ature property. If an SVT is added to a signature that do not have an Id attribu te, implementations SHOULD add an Id attribute to the <ds:Signature> eleme nt and reference that Id in the Target attribute. This Id attribute and Target a ttribute value matching is required by the <xref target="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 applicati ons SHOULD not reject an SVT token because of Id and Target attribute mismatch, and MUST rely on matching against signature using signed information in the SVT itself.</t>	</middle>


	<t>The <svt:SignatureValidationToken> element is defined by the following XML Schema:</t>	<back>


	<figure><artwork><![CDATA[	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		125.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		161.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		647.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		035.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		280.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		652.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
		231.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		515.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		518.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		519.xml"/>

		<reference anchor="IANA-JOSE-REG" target="https://www.iana.org/assignments/jose/
		">
		<front>
		<title>JSON Object Signing and Encryption (JOSE)</title>
		<author>
		<organization>IANA</organization>
		</author>
		</front>
		</reference>

		<reference anchor="ETSI319102-1">
		<front>
		<title>Electronic Signatures and Infrastructures (ESI); Procedures f
		or Creation and Validation of AdES Digital Signatures; Part 1: Creation and Vali
		dation</title>
		<author>
		<organization>ETSI</organization>
		</author>
		<date year="2016" month="May"/>
		</front>
		<seriesInfo name="ETSI EN" value="319 102-1"/>
		<refcontent>v1.1.1</refcontent>
		</reference>

		<reference anchor="XMLDSIG11">
		<front>
		<title>XML Signature Syntax and Processing Version 1.1</title>
		<author initials="D." surname="Eastlake 3rd" fullname="Donald Eastla
		ke 3rd">
		<organization/>
		</author>
		<author initials="J." surname="Reagle" fullname="Joseph Reagle">
		<organization/>
		</author>
		<author initials="D." surname="Solo" fullname="David Solo">
		<organization/>
		</author>
		<author initials="F." surname="Hirsch" fullname="Frederick Hirsch">
		<organization/>
		</author>
		<author initials="M." surname="Nystrom" fullname="Magnus Nystrom">
		<organization/>
		</author>
		<author initials="T." surname="Roessler" fullname="Thomas Roessler">
		<organization/>
		</author>
		<author initials="K." surname="Yiu" fullname="Kelvin Yiu">
		<organization/>
		</author>
		<date year="2013" month="April"/>
		</front>
		<seriesInfo name="W3C" value="Proposed Recommendation"/>
		<annotation>Latest version available at <eref target="https://www.w3.org/TR/xmld
		sig-core1/"/>.</annotation>
		</reference>

		<reference anchor="ISOPDF2">
		<front>
		<title>Document management -- Portable document format -- Part 2: PD
		F 2.0</title>
		<author>
		<organization>ISO</organization>
		</author>
		<date year="2020" month="December"/>
		</front>
		<seriesInfo name="ISO" value="32000-2:2020"/>
		</reference>

		<reference anchor="XADES">
		<front>
		<title>Electronic Signatures and Infrastructures (ESI); XAdES digita
		l signatures; Part 1: Building blocks and XAdES baseline signatures</title>
		<author>
		<organization>ETSI</organization>
		</author>
		<date year="2016" month="April"/>
		</front>
		<seriesInfo name="ETSI EN" value="319 132-1"/>
		<refcontent>v1.1.1</refcontent>
		</reference>

		<reference anchor="PADES">
		<front>
		<title>Electronic Signatures and Infrastructures (ESI); PAdES digita
		l signatures; Part 1: Building blocks and PAdES baseline signatures</title>
		<author>
		<organization>ETSI</organization>
		</author>
		<date year="2016" month="April"/>
		</front>
		<seriesInfo name="ETSI EN" value="319 142-1"/>
		<refcontent>v1.1.1</refcontent>
		</reference>

		<reference anchor="CADES">
		<front>
		<title>Electronic Signatures and Infrastructures (ESI); CAdES digita
		l signatures; Part 1: Building blocks and CAdES baseline signatures</title>
		<author>
		<organization>ETSI</organization>
		</author>
		<date year="2016" month="April"/>
		</front>
		<seriesInfo name="ETSI EN" value="319 122-1"/>
		<refcontent>v1.1.1</refcontent>
		</reference>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		610.xml"/>
		</references>
		</references>

		<section anchor="appendix-xml-profile">
		<name>XML Signature Profile</name>
		<t>This appendix defines a profile for implementing SVTs with a signed XML
		document and defines the following aspects of SVT usage:</t>
		<ul spacing="normal">
		<li>How to include reference data related to XML signatures and XML docu
		ments in an SVT</li>
		<li>How to add an SVT token to an XML signature</li>
		</ul>
		<t>XML documents can have any number of signature elements, signing an arb
		itrary number of fragments of XML documents. The actual signature element may be
		included in the signed XML document (enveloped), include the Signed Data (envel
		oping), or may be separate from the signed content (detached).</t>
		<t>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> e
		lement.</t>
		<section anchor="notation">
		<name>Notation</name>
		<section anchor="ref-to-xml-elements">
		<name>References to XML Elements from XML Schemas</name>
		<t>When referring to elements from the W3C XML Signature namespace
		(<eref target="https://www.w3.org/2000/09/xmldsig#"/>), the following syntax is
		used:</t>
		<ul spacing="normal">
		<li><ds:Signature></li>
		</ul>
		<t>When referring to elements from the ETSI XAdES XML Signature namesp
		ace
		(<eref target="https://uri.etsi.org/01903/v1.3.2#"/>), the following syntax is u
		sed:</t>
		<ul spacing="normal">
		<li><xades:CertDigest></li>
		</ul>
		<t>When referring to elements defined in this specification
		(<eref target="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"/>), the
		following syntax is used:</t>

		<ul spacing="normal">
		<li><svt:Element></li>
		</ul>
		</section>
		</section>
		<section anchor="svt-in-xml">
		<name>SVT in XML Documents</name>
		<t>When SVTs are provided for XML signatures, then one SVT <bcp14>MUST</
		bcp14> be provided for each XML signature.</t>
		<t>An SVT embedded within the XML signature element <bcp14>MUST</bcp14>
		be placed in a <svt:SignatureValidationToken> element as defined in <xref
		target="signaturevalidationtoken-signature-property"/>.</t>
		<section anchor="signaturevalidationtoken-signature-property">
		<name>SignatureValidationToken Signature Property</name>
		<t>The <svt:SignatureValidationToken> element <bcp14>MUST</bcp14
		> be placed in a <ds:SignatureProperty> element in accordance with <xref t
		arget="XMLDSIG11"/>. The <ds:SignatureProperty> element <bcp14>MUST</bcp14
		> be placed inside a <ds:SignatureProperties> element inside a <ds:Obje
		ct> element inside a <ds:Signature> element.</t>
		<t>Note: <xref target="XMLDSIG11"/> requires the Target attribute to b
		e present in <ds:SignatureProperty>, referencing the signature targeted by
		this signature property. If an SVT is added to a signature that does not have a
		n Id attribute, implementations <bcp14>SHOULD</bcp14> add an Id attribute to the
		<ds:Signature> element and reference that Id in the Target attribute. Thi
		s Id attribute and Target attribute value matching is required by the <xref targ
		et="XMLDSIG11"/> standard, but it is redundant in the context of SVT validation
		as the SVT already contains information that uniquely identifies the target sign
		ature. Validation applications <bcp14>SHOULD NOT</bcp14> reject an SVT token bec
		ause of Id and Target attribute mismatch and <bcp14>MUST</bcp14> rely on matchin
		g against a signature using signed information in the SVT itself.</t>
		<t>The <svt:SignatureValidationToken> element is defined by the
		following XML Schema:</t>
		<sourcecode type="xml"><![CDATA[
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified"	elementFormDefault="qualified"
	targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"	targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
	xmlns:svt="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"	<xs:element name="SignatureValidationToken"
	type="svt:SignatureValidationTokenType" />	type="svt:SignatureValidationTokenType" />

	<xs:complexType name="SignatureValidationTokenType">	<xs:complexType name="SignatureValidationTokenType">
	<xs:simpleContent>	<xs:simpleContent>
	<xs:extension base="xs:string">	<xs:extension base="xs:string">
	</xs:extension>	</xs:extension>
	</xs:simpleContent>	</xs:simpleContent>
	</xs:complexType>	</xs:complexType>

	</xs:schema>	</xs:schema>

	]]></artwork></figure>	]]></sourcecode>
		<t>The SVT token <bcp14>MUST</bcp14> be included as a string represent
	<t>The SVT token MUST be included as a string representation of the SVT JWT. Not	ation of the SVT JWT. Note that this is the string representation of the JWT wit
	e that this is the string representation of the JWT without further encoding. Th	hout further encoding. The SVT <bcp14>MUST NOT</bcp14> be represented by the Bas
	e SVT MUST NOT be represented by the Base64 encoded bytes of the JWT string.</t>	e64-encoded bytes of the JWT string.</t>
		<t>Example:</t>
	<t>Example:</t>	<sourcecode type="xml"><![CDATA[

	<figure><artwork><![CDATA[
	<ds:Signature Id="MySignatureId">	<ds:Signature Id="MySignatureId">
	...	...
	<ds:Object>	<ds:Object>
	<ds:SignatureProperties>	<ds:SignatureProperties>
	<ds:SignatureProperty Target="#MySignatureId">	<ds:SignatureProperty Target="#MySignatureId">
	<svt:SignatureValidationToken>	<svt:SignatureValidationToken>
	eyJ0eXAiOiJKV1QiLCJhb...2aNZ	eyJ0eXAiOiJKV1QiLCJhb...2aNZ
	</svt:SignatureValidationToken>	</svt:SignatureValidationToken>
	</ds:SignatureProperty>	</ds:SignatureProperty>
	</ds:SignatureProperties>	</ds:SignatureProperties>
	</ds:Object>	</ds:Object>
	</ds:Signature>	</ds:Signature>

	]]></artwork></figure>	]]></sourcecode>
		</section>
	</section>	<section anchor="xml-multiple-svt-tokens">
	<section anchor="xml-multiple-svt-tokens"><name>Multiple SVT in an XML signature	<name>Multiple SVTs in an XML Signature</name>
	</name>	<t>If a new SVT is stored in a signature that already contains a previ
		ously issued SVT, implementations can choose either to replace the existing SVT
	<t>If a new SVT is stored in a signature which already contains a previously iss	or to store the new SVT in addition to the existing SVT.</t>
	ued SVT, implementations can choose to either replace the existing SVT or to sto	<t>If the new SVT is stored in addition to the old SVT, it <bcp14>SHOU
	re the new SVT in addition to the existing SVT.</t>	LD</bcp14> be stored in a new <ds:SignatureProperty> element inside the ex
		isting <ds:SignatureProperties> element where the old SVT is located.</t>
	<t>If the new SVT is stored in addition to the old SVT, it SHOULD be stored in a	<t>For interoperability robustness, signature validation applications
	new <ds:SignatureProperty> element inside the existing <ds:SignaturePr	<bcp14>MUST</bcp14> be able to handle signatures where the new SVT is located in
	operties> element where the old SVT is located.</t>	a new <ds:Object> element.</t>
		</section>
	<t>For interoperability robustness, signature validation applications MUST be ab	</section>
	le to handle signatures where the new SVT is located in a new <ds:Object>	<section anchor="xml-svt-claims">
	element.</t>	<name>XML Signature SVT Claims</name>
		<section anchor="xml-profile-identifier">
	</section>	<name>XML Profile Identifier</name>
	</section>	<t>When this profile is used, the SigValidation object <bcp14>MUST</bc
	<section anchor="xml-svt-claims"><name>XML signature SVT Claims</name>	p14> contain a "profile" claim with the value "XML".</t>
		</section>
	<section anchor="xml-profile-identifier"><name>XML Profile Identifier</name>	<section anchor="xml-signature-reference-data">
		<name>XML Signature Reference Data</name>
	<t>When this profile is used the SigValidation object MUST contain a "profile" c	<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "sig_ref" cl
	laim with the value "XML".</t>	aim (SigReference object) with the following elements:</t>

	</section>
	<section anchor="xml-signature-reference-data"><name>XML Signature Reference Dat
	a</name>

	<t>The SVT Signature object MUST contain a "sig_ref" claim (SigReference object)
	with the following elements:</t>

	<t><list style="symbols">
	<t>"id" -- The Id-attribute of the XML signature, if present.</t>
	<t>"sig_hash" -- The hash over the signature value bytes.</t>
	<t>"sb_hash" -- The hash over the canonicalized <ds:SignedInfo> element
	(the bytes the XML signature algorithm has signed to generated the signature val
	ue).</t>
	</list></t>

	</section>
	<section anchor="xml-signed-data-reference"><name>XML Signed Data Reference Data
	</name>

	<t>The SVT Signature object MUST contain one instance of the "sig_data" claim (S
	ignedData object) for each <ds:Reference> element in the <ds:SignedInfo
	> element. The "sig_data" claim MUST contain the following elements:</t>

	<t><list style="symbols">
	<t>"ref" -- The value of the URI attribute of the corresponding <ds:Referen
	ce> element.</t>
	<t>"hash" -- The hash of all bytes identified corresponding <ds:Reference&g
	t; element after applying all identified canonicalization and transformation alg
	orithms. These are the same bytes that is hashed by the hash value in the <ds
	:DigestValue> element inside the <ds:Reference> element.</t>
	</list></t>

	</section>
	<section anchor="xml-signer-certificate-references"><name>XML Signer Certificate
	References</name>

	<t>The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReferenc
	e object). The "type" parameter of the "signer_cert_ref" claim MUST be either "c
	hain" or "chain_hash".</t>

	<t><list style="symbols">
	<t>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.</t>
	<t>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.</t>
	</list></t>

	</section>
	</section>
	<section anchor="xml-jose-header"><name>JOSE Header</name>

	<section anchor="xml-svt-signing-key-reference"><name>SVT Signing Key Reference<
	/name>

	<t>The SVT JOSE header for XML signatures must contain one of the following head
	er parameters in accordance with <xref target="RFC7515"/>, for storing a referen
	ce to the public key used to verify the signature on the SVT:</t>

	<t><list style="symbols">
	<t>"x5c" -- Holds an X.509 certificate <xref target="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.</t>
	<t>"kid" -- A key identifier holding the Base64 encoded hash value of the cert
	ificate 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 <spanx style=
	"verb">alg</spanx> header parameter.</t>
	</list></t>

	</section>
	</section>
	</section>
	<section anchor="appendix-pdf-profile"><name>Appendix: PDF signature profile</na
	me>

	<t>This appendix defines a profile for implementing SVT with a signed PDF docume
	nt, and defines the following aspects of SVT usage:</t>

	<t><list style="symbols">
	<t>How to include reference data related to PDF signatures and PDF documents i
	n an SVT.</t>
	<t>How to add an SVT token to a PDF document.</t>
	</list></t>

	<t>PDF document signatures are added as incremental updates to the signed PDF do
	cument and signs all data of the PDF document up until the current signature. Wh
	en 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 t
	his event.</t>

	<t>To minimize the impact on PDF documents with multiple signatures and to stay
	backwards compatible with PDF software that do not understand SVT, PDF documents
	add one SVT token for all signatures of the PDF as an extension to a document t
	imestamp added to the signed PDF as an incremental update. This SVT covers all s
	ignatures of the signed PDF.</t>

	<section anchor="svt-in-pdf"><name>SVT in PDF Documents</name>

	<t>The SVT for a signed PDF document MAY provide signature validation informatio
	n about any of the present signatures in the PDF. The SVT MUST contain a separat
	e "sig" claim (Signature object) for each signature on the PDF that is covered b
	y the SVT.</t>

	<t>An SVT added to a signed PDF document MUST be added to a document timestamp a
	ccordance with ISO 32000-2:2017 <xref target="ISOPDF2"/>.</t>

	<t>The document timestamp contains an <xref target="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 <xref tar
	get="svt-extension-to-timestamps"/>.</t>

	<section anchor="svt-extension-to-timestamps"><name>SVT Extension to Timestamp T
	okens</name>

	<t>The SVT extension is an Extension suitable to be included in TSTInfo as defin
	ed by <xref target="RFC3161"/>.</t>

	<t>The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.
	2</t>

	<t>Editors note: This is the current used OID. Consider assigning an IETF extens
	ion OID.</t>

	<t>This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as
	a UTF-8 encoded string.</t>

	<t>This extension MUST NOT be marked critical.</t>

	<t>Note: Extensions in timestamp tokens according to <xref target="RFC3161"/> ar
	e imported from the definition of the X.509 certificate extensions defined in <x
	ref target="RFC5280"/>.</t>

	</section>
	</section>
	<section anchor="pdf-svt-claims"><name>PDF signature SVT Claims</name>

	<section anchor="pdf-profile-identifier"><name>PDF Profile Identifier</name>

	<t>When this profile is used the SigValidation object MUST contain a "profile" c
	laim with the value "PDF".</t>

	</section>
	<section anchor="pdf-signature-reference-data"><name>PDF Signature Reference Dat
	a</name>

	<t>The SVT Signature object MUST contain a "sig_ref" claim (SigReference object)
	with the following elements:</t>

	<t><list style="symbols">
	<t>"id" -- Absent or a Null value.</t>
	<t>"sig_hash" -- The hash over the signature value bytes.</t>
	<t>"sb_hash" -- The hash over the DER encoded SignedAttributes in SignerInfo.<
	/t>
	</list></t>


	</section>	<dl>
	<section anchor="pdf-signed-data-reference"><name>PDF Signed Data Reference Data
	</name>


	<t>The SVT Signature object MUST contain one instance of the "sig_data" claim (S	<dt>"id":
	ignedData object) with the following elements:</t>	</dt>
		<dd>The Id-attribute of the XML signature, if present.
		</dd>


	<t><list style="symbols">	<dt>"sig_hash":
	<t>"ref" -- The string representation of the ByteRange value of the PDF signat	</dt>
	ure dictionary of the target signature. This is a sequence of integers separated	<dd>The hash over the signature value bytes.
	by space where each integer pair specifies the start index and length of a byte	</dd>
	range.</t>
	<t>"hash" -- The hash of all bytes identified by the ByteRange value. This is
	the concatenation of all byte ranges identified by the ByteRange value.</t>
	</list></t>


	</section>	<dt>"sb_hash":
	<section anchor="pdf-signer-certificate-references"><name>PDF Signer Certificate	</dt>
	References</name>	<dd>The hash over the canonicalized <ds:SignedInfo> element
		(the bytes the XML signature algorithm has signed to generate the
		signature value).
		</dd>


	<t>The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReferenc e object). The "type" parameter of the "signer_cert_ref" claim MUST be either "c hain" or "chain_hash".</t>	</dl>


	<t><list style="symbols">	</section>
	<t>The "chain" type MUST be used when signature validation was performed using	<section anchor="xml-signed-data-reference">
	one or more certificates where some or all of the certificates in the chain are	<name>XML Signed Data Reference Data</name>
	not present in the target signature.</t>	<t>The SVT Signature object <bcp14>MUST</bcp14> contain one instance o
	<t>The "chain_hash" type MUST be used when signature validation was performed	f the "sig_data" claim (SignedData object) for each <ds:Reference> element
	using one or more certificates where all of the certificates are present in the	in the <ds:SignedInfo> element. The "sig_data" claim <bcp14>MUST</bcp14>
	target signature.</t>	contain the following elements:</t>
	</list></t>


	<t>Note: The referenced signer certificate MUST match any certificates reference d using ESSCertID or ESSCertIDv2 from <xref target="RFC5035"/>.</t>	<dl>


	</section>	<dt>"ref":
	</section>	</dt>
	<section anchor="pdf-jose-header"><name>JOSE Header</name>	<dd>The value of the URI attribute of the corresponding <ds:Reference>
		element.
		</dd>


	<section anchor="pdf-svt-signing-key-reference"><name>SVT Signing Key Reference<	<dt>"hash":
	/name>	</dt>
		<dd>The hash of all bytes that were identified by the corresponding <ds:Refer
		ence>
		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.
		</dd>


	<t>The SVT JOSE header must contain one of the following header parameters in ac cordance with <xref target="RFC7515"/>, for storing a reference to the public ke y used to verify the signature on the SVT:</t>	</dl>


	<t><list style="symbols">	</section>
	<t>"x5c" -- Holds an X.509 certificate <xref target="RFC5280"/> or a chain of	<section anchor="xml-signer-certificate-references">
	certificates. The certificate holding the public key that verifies the signature	<name>XML Signer Certificate References</name>
	on the SVT MUST be the first certificate in the chain.</t>	<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "signer_cert
	<t>"kid" -- A key identifier holding the Base64 encoded hash value of the cert	_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref
	ificate that can verify the signature on the SVT. The hash algorithm MUST be the	" claim <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
	same hash algorithm used when signing the SVT as specified by the <spanx style=	<ul spacing="normal">
	"verb">alg</spanx> header parameter. The referenced certificate SHOULD be the sa	<li>The "chain" type <bcp14>MUST</bcp14> be used when signature vali
	me certificate that was used to sign the document timestamp that contains the SV	dation was performed using one or more certificates where some or all of the cer
	T.</t>	tificates in the chain are not present in the target signature.</li>
	</list></t>	<li>The "chain_hash" type <bcp14>MUST</bcp14> be used when signature
		validation was performed using one or more certificates where all of the certif
		icates are present in the target signature.</li>
		</ul>
		</section>
		</section>
		<section anchor="xml-jose-header">
		<name>JOSE Header</name>
		<section anchor="xml-svt-signing-key-reference">
		<name>SVT Signing Key Reference</name>
		<t>The SVT JOSE header for XML signatures must contain one of the foll
		owing header parameters in accordance with <xref target="RFC7515"/> for storing
		a reference to the public key used to verify the signature on the SVT:</t>


	</section>	<dl>
	</section>
	</section>
	<section anchor="appendix-jws-profile"><name>Appendix: JWS Profile</name>


	<t>This appendix defines a profile for implementing SVT with a JWS signed payloa	<dt>"x5c":
	d according to <xref target="RFC7515"/>, and defines the following aspects of SV	</dt>
	T usage:</t>	<dd>Holds an X.509 certificate <xref target="RFC5280"/> or a chain
		of certificates. The certificate holding the public key that
		verifies the signature on the SVT <bcp14>MUST</bcp14> be the first
		certificate in the chain.
		</dd>


	<t><list style="symbols">	<dt>"kid":
	<t>How to include reference data related to JWS signatures in an SVT.</t>	</dt>
	<t>How to add an SVT token to JWS signatures.</t>	<dd> A key identifier holding the Base64-encoded hash value of the
	</list></t>	certificate that can verify the signature on the SVT. The hash
		algorithm <bcp14>MUST</bcp14> be the same hash algorithm used when
		signing the SVT as specified by the "<tt>alg</tt>" Header Parameter.
		</dd>


	<t>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 (enve loping) or may sign any externally associated payload data (detached).</t>	</dl>


	<t>To provide a generic solution for JWS, an SVT is added to each present signat	</section>
	ure as a JWS Unprotected Header. If a JWS includes multiple signatures, then eac	</section>
	h signature includes its own SVT.</t>	</section>
		<section anchor="appendix-pdf-profile">
		<name>PDF Signature Profile</name>
		<t>This appendix defines a profile for implementing SVTs with a signed PDF
		document, and it defines the following aspects of SVT usage:</t>
		<ul spacing="normal">
		<li>How to include reference data related to PDF signatures and PDF docu
		ments in an SVT.</li>
		<li>How to add an SVT token to a PDF document.</li>
		</ul>
		<t>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 signatu
		re. When more than one signature is added to a PDF document the previous signatu
		re is signed by the next signature and can not be updated with additional data a
		fter this event.</t>
		<t>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 d
		ocument timestamp added to the signed PDF as an incremental update. This SVT cov
		ers all signatures of the signed PDF.</t>
		<section anchor="svt-in-pdf">
		<name>SVTs in PDF Documents</name>
		<t>The SVT for a signed PDF document <bcp14>MAY</bcp14> provide signatur
		e validation information about any of the present signatures in the PDF. The SVT
		<bcp14>MUST</bcp14> contain a separate "sig" claim (Signature object) for each
		signature on the PDF that is covered by the SVT.</t>
		<t>An SVT added to a signed PDF document <bcp14>MUST</bcp14> be added to
		a document timestamp in accordance with ISO 32000-2:2020 <xref target="ISOPDF2"
		/>.</t>
		<t>The document timestamp contains an <xref target="RFC3161"/> timestamp
		token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT <bcp14
		>MUST</bcp14> be added to the timestamp token (TSTInfo) as an Extension object a
		s defined in <xref target="svt-extension-to-timestamps"/>.</t>
		<section anchor="svt-extension-to-timestamps">
		<name>SVT Extension to Timestamp Tokens</name>
		<t>The SVT extension is an Extension suitable to be included in TSTInf
		o as defined by <xref target="RFC3161"/>.</t>
		<t>The SVT extension is identified by the Object Identifier (OID) 1.2.
		752.201.5.2.</t>


	<section anchor="svt-in-jws"><name>SVT in JWS</name>	<t>This extension data (OCTET STRING) holds the bytes of SVT JWT, repr
		esented as a UTF-8-encoded string.</t>
		<t>This extension <bcp14>MUST NOT</bcp14> be marked critical.</t>
		<t>Note: Extensions in timestamp tokens according to <xref target="RFC
		3161"/> are imported from the definition of the X.509 certificate extensions def
		ined in <xref target="RFC5280"/>.</t>
		</section>
		</section>
		<section anchor="pdf-svt-claims">
		<name>PDF Signature SVT Claims</name>
		<section anchor="pdf-profile-identifier">
		<name>PDF Profile Identifier</name>
		<t>When this profile is used, the SigValidation object <bcp14>MUST</bc
		p14> contain a "profile" claim with the value "PDF".</t>
		</section>
		<section anchor="pdf-signature-reference-data">
		<name>PDF Signature Reference Data</name>
		<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "sig_ref" cl
		aim (SigReference object) with the following elements:</t>


	<t>An SVT token MAY be added to any signature of a JWS to support validation of	<dl>
	that signature. If more than one signature is present then each present SVT MUST	<dt>"id":
	provide information exclusively related to one associated signature and MUST NO	</dt>
	T include information about any other signature in the JWS.</t>	<dd>Absent or a Null value.
		</dd>


	<t>Each SVT is stored in its associated signature's "svt" header as defined in <	<dt>"sig_hash":
	xref target="svt-header"/>.</t>	</dt>
		<dd>The hash over the signature value bytes.
		</dd>


	<section anchor="svt-header"><name>"svt" Header Parameter</name>	<dt>"sb_hash":
		</dt>
		<dd>The hash over the DER-encoded SignedAttributes in SignerInfo.
		</dd>


	<t>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 <xref target="RFC7519" /> and is stored using its natural string representation without further wrappin g or encoding.</t>	</dl>


	<t>The "svt" Header Parameter, when used, MUST be included as a JWS Unprotected	</section>
	Header.</t>	<section anchor="pdf-signed-data-reference">
		<name>PDF Signed Data Reference Data</name>
		<t>The SVT Signature object <bcp14>MUST</bcp14> contain one instance o
		f the "sig_data" claim (SignedData object) with the following elements:</t>


	<t>Note: JWS Unprotected Header is not supported with JWS Compact Serialization.	<dl>
	A consequence of adding an SVT token to a JWS is therefore that JWS JSON Serial	<dt>"ref":
	ization MUST be used, either in the form of general JWS JSON Serialization (for	</dt>
	one or more signatures) or in the form of flattened JWS JSON Serialization (opti	<dd>The string representation of the ByteRange value of the PDF
	onally used when only one signature is present in the JWS).</t>	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.
		</dd>


	</section>	<dt>"hash":
	<section anchor="jws-multiple-svt-tokens"><name>Multiple SVT in a JWS signature<	</dt>
	/name>	<dd> The hash of all bytes identified by the ByteRange value. This
		is the concatenation of all byte ranges identified by the
		ByteRange value.
		</dd>


	<t>If a new SVT is stored in a signature which already contains a previously iss ued SVT, implementations can choose to either replace the existing SVT or to sto re the new SVT in addition to the existing SVT.</t>	</dl>


	<t>If a JWS signature already contains an array of SVTs and a new SVT is to be a	</section>
	dded, then the new SVT MUST be added to the array of SVT tokens in the existing	<section anchor="pdf-signer-certificate-references">
	"svt" Header Parameter.</t>	<name>PDF Signer Certificate References</name>
		<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "signer_cert
		_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref
		" claim <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
		<ul spacing="normal">
		<li>The "chain" type <bcp14>MUST</bcp14> be used when signature vali
		dation was performed using one or more certificates where some or all of the cer
		tificates in the chain are not present in the target signature.</li>
		<li>The "chain_hash" type <bcp14>MUST</bcp14> be used when signature
		validation was performed using one or more certificates where all of the certif
		icates are present in the target signature.</li>
		</ul>
		<t>Note: The referenced signer certificate <bcp14>MUST</bcp14> match a
		ny certificates referenced using ESSCertID or ESSCertIDv2 from <xref target="RFC
		5035"/>.</t>
		</section>
		</section>
		<section anchor="pdf-jose-header">
		<name>JOSE Header</name>
		<section anchor="pdf-svt-signing-key-reference">
		<name>SVT Signing Key Reference</name>
		<t>The SVT JOSE header must contain one of the following header parame
		ters in accordance with <xref target="RFC7515"/> for storing a reference to the
		public key used to verify the signature on the SVT:</t>


	</section>	<dl>
	</section>	<dt>"x5c":
	<section anchor="jws-svt-claims"><name>JWS signature SVT Claims</name>	</dt>
		<dd>Holds an X.509 certificate <xref target="RFC5280"/> or a chain
		of certificates. The certificate holding the public key that
		verifies the signature on the SVT <bcp14>MUST</bcp14> be the first
		certificate in the chain.
		</dd>


	<section anchor="jws-profile-identifier"><name>JWS Profile Identifier</name>	<dt>"kid":
		</dt>
		<dd>A key identifier holding the Base64-encoded hash value of the
		certificate that can verify the signature on the SVT. The hash
		algorithm <bcp14>MUST</bcp14> be the same hash algorithm used when
		signing the SVT as specified by the "<tt>alg</tt>" Header
		Parameter. The referenced certificate <bcp14>SHOULD</bcp14> be the
		same certificate that was used to sign the document timestamp that
		contains the SVT.
		</dd>
		</dl>


	<t>When this profile is used the SigValidation object MUST contain a "profile" c	</section>
	laim with the value "JWS".</t>	</section>
		</section>
		<section anchor="appendix-jws-profile">
		<name>JWS Profile</name>
		<t>This appendix defines a profile for implementing SVTs with a JWS signed
		payload according to <xref target="RFC7515"/>, and it defines the following asp
		ects of SVT usage:</t>
		<ul spacing="normal">
		<li>How to include reference data related to JWS signatures in an SVT.</
		li>
		<li>How to add an SVT token to JWS signatures.</li>
		</ul>
		<t>A JWS may have one or more signatures, depending on its serialization f
		ormat, signing the same payload data. A JWS either contains the data to be signe
		d (enveloping) or may sign any externally associated payload data (detached).</t
		>
		<t>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, th
		en each signature includes its own SVT.</t>
		<section anchor="svt-in-jws">
		<name>SVT in JWS</name>
		<t>An SVT token <bcp14>MAY</bcp14> be added to any signature of a JWS to
		support validation of that signature. If more than one signature is present, th
		en each present SVT <bcp14>MUST</bcp14> provide information exclusively related
		to one associated signature and <bcp14>MUST NOT</bcp14> include information abou
		t any other signature in the JWS.</t>
		<t>Each SVT is stored in its associated signature's "svt" header as defi
		ned in <xref target="svt-header"/>.</t>
		<section anchor="svt-header">
		<name>"svt" Header Parameter</name>
		<t>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 <xref target
		="RFC7519"/> and is stored using its natural string representation without furth
		er wrapping or encoding.</t>
		<t>The "svt" Header Parameter, when used, <bcp14>MUST</bcp14> be inclu
		ded as a JWS Unprotected Header.</t>
		<t>Note: A JWS Unprotected Header is not supported with JWS Compact Se
		rialization. A consequence of adding an SVT token to a JWS is therefore that JWS
		JSON Serialization <bcp14>MUST</bcp14> be used either in the form of general JW
		S JSON Serialization (for one or more signatures) or in the form of flattened JW
		S JSON Serialization (optionally used when only one signature is present in the
		JWS).</t>
		</section>
		<section anchor="jws-multiple-svt-tokens">
		<name>Multiple SVTs in a JWS Signature</name>
		<t>If a new SVT is stored in a signature that already contains a previ
		ously issued SVT, implementations can choose either to replace the existing SVT
		or to store the new SVT in addition to the existing SVT.</t>
		<t>If a JWS signature already contains an array of SVTs and a new SVT
		is to be added, then the new SVT <bcp14>MUST</bcp14> be added to the array of SV
		T tokens in the existing "svt" Header Parameter.</t>
		</section>
		</section>
		<section anchor="jws-svt-claims">
		<name>JWS Signature SVT Claims</name>
		<section anchor="jws-profile-identifier">
		<name>JWS Profile Identifier</name>
		<t>When this profile is used, the SigValidation object <bcp14>MUST</bc
		p14> contain a "profile" claim with the value "JWS".</t>
		</section>
		<section anchor="jws-signature-reference-data">
		<name>JWS Signature Reference Data</name>
		<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "sig_ref" cl
		aim (SigReference object) with the following elements:</t>


	</section>	<dl>
	<section anchor="jws-signature-reference-data"><name>JWS Signature Reference Dat
	a</name>


	<t>The SVT Signature object MUST contain a "sig_ref" claim (SigReference object)	<dt>"sig_hash":
	with the following elements:</t>	</dt>
		<dd>The hash over the associated signature value (the bytes of the
		base64url-decoded signature parameter).
		</dd>


	<t><list style="symbols">	<dt>"sb_hash":
	<t>"sig_hash" -- The hash over the associated signature value (the bytes of th	</dt>
	e base64url-decoded signature parameter).</t>	<dd>The hash over all bytes signed by the associated signature
	<t>"sb_hash" -- The hash over all bytes signed by the associated signature (th	(the JWS Signing Input according to <xref target="RFC7515"/>).
	e JWS Signing Input according to <xref target="RFC7515"/>).</t>	</dd>
	</list></t>


	</section>	</dl>
	<section anchor="jws-signed-data-reference"><name>JWS Signed Data Reference Data
	</name>


	<t>The SVT Signature object MUST contain one instance of the "sig_data" claim (S	</section>
	ignedData object) with the following elements:</t>	<section anchor="jws-signed-data-reference">
		<name>JWS Signed Data Reference Data</name>
		<t>The SVT Signature object <bcp14>MUST</bcp14> contain one instance o
		f the "sig_data" claim (SignedData object) with the following elements:</t>


	<t><list style="symbols">	<dl>
	<t>"ref" -- This parameter MUST hold one of the following thee possible values
	. <list style="numbers">
	<t>The explicit string value "payload" if the signed JWS Payload is embedd
	ed in a "payload" member of the JWS.</t>
	<t>The explicit string value "detached" if the JWS signs detached payload
	data without explicit reference.</t>
	<t>A URI that can be used to identify or fetch the detached signed data. T
	he means to determine the URI for the detached signed data is outside the scope
	of this specification.</t>
	</list></t>
	<t>"hash" -- The hash over the JWS Payload data bytes (not its base64url-encod
	ed string representation).</t>
	</list></t>


	</section>	<dt>"ref":
	<section anchor="jws-signer-certificate-references"><name>JWS Signer Certificate	</dt>
	References</name>	<dd>
		<t>This parameter <bcp14>MUST</bcp14> hold one of the
		following three possible values: </t>
		<ol spacing="normal" type="1"><li>The explicit string value
		"payload" if the signed JWS Payload is embedded in a "payload"
		member of the JWS.</li>
		<li>The explicit string value "detached" if the JWS signs
		detached payload data without explicit reference.</li>
		<li>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.</li>
		</ol>
		</dd>


	<t>The SVT Signature object MUST contain a "signer_cert_ref" claim (CertReferenc	<dt>"hash":
	e object). The "type" parameter of the "signer_cert_ref" claim MUST be either "c	</dt>
	hain" or "chain_hash".</t>	<dd>The hash over the JWS Payload data bytes (not its
		base64url-encoded string representation).
		</dd>


	<t><list style="symbols">	</dl>
	<t>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.</t>
	<t>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.</t>
	</list></t>

	</section>	</section>

	</section>	<section anchor="jws-signer-certificate-references">
	<section anchor="jws-svt-jose-header"><name>SVT JOSE Header</name>	<name>JWS Signer Certificate References</name>
		<t>The SVT Signature object <bcp14>MUST</bcp14> contain a "signer_cert
	<section anchor="jws-svt-signing-key-reference"><name>SVT Signing Key Reference<	_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref
	/name>	" claim <bcp14>MUST</bcp14> be either "chain" or "chain_hash".</t>
		<ul spacing="normal">
	<t>The SVT JOSE header must contain one of the following header parameters in ac	<li>The "chain" type <bcp14>MUST</bcp14> be used when signature vali
	cordance with <xref target="RFC7515"/>, for storing a reference to the public ke	dation was performed using one or more certificates where some or all of the cer
	y used to verify the signature on the SVT:</t>	tificates in the chain are not present in the target signature.</li>
		<li>The "chain_hash" type <bcp14>MUST</bcp14> be used when signature
		validation was performed using one or more certificates where all of the certif
		icates are present in the target signature JOSE header using the "x5c" Header Pa
		rameter.</li>
		</ul>
		</section>
		</section>
		<section anchor="jws-svt-jose-header">
		<name>SVT JOSE Header</name>
		<section anchor="jws-svt-signing-key-reference">
		<name>SVT Signing Key Reference</name>
		<t>The SVT JOSE header must contain one of the following header
		parameters in accordance with <xref target="RFC7515"/> for storing
		a reference to the public key used to verify the signature on the
		SVT:</t>


	<t><list style="symbols">	<dl>
	<t>"x5c" -- Holds an X.509 certificate <xref target="RFC5280"/> or a chain of	<dt>"x5c":
	certificates. The certificate holding the public key that verifies the signature	</dt>
	on the SVT MUST be the first certificate in the chain.</t>	<dd>Holds an X.509 certificate <xref target="RFC5280"/> or a chain
	<t>"kid" -- A key identifier holding the Base64 encoded hash value of the cert	of certificates. The certificate holding the public key that
	ificate that can verify the signature on the SVT. The hash algorithm MUST be the	verifies the signature on the SVT <bcp14>MUST</bcp14> be the first
	same hash algorithm used when signing the SVT as specified by the <spanx style=	certificate in the chain.
	"verb">alg</spanx> header parameter.</t>	</dd>
	</list></t>


	</section>	<dt>"kid":
	</section>	</dt>
	</section>	<dd>A key identifier holding the Base64-encoded hash value of the
	<section anchor="schema-appendix"><name>Appendix: Schemas</name>	certificate that can verify the signature on the SVT. The hash
		algorithm <bcp14>MUST</bcp14> be the same hash algorithm used when
		signing the SVT as specified by the "<tt>alg</tt>" Header Parameter.
		</dd>


	<section anchor="concise-data-definition-language-cddl"><name>Concise Data Defin ition Language (CDDL)</name>	</dl>


	<t>The following informative CDDL <xref target="RFC8610"/> express the structure	</section>
	of an SVT token:</t>	</section>
		</section>


	<figure><artwork><![CDATA[	<section anchor="schema-appendix">
		<name>Schemas</name>
		<section anchor="concise-data-definition-language-cddl">
		<name>Concise Data Definition Language (CDDL)</name>
		<t>The following informative CDDL <xref target="RFC8610"/> expresses the
		structure of an SVT token:</t>
		<sourcecode type="cddl"><![CDATA[
	svt = {	svt = {
	jti: text	jti: text
	iss: text	iss: text
	iat: uint	iat: uint
	? aud: text / [* text]	? aud: text / [* text]
	? exp: uint	? exp: uint
	sig_val_claims: SigValClaims	sig_val_claims: SigValClaims
	}	}

	SigValClaims = {	SigValClaims = {

	skipping to change at line 1020 ¶	skipping to change at line 1463 ¶
	? hash: binary-value / null	? hash: binary-value / null
	? val: [* PolicyValidation]	? val: [* PolicyValidation]
	? ext: Extension	? ext: Extension
	}	}

	Extension = {	Extension = {
	+ text => text	+ text => text
	} / null	} / null

	binary-value = text ; base64 classic with padding	binary-value = text ; base64 classic with padding

	]]></artwork></figure>	]]></sourcecode>
		</section>
	</section>	<section anchor="json-schema">
	<section anchor="json-schema"><name>JSON Schema</name>	<name>JSON Schema</name>
		<t>The following informative JSON schema describes the syntax of the SVT
	<t>The following informative JSON schema describes the syntax of the SVT token p	token payload.</t>
	ayload.</t>	<sourcecode type="json"><![CDATA[

	<figure><artwork><![CDATA[
	{	{
	"$schema": "https://json-schema.org/draft/2020-12/schema",	"$schema": "https://json-schema.org/draft/2020-12/schema",
	"title": "Signature Validation Token JSON Schema",	"title": "Signature Validation Token JSON Schema",

	"description": "Schema defining the payload format for SVT",	"description": "Schema defining the payload format for SVTs",
	"type": "object",	"type": "object",
	"required": [	"required": [
	"jti",	"jti",
	"iss",	"iss",
	"iat",	"iat",
	"sig_val_claims"	"sig_val_claims"
	],	],
	"properties": {	"properties": {
	"jti": {	"jti": {
	"description": "JWT ID",	"description": "JWT ID",

	skipping to change at line 1299 ¶	skipping to change at line 1740 ¶
	"Extension": {	"Extension": {
	"description": "Extension map",	"description": "Extension map",
	"type": ["object","null"],	"type": ["object","null"],
	"required": [],	"required": [],
	"additionalProperties": {	"additionalProperties": {
	"type": "string"	"type": "string"
	}	}
	}	}
	}	}
	}	}

	]]></artwork></figure>	]]></sourcecode>
		</section>
	</section>	</section>
	</section>	<section anchor="appendix-examples">
	<section anchor="appendix-examples"><name>Appendix: Examples</name>	<name>Examples</name>
		<t>The following example illustrates a basic SVT according to this specifi
	<t>The following example illustrates a basic SVT according to this specification	cation
	issued for a signed PDF document.</t>	issued for a signed PDF document.</t>

		<t>Note: Line breaks in the decoded example are inserted for readability.
	<t>Note: Line breaks in the decoded example are inserted for readablilty. Line	Line
	breaks are not allowed in valid JSON data.</t>	breaks are not allowed in valid JSON data.</t>

		<t>Signature validation token JWT:</t>
	<t>Signature validation token JWT:</t>	<sourcecode><![CDATA[

	<figure><artwork><![CDATA[
	eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG	eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
	QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9	QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
	PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l	PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
	eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv	eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
	bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx	bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
	Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6	Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
	eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi	eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
	Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv	Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv
	bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp	bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp
	Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht	Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht

	skipping to change at line 1352 ¶	skipping to change at line 1789 ¶
	aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu	aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu
	YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX	YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX
	mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN	mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN
	n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_	n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_
	3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM	3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM
	rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk	rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk
	kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY	kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY
	Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A	Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A
	qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc	qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc
	Cr0hUK_kvREqjD2Z	Cr0hUK_kvREqjD2Z

	]]></artwork></figure>	]]></sourcecode>
		<t>Decoded JWT Header:</t>
	<t>Decoded JWT Header:</t>	<sourcecode><![CDATA[

	<figure><artwork><![CDATA[
	{	{
	"kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov	"kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
	1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",	1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
	"typ":"JWT",	"typ":"JWT",
	"alg":"RS512"	"alg":"RS512"
	}	}

	]]></artwork></figure>	]]></sourcecode>
		<t>Decoded JWT Claims:</t>
	<t>Decoded JWT Claims:</t>	<sourcecode><![CDATA[

	<figure><artwork><![CDATA[
	{	{
	"aud" : "http://example.com/audience1",	"aud" : "http://example.com/audience1",
	"iss" : "https://swedenconnect.se/validator",	"iss" : "https://swedenconnect.se/validator",
	"iat" : 1603458421,	"iat" : 1603458421,
	"jti" : "4d1396f1ff728f40d52403b61c574486",	"jti" : "4d1396f1ff728f40d52403b61c574486",
	"sig_val_claims" : {	"sig_val_claims" : {
	"sig" : [ {	"sig" : [ {
	"ext" : null,	"ext" : null,
	"sig_val" : [ {	"sig_val" : [ {
	"msg" : "OK",	"msg" : "OK",

	skipping to change at line 1416 ¶	skipping to change at line 1849 ¶
	pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="	pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
	} ],	} ],
	"time_val" : [ ]	"time_val" : [ ]
	} ],	} ],
	"ext" : null,	"ext" : null,
	"ver" : "1.0",	"ver" : "1.0",
	"profile" : "XML",	"profile" : "XML",
	"hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"	"hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
	}	}
	}	}

	]]></artwork></figure>	]]></sourcecode>
		</section>
	</section>

	</back>	</back>


	<!-- ##markdown-source:
	H4sIACq3gmIAA+19aVfrSLLgd/0KHe47b+6dxsYLe7/qHsAGzGLAK1DdUyNL
	MhbIkq8kG0yd+377REQuypRlA7duVfecqeqlsKTMjIyMPSMjC4WCkXiJ7+6b
	be8hsJJp5Jo9y/ccK/HCwOyET25gOKEdWGP4xomsYVKIrSBx4zgMCvEsKZR2
	DfgYXlZKlUqhtFUo7xg2PHgIo/m+6QXD0Iing7EXx9BhZz5x8aHjTlz4vyAx
	DG8S7ZtJNI2TSqm0V6oYVuRaAI5rTyMvmRtP7vw5jJx9swGjRoGbFGoIhWHE
	iRU4v1h+GECXQWhMvH3z5yS01804jJLIHcbw13yMf/zTMKxpMgqjfcMsGCb8
	4wUxjFE022Iu9JTNsp24QyvIvAqjBwChFru22Q79KWInNg8O6Z01GETubOE1
	vYsBEjfZN4/DKH4KvOAhHswDs+G4vF8b5rhvXkwDh/0MHYBgrVKpmjulNf5o
	GiSIy3adfrtjy/P3oeP4f1mWVYAhi3Y4NrSZtYrmaTiNfXeuzKs1jWPtMc2p
	5z14vkT3unlxcaRNSn+vzWmrvG3CYgRuPPN83zVboeUokzqF5XLCYN3sHShz
	q5TKOyV9Yt22OrERg/B/zXBgObsgjMZAkzMXltBsHR9VyuU9/me1XNmSf26X
	xZ/bmzv8z61SVXywW97ZFE8ruyXx5/ZWhf+5vVcVPexslbfSP3fTP2ngeqfd
	qJb3yqVKgRqYJmekNXxjFsy679pJFAaenfJWbALNAiUPIwuQOLXZs8/1duPL
	X83rKLRdh54Mw8g8Aj4gJsQmCk+GQ/PAqbfNGuAnsXylc+jCihKzvL+sLSMo
	yQqmJAIEmX4LVi5vAyuzxXYjz42Rj0ULmuAaTrRpAgZMQoE5KxfhPzjC7eVF
	rd04KWfQAo8VIdOeB4n1QvDRvEE8BA9mz41QTJi8pyysBf5vTuW1olkHPPrW
	kytfMFKvhYHlO9m3meZnRbPlWg9+tvFZGLuTkf5ucWRg8zA7qjXzHPVFptUx
	cKUXxfYo0+44ch3Asv2kv860viyazTlQDXCD3vzSegimceZlpnEH5hoCkn03
	yrTujMKxFWffZpqfF807b5ppee76My+QLyTpVAulzUK5vIx6+tUjJB5Y9Qkg
	2gE8A4OPQR1IEm20r65rxxWdfGqhPYWvEnNsBdaDS38WCuY1yHprAMLHEe+H
	JCnoHXJDZd+EzsxKsbSU+mE8fQY7hdLOMvDhYwS/CtqqVKgQvR/U6u2MCPgo
	798SSzucpeMclj6cer6DPDLwQ/uJdcZaDazY9b3AVZp9jNE338voVZ3Rr3/A
	xK+/a+LXf/DEN/WJH/2AiR9918SP/uCJV9SJG/iproZ3t8ugRI0CcJs1gEla
	NlhmCi5SAM2RNXNNy/S9sZcA2/ve0I0nYGc9e8nIhA8m0MhMQjMZuYDVsWtO
	ALzQgd/AzfBwDmZlYA5cc8b0GfSBGHFcMAvHgAwHG8NrxAHIAc8ugmxzV9i1
	5ud2r/PFcNwhtQZRloy82ERAvKFnsy8nUQhCHcB38V+B7TJ4rBiQl8QELMED
	Fg9qZisw3JzZc1B6HRMG4F065mAO+CDTF+dCS0cm2PPIs0fKEFZiWOYEqMKz
	p74Vpd2azyC546mN6nM49f25ihvbBrMZyQfQIuY4SU0M6tSGESycOOC7aB4E
	c3M4pY5nmr1BU86bl8mXJIZP46FHczJEWxyazxrXOJwC2mCEwGVLZflxKOGl
	L2H6Dx4o7vyhwsjAjwAtoe3RFAXz4CzYirlxkcaLp5NJiMjL6ynGpT66bK+j
	pbJuoHZAQjprXzWlFomLjKjHnuOAEWB8QvcjCh1gYsTJr588/Pnto7QeuQ8W
	W5RnoFGiajNL1cZbVH2JWBwCp4FLAdrwyTU90IohoMjxhkOkEeIj0WEuQcZm
	OHMjvu7gm5juizWegCSDaZsdTpKS3dGQHOD6ZckdfyvYB5M+QHoSS4/DudH/
	AJKfDnwYHnw5ZIAgBEqYgbGPirv45oBEH4gUkgoCcRkuAHRMLeQAG01f7Ctn
	nAP/AVlsNI7NacxQyz6nDnOpbmwBxYYmeJkPgK8BTTEG7gWTDeSnjZ8w8cSg
	A5worINAYwfwGtxQXCGtKwkbEmQcDpNn8H2BWAaRhYIZIW670cwD9gauQSa3
	orm6tBk8WNoAae9LAaQRGKvgkkkRByIF5Q9oG4231s2ro/Y1yWpAAv4+al3A
	/4eMkMAhH0+QcVDW2SNYDRcAiRWAuTgBgs/FtRfgakDHhiTOdcKhOwPSZ8uL
	pA4YjT2g1jkiEf4IwXnAeeJAoDOGhHBDoQ/UMBbMCrnDQxvRhx59AiWOp+DB
	2kAeRv3FiwkPFFkAPsUAAscE4o/8OmZy/forGX3fvqFEHXowNnpsIE4MhcPg
	I+EJffu2zppf8+bXOc1REKXNjV9/5XYwNkYsUAdHvIOjnA5ApukdcNcWPuNC
	RlC9+5K4yFCCKhBDQINc8SzId0NRK4yW7DBOEH/4JZEHIBXMeJAgLygaWEde
	MAv9GWAiBlGFiIVZqNpBbWyNMRoQY58IXERqQNAjfG/JpYjcWciVMz5fVxaa
	5sLIkDBmRfbIgwHVF5w+c82CJDULzNVmQQJiF8YwhPZOYVBIfcIcWwQa0OgF
	E9KAqIVdUO2IGClPWQN4DsLbwLXMqDqFyQP2C/UfV1apdaHaDKZqM+QqgVXm
	Q75tolkVRq5VYaZWhSa4EUjw99SPL7vtDjK9P3VQYLhg5BrC2tNEcAIrL/VJ
	Ou913sjMabRgK4JhIr5A8FWthSDm9ZT9bgLoVR8YEwsEi7J+jOMqu6Vv34rG
	4nQP7pjRo09ZXWYuqRRbj5bAnISgPueCBRiSYIKwGu6Eub8anOxrBRr2N4bE
	4G9cdSEIPJB/rhSXpKtXYUYfM8U2H1H2rCAbBDkbvFzZQrQYV8yIluYwgaAT
	nKEYw9YPMUrNVOwYfOz15VZp5Bbeb5jClA5iMRmBV8Hii9xthgNkDvxsFIXT
	B1jQCagy0r9cARlSAZFYz5Mt66gIYTwmc5EZuGmAK0Z2Dww38S3bFTERRjyp
	ajMYFQpTjZSLPi7aESaaoeokfI9JhAGo6KKBs3ZCcxQ+u6ixyezF3iZhgsYq
	aWxQzx56jKY7HJKLh+sm1bjUAPAl2FRTTht8OQzCjdAsBFEhC5EiUblsdu1R
	4H2dusvRZ3hkhegUSBoDxvPYEuYIHJOxgGtFABQg64HM0Shjhy36qYLQuFuC
	1Au8Da1Xab0i6SkgKHyLkOqWpINBBcCcryNOUcLQLCVkzjShD8xFWhHAynUM
	hH6EAQUfMSSQbJpEoE+BK8CS5yo2NanJUeXOLZrJQ669cREsaTeT5FD8+yJ4
	VuTNrJtjYA8PoMfBY9VkMWA5QqCeyHwgcz1S7DbVewFTNOCgh1PfweYTctpS
	0crw3mofGMpU1tHmcQFChzoQ9iLiBrjS970JYNoEY3/GDVILbYJI+/rrFIh4
	OjZia+guhnVSPDHpAPwBrGA9gCQA8W45M5wLOaa4gFMyjybAVRHZTHY0B5EL
	xDEnOKyJNfB8YCp0d4+nERLFOjPmFhQ2YtFyHPyfh0SAGwaAXcNjThSXrFOK
	vg9h+XOWWDFpddMR3VrhVMDvdeQq6acU0WmuoYXgsc2yXz+BvRB/Y+SFniBu
	68XmGloBa+vs32bziv5u1W+6jVa9hn+3Tw8uLuQf4ov26VX3At4b/K+05dHV
	5WW9WWON4amZeQRqeI2t4trVdadx1Ty4WBNWnpFyeuRyz9vDfUcQMITXGOzC
	2I68AbMMD4+u/zMYxJO/ljeZlsNtKaFuca/p2zcDHVY2Xhj4c5P9JM8fhA2I
	EuwHuBiXFWkGnA60ykCkBiYyO/EjCCkJGUoEWrrQ98Nnj8vomDz3NmPVGtrL
	hQKZhWQ72+hQCSWrWBfLYlUkFM1kPmECxnC/TtGOxuF1yYgOPz5FV0qxy3C2
	IOJBBaFgDnigjEARFhY3OAi9gcNELj4ieRCHY1Tj5GMKu9/jj3EfKSXJdU1O
	wwBC+jJh6OMEueyLUUcB/RMYw8h6oEAPSHMb448gXVBaEY40cU4AIcAID/YD
	Ptk68wk8ZV4KivHZ2uE8cVsWOMBriHBrjAEd08uELgzHI/CQX3CYs35b73oa
	AFAhomdizf3QYnM0Pw+YEsBA8PbmNAKtgZ8BMXwpKnSAMMScEGIWHyC/gmIl
	ACm+hQml6/KMymxkxSOuDjle2ZyMFVKNoB+jU8hXTUwCbRFlTIVA180B2l5G
	ZpFSs99NrBQybjPH6UrF5meE9IuIQ6m0DzbyM8htRjbZmJKisogrUXwyHMDr
	gFmBmeXHQCETEHxdgMiQa0C3vsKYbOgGjIQcxVyyBsUY2W6F5thrC2zU6q2C
	WGLWzUGSgHyZJuQ3812DfOLgagRajlzLYbpC0InBqJymvhAOJvGE29tkkPd5
	RA3lCkoSohMyZEncZdxgtlS6BGMq0OASjFAy9KIY4ywweESqYEUc/tdP8SwB
	xfBp5VfH00AEXzHvZMh/Qru3QvxkKPOwoObXxiy6RitOnrMhQw5IitIzzncz
	FMuK6U/LRKIrCJSh5qaRQNElo/nKGEHqwg+8wFkSGECDWHmhhgWYGJQ6QuPb
	TPAgG7Pl7MPEcZEpGwtVS0xOBHNNUGfM9QCbvu+RNZUNYfOCT8CpbqlXpcb4
	+Yeo5NAtg669RHWRmS0UPkTWZASrofAymZkx81p4xI7s+yR2/eFCPKAorVwQ
	/57LgjEwc0AZroBwi1Ilq8oRdExkQCiXOEgbH4D4Rj/ERJpK0uARx/gSZ1JR
	2xQ/FmJQX9OVjXN9eSbgATNKMC+mhSX3I5fCcbE51LLztE+iXwyByK6F+7sQ
	oM5CQ70dBJzt0o02LQwtnPzFaD8DzHXWczYIiDQVwKkB+Bq4fKKFEpWRIKeE
	nYeLdck7QNR2KI3eRRy9a1ZZoBF/FDPV5woE+RSgJQgAknNNIYJVs1ARrw9B
	Pia2BiCWz0bZG0gdQcsbk+0v/NfcyAAtFWezIXNKuLNA6oPbjdzhGMzTsIfO
	Z7iJnLgP4NsQDx3OuXAVmy0pw5PWIVDQEYGxXNxCBkeKGdkyhMclQZF3B9IF
	HX51e5JbU2CxDjAZhRwxPh4IFQqzyE0f92XiRSg/oLerCXOpfPAgB3NTdMv8
	WO7I7nNAcW8ODRfN/mC+IDnM6MMHDkGPXiDZmoHqN6JwilCp4cqsVpU8uYop
	yph+fEtXE+djRZHHtLrFNj777kCozLM+qExd9QuDYY8Mhk8wOplZmM4Za8MU
	nISPxD0DMjBtnygIR2NBF7QwuPyEAdgC62TALD/snzk2CW0ggClL0MrRSU+z
	d4z+2AYkBdytaOABMUVzhk3wQ3ggijcA2p0yQXRIZvShh3b4B8aA56ylKSw4
	NKlh3MgizTVgHeJUiukkrqJuq/G9M+FfoKoLTOxn6TqJNALuSoMlyiac3aMF
	8xvoxh5ZmLsBLPt5bX/ti9h0xiEI9A+DvBI26hLzeXGfMrfbYDoe4Bag3q1Z
	rRQAE0IVerwHNq/Pwygcm4XK/66WEXz8d6HM3KGLcBntLBlne/Md42xX2Tjb
	VTFOE0yfyLNrKHc/MhxT9m+tJLf6eR/k0GLICiwfBKi8t1MqlMrw306ptE//
	vTe7nSOwQRLPZ3pFchw+R+2wwfZYYZpsg853rYnolnFGGMKzIH82A/5Snw4I
	SN+zAXsMXahYoikJ0qHlx4zhrgaPIKr/00/+euSDsvzPh+SvOMQBGySkt+Yo
	ZOlPlpAf/DmZmza2e2OT7nPsuoBIRTpRR9++sdW6tCYIAc4mHwCS25jrWGBT
	mVjg1CgRX/bUI3pPYdMxTbjibj/4wky16jFLDgeTDgQJdpkPibkICcaO6Clz
	3BACHJN1xywSEkjp9KSAUoxYKW9XOH1Fsm2osUfrDJZHvBT7oBDjr1MEaQCi
	5clN4sy8//Ezg/Ef/8QTASzFgEk7Dl5bkdMxM1n+8XNKOrXQPrXiEWJsaRf8
	G47HmHMpYCzFRoA/iYSVcBX2McA/uZaAj4l2RLSXGsn1V8Jj7L1sTY24ylyh
	sEHlmkeMyDVtyug1Vd0UI+WcxsKJ2DJVr7oOxb0a0p6PiccmzDGaLjaLrSC5
	rWFPjdoa5iihlYi2DptybugApbjZoLZKfDW114XLg7tCwMc4wghW3gEKGaPL
	xwCRGE9zQ8xyZZeE7zTQxS+uQQ4O3BRygewCWmKmOmOmc3OmHZhrDdz9iT4w
	b0Uea7o54+wxGZ1udOIoPLbKCIcHruWmmZSXXH1icA+DxhRZHdNsnxUPUPS4
	DCtiXgpWWFr0gaanViDFMQ+S78CLEAwyOLqYveWxDVP0zNjm2xvTYJCkM7Gm
	DpuJkCG0wCAF0tnQptPbq38wdTz0iD5E98iOFm/IP/Z0uYOgAwSUlZcSBAgx
	/mPOQgrcO4qAKyaesJaFv2LWMTKtkBMmEIj2FHEJHsDHwN+0UW4+ROF0Qn4e
	PvIwuMt23sZjdEXZHr3lhBMZCFtoATw9ZIIFZyAFnExZBb5EKNjGGnuE2S0C
	lnx8824CwK7lsKwrDVlMwGOM0/ansRIhUVaHYxmZgfswYvOGCAJo7r2kXUcH
	jgtfIMnfg8BjkbWHj3m6nCe27DCmRtEX8og9mTqQZu6pCcKL8gNRD/QSY4Tc
	IjNexJPSiREokjCFOofu/NAG6UukQKvddimDjqcQUFuwUkBlu6BD8lZkAXtv
	LAzI8F9gfX/hOorWKFXhoBJTXUimT2bNpFWZGzzlnbJ8KY5JFnKQGag8o0Fd
	5LNOX7RkaQzLZE8GdiF+miEm0h8EqzOu8hLBKEQGHB9h+ljAkqUAQgxrLuRK
	wXRwV9wMKLMC/DPKpaT0DnrC4hAxHvSj5It1tjvGdjMsyqaPDUUBiW0032Ob
	x3NCG5nk0r6OZEScSDBmoWdJram5aIh8BAaFaQ1pU15mfvHUfRyeHAwxuCUH
	4LZrgBkJSrKBMZ08RJYjxgvcZwa8koLAdqlzEhBSM0uxrxitmeRmoG3lPaTr
	UgCrsECOBDexMgsubSsMr8Vik0k9isc6py6IinLeGtz8wR3eaZyAp8Z6F4kE
	+T0KstcNOrmRyIIiM+Y955h10q4SfDBjB+s4YaUbkkTzJM3p8zQuyBssse2F
	sS1FFBPxa+ViaY3YXqSlrrDBFmAk/4ZMQNGamIpJL4rBYRow5RIwlOA2E9Ks
	8GEEUyNegzmTBDSJSeihbuWpafk22VKc0Hxwp/EXJDU2ozx7QuhptmjYQAne
	yXRzyu5w00+458YTcKXqR2rEQVTtz8FCyZQNFOCp1W/fKFjJOmkcNA+4zMMI
	VKoAFhfzXfMHzhAGlya9mUzmLlgGIw/ezM3bf033H/JPJmSsg9RtEk4c2ihi
	DVcrCBl0HwpjDCCTwl3ZOgtYGoAWeZcEKqyl2EUkJe4CSMD7uNdpYU50sPg6
	F6NAnQyji+5/Bo/yCJKSw8NJXTMlhNUoyV7wAwpax0mTtx0vtiNX3YpKueGv
	IplvXeEf3hFNg7EeMZjKkQpFpvxLvS8Ly/CPYgzHZA0NjR51k0L3pLnTvCjl
	2fs8Cb+YjrFcqGuCX1tTgwv9Ts67lCgXlyk3G1Ej0wxx8lSa92kEVGCRO8wx
	s1oibWKllSWTKzS2VX0WyjLDHLpkIWPoTQnyCw6bwpcVJa6D0UUN0EWhoofF
	uYhQckIAxWoiiNyZ1HdP+Qzy058WeDkD2CquZnudv6AdlLcQR/B85UqoM1m2
	kUtJK3LnSVkzZqKl53netVObbnuuRMo7VxgPWyws7jV5nrqh/+6VxcSHWM8M
	0nZ33zjnmFnOLCir1hJN1/wJoefzXdMhv0wDX0xQBs6yzIVmgtj25R6DErNV
	PE8uzCYw1Y/IU1UTHVz/KE20KCK+Vy01/p9SS6mQWKqZJL/muh8oNPIUVEbB
	LCinrHTK6KcF4SWXUhX0QiikJ27kyIa+B6N5g6skB6NPTc5QPJeKyfBlXiB5
	5k1gSzWR8YO60HNWxbxV9lSMbMAZG3EpHX+Es3BByconQLRd5qXgKG6BqeNn
	WRLa9J3iefAjYNEyS9+G7x2QCYMuq2WXm3augxCv5iNpanwPMy3R+Fmbb4ld
	sJK1Vulb5STjcosGtIFIbV3CVuRD+36a1otJq7n2z/eamdKyeYu3VIMyZTJx
	vpGahZGekJ1NpP6tVskHaV53zHVQfyhkSPYL1kg+zbPIPQC0LGD1cSJfYgep
	FL7MVMol7/S0vjjlNmQJJ8LFkWdhVXONVMiQVAib4wfpEBq9ucun9bS4N8d3
	RR5waWVOzJvJkGra7psUGLnxu7hFx96H4RBqU40TQT9r1wftNjv5cnzQuIC/
	kOXWGs1avVNvXTaaB536mrrpP8CTo2p1M7bj9eY0x/HDO4XCGE8IPbjiKI3A
	Opv7n7brv8R21V2aJYII/QyYx4IYkp7Sh+VQZthFKZT5QLdC3yuK1KIDWh4u
	pd6yZF2RxJZrkGr+l3KqfoUHVs+Oox6owjMIomJGznYjljH89o3Ox7D9HEqE
	pH1a0StuvoiCDunuCvDjzMP6iXNxqBXJUO6PafrpDdy+TwLTzN7aeNW6Eqnb
	6kbXasFCHb1bzOv2vLBQecZadvHfNT4mk/y24dkWvdiFpnWhx98FzbvdmsV8
	lKx3swjAh4TvbzOt9Ixz3A1YgOYjwPyOkaeEi7gUQvX4eV78Kbv3y0NRf2q2
	P1izMd2mRV2XqDaMlYKzkmdhawHdD2s4ffBFBZf3XnX/ZG7NbXGrtKef3MIt
	d3psLIZ6YUk80h1gz6WnUCjjW+lCuGDaR8ikhgIC6g+1DpSpHvXAjJJEJIGu
	dIrIuDfebdz/QLEv58JQTo+X7KzylkrOVmoYY07MemakNNNXHLajqbMYNJLs
	OlsmfTP3nX7DUE9ye6fk4rmVKTp1GZXHiMKj1RGTiZ2vgrajrWSmHyZV+Fi0
	tvYIs0T4CXWcZ+5EMocrFhgg1gruZA6nifpCaqoap1HABa5cYjGzj7JKmJp2
	hKpWj6qxuohycir7jLE4Dx6UEOXH8guzhdww5NaZ1gWHiSZdlLiRobqVCFKz
	DDPI0pILKNeGNrgV/evJAB9VW7NyBIxaQWjp0T6uSX4/9P+B+GdsyTbXTFGQ
	QtrZ08CnEIbvizPy2nyRyDlHvEMapolkvl7BUq1FkJ6M0rgJs9ZouEWWKBrX
	XFUuUaiYvslYESZCJWfoTJT0MJRSjZzmYMi/GlLRg/tuPWLmmDiOzSRm7Kpw
	a/PhVQAeca3odC//jM4yp8PxegBYf0k5FkcLOWVaUSQIpTujIgU9EWVxDCwH
	GCUWr3lECgZT9VVo+Rk06e0pcOdNnkAypJGFLTDxksKvMhs3c4iaBbVhkLOr
	dt08ZafzWWb/Yxi7BXZeX0nsx1QzLf9QV43UDT/kr8h1T5ifWD2GGMlo81IK
	WwiSkrsqVCqTKYu6R2ahq4fjKLV+zfw8nUwwBxEkDDs5Y/kPOf1kMqAWk58Q
	O9KChJ55InV6wnFRJafqVTkTtctSnWSekzzAmNpiVC8xoLPiiA2l8GdLJEX9
	42dWGIfE6z/+yYBJx9M2YNVULgEagxbTabl1nflOA128ZzlkKc7SXZXFQKuS
	E7YkE1VQD6cMjYAslZjJBMkkCiivczYnFoQnpQgt0JtWSoIlrEu7B2OK4DxM
	xRkh1YpfZ8ByQcS48OvUi1xWkwV5FyQOveDw47+U3YRYVARJ0UtIoFoTUgT+
	+kkOaRh1keHlqhW91AJHzHB59kjAz9zUoxPqg9KuRc0btGZ5eS5RWkY/icMO
	HatIYbOmUM3YC7zxdMwH2Ben63Mi1KwpMd4p4iRUVzLdkquxLQpZj0fKI6VQ
	ZH4f4Vu6SmaF5u3+6eUHFnrXVIGSnELmiD4YFtDSuxGVElNapSxlfXdMfalh
	vmD2Ry75QDmDpXl+HCiZ5cePMmCFQBjrmXchKotR2Tp+Dl4WLFtSYpkjCNWW
	sgQHKTWIipAKEdTF8Uk1pgn/HTGM8EIG+emO6YmhQKKAY9JKEsSB0H3h0iK8
	vGKeTjWfeCkv15G8lbX5BaOptj4ux8EEr/rxXhSDRHRM8/31V4t/UXgZ+wXe
	DSgsKvTER9O/mzhD9Tssr5P73eNzrH531m/L74wrWlRZ7ls1i1jIVc6H7AR8
	ndZaBNlGN1YQsqawJIB2l1tBol226I1WkYIdIoSVUIvXaBs76lJa6fEEHlBh
	Q8WJO0FfuVw0L0KWGoYbw7LuM5XRS38KgygrAtnRBdp09t2ZajqtNl8reHzE
	ZyUdXVb8CSQk9ijNK1FBcEmJeipv4iZxVgEIztGqz8CI1SLDY86Gt66zVsmr
	VXIutbdFLo5QtZvK0NxuVOWumjjJnZxVtewpwcYV8xZNubum6HyZxSDA2FqO
	AcWMVSFjU5I+mOoXrhpou2heDaQlKoP2y6Q5GXy0kbIkrVunblH6NLWZ0wib
	gGBHx3iuwOO7tyJWyyq+zhftiSX0tKsPoW1N5HZK6vUlZRCu/vNV7QEditFo
	n0tvjjHBwuvZyeGK4rHiGOvseqwam0z7ILdJrTvtatE5rXwRsyaSjH8iw/85
	mScktsiqPhIFO0X5Rs8KLFali0KoZtPCSincnuYFkD/R6hXQU4sLkfvwjVcv
	5CfI5TEsRvprul0rDpORn6ceZFjLlCg54p/LAw4qpkCJCyeoXCqW88uXSC/g
	SJQpQdDprD90WhDFSwB80ywo891fgFn5oEb72eRxrLxPj1rQgS4aPsICeNG+
	2ai3T+hdW3PYxcVHn+Mv+1jNYMkJpm/k8Gn6FaBvXnXquNwwf9MFugphnGsM
	6bmiPnC2DVNOvOgWo2lszKpOMFOA+7PX0ovJpQQkF+7oFsjhid8ihlmytth3
	Ph0s9fSy7VdQiV4FbxlVLE6D03UhHw/7bCJ5r99LHzlNu5QwccEL3xMpgDlj
	LKejt6hologgxB9FOGgO8VsEF2ULkATWWGLi5ULczgDy2iNXU3xQ8Gd+IRwW
	xAv4XpzDFBXrshqHibs48VjBhpXl50hXGkteOqIiG3QnarBqpyRSP5ntAXgw
	C6yZZ/CNGAqAUV1ksN/l1idV1Q+cRWtGguBQsUyxyc87kBJebSZ0EN/U0cbQ
	NEDmRIGb2KivAmb5PltzMce0RjY/u+YDNdKZAzohrm7g0tZfKHfmhMFhKOft
	OPLCMZWGzVSmXoL1NBVYvDRUyPH0LAZ0sUa92A4XFXPtUejZPM6NdScIrjHQ
	vDy0KAhE2x9BCsaSa+K8PB7h9uInMm/imOt2eegWryZhh76FcaHES/JRk4Yg
	WQ33GRVVTYk0tUgMHnaIhVFNpcgisLKxXHr23gDarV0S1+Dn3wcuj+2llyIo
	qTEiSEUVCYRRSsSk0HbW1l6Xdda0i4BwE4NdzSEIUtjkMhM1YU7SJ/Pggcr8
	pDE6ye4WvingGwrgIK69dBNaxmR5IVTajhcltdPeqKYb7TS4eOzaJbeNlVIz
	lYtm2EZy2hNuBATCX8mrLmkt3iakRTipyBkt6cKdQSJubTkzLxabF7wwnQy1
	USXd9KB0GlkUQCoV7KAvcGrYqR8f753ghExO6pAK5NHVC67gbnHXDreLYw9P
	yrPcizzUiXp461wWMEDVgu2pe4nWW0p6y4vfIUFgVA+vCUpGYqZ60TtWx51h
	ER1JVpTPVQiB+AErLDgaEbElEZs7ykYHx5YspYe3fA0s+wn1k4hV7OtFpmW8
	5tdPubEKLm/EO3liOc1tQNzIMgsIp7gULS2ciiPqBbRFN/pWAD/aTydjoZMp
	Ggb7OSGzDAcrmSB6AW0aSh1cqdNXVOJHGCoXwSPkHIoha10BMvV+0PtnN6Hh
	BRtp2bI0rY4hJE5liFZQJ22SVuuGH9ogfA+BVZde6FmkyWVjxTk4Nz+7ASjs
	cOI6X9YlFlXPjgpv84+w0jZtvbL+5clgKsWmNBLx2M+Oi/E36Bu1U7q9ZQHb
	Bpg3Z8b82mgmaQBhInlBJ8VUI7MsHazIj4E9/SsxfWULQf8AM4qceJ9nSmFS
	kShcTRK5ySuVAcWLomXfhImshl6x07ovgvY4d7rlFyaKd8r++gkzapKQmEWs
	9TdecJroM+I619X6QHD71SNTvzGYfMoJGJ7G51GSTPY3Np6fn4vP1WIYPWzg
	bawbpb0NGMmBWf7j05cM27CCWuKKFmIYgQQ5BOLhfdApV4G9BSQYvEU3iT0C
	s1TeK1U3ZuVitVh5N4hYNSvexzyhmvcAPsybYK6siicB85xi/OxiPlsYBHiI
	PXY3wC3YKBdLG4BClG6TjSB+L5TQdJ+TAgPQ4FugHpVPlw6IqHDmBUgWghqy
	V2Py69RUOZXgdyIKv5BbgA0WGaEo/QMXRAkxzFKWEDwju0Ynh+eoyRnKlU6d
	NvLZVBZaqOQox0jtQZKhBfmCkA0LPJeu6LKBFFq75m3UA+/vGIEF7j80oTyU
	ZJlHQKM1zN0wVG7FY9L7XV0twBAz+bmksefGGUj07xcl3/IuM/KRpW1o8xDR
	Rp7UziLMlijkz6upKrkhq2a8LlW3EosWdjz1rFbyUG0U6oKqY+RoCSvrDjgh
	pWVwBW02nBTg9UxNqFjUquNWgPqtCCauQhqvg5VuWsLwDamMs+jiWTjaINjB
	AlqZb0ixdLJRY7EMMqFNXyRRDIplmjDnS5Rdlik7IsTL7Ss10zctKm/5YDw7
	8zQrS6sOj9NjydeYh69nRSym4CrhH7p9ytZRjmsUuZQQoNlfYJpbPPzccPLx
	M/ZiQg4zJ4mBhOMukSb8peweCLdflgQ4WFH94neIEm8h6TBVLantAGrlv//7
	v43/+juoCFGK6CeqLiQvOvlprds5Luyu/f1vxn+9xPsxtTPh+yDef4l/Wsu1
	EcobMAYbgl2YzcE6hknW3KEF/sxPa1/BlKR9APYJW7GmUOyy53fqT9YJgwte
	f7j53zAEjTMUGEQT46e1Zche4zd5o/X409qqZcHKtGvmhuyf3xxGBWtXj0Et
	/0YDEepJWPCQ6d/4+ASxzAnH3cyf1vBbyi5ak19tqJ/xLjfy+qSnCogANvuQ
	FvNvRC4yH4ZxiEzUEcY/K0C2rPKolpiEMl7s9KUXrqxsiylc4tILWf+eE2t6
	vYeaVJgpMISd5NQTj9UBYlHVty7vayZGUSUvyIOf1i7n8nfDIXwXi0XEo9R9
	HNv5ulMuUJ6W4pLmp7VPi6PwZqsIL/2M/ePOz0ru7YF35Z2d98o33sXR2WgA
	0Fas5n3a48Z7uvyvjTx4BV0tnyq9E2jRP+SkhTbZpRruYE6ybkL++gk9HREV
	KaCZS6SITg9qZVnPzmN34gpbSomWsBt4s+plycmuRT2NLrc9CnkEiAeeRcCe
	9vzEJccUy+Ox8TASty4+y7nxsyRyr1BpV6TZaA20+WSa8gp/dGUlV2roMivz
	x27eaU/GIilUAvROAzAt2y0qDnqxOLwAEzoO2VVk1FhUSIzCwTROAjde3KLN
	UdhC3oh43gi0rnpLqlo6XEGccoBCw0Sub45OlU5z2IssHY3kh1TH9ia5y67k
	0YBokOll7GseoSqkeWff5I1QzCGjdp6IcS5LVszkHq7xhmJLVwaoeV4pwLRW
	TMFLZVd6FIayF/iUpBeTFn3AcIySQJv2sAQgntAhAPrcXiyK8iUFMzVKhFdN
	nu6a56yJrPyGU0hNLS6itaVZxxCleqCDYMAAu+wjTb/X7XyGJREix5aDVQ31
	28gUhmCXkml88BkbML2y6AOn4dNRWjMLSJmCVCx+uAjnl6Khr6RIPVm6lq5D
	y5eu5rsXEv1/tFdFrFpmEWB/6try4hxyZWV8gGNHr8Kl+KsZX2YRg0yXLwy6
	IntbJyEiQr6M2klIujIjS1F6eHsV8IxQcqiEVQNhSy7Z3PlAz6K8q7iwB7tT
	O0qpj0tF3OmJrCBWDmWnVVozlxHSdoGgR7ZLxfeguEmkHlnRlodFw3r4ZpmS
	eANfGtFGdBRPbGApcU6FbqOCssmVkm/8QUGk5jtJos07CPiFE1tCtvpC2viy
	voQm4vp/jXbjWN2H9HTRmrzRS7yniLNoS+Je3qO0oPm0S7W4z6geR9ISxZje
	Y/WJIyIfQd3aORHugNPZMCQPdH3zD9QoAT51ClxG/s7zWAb/8vM/WnbVp8yh
	ECQu/VCIODzS5psi5+5ckaWpluebJoUnd54rStVTIzkB1THPR5CClU8qFVzv
	OXGiptGss3q8CbtMJnPigPayP3zmgMnMly2bhNopq6UcvHFWjZW9JzqCOWnH
	o7LH1OQtMxnw1ITAeCl0ksoIb3TlZc7ZMoIEKXXtidsPBzRG5o4MAcXSk3w5
	VGfKNNs38FhMFcLiURYph/OqFufdpUZXFGdPvv4faPh/FmiGZf6kO6vaZah5
	O6tqdvcP2VnFEf+YnVX9old59+v37Kyq7QCF6k9tiPS4fsz29MkZ9M3pxGFH
	tbXrmrVuRIpInFYL4wSmfTadKFdI2dMo0kAomuQsLKmtnIlAa/3y3BZ2IlNr
	ITNEuKv0ooYnEWqkd1QOKN4nTpoBoxRAYCknZLeQI4MpAwnbe6WTN2Aps/yp
	8QSr7AOj6CtF/cn8hsyiktOMO7+W/fRs4S3mGJkChYKeH7UkSgiHybOVCbdT
	+X8KRDOfWB8VaUFscTFiGHKFqUCgLBIrlZ3G2QjLKYbTEjNiDTK0wNov0g0P
	wbMC2zM6c5oLQ9pVUdvww75zNvyAtRX1RFPLpUw8bSF2yHO1ds6lzoFMcRM6
	WAGXC2KEU4/EpXaZ3MJHo0rzJFRrTnEkFqQsTkGYsJlScSxoIlIV9S2ZhcmL
	MEL6Wd6KZrRwo31lVnEXvFDZr5TKO6AP4RF0XKEtxY6aG5b2op4qVysPpV8w
	KvzcaXfQD/qCmKwHtjWJpyT1eISWrr7m6MdbrxXx0MloSo0Ul4/DKDMtT8KN
	aX1rlSeySvrHXAPZZZzupcLwdZVHOnJYih4KCl3WT0qyKad5GfjiqZeIwE8m
	4YTPaaHGmkR3cckAio/F6YgXLVGiOJ+vGrUvZrlYKe5sVYqw8sWtYsUw6pSy
	Swev3X3GzDyGLSQ46XZoXJTJuDxvl6fhNOqdYwUc/JJr4/QhS4m5OurUwVjt
	tBrNky/8tq80yMC16Vm/s64FvCkYT1s40tKRwe3MMGrMfGxFT+hzgoGCLqfc
	jpUrwZhdp6t4eY0tlM/szDgmEYj8DlonT43uLxqcbjpi9joGXpGCJKJu72jR
	OrR0FqJ1ymk2PVqn2EV/dLQOYBLROgRvRbSOpvTvFq07YHfxkbppyov7ft+Q
	XK3eknTN4kgHIrRDFMpCDigXRPRMYHZp9Ezg9l8QPXsT02pQa+UuGR7Fa9GR
	Bc2l0bnE8SgFF3MAl5SILkqZhpr761TUDeN3BcZSnZPopI1btQyKuNEV79GU
	jozY48Mb0T0w017I1mPZqayeKV3vGyH0Hw22ie09ffZFXTKHAQqWIL0LkffE
	hnxPfxlKWhHSksT0Z0jrz5DWbwxpNbmRoZVSYeuoaUyCn9WWp4pwK4ve1Ntt
	JJ9GDeGWP2YVpqSZmi1VxdmtTEwNqftjMTWhiz8SU/szgPZnAO0PCKBlOUuF
	Pt1PlyAsTE697gXBYBbuojO4WK2Tua1q9E6poaDG7NRKC78tZocDcK94Ys39
	0HLyr+MkZvk9Y3kCkDSC8K7Ind6Mqn3gIzwnQJmWqiBWunfcCb+1El0/PHUO
	1JjuqLFox7pGRbTYAkd07s1kY3EVqa0kqxtIrinHbt5JBqIOcXVexK4XUk6Z
	qYN99EQDALa+9PDCQsSGeYc4mW7ATzvB50y8swRXeslXMc4L1C251k20EKf8
	OInLyBV2K+NVQNbpCVOeVMZuv02DM8FcFRcCMmQ1XiQme8zR0q8TGa6KnQrE
	pFNRTwOS9BF4V0Ni7gudNZzxo5qCpOloVbqcekxVOtmCNZbE2Ii2VITy3LS2
	KHW0kA/EjwQvDPs/Yn7mm0u8hbR55Ywyt2yXnBFnC6YVVWNfKvG77CnrLzlH
	zVM5KY1b9SJCQQTxquXNRzGvjZXSkVp2kJItmPxChAsq6ixgRFYxYCeGJZKZ
	xYR4ptGW3q+eTU98jkBKk9BRUhVV/GVRtM6UGWJpfUl+5RKmFVZi/mtRIzAt
	xUTqAD8+ClmEvq0KRBR1eKhS8fww9s8iV5mdFBIUSolAxoL4lKoJaP1qJras
	oCsTOqIxjsSSYfxlXXwWl/gtivkvyg2dorchsGdCp1KX9afc9ZbaE/KO7lx5
	kXLll+KS3EVdUwELoQ7//yR1MTv5RaB1tud3yqo4YLqU1ADXNCoUucHuPEHC
	F0qCmM923MXRYNYiibh2C5FE1VbTIomKtfZHRxIBJhFJRPBWRBJpSv82kcQ3
	woS5WpVNWcm34/phQO7JNPILjssD3+l+uFjyL28FGdMwk75dmgvKZy4NpPvb
	CCao0JdY1jKjTzRZGpMUq/TvHZPMKXeKScC5Ljv8wluB4pg2c1mlrCKekSgz
	R8wV9fn0QqncNl4Tx9L5ohAPcrMZ9zTEKUTOLKLR2BUnnVNjyjQrK0cU9rcc
	UsgHNBrYK91iF9pf9peWRcfRqkV+sbVauU3YQ2mh28gcuuJ2QDkOny3zQhBm
	WSHXQZyPRQlN7F5eqZXTmIouTBOZvxfb4WTJzQBLI7CCJ1XUU9+MWz6jnYGm
	UsqG+v5Txmj6khFXq4Kqkhv+DKr+GVT9LUFVLcyYFiVkYbx862Cx2rQwCj4W
	CBWt/gyE/hkI/TcLhGYyCdMyE+wQYEGEHHmRwjCgcs1kNNTSDf0LK3iYYjW1
	z0e12sWXbB1bGfaYuSZ+wMhhd7uM5ACqM8IrANhGYTS1ZdRHcTv5mTxgIvMn
	81fQrI+Jt2/ioWL4Gzyg9G8r2TenXoB//920pg57Y26YP/9P+uuf9AIGlZ/F
	WvHBfW6TMz/A+EbVZOVvPvoMa8LxEbl1Ln/LkuTyCQywb/78l1Q9CRgSJceC
	j8RJgw3D7ex97bZh/lxUF5U9Z25O/Sf7TlVR+/rFOOnUqY/svU4MSHEN3T7i
	T7/cbMUsUuHHJvJ34Ca5EMHU9/nYiKt9rK5pRfMCcRG+GOQ95+jJ3g/L+qfJ
	KfhfbGvoKp41Q2W1L1XwhqbJRK+AGUY20MnC9Z2sm0noy9GBlPfl/ZDYpbgg
	ciN7PyShZRw/ZPGSh9LMrXJs2DVcmzVJxmwyOSyRh/y/56BJfStWPJ8oFgE0
	0qwtBhzDmvnT3xgU30TnhjbiT+wr9Z+/ciOS3fkE8p7U2ISFosS5UR7TIRG1
	StjQZ/wYO78ZU+gLVnJFOaPMwlvcui8yefMrnXJd+w/WBeCaTprH+xsbj3EY
	FNhjOgjvRNYw2aiUKqVCubLBv19nzRMv8XGh0sPfC5FTdUKimZOWtqTGYhoo
	dYVK5LY4D3KifoepyHHRcoWWzJ4VT0U9B3jzszwKvAbylH9AP4F+tJ9Wov6M
	F8q1muY/efcTeVQUBvhVH0B9kDdFjM82aspI2jT4OXf58lsG3rd6Z/erfVfv
	MP139e6YB8myAXh+TP4IoKjeHOFg6ngovJYM8LP2lN7wOa0vvqG42Zr2/J+Z
	br3EHRNSsyj6ljsD0KhvzqD+MvF4LVsqB/05dsHCdTDcgkLZnYT26Mt34S9D
	kW8B0s5zR3jbJcNrTCTf5jKTfDtbIDd6LOJ5Oa+k8ZD3EpOoVy7ZEt7T4Ml7
	kYeiHqsQkgMHfb2MbcQ/31bM+70gNLRotrkcbd8NUYru98J0qtvg3VbjR8KD
	K/zuBZIVR9PNkLdgYWy/5CPJ8Lmv6ZP/wEAH9PNp4z9AD21INlqc3ZIZUi9j
	L2jwscrvQgvYCO9GS2qIjK3Jsqlm5iHb5KyS9iQD3Fp6OOZaZb2h5ceuoXcB
	TVd+Dq8RFn2eqaBa289Mf7VgekMypSH8HAStqe7Fsg+00NeyTkC4ZjD6zyyY
	b4isFNCldLlctktzfwkZ5NFz2maxSR4968j6EJAiPruKKd/Huu/hXT5ZU+fe
	jDuVz8fLGPkNTl6KL412PoYyPfkx+ugCa07gR1YYKfk7KFCxLvjVF3/UOqdz
	zrpwf8Aai6DB+1GGDq6CrX8BmnQXexmS3oWAfx99tQDd+zSW1mxNk4q/gxqi
	cEsu4w1kKEb55/tUCHX0bnI85ecO9HgtxSzepMylThf7jLnq+CGLc7xbCg1+
	wxy4uqE7m/5VE/AWPdylsKcStFF7h5QXHrAEfQ1jTWv/zIFsJXt8J3csaNGF
	ef5GLllmY/0Q7viQEm5l94yUjeb3EtY76eVj1K4aVMsESh4wv4XKfzgt6ebJ
	Dxa11DoP0UgAv5WIOGjv1fa8DPvHbLl3rpwbTMckDFhYf10N6udJhGUoefds
	jvJm8T6O+O1WzPuQQp++g6Txn+81BH84NywYrj+YISahv4Qf4t/MD9j3uwmI
	TVTZcP7BkjRaBmYeMCuclx/GmXx7bF1sjq1ntsbey6bjeHm4bGFil26MJ1Z+
	hBGRB8u/rc3/PayXcYZ+tCbCfctcv3GZisLtnd+sothu6TuppafeW/km4S/s
	Tch/8v3j79KWie4jYzw8zLULNdA+Jiry9tGWAsY21ORxcgTvd4HpA44DxRFc
	PLxD98a+W6Iucv3vYqVKn0wF88Ow/WjP7EORmt6HtcK/LKL1/6PkTgfLTOkD
	M0kJT8j3PMLTpHzm1RLAF3C8SiIouOF/fjO+8QQQJWONF21fuDvdZc9Nz/en
	dIMqHZcFxvBsliOn5unnXOnDj9UsLaglT19dYCL2IHKtJ5lGK84gCBioIE7A
	b3LGHvFoDF6b6uPdItiBwTsQqbd09SbLaWd35VF+CL+JMddEY+krZ/0OT5Vz
	52eR1b/BCvDX9/2ts/PXm9dmfRLeBffj1slW6d6/ty9eR/NOdXTaLN1HTuB/
	vesm/fb4uG93/RPjxh/NrOP78KbfLd8/xZt3/a2Z83jcaT4+bNqPzsXd+Dg+
	r9xX7JPjxmU/3LT6Z0Gzc9a6CZ5eusf1PeO63YgbQWvLPmpsN54mt70j+A2N
	7ufw2z/rNDv1eSMoFQHSkcMgDZ3T1vOV/zy7PdrzDffkOLFPXvyLcXM26D3P
	7m57T1a/N72rdF8a3rNn3TZfG4+hZ522Svbp5TY0si+qzep9v+UPoI0xGG/5
	d9WbqV3pwYv70eDEf7q7bc1sDyHxRw5Adtm5e758vSlf1W7ml23oNGhNsNPm
	yc2Lcfn6VLl/PB7fP9rzq5O70uXJTfny8eb5stKoXPYvy83Xm9JV7Q7L679a
	fWfowPRuK834ru8nNkwTVwFe2N6Vn+w0xr1NHHEQ9OLB0bNnV/zgFqGCZ/1q
	7A1umwGO3CnF2KHvnt54xtV4qzw4eQZEnvk2Ie7wsFtuHrcQmcHhDBs3xqOS
	c3rA5l/xny6CpThoVpzj5xmOjKBe3EIHJ/6jC8h1Ti8B2cnEhfeXtbo37JVg
	gObEuC/vze/7d94VSAsCuTIa2ZUHXK6tu0rvpvf0cuaOW492Pd5qlvz7TmV0
	0u7fvQyCp+pVd5QY7W7TAxLabvd7Vmd8NnHHu1X7yTlzSqOrzuPhdr/ud9xu
	cmo9NSuD8d60UzlutSr3lzCdm8vqfd1w6o3Nq1P/olt2/P6JvUeENfafaO37
	N0nz9XLrquY/NmGdLmt3r83Hy8pdv1G+79hl+AuW8eSu2uzYpeajTUt15++F
	d7fNEDu4Ge/d9B5btzel+pZdOj6764++tl+PG3f9ybgVjCbnpeNt4+a1dd4q
	t8rQ/1bvtWn1KpNH96lV6/XONu9PLrf6/V7pvjsq3QEz9ca94L56uNmuh9Um
	Um25XjXa9c2X+3rrCbC91b51gutOyRu2GQ0Mxr05EI1vB62hPe6NG4+THVzu
	ew/oYt54Oa8cj4z2GEZ4dWAlXo6745de69g/tnrdUv/Jt6zjm1LX71Wsrt/q
	B72LZmX3pVW6v7jrtW66nfut80qyaSA2O0GrbgeHZbtXr/RP7udW6WHLKfv1
	9mvLdzuHW81jZ9556s0HgUDyQ6lbb23ePfYso10pb172e91u9bgCM7xvvY6C
	y1fAfa13DrL46Ly0FbS6o5NepxXcvfolu2s/WxWnYVWASl6BEjunk6h36lSd
	27Mzq3Z/f9U9Ht37k3u7fzl3/YO5Xe/O7VqrhbiBVarf185qzdvm0WXdv+72
	e02jN946vhknzWavDqvwVBl0zxqdwKnedc5Krj9q2vPk0qn27u9Kez3HP4zs
	wD/tPh6OunV7s/PqT4127+B1cHJWbT4lX7ud47B1Um5br/fbN6+jzcvx5On+
	tbTX8EtMap10kcQfrZPjyYDTiwHiipgCeAIFyei2ypcJ2JctXeiRZDo5frVI
	7N0/tqqH153KHcjHl0ejewpSpuvg3B5bla3LVqm12fUvy9aj8+o8lUp3t4fP
	l08Ppct+q97qviSXT81tQF+33zmYD8YtH+jg/tYa+1PnpNy6fLUr7f7LXa++
	d2g/Xr64t5N7N2hy4nqRRNTwmiC9WyA/SsAL/fpLs9N7uuqcefePIEpekS/q
	r3fjRvXu8a5y2bkBKQGsRNJasvpFd5wEd35YMbogIAbjUa/52Dzr9OPnVsXv
	3fsgXEqtrlO99/t9v3TfO46ckuO3g+Nas3u2DQvWvzo5a90Fh75xfwwf9pzz
	7unoxXkKn7v+02bzZFQddIC9gWHuXw8b9tMxaC3nwsEVCcoO0EPJ6pd9lJcG
	Ccxyee8WGOj+dlQChpk6/ZcYPqrc3zYA3MbLxeMBEtGzPd4bA+Z9XJl+vXyJ
	q2PQ8hzvgT5wZlKB1Cb2RRnkYNWpXgT268UYxB78vnw8eL7soUxsgfwcJYOT
	3tS4mzdfrRPortPwhrelYsc5PQob3fb9Y+X1stE8f9ipb24Wdnv1X8ZnX7c7
	J+Wr8Po5uGvHv4zm3cH01hhHF2eT6dPuSWvrLgoc92pqX3fvDp6vX06TX4bb
	u2eNm/lxxytZD1d7vbPHoNzauX6sniXb/ZO9yR3wQrB1cVqolcfWS61cvn95
	Gdh37ukgjhOn0p5XppdW9dCZwM8T53o+bo/t7ZOXu63pWXhRKmzNnsNfjKpf
	2DwcVC+OOt705e7aHr8m541BbV4Z1R/Oqqcv5fPN0+NS+/QhqDaCyddDd1Yd
	jSvti2cQcVuHR5dGNH8+PBid3tW3r07qJevqbPspOdjqXpceG43TofW855Wf
	G95ZctqxTqazZN5vXzxt2fFoPA32Tp+cJ+Op1TnY2Rq8Tr+WGnOn9HVU2ilF
	B7snj24h3uw8b768JsnDOQDSfprNd4Ot46+z174T389s/+ikMr4z7vaiy5fR
	LzvbpZ3mrf1iPR5cb85rV+F5M94KxnvVne6FW5odNXetnX4nOp4CWz5G853T
	0WvrcvNo68D4+jKoXR3eXl/Mw8to82uwedE6Ozp9uXIv7rfD6vRhVru66sfz
	x6eq63vzw+fadPfr2elOdzz37IuXmm0cRaVR9/yXp1mr/vWxVrln5mmNm3+Y
	zspODu2n6cR0ymR/7coNGn/ZrG6ejQazYS1Ihr1/bOxGVy8nO8cw20frvHdm
	9b42jg9vw1FvdOBuDc93rSCcpUZxub29uxvtnA8s/y/D2cQ6LT/ueoOHrcrN
	4bx8ffPTT2TUo4UNwwEo7KflP8DPVnurXFkT5rQKLzvmoMKLqakmz3ze39jg
	Nm3RDscbFs9ILbO+MXggvsQc6YW7uLi5Gkb8e3BW4fvydqm6ubW7WSnTU0wU
	xl42nXJ1b3tYHg53KrvDzZKzVdksVQfbZXtrZ3Nzd5v1kUn8NIWTwSrOgmci
	nQ7y8+AJujLCW5G5HdqXPLKIQFydq3nPOT3w8KqZJv0rbzAKrKBu2fVkAATA
	UGCXo28s+pRJXJg8eS8bpbJwkL6l8a/0MLaWbp0erobx57Z73btovDr25Hxv
	p3F3NTpuDMvBfGfvdNw4GrR7rw33vjnwXsOd6KTxvMQTP202S6+3jfb8/OTx
	aBaEwZV1czK82LiuzmrJ4e7u/Lzdd28fOOFxODxGPJ5T2Knu7e7Z20O7tF2F
	/1iDLXdnqzosl4Y7sKDbO1qC+SAF/jC87m32jw724oOGNXo8L59aj8PjF+8v
	B69Hm2cnnemwutcHe/fRfq0ddVsv+dA79t6dm7inif1y0nMfHiYvp2c7Wxv2
	zc5ps+zUHODvxjPCLjCs4lc/56nhmT/52Vwr/8WyztzkYSdy/XrL79bu6l53
	875xP+pstrozr3FzPz3fCcsnx+dW5/pme/6XPEifXjaum0ktmky/3mzfDqOn
	073nu9r5pjsvzTf7UbMeBc8ahtN/1kab17WXwdb9+fil7HbaX2e92d3J7kO1
	Gpe2zl6fD//SfKifHnc3H+y95OtJ6enhNBeCIZgz4cXrU+f5eRo1Rtt3ewfW
	8P7uq115va5M6pXJ5s0yCGpO5WgrPiw1rm7cy15QP3y63LrZ6+9tjw9Pm89g
	Diavt5fxXy6ep3f2VXd2/RTlQTA/aZWs65Pdq72gcV31B8/b54835VFt3Hra
	fj3afak8OrhSagyYn9Ldzx7hWVjKNFcvy/IiO06lQ0mEx/bJ5OpquOv59nVS
	KZ/ARO2T4OKk9gKi9HEnnl1uWpNJ5XQTaKl+Ma4cvdo5M3M7d6UKaPuzYf/R
	C5LxTXUHHLrbztVBVC3PX+9eY40C86D7RDcXF8plq7y15exVBsOtrR1gn3J1
	MNgZbG+XN3d27KGTO4nz1tPD4H77eiMYdberjcun0onXHXY3ap3nmXvnJe7N
	0/OJe/b1aOvwtdPs7Q5uBjmTmLhOpzPtn12/fJ2dlVp3u5uj5/GOe7fxUDqN
	Dq7ch/NnZRKKoJJZYYR5tq8i3y/KVspWR7Dxikr+SFbC2GfXXfHHaRq3Im2z
	t1SWNvEmaxC+n+KRReovjSj9X64MXzS09wAA


	</rfc>	</rfc>

End of changes. 198 change blocks.
	1501 lines changed or deleted	1415 lines changed or added
This html diff was produced by rfcdiff 1.48.