File: rfc9321.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3602 lines) | stat: -rw-r--r-- 179,831 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9321: Signature Validation Token</title>
<meta content="Stefan Santesson" name="author">
<meta content="Russ Housley" name="author">
<meta content="
       Electronic signatures have a limited lifespan with respect to the time period that they
can be validated and determined to be authentic. The Signature Validation Token (SVT)
defined in this specification provides evidence that asserts the validity of an
electronic signature. The SVT is provided by a trusted authority, which asserts that
a particular signature was successfully validated according to defined procedures at
a certain time. Any future validation of that electronic signature can be satisfied by
validating the SVT without any need to also validate the original electronic signature or
the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML,
PDF, and JSON documents. 
    " name="description">
<meta content="xml2rfc 3.15.0" name="generator">
<meta content="digital signature" name="keyword">
<meta content="electronic signature" name="keyword">
<meta content="long-term archive" name="keyword">
<meta content="9321" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.15.0
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9321.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  display: table;
  border: none;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  pre.breakable {
    break-inside: auto;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr {
  break-inside: avoid;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9321" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-santesson-svt-08" rel="prev">
  </head>
<body class="xml2rfc">
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9321</td>
<td class="center">Signature Validation Token</td>
<td class="right">October 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Santesson &amp; Housley</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9321" class="eref">9321</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-10" class="published">October 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Santesson</div>
<div class="org">IDsec Solutions</div>
</div>
<div class="author">
      <div class="author-name">R. Housley</div>
<div class="org">Vigil Security</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9321</h1>
<h1 id="title">Signature Validation Token</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Electronic signatures have a limited lifespan with respect to the time period that they
can be validated and determined to be authentic. The Signature Validation Token (SVT)
defined in this specification provides evidence that asserts the validity of an
electronic signature. The SVT is provided by a trusted authority, which asserts that
a particular signature was successfully validated according to defined procedures at
a certain time. Any future validation of that electronic signature can be satisfied by
validating the SVT without any need to also validate the original electronic signature or
the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS), XML,
PDF, and JSON documents.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9321">https://www.rfc-editor.org/info/rfc9321</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-definitions" class="internal xref">Definitions</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-signature-validation-token" class="internal xref">Signature Validation Token</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-signature-validation-token-" class="internal xref">Signature Validation Token Function</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-signature-validation-token-s" class="internal xref">Signature Validation Token Syntax</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="auto internal xref">3.2.1</a>.  <a href="#name-data-types" class="internal xref">Data Types</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.2">
                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="auto internal xref">3.2.2</a>.  <a href="#name-signature-validation-token-j" class="internal xref">Signature Validation Token JWT Claims</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.3">
                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="auto internal xref">3.2.3</a>.  <a href="#name-sigvalidation-object-class" class="internal xref">SigValidation Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.4">
                    <p id="section-toc.1-1.3.2.2.2.4.1"><a href="#section-3.2.4" class="auto internal xref">3.2.4</a>.  <a href="#name-signature-claims-object-cla" class="internal xref">Signature Claims Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.5">
                    <p id="section-toc.1-1.3.2.2.2.5.1"><a href="#section-3.2.5" class="auto internal xref">3.2.5</a>.  <a href="#name-sigreference-claims-object-" class="internal xref">SigReference Claims Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.6">
                    <p id="section-toc.1-1.3.2.2.2.6.1"><a href="#section-3.2.6" class="auto internal xref">3.2.6</a>.  <a href="#name-signeddatareference-claims-" class="internal xref">SignedDataReference Claims Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.7">
                    <p id="section-toc.1-1.3.2.2.2.7.1"><a href="#section-3.2.7" class="auto internal xref">3.2.7</a>.  <a href="#name-policyvalidation-claims-obj" class="internal xref">PolicyValidation Claims Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.8">
                    <p id="section-toc.1-1.3.2.2.2.8.1"><a href="#section-3.2.8" class="auto internal xref">3.2.8</a>.  <a href="#name-timevalidation-claims-objec" class="internal xref">TimeValidation Claims Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.9">
                    <p id="section-toc.1-1.3.2.2.2.9.1"><a href="#section-3.2.9" class="auto internal xref">3.2.9</a>.  <a href="#name-certreference-claims-object" class="internal xref">CertReference Claims Object Class</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.10">
                    <p id="section-toc.1-1.3.2.2.2.10.1"><a href="#section-3.2.10" class="auto internal xref">3.2.10</a>. <a href="#name-svt-jose-header" class="internal xref">SVT JOSE Header</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-profiles" class="internal xref">Profiles</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="auto internal xref">4.1</a>.  <a href="#name-defined-profiles" class="internal xref">Defined Profiles</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>.  <a href="#name-signature-verification-with" class="internal xref">Signature Verification with an SVT</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>.  <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="auto internal xref">6.1</a>.  <a href="#name-claim-names-registration" class="internal xref">Claim Names Registration</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.1">
                    <p id="section-toc.1-1.6.2.1.2.1.1"><a href="#section-6.1.1" class="auto internal xref">6.1.1</a>.  <a href="#name-registry-contents" class="internal xref">Registry Contents</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>.  <a href="#name-header-parameter-names-regi" class="internal xref">Header Parameter Names Registration</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2.2.1">
                    <p id="section-toc.1-1.6.2.2.2.1.1"><a href="#section-6.2.1" class="auto internal xref">6.2.1</a>.  <a href="#name-registry-contents-2" class="internal xref">Registry Contents</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref">7</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="auto internal xref">7.1</a>.  <a href="#name-level-of-reliance" class="internal xref">Level of Reliance</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="auto internal xref">7.2</a>.  <a href="#name-aging-algorithms" class="internal xref">Aging Algorithms</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref">8</a>.  <a href="#name-references" class="internal xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="auto internal xref">8.1</a>.  <a href="#name-normative-references" class="internal xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref">8.2</a>.  <a href="#name-informative-references" class="internal xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="auto internal xref">Appendix A</a>.  <a href="#name-xml-signature-profile" class="internal xref">XML Signature Profile</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#appendix-A.1" class="auto internal xref">A.1</a>.  <a href="#name-notation" class="internal xref">Notation</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1.2.1">
                    <p id="section-toc.1-1.9.2.1.2.1.1"><a href="#appendix-A.1.1" class="auto internal xref">A.1.1</a>.  <a href="#name-references-to-xml-elements-" class="internal xref">References to XML Elements from XML Schemas</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#appendix-A.2" class="auto internal xref">A.2</a>.  <a href="#name-svt-in-xml-documents" class="internal xref">SVT in XML Documents</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.1">
                    <p id="section-toc.1-1.9.2.2.2.1.1"><a href="#appendix-A.2.1" class="auto internal xref">A.2.1</a>.  <a href="#name-signaturevalidationtoken-si" class="internal xref">SignatureValidationToken Signature Property</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.2.2.2">
                    <p id="section-toc.1-1.9.2.2.2.2.1"><a href="#appendix-A.2.2" class="auto internal xref">A.2.2</a>.  <a href="#name-multiple-svts-in-an-xml-sig" class="internal xref">Multiple SVTs in an XML Signature</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#appendix-A.3" class="auto internal xref">A.3</a>.  <a href="#name-xml-signature-svt-claims" class="internal xref">XML Signature SVT Claims</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.1">
                    <p id="section-toc.1-1.9.2.3.2.1.1"><a href="#appendix-A.3.1" class="auto internal xref">A.3.1</a>.  <a href="#name-xml-profile-identifier" class="internal xref">XML Profile Identifier</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.2">
                    <p id="section-toc.1-1.9.2.3.2.2.1"><a href="#appendix-A.3.2" class="auto internal xref">A.3.2</a>.  <a href="#name-xml-signature-reference-dat" class="internal xref">XML Signature Reference Data</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.3">
                    <p id="section-toc.1-1.9.2.3.2.3.1"><a href="#appendix-A.3.3" class="auto internal xref">A.3.3</a>.  <a href="#name-xml-signed-data-reference-d" class="internal xref">XML Signed Data Reference Data</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3.2.4">
                    <p id="section-toc.1-1.9.2.3.2.4.1"><a href="#appendix-A.3.4" class="auto internal xref">A.3.4</a>.  <a href="#name-xml-signer-certificate-refe" class="internal xref">XML Signer Certificate References</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#appendix-A.4" class="auto internal xref">A.4</a>.  <a href="#name-jose-header" class="internal xref">JOSE Header</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.4.2.1">
                    <p id="section-toc.1-1.9.2.4.2.1.1"><a href="#appendix-A.4.1" class="auto internal xref">A.4.1</a>.  <a href="#name-svt-signing-key-reference" class="internal xref">SVT Signing Key Reference</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="auto internal xref">Appendix B</a>.  <a href="#name-pdf-signature-profile" class="internal xref">PDF Signature Profile</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#appendix-B.1" class="auto internal xref">B.1</a>.  <a href="#name-svts-in-pdf-documents" class="internal xref">SVTs in PDF Documents</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.1">
                    <p id="section-toc.1-1.10.2.1.2.1.1"><a href="#appendix-B.1.1" class="auto internal xref">B.1.1</a>.  <a href="#name-svt-extension-to-timestamp-" class="internal xref">SVT Extension to Timestamp Tokens</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#appendix-B.2" class="auto internal xref">B.2</a>.  <a href="#name-pdf-signature-svt-claims" class="internal xref">PDF Signature SVT Claims</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.1">
                    <p id="section-toc.1-1.10.2.2.2.1.1"><a href="#appendix-B.2.1" class="auto internal xref">B.2.1</a>.  <a href="#name-pdf-profile-identifier" class="internal xref">PDF Profile Identifier</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.2">
                    <p id="section-toc.1-1.10.2.2.2.2.1"><a href="#appendix-B.2.2" class="auto internal xref">B.2.2</a>.  <a href="#name-pdf-signature-reference-dat" class="internal xref">PDF Signature Reference Data</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.3">
                    <p id="section-toc.1-1.10.2.2.2.3.1"><a href="#appendix-B.2.3" class="auto internal xref">B.2.3</a>.  <a href="#name-pdf-signed-data-reference-d" class="internal xref">PDF Signed Data Reference Data</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.4">
                    <p id="section-toc.1-1.10.2.2.2.4.1"><a href="#appendix-B.2.4" class="auto internal xref">B.2.4</a>.  <a href="#name-pdf-signer-certificate-refe" class="internal xref">PDF Signer Certificate References</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#appendix-B.3" class="auto internal xref">B.3</a>.  <a href="#name-jose-header-2" class="internal xref">JOSE Header</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3.2.1">
                    <p id="section-toc.1-1.10.2.3.2.1.1"><a href="#appendix-B.3.1" class="auto internal xref">B.3.1</a>.  <a href="#name-svt-signing-key-reference-2" class="internal xref">SVT Signing Key Reference</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-C" class="auto internal xref">Appendix C</a>.  <a href="#name-jws-profile" class="internal xref">JWS Profile</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#appendix-C.1" class="auto internal xref">C.1</a>.  <a href="#name-svt-in-jws" class="internal xref">SVT in JWS</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1.2.1">
                    <p id="section-toc.1-1.11.2.1.2.1.1"><a href="#appendix-C.1.1" class="auto internal xref">C.1.1</a>.  <a href="#name-svt-header-parameter" class="internal xref">"svt" Header Parameter</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1.2.2">
                    <p id="section-toc.1-1.11.2.1.2.2.1"><a href="#appendix-C.1.2" class="auto internal xref">C.1.2</a>.  <a href="#name-multiple-svts-in-a-jws-sign" class="internal xref">Multiple SVTs in a JWS Signature</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#appendix-C.2" class="auto internal xref">C.2</a>.  <a href="#name-jws-signature-svt-claims" class="internal xref">JWS Signature SVT Claims</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2.2.1">
                    <p id="section-toc.1-1.11.2.2.2.1.1"><a href="#appendix-C.2.1" class="auto internal xref">C.2.1</a>.  <a href="#name-jws-profile-identifier" class="internal xref">JWS Profile Identifier</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2.2.2">
                    <p id="section-toc.1-1.11.2.2.2.2.1"><a href="#appendix-C.2.2" class="auto internal xref">C.2.2</a>.  <a href="#name-jws-signature-reference-dat" class="internal xref">JWS Signature Reference Data</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2.2.3">
                    <p id="section-toc.1-1.11.2.2.2.3.1"><a href="#appendix-C.2.3" class="auto internal xref">C.2.3</a>.  <a href="#name-jws-signed-data-reference-d" class="internal xref">JWS Signed Data Reference Data</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2.2.4">
                    <p id="section-toc.1-1.11.2.2.2.4.1"><a href="#appendix-C.2.4" class="auto internal xref">C.2.4</a>.  <a href="#name-jws-signer-certificate-refe" class="internal xref">JWS Signer Certificate References</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#appendix-C.3" class="auto internal xref">C.3</a>.  <a href="#name-svt-jose-header-2" class="internal xref">SVT JOSE Header</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.3.2.1">
                    <p id="section-toc.1-1.11.2.3.2.1.1"><a href="#appendix-C.3.1" class="auto internal xref">C.3.1</a>.  <a href="#name-svt-signing-key-reference-3" class="internal xref">SVT Signing Key Reference</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-D" class="auto internal xref">Appendix D</a>.  <a href="#name-schemas" class="internal xref">Schemas</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#appendix-D.1" class="auto internal xref">D.1</a>.  <a href="#name-concise-data-definition-lan" class="internal xref">Concise Data Definition Language (CDDL)</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#appendix-D.2" class="auto internal xref">D.2</a>.  <a href="#name-json-schema" class="internal xref">JSON Schema</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-E" class="auto internal xref">Appendix E</a>.  <a href="#name-examples" class="internal xref">Examples</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-F" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Electronic signatures have a limited lifespan regarding when they can be validated
and determined to be authentic. Many factors make it more difficult to validate
electronic signatures over time. For example:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">Trusted information about the validity of the certificate containing the signer's public key is not available.<a href="#section-1-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.2">Trusted information about the time when the signature was actually created is not available.<a href="#section-1-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.3">Algorithms used to create the electronic signature may no longer be considered secure at the time of validation and may therefore no longer be available in software libraries.<a href="#section-1-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.4">Services necessary to validate the signature are no longer available at the time of validation.<a href="#section-1-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.5">Supporting evidence such as certification authority (CA) certificates, Online Certificate Status Protocol (OCSP) responses, Certificate Revocation Lists (CRLs), or timestamps is not available or can't be validated.<a href="#section-1-2.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-3">The challenges to validation of an electronic signature increase
over time, and eventually it may simply be impossible to verify the
signature with a sufficient level of assurance.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Existing standards, such as the ETSI XAdES <span>[<a href="#XADES" class="cite xref">XADES</a>]</span> profile for XML
signatures <span>[<a href="#XMLDSIG11" class="cite xref">XMLDSIG11</a>]</span>, ETSI PAdES <span>[<a href="#PADES" class="cite xref">PADES</a>]</span> profile for PDF signatures
<span>[<a href="#ISOPDF2" class="cite xref">ISOPDF2</a>]</span>, and ETSI CAdES <span>[<a href="#CADES" class="cite xref">CADES</a>]</span> profile for CMS signatures
<span>[<a href="#RFC5652" class="cite xref">RFC5652</a>]</span>, can be used to extend the time within which a signature can be
validated at the cost of significant complexity, which involves storing and
validating significant amounts of external evidence data such as revocation data,
signature time stamps, and archival time stamps.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The Signature Validation Token (SVT) defined in this specification takes a
trusted signature validation process as an input and preserves the validation result
for the associated signature and signed document. The SVT asserts that a particular
electronic signature was successfully validated by a trusted authority according to
defined procedures at a certain time. Those procedures <span class="bcp14">MUST</span> include checks
that the signature match the signed document, checks that the signature can be validated by
the signing certificate, and checks that the signing certificate pass certificate
path validation <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>.
Those procedures <span class="bcp14">MAY</span> also include checks associated with a particular trust policy such as
that an acceptable certificate policy <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> <span>[<a href="#RFC3647" class="cite xref">RFC3647</a>]</span> was used to issue the
signer's certificate and checks that an acceptable signature policy was used by
the signer <span>[<a href="#RFC3125" class="cite xref">RFC3125</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Once the SVT is issued by a trusted
authority, any future validation of that electronic signature can be satisfied by validating
the SVT without any need to also revalidate the original electronic signature.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">As the SVT is used to preserve validation results obtained through applying existing
standards for signature validation, it is complementary to and not a replacement for such standards,
including the ETSI standards for long-term validation listed above.
The SVT does, however, have the potentially positive effect that it may significantly reduce the need to
apply complex long-term validation and preservation techniques for signature validation
if an SVT is issued and applied to the signed document at an early stage where the signature
can be validated without support of large amounts of external evidence.
The use of SVTs may therefore drastically reduce the complexity of revalidation of old
archived electronic signatures.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">The SVT can be signed with private keys and algorithms that
provide confidence for a considerable time period. In fact, multiple SVTs can be used
to offer greater assurance. For example, one SVT could be produced with a large RSA
private key, a second one with a strong elliptic curve, and a third one with a quantum
safe digital signature algorithm to protect against advances in computing power and
cryptanalytic capabilities. Further, the trusted authority can add additional SVTs
in the future using fresh private keys and signatures to extend the lifetime of the SVTs if necessary.<a href="#section-1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="defs">
<section id="section-2">
      <h2 id="name-definitions">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-definitions" class="section-name selfRef">Definitions</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This document use the following terms:<a href="#section-2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-3">
        <dt id="section-2-3.1">Signed Data:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-3.2">The data covered by a particular electronic signature. This is
 typically equivalent to the signed content of a document, and it
 represents the data that the signer intended to sign. In some cases,
 such as in some XML signatures, the Signed Data can be the collection
 of several data fragments each referenced by the signature. In the
 case of PDF, this is the data covered by the "ByteRange" parameter in
 the signature dictionary. In JSON Web Signature (JWS), this is the
 unencoded payload data (before base64url encoding).<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.3">Signed Bytes:
        </dt>
        <dd style="margin-left: 1.5em" id="section-2-3.4">These are the actual bytes of data that were hashed and signed by
 the digital signature algorithm. In most cases, this is not the actual
 Signed Data but a collection of signature metadata that includes
 references (hash) of the Signed Data as well as information about
 algorithms and other data bound to a signature. In XML, this is the
 canonicalized SignedInfo element. In CMS and PDF signatures, this is
 the DER-encoded SignedAttributes structure. In JWS, this is the
 protected header and payload data formatted according to <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-4">When these terms are used as defined in this section, they appear with a
capitalized first letter.<a href="#section-2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="svt">
<section id="section-3">
      <h2 id="name-signature-validation-token">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-signature-validation-token" class="section-name selfRef">Signature Validation Token</a>
      </h2>
<div id="svt-function">
<section id="section-3.1">
        <h3 id="name-signature-validation-token-">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-signature-validation-token-" class="section-name selfRef">Signature Validation Token Function</a>
        </h3>
<p id="section-3.1-1">The Signature Validation Token (SVT) is created by a trusted service to assert
evidence of successful electronic signature validation using a well-defined and
trustworthy signature validation process. The SVT binds the validation result to
the validated signature, the document signed by the signature, and the certificate of the signer.
This allows a relying party to verify the validity of a signed document
without having to revalidate the original signature or to reuse any of its associated
cryptographic algorithms for as long as the SVT itself can be validated.
The SVT achieves this by binding the following information to
a specific electronic signature:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-2.1">A unique identification of the electronic signature.<a href="#section-3.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.2">The data and metadata signed by the electronic signature.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.3">The signer's certificate that was validated as part of electronic signature verification.<a href="#section-3.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.4">The certification path that was used to validate the signer's certificate.<a href="#section-3.1-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.5">An assertion providing evidence of signature verification, the time the verification was performed, the procedures used to verify the electronic signature, and the outcome of the verification.<a href="#section-3.1-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-2.6">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.<a href="#section-3.1-2.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.1-3">The SVT aims to support long-term validation that can be further extended into the future by applying the following strategies:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.1-4.1">by using secure algorithms with long life expectancy when signing the SVT<a href="#section-3.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-4.2">by reissuing the SVT before it becomes insecure or is considered expired<a href="#section-3.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.1-4.3">optionally, by issuing multiple SVTs with different algorithms to provide redundancy in case one algorithm is broken<a href="#section-3.1-4.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="svt-syntax">
<section id="section-3.2">
        <h3 id="name-signature-validation-token-s">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-signature-validation-token-s" class="section-name selfRef">Signature Validation Token Syntax</a>
        </h3>
<p id="section-3.2-1">The SVT is carried in a JSON Web Token (JWT) as defined in <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<div id="svt-syntax-dt">
<section id="section-3.2.1">
          <h4 id="name-data-types">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-data-types" class="section-name selfRef">Data Types</a>
          </h4>
<p id="section-3.2.1-1">The contents of claims in an SVT are specified using the following data types:<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.1-2">
            <dt id="section-3.2.1-2.1">String:
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.2">JSON Data Type of string that contains an arbitrary
     case-sensitive string value.<a href="#section-3.2.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.3">Base64Binary: 
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.4">JSON Data Type of string that contains a Base64-encoded byte
     array of binary data.<a href="#section-3.2.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.5">StringOrURI:
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.6">JSON Data Type of string that contains an arbitrary string or
     a URI as defined in <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>. It is <span class="bcp14">REQUIRED</span> to contain the colon character (":") to be a URI.<a href="#section-3.2.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.7">URI:
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.8">JSON Data Type of string that contains a URI as defined in
     <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>.<a href="#section-3.2.1-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.9">Integer:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.10">JSON Data Type of number that contains a 32-bit signed integer value (from
-2<sup>31</sup> to 2<sup>31</sup>-1).<a href="#section-3.2.1-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.11">Long:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.12">JSON Data Type of number that contains a 64-bit signed integer value (from      
-2<sup>63</sup> to 2<sup>63</sup>-1).<a href="#section-3.2.1-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.13">NumericDate:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.14">JSON Data Type of number that contains data as defined in <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, which is the number of seconds from 1970-01-01T00:00:00Z UTC until the specified    
UTC date/time, ignoring leap seconds.<a href="#section-3.2.1-2.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.15">Boolean:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.16"> JSON Data Type of boolean that contains the explicit value of true or
false.<a href="#section-3.2.1-2.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.17">Object&lt;Class&gt;:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.18">A JSON object holding a claims object of a class defined in this
specification (see <a href="#svt-syntax-claim" class="auto internal xref">Section 3.2.2</a>).<a href="#section-3.2.1-2.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.19">Map&lt;Type&gt;: 
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.20">A JSON object with name-value pairs where the value is an object of the
specified Type in the notation. For example, Map&lt;String&gt; is a JSON
object with name-value pairs where all values are of type String.<a href="#section-3.2.1-2.20" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.21">Array:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.22">A JSON array of a specific data type as defined in this section. An array
is expressed in this specification by square brackets. For example, [String]
indicates an array of String values, and [Object&lt;DocHash&gt;] indicates an
array of DocHash objects.<a href="#section-3.2.1-2.22" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.1-2.23">Null:
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.1-2.24">A JSON null that represents an absent value. A claim with a null value is
equivalent with an absent claim.<a href="#section-3.2.1-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="svt-syntax-claim">
<section id="section-3.2.2">
          <h4 id="name-signature-validation-token-j">
<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-signature-validation-token-j" class="section-name selfRef">Signature Validation Token JWT Claims</a>
          </h4>
<p id="section-3.2.2-1">The SVT <span class="bcp14">MUST</span> contain only JWT claims in the following list:<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.2-2">
            <dt id="section-3.2.2-2.1">"jti":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.2-2.2"> A String data type that is a "JWT ID" registered claim according to
  <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>. It is <span class="bcp14">RECOMMENDED</span> that the
  identifier holds a hexadecimal string representation of a 128-bit unsigned
  integer. An SVT <span class="bcp14">MUST</span> contain one "JWT ID" claim.<a href="#section-3.2.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.2-2.3">"iss":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.2-2.4">A StringOrURI data type that is an "Issuer" registered claim according
  to <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, which is an arbitrary unique identifier of the
  SVT issuer. This value <span class="bcp14">SHOULD</span> have the value of a URI based
  on a domain owned by the issuer. An SVT <span class="bcp14">MUST</span> contain one
  "Issuer" claim.<a href="#section-3.2.2-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.2-2.5">"iat":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.2-2.6">A NumericDate data type that is an "Issued At" registered claim
  according to <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, which expresses the time
  when this SVT was issued. An SVT <span class="bcp14">MUST</span> contain one "Issued At"
  claim.<a href="#section-3.2.2-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.2-2.7">"aud":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.2-2.8">A [StringOrURI] data type or a StringOrURI data type that is an
  "Audience" registered claim according to <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>. The
  audience claim is an array of one or more identifiers, identifying intended
  recipients of the SVT. Each identifier <span class="bcp14">MAY</span> identify a single
  entity, a group of entities, or a common policy adopted by a group of
  entities. If only one value is provided, it <span class="bcp14">MAY</span> 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
  <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.2-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.2-2.9">"exp":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.2-2.10">A NumericDate data type that is an "Expiration Time" registered claim
  according to <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>, 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 <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.2-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.2-2.11">"sig_val_claims":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.2-2.12">An Object&lt;SigValidation&gt; data type that contains signature
  validation claims for this SVT extending the standard registered JWT claims
  above. An SVT <span class="bcp14">MUST</span> contain one sig_val_claims claim.<a href="#section-3.2.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-3.2.2-3">Note: An SVT asserts that a particular validation process was undertaken at a stated
time. This fact never changes and never expires. However, some other aspects
of the SVT such as liability for false claims or service provision related to a specific
SVT may expire after a certain period of time, such as a service where an old SVT can be
upgraded to a new SVT signed with fresh keys and algorithms.<a href="#section-3.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sigvalidation-obj-class">
<section id="section-3.2.3">
          <h4 id="name-sigvalidation-object-class">
<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-sigvalidation-object-class" class="section-name selfRef">SigValidation Object Class</a>
          </h4>
<p id="section-3.2.3-1">The sig_val_claims JWT claim uses the SigValidation object class. A SigValidation object
holds all custom claims, and a SigValidation object contains the following parameters:<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.3-2">
            <dt id="section-3.2.3-2.1">"ver":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.3-2.2">A String data type representing the version. This parameter
  <span class="bcp14">MUST</span> be present and the version in this specification
  indicated by the value "1.0".<a href="#section-3.2.3-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.3-2.3">"profile":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.3-2.4">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 <span class="bcp14">MUST</span> be present.<a href="#section-3.2.3-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.3-2.5">"hash_algo":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.3-2.6">A URI data type that identifies the hash algorithm used to compute the
  hash values within the SVT. The URI identifier <span class="bcp14">MUST</span> be one
  defined in <span>[<a href="#RFC9231" class="cite xref">RFC9231</a>]</span> or in the IANA registry defined by this
  specification. This parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.3-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.3-2.7">"sig":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.3-2.8">An [Object&lt;Signature&gt;] data type that gives information about
validated electronic signatures as an array of Signature objects. If the SVT
contains signature validation evidence for more than one signature, then each
signature is represented by a separate Signature object. At least one
Signature object <span class="bcp14">MUST</span> be present.<a href="#section-3.2.3-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.3-2.9">"ext":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.3-2.10">A Map&lt;String&gt; data type that provides additional claims related to
the SVT. Extension claims are added at the discretion of the SVT issuer;
however, extension claims <span class="bcp14">MUST</span> follow any conventions defined
in a profile of this specification (see <a href="#profiles" class="auto internal xref">Section 4</a>). Inclusion
of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.3-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="signature-obj-class">
<section id="section-3.2.4">
          <h4 id="name-signature-claims-object-cla">
<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-signature-claims-object-cla" class="section-name selfRef">Signature Claims Object Class</a>
          </h4>
<p id="section-3.2.4-1">The sig parameter in the SigValidation object class uses the Signature object
class. The Signature object contains claims related to signature validation
evidence for one signature, and it contains the following parameters:<a href="#section-3.2.4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.4-2">
            <dt id="section-3.2.4-2.1">"sig_ref": 
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.4-2.2">An Object&lt;SigReference&gt; data type that contains reference
information identifying the target signature. This parameter
<span class="bcp14">MUST</span> be present.<a href="#section-3.2.4-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.4-2.3">"sig_data_ref":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.4-2.4">An [Object&lt;SignedDataReference&gt;] data type that contains an array of
references to Signed Data that was signed by the target electronic
signature. At least one SignedDataReference object <span class="bcp14">MUST</span> be
present.<a href="#section-3.2.4-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.4-2.5">"signer_cert_ref":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.4-2.6">An Object&lt;CertReference&gt; 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
<span class="bcp14">MUST</span> be present.<a href="#section-3.2.4-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.4-2.7">"sig_val":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.4-2.8">An [Object&lt;PolicyValidation&gt;] data type that contains an array of
results of signature verification according to defined procedures. At least
one PolicyValidation object <span class="bcp14">MUST</span> be present.<a href="#section-3.2.4-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.4-2.9">"time_val":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.4-2.10">An [Object&lt;TimeValidation&gt;] data type that contains an array of time
verification results showing that the target signature has existed at a specific
time in the past.  Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.4-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.4-2.11">"ext":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.4-2.12">A MAP&lt;String&gt; 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 <span class="bcp14">MUST</span> follow any conventions
defined in a profile of this specification (see <a href="#profiles" class="auto internal xref">Section 4</a>). Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.4-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sigreference-obj-class">
<section id="section-3.2.5">
          <h4 id="name-sigreference-claims-object-">
<a href="#section-3.2.5" class="section-number selfRef">3.2.5. </a><a href="#name-sigreference-claims-object-" class="section-name selfRef">SigReference Claims Object Class</a>
          </h4>
<p id="section-3.2.5-1">The sig_ref parameter in the Signature object class uses the SigReference object
class. The SigReference object provides information used to match the Signature
claims object to a specific target electronic signature and to verify the integrity
of the target signature value and Signed Bytes, and it contains the following parameters:<a href="#section-3.2.5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.5-2">
            <dt id="section-3.2.5-2.1">"id":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.5-2.2">A String data type that contains an identifier assigned to the target
signature.  Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.5-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.5-2.3">"sig_hash":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.5-2.4">A Base64Binary data type that contains a hash value of the target
electronic signature value. This parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.5-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.5-2.5">"sb_hash":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.5-2.6">A Base64Binary data type that contains a hash value of the Signed Bytes of
the target electronic signature. This parameter <span class="bcp14">MUST</span> be
present.<a href="#section-3.2.5-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="signeddatareference-obj-class">
<section id="section-3.2.6">
          <h4 id="name-signeddatareference-claims-">
<a href="#section-3.2.6" class="section-number selfRef">3.2.6. </a><a href="#name-signeddatareference-claims-" class="section-name selfRef">SignedDataReference Claims Object Class</a>
          </h4>
<p id="section-3.2.6-1">The sig_data_ref parameter in the Signature object class uses the SignedDataReference object
class. The SignedDataReference object provides information used to verify the target electronic
signature references to Signed Data as well as to verify the integrity of all data that
is signed by the target signature, and it contains the following parameters:<a href="#section-3.2.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.6-2">
            <dt id="section-3.2.6-2.1">"ref":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.6-2.2">A String data type that contains a reference identifier for the data or
data fragment covered by the target electronic signature. This parameter
<span class="bcp14">MUST</span> be present.<a href="#section-3.2.6-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.6-2.3">"hash":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.6-2.4">A Base64Binary data type that contains the hash value for the data covered
by the target electronic signature. This parameter <span class="bcp14">MUST</span> be
present.<a href="#section-3.2.6-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="policyval-obj-class">
<section id="section-3.2.7">
          <h4 id="name-policyvalidation-claims-obj">
<a href="#section-3.2.7" class="section-number selfRef">3.2.7. </a><a href="#name-policyvalidation-claims-obj" class="section-name selfRef">PolicyValidation Claims Object Class</a>
          </h4>
<p id="section-3.2.7-1">The sig_val parameter in the Signature object class uses the PolicyValidation object
class. The PolicyValidation object provides information about the result of a validation
process according to a specific policy, and it contains the following parameters:<a href="#section-3.2.7-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.7-2">
            <dt id="section-3.2.7-2.1">"pol":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.7-2.2">A StringOrURI data type that contains the identifier of the policy
  governing the electronic signature verification process. This parameter
  <span class="bcp14">MUST</span> be present.<a href="#section-3.2.7-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.7-2.3">"res":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.7-2.4">A String data type that contains the result of the electronic signature
  verification process. The value <span class="bcp14">MUST</span> be one of "PASSED",
  "FAILED", or "INDETERMINATE" as defined by <span>[<a href="#ETSI319102-1" class="cite xref">ETSI319102-1</a>]</span>. This parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.7-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.7-2.5">"msg":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.7-2.6">A String data type that contains a message describing the
  result. Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.7-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.7-2.7">"ext":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.7-2.8">A MAP&lt;String&gt; 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 <span class="bcp14">MUST</span> follow any
  conventions defined in a profile of this specification (see <a href="#profiles" class="auto internal xref">Section 4</a>). Inclusion of this parameter is
  <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.7-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="timever-obj-class">
<section id="section-3.2.8">
          <h4 id="name-timevalidation-claims-objec">
<a href="#section-3.2.8" class="section-number selfRef">3.2.8. </a><a href="#name-timevalidation-claims-objec" class="section-name selfRef">TimeValidation Claims Object Class</a>
          </h4>
<p id="section-3.2.8-1">The time_val parameter in the Signature object class uses the TimeValidation object
class. The TimeValidation claims object provides information about the result of
validating evidence of time asserting that the target signature existed at a particular
time in the past. Evidence of time is typically a timestamp according to <span>[<a href="#RFC3161" class="cite xref">RFC3161</a>]</span>, but other types of evidence may be used such as a previously issued SVT for this signature. The TimeValidation claims object contains the following parameters:<a href="#section-3.2.8-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.8-2">
            <dt id="section-3.2.8-2.1">"time":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.2">A NumericDate data type that contains the verified time. This parameter
  <span class="bcp14">MUST</span> be present.<a href="#section-3.2.8-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.8-2.3">"type":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.4">A StringOrURI data type that contains an identifier of the type of
  evidence of time. This parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.8-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.8-2.5">"iss":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.6">A StringOrURI data type that contains an identifier of the entity that
  issued the evidence of time. This parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.8-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.8-2.7">"id":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.8">A String data type that contains an unique identifier assigned to the
  evidence of time.  Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.8-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.8-2.9">"hash":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.10">A Base64Binary data type that contains the hash value of the validated
  evidence of time. Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.8-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.8-2.11">"val":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.12">An [Object&lt;PolicyValidation&gt;] data type that contains an array of
  results of the time evidence validation according to defined validation
  procedures. Inclusion of this parameter is <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.8-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.8-2.13">"ext":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.8-2.14">A MAP&lt;String&gt; 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 <span class="bcp14">MUST</span> follow any
  conventions defined in a profile of this specification (see <a href="#profiles" class="auto internal xref">Section 4</a>). Inclusion of this parameter is
  <span class="bcp14">OPTIONAL</span>.<a href="#section-3.2.8-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="certref-obj-class">
<section id="section-3.2.9">
          <h4 id="name-certreference-claims-object">
<a href="#section-3.2.9" class="section-number selfRef">3.2.9. </a><a href="#name-certreference-claims-object" class="section-name selfRef">CertReference Claims Object Class</a>
          </h4>
<p id="section-3.2.9-1">The signer_cert_ref parameter in the Signature object class uses the CertReference object
class. The CertReference object references a single X.509 certificate or a X.509
certification path either by providing the certificate data or by providing hash
references for certificates that can be located in the target electronic signature, and
it contains the following parameters:<a href="#section-3.2.9-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.9-2">
            <dt id="section-3.2.9-2.1">"type":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.9-2.2">A StringOrURI data type that contains an identifier of the type of
  reference.  The type identifier <span class="bcp14">MUST</span> be one of the
  identifiers defined below, an identifier specified by the selected profile,
  or a URI identifier. This parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.9-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.9-2.3">"ref":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.9-2.4">A [String] data type that contains an array of string parameters
  according to conventions defined by the type identifier. At least one
  parameter <span class="bcp14">MUST</span> be present.<a href="#section-3.2.9-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-3.2.9-3">The following type identifiers are defined:<a href="#section-3.2.9-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.9-4">
            <dt id="section-3.2.9-4.1">"chain":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.9-4.2">The ref contains an array of Base64-encoded X.509 certificates <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>. The certificates <span class="bcp14">MUST</span> 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.<a href="#section-3.2.9-4.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.9-4.3">"chain_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="section-3.2.9-4.4">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 <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> used to validate the signature.  The certificates
  <span class="bcp14">MUST</span> 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 <span class="bcp14">MUST NOT</span> be used unless all hashed certificates are present in the target
  electronic signature.<a href="#section-3.2.9-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-3.2.9-5">Note: All certificates referenced using the identifiers above are X.509 certificates.
Profiles of this specification <span class="bcp14">MAY</span> define alternative types of public key containers;
however, a major function of these referenced certificates is not just to reference
the public key but also to provide the subject name of the signer. It is therefore
important for the full function of an SVT that the referenced public key container also
provides the means to identify the signer.<a href="#section-3.2.9-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="svt-jose-header">
<section id="section-3.2.10">
          <h4 id="name-svt-jose-header">
<a href="#section-3.2.10" class="section-number selfRef">3.2.10. </a><a href="#name-svt-jose-header" class="section-name selfRef">SVT JOSE Header</a>
          </h4>
<p id="section-3.2.10-1">The SVT JWT <span class="bcp14">MUST</span> contain the following JSON Object Signing and Encryption (JOSE) header parameters in accordance with
<span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-5" class="relref">Section 5</a> of [<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>:<a href="#section-3.2.10-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2.10-2">
            <dt id="section-3.2.10-2.1">"typ":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.10-2.2">This parameter <span class="bcp14">MUST</span> have the string value "JWT" (upper
case).<a href="#section-3.2.10-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.2.10-2.3">"alg":
</dt>
            <dd style="margin-left: 1.5em" id="section-3.2.10-2.4">This parameter identifies the algorithm used to sign the SVT JWT. The
algorithm identifier <span class="bcp14">MUST</span> be specified in <span>[<a href="#RFC7518" class="cite xref">RFC7518</a>]</span> or the IANA "JSON Web Signature and Encryption Algorithms"
registry <span>[<a href="#IANA-JOSE-REG" class="cite xref">IANA-JOSE-REG</a>]</span>. The specified signature hash
algorithm <span class="bcp14">MUST</span> be identical to the hash algorithm specified in
the hash_algo parameter of the SigValidation object within the sig_val_claims
claim.<a href="#section-3.2.10-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-3.2.10-3">The SVT header <span class="bcp14">MUST</span> contain a public key or a reference to a public key used to verify the signature on the SVT in accordance with <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>. Each profile, as discussed in <a href="#profiles" class="auto internal xref">Section 4</a>, <span class="bcp14">MUST</span> define the requirements for how the key or key reference is included in the header.<a href="#section-3.2.10-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="profiles">
<section id="section-4">
      <h2 id="name-profiles">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-profiles" class="section-name selfRef">Profiles</a>
      </h2>
<p id="section-4-1">Each signed document and signature type will have to define the precise content and
use of several claims in the SVT.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">At a minimum, each profile <span class="bcp14">MUST</span> define:<a href="#section-4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-3.1">The identifier of the profile<a href="#section-4-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.2">How to reference the Signed Data content of the signed document<a href="#section-4-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.3">How to reference the target electronic signature and the Signed Bytes of the signature<a href="#section-4-3.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.4">How to reference certificates supporting each electronic signature<a href="#section-4-3.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.5">How to include public keys or references to public keys in the SVT<a href="#section-4-3.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-3.6">Whether each electronic signature is supported by a single SVT, or one SVT may support multiple electronic signatures of the same document<a href="#section-4-3.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-4">A profile <span class="bcp14">MAY</span> also define:<a href="#section-4-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-5.1">Explicit information on how to perform signature validation based on an SVT<a href="#section-4-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-5.2">How to attach an SVT to an electronic signature or signed document<a href="#section-4-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<div id="defined-profiles">
<section id="section-4.1">
        <h3 id="name-defined-profiles">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-defined-profiles" class="section-name selfRef">Defined Profiles</a>
        </h3>
<p id="section-4.1-1">The following profiles are defined in appendixes of this document:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-2">
          <dt id="section-4.1-2.1"> <a href="#appendix-xml-profile" class="auto internal xref">Appendix A</a>:
          </dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.2">XML Signature Profile<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.3">
<a href="#appendix-pdf-profile" class="auto internal xref">Appendix B</a>:
          </dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.4">PDF Signature Profile<a href="#section-4.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.5">
<a href="#appendix-jws-profile" class="auto internal xref">Appendix C</a>:
          </dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.6">JWS Profile<a href="#section-4.1-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-3">Other documents <span class="bcp14">MAY</span> define other profiles that <span class="bcp14">MAY</span> complement, amend, or supersede these profiles.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="signature-verification-with-a-svt">
<section id="section-5">
      <h2 id="name-signature-verification-with">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-signature-verification-with" class="section-name selfRef">Signature Verification with an SVT</a>
      </h2>
<p id="section-5-1">Signature verification based on an SVT <span class="bcp14">MUST</span> follow these steps:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5-2">
<li id="section-5-2.1">Locate all available SVTs available for the signed document that are relevant for the target electronic signature.<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.2">Select the most recent SVT that can be successfully validated and meets the requirement of the relying party.<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.3">Verify the integrity of the signature and the Signed Bytes of the target electronic signature using the sig_ref claim.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.4">Verify that the Signed Data reference in the original electronic signature matches the reference values in the sig_data_ref claim.<a href="#section-5-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.5">Verify the integrity of referenced Signed Data using provided hash values in the sig_data_ref claim.<a href="#section-5-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.6">Obtain the verified certificates supporting the asserted electronic signature verification through the signer_cert_ref claim.<a href="#section-5-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.7">Verify that signature validation policy results satisfy the requirements of the relying party.<a href="#section-5-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.8">Verify that verified time results satisfy the context for the use of the signed document.<a href="#section-5-2.8" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-5-3">After successfully performing these steps, signature validity is established as well as
the trusted signer certificate binding the identity of the signer to the electronic
signature.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="claim-names-reg">
<section id="section-6.1">
        <h3 id="name-claim-names-registration">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-claim-names-registration" class="section-name selfRef">Claim Names Registration</a>
        </h3>
<p id="section-6.1-1">IANA has registered the "sig_val_claims" claim name in the "JSON Web Token Claims" registry established by <span><a href="https://www.rfc-editor.org/rfc/rfc7519#section-10.1" class="relref">Section 10.1</a> of [<a href="#RFC7519" class="cite xref">RFC7519</a>]</span>.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<div id="clname-reg-contents">
<section id="section-6.1.1">
          <h4 id="name-registry-contents">
<a href="#section-6.1.1" class="section-number selfRef">6.1.1. </a><a href="#name-registry-contents" class="section-name selfRef">Registry Contents</a>
          </h4>
<span class="break"></span><dl class="dlParallel" id="section-6.1.1-1">
            <dt id="section-6.1.1-1.1">Claim Name:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.2">sig_val_claims<a href="#section-6.1.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.1.1-1.3">Claim Description:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.4">Signature Validation Token<a href="#section-6.1.1-1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.1.1-1.5">Change Controller:
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.6">IESG<a href="#section-6.1.1-1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.1.1-1.7">Specification Document(s):
            </dt>
            <dd style="margin-left: 1.5em" id="section-6.1.1-1.8">
              <a href="#sigvalidation-obj-class" class="auto internal xref">Section 3.2.3</a> of RFC 9321<a href="#section-6.1.1-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="iana-header-params">
<section id="section-6.2">
        <h3 id="name-header-parameter-names-regi">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-header-parameter-names-regi" class="section-name selfRef">Header Parameter Names Registration</a>
        </h3>
<p id="section-6.2-1">IANA has registered the "svt" Header Parameter in the "JSON Web Signature and Encryption Header Parameters" registry established by <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<div id="iana-header-params-reg">
<section id="section-6.2.1">
          <h4 id="name-registry-contents-2">
<a href="#section-6.2.1" class="section-number selfRef">6.2.1. </a><a href="#name-registry-contents-2" class="section-name selfRef">Registry Contents</a>
          </h4>
<span class="break"></span><dl class="dlParallel" id="section-6.2.1-1">
            <dt id="section-6.2.1-1.1">Header Parameter Name:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.2.1-1.2">svt<a href="#section-6.2.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.2.1-1.3">Header Parameter Description:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.2.1-1.4"> Signature Validation Token<a href="#section-6.2.1-1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.2.1-1.5">Header Parameter Usage Location(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.2.1-1.6">JWS<a href="#section-6.2.1-1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.2.1-1.7">Change Controller:
</dt>
            <dd style="margin-left: 1.5em" id="section-6.2.1-1.8">IESG<a href="#section-6.2.1-1.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-6.2.1-1.9">Specification Document(s):
</dt>
            <dd style="margin-left: 1.5em" id="section-6.2.1-1.10">
              <a href="#svt-header" class="auto internal xref">Appendix C.1.1</a> of RFC 9321<a href="#section-6.2.1-1.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="seccons">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<div id="seccon-lvl-of-reliance">
<section id="section-7.1">
        <h3 id="name-level-of-reliance">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-level-of-reliance" class="section-name selfRef">Level of Reliance</a>
        </h3>
<p id="section-7.1-1">An SVT allows a signature verifier to still validate the original signature using
the original signature data and to use the information in the SVT selectively to
confirm the validity and integrity of the original data, such as confirming the integrity of Signed Data or the validity of the signer's certificate, etc.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">Another way to use an SVT is to completely rely on the validation conclusion provided
by the SVT and to omit revalidation of the original signature value and original
certificate status checking data.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
<p id="section-7.1-3">This choice is a decision made by the verifier according to its own policy and risk assessment.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<p id="section-7.1-4">However, even when relying on the SVT validation conclusion of an SVT, it is vital to still verify that
the present SVT is correctly associated with the document and signature that is being validated by
validating the hashed reference data in the SVT of the signature, signing certificate chain,
Signed Data, and the Signed Bytes.<a href="#section-7.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="seccon-aging-algos">
<section id="section-7.2">
        <h3 id="name-aging-algorithms">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-aging-algorithms" class="section-name selfRef">Aging Algorithms</a>
        </h3>
<p id="section-7.2-1">Even if the SVT provides protection against algorithms becoming weakened or broken over time, this protection is only valid for as long as the algorithms used to sign the SVT are still considered secure. It is advisable to reissue SVTs in cases where an algorithm protecting the SVT is getting close to its end of life.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">One way to increase the resistance of algorithms becoming insecure, is to issue multiple SVTs for the same signature with different algorithms and key lengths where one algorithm could still be secure even if the corresponding algorithm used in the alternative SVT is broken.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="CADES">[CADES]</dt>
        <dd>
<span class="refAuthor">ETSI</span>, <span class="refTitle">"Electronic Signatures and Infrastructures (ESI); CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures"</span>, <span class="refContent">v1.1.1</span>, <span class="seriesInfo">ETSI EN 319 122-1</span>, <time datetime="2016-04" class="refDate">April 2016</time>. </dd>
<dd class="break"></dd>
<dt id="ETSI319102-1">[ETSI319102-1]</dt>
        <dd>
<span class="refAuthor">ETSI</span>, <span class="refTitle">"Electronic Signatures and Infrastructures (ESI); Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation"</span>, <span class="refContent">v1.1.1</span>, <span class="seriesInfo">ETSI EN 319 102-1</span>, <time datetime="2016-05" class="refDate">May 2016</time>. </dd>
<dd class="break"></dd>
<dt id="IANA-JOSE-REG">[IANA-JOSE-REG]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"JSON Object Signing and Encryption (JOSE)"</span>, <span>&lt;<a href="https://www.iana.org/assignments/jose/">https://www.iana.org/assignments/jose/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ISOPDF2">[ISOPDF2]</dt>
        <dd>
<span class="refAuthor">ISO</span>, <span class="refTitle">"Document management -- Portable document format -- Part 2: PDF 2.0"</span>, <span class="seriesInfo">ISO 32000-2:2020</span>, <time datetime="2020-12" class="refDate">December 2020</time>. </dd>
<dd class="break"></dd>
<dt id="PADES">[PADES]</dt>
        <dd>
<span class="refAuthor">ETSI</span>, <span class="refTitle">"Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures"</span>, <span class="refContent">v1.1.1</span>, <span class="seriesInfo">ETSI EN 319 142-1</span>, <time datetime="2016-04" class="refDate">April 2016</time>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3125">[RFC3125]</dt>
        <dd>
<span class="refAuthor">Ross, J.</span>, <span class="refAuthor">Pinkas, D.</span>, and <span class="refAuthor">N. Pope</span>, <span class="refTitle">"Electronic Signature Policies"</span>, <span class="seriesInfo">RFC 3125</span>, <span class="seriesInfo">DOI 10.17487/RFC3125</span>, <time datetime="2001-09" class="refDate">September 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3125">https://www.rfc-editor.org/info/rfc3125</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3161">[RFC3161]</dt>
        <dd>
<span class="refAuthor">Adams, C.</span>, <span class="refAuthor">Cain, P.</span>, <span class="refAuthor">Pinkas, D.</span>, and <span class="refAuthor">R. Zuccherato</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)"</span>, <span class="seriesInfo">RFC 3161</span>, <span class="seriesInfo">DOI 10.17487/RFC3161</span>, <time datetime="2001-08" class="refDate">August 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3161">https://www.rfc-editor.org/info/rfc3161</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3647">[RFC3647]</dt>
        <dd>
<span class="refAuthor">Chokhani, S.</span>, <span class="refAuthor">Ford, W.</span>, <span class="refAuthor">Sabett, R.</span>, <span class="refAuthor">Merrill, C.</span>, and <span class="refAuthor">S. Wu</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework"</span>, <span class="seriesInfo">RFC 3647</span>, <span class="seriesInfo">DOI 10.17487/RFC3647</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3647">https://www.rfc-editor.org/info/rfc3647</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5035">[RFC5035]</dt>
        <dd>
<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility"</span>, <span class="seriesInfo">RFC 5035</span>, <span class="seriesInfo">DOI 10.17487/RFC5035</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5035">https://www.rfc-editor.org/info/rfc5035</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span>, <span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Boeyen, S.</span>, <span class="refAuthor">Housley, R.</span>, and <span class="refAuthor">W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5652">[RFC5652]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Cryptographic Message Syntax (CMS)"</span>, <span class="seriesInfo">STD 70</span>, <span class="seriesInfo">RFC 5652</span>, <span class="seriesInfo">DOI 10.17487/RFC5652</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5652">https://www.rfc-editor.org/info/rfc5652</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7515">[RFC7515]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Signature (JWS)"</span>, <span class="seriesInfo">RFC 7515</span>, <span class="seriesInfo">DOI 10.17487/RFC7515</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7515">https://www.rfc-editor.org/info/rfc7515</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7518">[RFC7518]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refTitle">"JSON Web Algorithms (JWA)"</span>, <span class="seriesInfo">RFC 7518</span>, <span class="seriesInfo">DOI 10.17487/RFC7518</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7518">https://www.rfc-editor.org/info/rfc7518</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7519">[RFC7519]</dt>
        <dd>
<span class="refAuthor">Jones, M.</span>, <span class="refAuthor">Bradley, J.</span>, and <span class="refAuthor">N. Sakimura</span>, <span class="refTitle">"JSON Web Token (JWT)"</span>, <span class="seriesInfo">RFC 7519</span>, <span class="seriesInfo">DOI 10.17487/RFC7519</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7519">https://www.rfc-editor.org/info/rfc7519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9231">[RFC9231]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Additional XML Security Uniform Resource Identifiers (URIs)"</span>, <span class="seriesInfo">RFC 9231</span>, <span class="seriesInfo">DOI 10.17487/RFC9231</span>, <time datetime="2022-07" class="refDate">July 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9231">https://www.rfc-editor.org/info/rfc9231</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="XADES">[XADES]</dt>
        <dd>
<span class="refAuthor">ETSI</span>, <span class="refTitle">"Electronic Signatures and Infrastructures (ESI); XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures"</span>, <span class="refContent">v1.1.1</span>, <span class="seriesInfo">ETSI EN 319 132-1</span>, <time datetime="2016-04" class="refDate">April 2016</time>. </dd>
<dd class="break"></dd>
<dt id="XMLDSIG11">[XMLDSIG11]</dt>
      <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refAuthor">Reagle, J.</span>, <span class="refAuthor">Solo, D.</span>, <span class="refAuthor">Hirsch, F.</span>, <span class="refAuthor">Nystrom, M.</span>, <span class="refAuthor">Roessler, T.</span>, and <span class="refAuthor">K. Yiu</span>, <span class="refTitle">"XML Signature Syntax and Processing Version 1.1"</span>, <span class="seriesInfo">W3C Proposed Recommendation</span>, <time datetime="2013-04" class="refDate">April 2013</time>. <span class="annotation">Latest version available at <span><a href="https://www.w3.org/TR/xmldsig-core1/">https://www.w3.org/TR/xmldsig-core1/</a></span>.</span>
        </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC8610">[RFC8610]</dt>
      <dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Vigano, C.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"</span>, <span class="seriesInfo">RFC 8610</span>, <span class="seriesInfo">DOI 10.17487/RFC8610</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8610">https://www.rfc-editor.org/info/rfc8610</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="appendix-xml-profile">
<section id="appendix-A">
      <h2 id="name-xml-signature-profile">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-xml-signature-profile" class="section-name selfRef">XML Signature Profile</a>
      </h2>
<p id="appendix-A-1">This appendix defines a profile for implementing SVTs with a signed XML document and defines the following aspects of SVT usage:<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A-2.1">How to include reference data related to XML signatures and XML documents in an SVT<a href="#appendix-A-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-2.2">How to add an SVT token to an XML signature<a href="#appendix-A-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-A-3">XML documents can have any number of signature elements, signing an arbitrary number of fragments of XML documents. The actual signature element may be included in the signed XML document (enveloped), include the Signed Data (enveloping), or may be separate from the signed content (detached).<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<p id="appendix-A-4">To provide a generic solution for any type of XML signature, an SVT is added to each XML signature element within the XML signature &lt;ds:Object&gt; element.<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<div id="notation">
<section id="appendix-A.1">
        <h3 id="name-notation">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-notation" class="section-name selfRef">Notation</a>
        </h3>
<div id="ref-to-xml-elements">
<section id="appendix-A.1.1">
          <h4 id="name-references-to-xml-elements-">
<a href="#appendix-A.1.1" class="section-number selfRef">A.1.1. </a><a href="#name-references-to-xml-elements-" class="section-name selfRef">References to XML Elements from XML Schemas</a>
          </h4>
<p id="appendix-A.1.1-1">When referring to elements from the W3C XML Signature namespace
(<span><a href="https://www.w3.org/2000/09/xmldsig#">https://www.w3.org/2000/09/xmldsig#</a></span>), the following syntax is used:<a href="#appendix-A.1.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A.1.1-2.1">&lt;ds:Signature&gt;<a href="#appendix-A.1.1-2.1" class="pilcrow">¶</a>
</li>
          </ul>
<p id="appendix-A.1.1-3">When referring to elements from the ETSI XAdES XML Signature namespace
(<span><a href="https://uri.etsi.org/01903/v1.3.2#">https://uri.etsi.org/01903/v1.3.2#</a></span>), the following syntax is used:<a href="#appendix-A.1.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A.1.1-4.1">&lt;xades:CertDigest&gt;<a href="#appendix-A.1.1-4.1" class="pilcrow">¶</a>
</li>
          </ul>
<p id="appendix-A.1.1-5">When referring to elements defined in this specification
   (<span><a href="http://id.swedenconnect.se/svt/1.0/sig-prop/ns">http://id.swedenconnect.se/svt/1.0/sig-prop/ns</a></span>), the following syntax is used:<a href="#appendix-A.1.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A.1.1-6.1">&lt;svt:Element&gt;<a href="#appendix-A.1.1-6.1" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="svt-in-xml">
<section id="appendix-A.2">
        <h3 id="name-svt-in-xml-documents">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-svt-in-xml-documents" class="section-name selfRef">SVT in XML Documents</a>
        </h3>
<p id="appendix-A.2-1">When SVTs are provided for XML signatures, then one SVT <span class="bcp14">MUST</span> be provided for each XML signature.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2-2">An SVT embedded within the XML signature element <span class="bcp14">MUST</span> be placed in a  &lt;svt:SignatureValidationToken&gt; element as defined in <a href="#signaturevalidationtoken-signature-property" class="auto internal xref">Appendix A.2.1</a>.<a href="#appendix-A.2-2" class="pilcrow">¶</a></p>
<div id="signaturevalidationtoken-signature-property">
<section id="appendix-A.2.1">
          <h4 id="name-signaturevalidationtoken-si">
<a href="#appendix-A.2.1" class="section-number selfRef">A.2.1. </a><a href="#name-signaturevalidationtoken-si" class="section-name selfRef">SignatureValidationToken Signature Property</a>
          </h4>
<p id="appendix-A.2.1-1">The &lt;svt:SignatureValidationToken&gt; element <span class="bcp14">MUST</span> be placed in a &lt;ds:SignatureProperty&gt; element in accordance with <span>[<a href="#XMLDSIG11" class="cite xref">XMLDSIG11</a>]</span>. The &lt;ds:SignatureProperty&gt; element <span class="bcp14">MUST</span> be placed inside a &lt;ds:SignatureProperties&gt; element inside a &lt;ds:Object&gt; element inside a &lt;ds:Signature&gt; element.<a href="#appendix-A.2.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.1-2">Note: <span>[<a href="#XMLDSIG11" class="cite xref">XMLDSIG11</a>]</span> requires the Target attribute to be present in &lt;ds:SignatureProperty&gt;, referencing the signature targeted by this signature property. If an SVT is added to a signature that does not have an Id attribute, implementations <span class="bcp14">SHOULD</span> add an Id attribute to the &lt;ds:Signature&gt; element and reference that Id in the Target attribute. This Id attribute and Target attribute value matching is required by the <span>[<a href="#XMLDSIG11" class="cite xref">XMLDSIG11</a>]</span> standard, but it is redundant in the context of SVT validation as the SVT already contains information that uniquely identifies the target signature. Validation applications <span class="bcp14">SHOULD NOT</span> reject an SVT token because of Id and Target attribute mismatch and <span class="bcp14">MUST</span> rely on matching against a signature using signed information in the SVT itself.<a href="#appendix-A.2.1-2" class="pilcrow">¶</a></p>
<p id="appendix-A.2.1-3">The &lt;svt:SignatureValidationToken&gt; element is defined by the following XML Schema:<a href="#appendix-A.2.1-3" class="pilcrow">¶</a></p>
<div id="appendix-A.2.1-4">
<pre class="lang-xml sourcecode">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified"
    targetNamespace="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"
    xmlns:svt="http://id.swedenconnect.se/svt/1.0/sig-prop/ns"&gt;

  &lt;xs:element name="SignatureValidationToken"
      type="svt:SignatureValidationTokenType" /&gt;

  &lt;xs:complexType name="SignatureValidationTokenType"&gt;
    &lt;xs:simpleContent&gt;
      &lt;xs:extension base="xs:string"&gt;
      &lt;/xs:extension&gt;
    &lt;/xs:simpleContent&gt;
  &lt;/xs:complexType&gt;

&lt;/xs:schema&gt;
</pre><a href="#appendix-A.2.1-4" class="pilcrow">¶</a>
</div>
<p id="appendix-A.2.1-5">The SVT token <span class="bcp14">MUST</span> be included as a string representation of the SVT JWT. Note that this is the string representation of the JWT without further encoding. The SVT <span class="bcp14">MUST NOT</span> be represented by the Base64-encoded bytes of the JWT string.<a href="#appendix-A.2.1-5" class="pilcrow">¶</a></p>
<p id="appendix-A.2.1-6">Example:<a href="#appendix-A.2.1-6" class="pilcrow">¶</a></p>
<div id="appendix-A.2.1-7">
<pre class="lang-xml sourcecode">
&lt;ds:Signature Id="MySignatureId"&gt;
  ...
  &lt;ds:Object&gt;
    &lt;ds:SignatureProperties&gt;
      &lt;ds:SignatureProperty Target="#MySignatureId"&gt;
        &lt;svt:SignatureValidationToken&gt;
              eyJ0eXAiOiJKV1QiLCJhb...2aNZ
        &lt;/svt:SignatureValidationToken&gt;
      &lt;/ds:SignatureProperty&gt;
    &lt;/ds:SignatureProperties&gt;
  &lt;/ds:Object&gt;
&lt;/ds:Signature&gt;
</pre><a href="#appendix-A.2.1-7" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="xml-multiple-svt-tokens">
<section id="appendix-A.2.2">
          <h4 id="name-multiple-svts-in-an-xml-sig">
<a href="#appendix-A.2.2" class="section-number selfRef">A.2.2. </a><a href="#name-multiple-svts-in-an-xml-sig" class="section-name selfRef">Multiple SVTs in an XML Signature</a>
          </h4>
<p id="appendix-A.2.2-1">If a new SVT is stored in a signature that already contains a previously issued SVT, implementations can choose either to replace the existing SVT or to store the new SVT in addition to the existing SVT.<a href="#appendix-A.2.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.2-2">If the new SVT is stored in addition to the old SVT, it <span class="bcp14">SHOULD</span> be stored in a new &lt;ds:SignatureProperty&gt; element inside the existing &lt;ds:SignatureProperties&gt; element where the old SVT is located.<a href="#appendix-A.2.2-2" class="pilcrow">¶</a></p>
<p id="appendix-A.2.2-3">For interoperability robustness, signature validation applications <span class="bcp14">MUST</span> be able to handle signatures where the new SVT is located in a new &lt;ds:Object&gt; element.<a href="#appendix-A.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="xml-svt-claims">
<section id="appendix-A.3">
        <h3 id="name-xml-signature-svt-claims">
<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-xml-signature-svt-claims" class="section-name selfRef">XML Signature SVT Claims</a>
        </h3>
<div id="xml-profile-identifier">
<section id="appendix-A.3.1">
          <h4 id="name-xml-profile-identifier">
<a href="#appendix-A.3.1" class="section-number selfRef">A.3.1. </a><a href="#name-xml-profile-identifier" class="section-name selfRef">XML Profile Identifier</a>
          </h4>
<p id="appendix-A.3.1-1">When this profile is used, the SigValidation object <span class="bcp14">MUST</span> contain a "profile" claim with the value "XML".<a href="#appendix-A.3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="xml-signature-reference-data">
<section id="appendix-A.3.2">
          <h4 id="name-xml-signature-reference-dat">
<a href="#appendix-A.3.2" class="section-number selfRef">A.3.2. </a><a href="#name-xml-signature-reference-dat" class="section-name selfRef">XML Signature Reference Data</a>
          </h4>
<p id="appendix-A.3.2-1">The SVT Signature object <span class="bcp14">MUST</span> contain a "sig_ref" claim (SigReference object) with the following elements:<a href="#appendix-A.3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.3.2-2">
            <dt id="appendix-A.3.2-2.1">"id":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-A.3.2-2.2">The Id-attribute of the XML signature, if present.<a href="#appendix-A.3.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A.3.2-2.3">"sig_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-A.3.2-2.4">The hash over the signature value bytes.<a href="#appendix-A.3.2-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A.3.2-2.5">"sb_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-A.3.2-2.6">The hash over the canonicalized &lt;ds:SignedInfo&gt; element
     (the bytes the XML signature algorithm has signed to generate the
     signature value).<a href="#appendix-A.3.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="xml-signed-data-reference">
<section id="appendix-A.3.3">
          <h4 id="name-xml-signed-data-reference-d">
<a href="#appendix-A.3.3" class="section-number selfRef">A.3.3. </a><a href="#name-xml-signed-data-reference-d" class="section-name selfRef">XML Signed Data Reference Data</a>
          </h4>
<p id="appendix-A.3.3-1">The SVT Signature object <span class="bcp14">MUST</span> contain one instance of the "sig_data" claim (SignedData object) for each &lt;ds:Reference&gt; element in the &lt;ds:SignedInfo&gt; element. The "sig_data" claim <span class="bcp14">MUST</span> contain the following elements:<a href="#appendix-A.3.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.3.3-2">
            <dt id="appendix-A.3.3-2.1">"ref":
</dt>
            <dd style="margin-left: 1.5em" id="appendix-A.3.3-2.2">The value of the URI attribute of the corresponding &lt;ds:Reference&gt;
element.<a href="#appendix-A.3.3-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A.3.3-2.3">"hash":
</dt>
            <dd style="margin-left: 1.5em" id="appendix-A.3.3-2.4">The hash of all bytes that were identified by the corresponding &lt;ds:Reference&gt;
element after applying all identified canonicalization and transformation
algorithms. These are the same bytes that are hashed by the hash value in the
&lt;ds:DigestValue&gt; element inside the &lt;ds:Reference&gt; element.<a href="#appendix-A.3.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="xml-signer-certificate-references">
<section id="appendix-A.3.4">
          <h4 id="name-xml-signer-certificate-refe">
<a href="#appendix-A.3.4" class="section-number selfRef">A.3.4. </a><a href="#name-xml-signer-certificate-refe" class="section-name selfRef">XML Signer Certificate References</a>
          </h4>
<p id="appendix-A.3.4-1">The SVT Signature object <span class="bcp14">MUST</span> contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim <span class="bcp14">MUST</span> be either "chain" or "chain_hash".<a href="#appendix-A.3.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A.3.4-2.1">The "chain" type <span class="bcp14">MUST</span> 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.<a href="#appendix-A.3.4-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-A.3.4-2.2">The "chain_hash" type <span class="bcp14">MUST</span> be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.<a href="#appendix-A.3.4-2.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="xml-jose-header">
<section id="appendix-A.4">
        <h3 id="name-jose-header">
<a href="#appendix-A.4" class="section-number selfRef">A.4. </a><a href="#name-jose-header" class="section-name selfRef">JOSE Header</a>
        </h3>
<div id="xml-svt-signing-key-reference">
<section id="appendix-A.4.1">
          <h4 id="name-svt-signing-key-reference">
<a href="#appendix-A.4.1" class="section-number selfRef">A.4.1. </a><a href="#name-svt-signing-key-reference" class="section-name selfRef">SVT Signing Key Reference</a>
          </h4>
<p id="appendix-A.4.1-1">The SVT JOSE header for XML signatures must contain one of the following header parameters in accordance with <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> for storing a reference to the public key used to verify the signature on the SVT:<a href="#appendix-A.4.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-A.4.1-2">
            <dt id="appendix-A.4.1-2.1">"x5c":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-A.4.1-2.2">Holds an X.509 certificate <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> or a chain
    of certificates. The certificate holding the public key that
    verifies the signature on the SVT <span class="bcp14">MUST</span> be the first
    certificate in the chain.<a href="#appendix-A.4.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-A.4.1-2.3">"kid":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-A.4.1-2.4"> A key identifier holding the Base64-encoded hash value of the
    certificate that can verify the signature on the SVT. The hash
    algorithm <span class="bcp14">MUST</span> be the same hash algorithm used when
    signing the SVT as specified by the "<code>alg</code>" Header Parameter.<a href="#appendix-A.4.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="appendix-pdf-profile">
<section id="appendix-B">
      <h2 id="name-pdf-signature-profile">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-pdf-signature-profile" class="section-name selfRef">PDF Signature Profile</a>
      </h2>
<p id="appendix-B-1">This appendix defines a profile for implementing SVTs with a signed PDF document, and it defines the following aspects of SVT usage:<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-2.1">How to include reference data related to PDF signatures and PDF documents in an SVT.<a href="#appendix-B-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-2.2">How to add an SVT token to a PDF document.<a href="#appendix-B-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-B-3">PDF document signatures are added as incremental updates to the signed PDF document and signs all data of the PDF document up until the current signature. When more than one signature is added to a PDF document the previous signature is signed by the next signature and can not be updated with additional data after this event.<a href="#appendix-B-3" class="pilcrow">¶</a></p>
<p id="appendix-B-4">To minimize the impact on PDF documents with multiple signatures and to stay backwards compatible with PDF software that does not understand SVTs, PDF documents add one SVT token for all signatures of the PDF as an extension to a document timestamp added to the signed PDF as an incremental update. This SVT covers all signatures of the signed PDF.<a href="#appendix-B-4" class="pilcrow">¶</a></p>
<div id="svt-in-pdf">
<section id="appendix-B.1">
        <h3 id="name-svts-in-pdf-documents">
<a href="#appendix-B.1" class="section-number selfRef">B.1. </a><a href="#name-svts-in-pdf-documents" class="section-name selfRef">SVTs in PDF Documents</a>
        </h3>
<p id="appendix-B.1-1">The SVT for a signed PDF document <span class="bcp14">MAY</span> provide signature validation information about any of the present signatures in the PDF. The SVT <span class="bcp14">MUST</span> contain a separate "sig" claim (Signature object) for each signature on the PDF that is covered by the SVT.<a href="#appendix-B.1-1" class="pilcrow">¶</a></p>
<p id="appendix-B.1-2">An SVT added to a signed PDF document <span class="bcp14">MUST</span> be added to a document timestamp in accordance with ISO 32000-2:2020 <span>[<a href="#ISOPDF2" class="cite xref">ISOPDF2</a>]</span>.<a href="#appendix-B.1-2" class="pilcrow">¶</a></p>
<p id="appendix-B.1-3">The document timestamp contains an <span>[<a href="#RFC3161" class="cite xref">RFC3161</a>]</span> timestamp token (TSTInfo) in EncapsulatedContentInfo of the CMS signature. The SVT <span class="bcp14">MUST</span> be added to the timestamp token (TSTInfo) as an Extension object as defined in  <a href="#svt-extension-to-timestamps" class="auto internal xref">Appendix B.1.1</a>.<a href="#appendix-B.1-3" class="pilcrow">¶</a></p>
<div id="svt-extension-to-timestamps">
<section id="appendix-B.1.1">
          <h4 id="name-svt-extension-to-timestamp-">
<a href="#appendix-B.1.1" class="section-number selfRef">B.1.1. </a><a href="#name-svt-extension-to-timestamp-" class="section-name selfRef">SVT Extension to Timestamp Tokens</a>
          </h4>
<p id="appendix-B.1.1-1">The SVT extension is an Extension suitable to be included in TSTInfo as defined by <span>[<a href="#RFC3161" class="cite xref">RFC3161</a>]</span>.<a href="#appendix-B.1.1-1" class="pilcrow">¶</a></p>
<p id="appendix-B.1.1-2">The SVT extension is identified by the Object Identifier (OID) 1.2.752.201.5.2.<a href="#appendix-B.1.1-2" class="pilcrow">¶</a></p>
<p id="appendix-B.1.1-3">This extension data (OCTET STRING) holds the bytes of SVT JWT, represented as a UTF-8-encoded string.<a href="#appendix-B.1.1-3" class="pilcrow">¶</a></p>
<p id="appendix-B.1.1-4">This extension <span class="bcp14">MUST NOT</span> be marked critical.<a href="#appendix-B.1.1-4" class="pilcrow">¶</a></p>
<p id="appendix-B.1.1-5">Note: Extensions in timestamp tokens according to <span>[<a href="#RFC3161" class="cite xref">RFC3161</a>]</span> are imported from the definition of the X.509 certificate extensions defined in <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span>.<a href="#appendix-B.1.1-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="pdf-svt-claims">
<section id="appendix-B.2">
        <h3 id="name-pdf-signature-svt-claims">
<a href="#appendix-B.2" class="section-number selfRef">B.2. </a><a href="#name-pdf-signature-svt-claims" class="section-name selfRef">PDF Signature SVT Claims</a>
        </h3>
<div id="pdf-profile-identifier">
<section id="appendix-B.2.1">
          <h4 id="name-pdf-profile-identifier">
<a href="#appendix-B.2.1" class="section-number selfRef">B.2.1. </a><a href="#name-pdf-profile-identifier" class="section-name selfRef">PDF Profile Identifier</a>
          </h4>
<p id="appendix-B.2.1-1">When this profile is used, the SigValidation object <span class="bcp14">MUST</span> contain a "profile" claim with the value "PDF".<a href="#appendix-B.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pdf-signature-reference-data">
<section id="appendix-B.2.2">
          <h4 id="name-pdf-signature-reference-dat">
<a href="#appendix-B.2.2" class="section-number selfRef">B.2.2. </a><a href="#name-pdf-signature-reference-dat" class="section-name selfRef">PDF Signature Reference Data</a>
          </h4>
<p id="appendix-B.2.2-1">The SVT Signature object <span class="bcp14">MUST</span> contain a "sig_ref" claim (SigReference object) with the following elements:<a href="#appendix-B.2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-B.2.2-2">
            <dt id="appendix-B.2.2-2.1">"id":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.2.2-2.2">Absent or a Null value.<a href="#appendix-B.2.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-B.2.2-2.3">"sig_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.2.2-2.4">The hash over the signature value bytes.<a href="#appendix-B.2.2-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-B.2.2-2.5">"sb_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.2.2-2.6">The hash over the DER-encoded SignedAttributes in SignerInfo.<a href="#appendix-B.2.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="pdf-signed-data-reference">
<section id="appendix-B.2.3">
          <h4 id="name-pdf-signed-data-reference-d">
<a href="#appendix-B.2.3" class="section-number selfRef">B.2.3. </a><a href="#name-pdf-signed-data-reference-d" class="section-name selfRef">PDF Signed Data Reference Data</a>
          </h4>
<p id="appendix-B.2.3-1">The SVT Signature object <span class="bcp14">MUST</span> contain one instance of the "sig_data" claim (SignedData object) with the following elements:<a href="#appendix-B.2.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-B.2.3-2">
            <dt id="appendix-B.2.3-2.1">"ref":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.2.3-2.2">The string representation of the ByteRange value of the PDF
     signature dictionary of the target signature. This is a sequence
     of integers separated by space where each integer pair specifies
     the start index and length of a byte range.<a href="#appendix-B.2.3-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-B.2.3-2.3">"hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.2.3-2.4"> The hash of all bytes identified by the ByteRange value. This
     is the concatenation of all byte ranges identified by the
     ByteRange value.<a href="#appendix-B.2.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="pdf-signer-certificate-references">
<section id="appendix-B.2.4">
          <h4 id="name-pdf-signer-certificate-refe">
<a href="#appendix-B.2.4" class="section-number selfRef">B.2.4. </a><a href="#name-pdf-signer-certificate-refe" class="section-name selfRef">PDF Signer Certificate References</a>
          </h4>
<p id="appendix-B.2.4-1">The SVT Signature object <span class="bcp14">MUST</span> contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim <span class="bcp14">MUST</span> be either "chain" or "chain_hash".<a href="#appendix-B.2.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B.2.4-2.1">The "chain" type <span class="bcp14">MUST</span> 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.<a href="#appendix-B.2.4-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-B.2.4-2.2">The "chain_hash" type <span class="bcp14">MUST</span> be used when signature validation was performed using one or more certificates where all of the certificates are present in the target signature.<a href="#appendix-B.2.4-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="appendix-B.2.4-3">Note: The referenced signer certificate <span class="bcp14">MUST</span> match any certificates referenced using ESSCertID or ESSCertIDv2 from <span>[<a href="#RFC5035" class="cite xref">RFC5035</a>]</span>.<a href="#appendix-B.2.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="pdf-jose-header">
<section id="appendix-B.3">
        <h3 id="name-jose-header-2">
<a href="#appendix-B.3" class="section-number selfRef">B.3. </a><a href="#name-jose-header-2" class="section-name selfRef">JOSE Header</a>
        </h3>
<div id="pdf-svt-signing-key-reference">
<section id="appendix-B.3.1">
          <h4 id="name-svt-signing-key-reference-2">
<a href="#appendix-B.3.1" class="section-number selfRef">B.3.1. </a><a href="#name-svt-signing-key-reference-2" class="section-name selfRef">SVT Signing Key Reference</a>
          </h4>
<p id="appendix-B.3.1-1">The SVT JOSE header must contain one of the following header parameters in accordance with <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> for storing a reference to the public key used to verify the signature on the SVT:<a href="#appendix-B.3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-B.3.1-2">
            <dt id="appendix-B.3.1-2.1">"x5c":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.3.1-2.2">Holds an X.509 certificate <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> or a chain
     of certificates. The certificate holding the public key that
     verifies the signature on the SVT <span class="bcp14">MUST</span> be the first
     certificate in the chain.<a href="#appendix-B.3.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-B.3.1-2.3">"kid":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-B.3.1-2.4">A key identifier holding the Base64-encoded hash value of the
     certificate that can verify the signature on the SVT. The hash
     algorithm <span class="bcp14">MUST</span> be the same hash algorithm used when
     signing the SVT as specified by the "<code>alg</code>" Header
     Parameter. The referenced certificate <span class="bcp14">SHOULD</span> be the
     same certificate that was used to sign the document timestamp that
     contains the SVT.<a href="#appendix-B.3.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="appendix-jws-profile">
<section id="appendix-C">
      <h2 id="name-jws-profile">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-jws-profile" class="section-name selfRef">JWS Profile</a>
      </h2>
<p id="appendix-C-1">This appendix defines a profile for implementing SVTs with a JWS signed payload according to <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>, and it defines the following aspects of SVT usage:<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-2.1">How to include reference data related to JWS signatures in an SVT.<a href="#appendix-C-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.2">How to add an SVT token to JWS signatures.<a href="#appendix-C-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="appendix-C-3">A JWS may have one or more signatures, depending on its serialization format, signing the same payload data. A JWS either contains the data to be signed (enveloping) or may sign any externally associated payload data (detached).<a href="#appendix-C-3" class="pilcrow">¶</a></p>
<p id="appendix-C-4">To provide a generic solution for JWS, an SVT is added to each present signature as a JWS Unprotected Header. If a JWS includes multiple signatures, then each signature includes its own SVT.<a href="#appendix-C-4" class="pilcrow">¶</a></p>
<div id="svt-in-jws">
<section id="appendix-C.1">
        <h3 id="name-svt-in-jws">
<a href="#appendix-C.1" class="section-number selfRef">C.1. </a><a href="#name-svt-in-jws" class="section-name selfRef">SVT in JWS</a>
        </h3>
<p id="appendix-C.1-1">An SVT token <span class="bcp14">MAY</span> be added to any signature of a JWS to support validation of that signature. If more than one signature is present, then each present SVT <span class="bcp14">MUST</span> provide information exclusively related to one associated signature and <span class="bcp14">MUST NOT</span> include information about any other signature in the JWS.<a href="#appendix-C.1-1" class="pilcrow">¶</a></p>
<p id="appendix-C.1-2">Each SVT is stored in its associated signature's "svt" header as defined in <a href="#svt-header" class="auto internal xref">Appendix C.1.1</a>.<a href="#appendix-C.1-2" class="pilcrow">¶</a></p>
<div id="svt-header">
<section id="appendix-C.1.1">
          <h4 id="name-svt-header-parameter">
<a href="#appendix-C.1.1" class="section-number selfRef">C.1.1. </a><a href="#name-svt-header-parameter" class="section-name selfRef">"svt" Header Parameter</a>
          </h4>
<p id="appendix-C.1.1-1">The "svt" (Signature Validation Token) Header Parameter is used to contain an array of SVT tokens to support validation of the associated signature. Each SVT token in the array has the format of a JWT as defined in <span>[<a href="#RFC7519" class="cite xref">RFC7519</a>]</span> and is stored using its natural string representation without further wrapping or encoding.<a href="#appendix-C.1.1-1" class="pilcrow">¶</a></p>
<p id="appendix-C.1.1-2">The "svt" Header Parameter, when used, <span class="bcp14">MUST</span> be included as a JWS Unprotected Header.<a href="#appendix-C.1.1-2" class="pilcrow">¶</a></p>
<p id="appendix-C.1.1-3">Note: A JWS Unprotected Header is not supported with JWS Compact Serialization. A consequence of adding an SVT token to a JWS is therefore that JWS JSON Serialization <span class="bcp14">MUST</span> be used either in the form of general JWS JSON Serialization (for one or more signatures) or in the form of flattened JWS JSON Serialization (optionally used when only one signature is present in the JWS).<a href="#appendix-C.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="jws-multiple-svt-tokens">
<section id="appendix-C.1.2">
          <h4 id="name-multiple-svts-in-a-jws-sign">
<a href="#appendix-C.1.2" class="section-number selfRef">C.1.2. </a><a href="#name-multiple-svts-in-a-jws-sign" class="section-name selfRef">Multiple SVTs in a JWS Signature</a>
          </h4>
<p id="appendix-C.1.2-1">If a new SVT is stored in a signature that already contains a previously issued SVT, implementations can choose either to replace the existing SVT or to store the new SVT in addition to the existing SVT.<a href="#appendix-C.1.2-1" class="pilcrow">¶</a></p>
<p id="appendix-C.1.2-2">If a JWS signature already contains an array of SVTs and a new SVT is to be added, then the new SVT <span class="bcp14">MUST</span> be added to the array of SVT tokens in the existing "svt" Header Parameter.<a href="#appendix-C.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="jws-svt-claims">
<section id="appendix-C.2">
        <h3 id="name-jws-signature-svt-claims">
<a href="#appendix-C.2" class="section-number selfRef">C.2. </a><a href="#name-jws-signature-svt-claims" class="section-name selfRef">JWS Signature SVT Claims</a>
        </h3>
<div id="jws-profile-identifier">
<section id="appendix-C.2.1">
          <h4 id="name-jws-profile-identifier">
<a href="#appendix-C.2.1" class="section-number selfRef">C.2.1. </a><a href="#name-jws-profile-identifier" class="section-name selfRef">JWS Profile Identifier</a>
          </h4>
<p id="appendix-C.2.1-1">When this profile is used, the SigValidation object <span class="bcp14">MUST</span> contain a "profile" claim with the value "JWS".<a href="#appendix-C.2.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="jws-signature-reference-data">
<section id="appendix-C.2.2">
          <h4 id="name-jws-signature-reference-dat">
<a href="#appendix-C.2.2" class="section-number selfRef">C.2.2. </a><a href="#name-jws-signature-reference-dat" class="section-name selfRef">JWS Signature Reference Data</a>
          </h4>
<p id="appendix-C.2.2-1">The SVT Signature object <span class="bcp14">MUST</span> contain a "sig_ref" claim (SigReference object) with the following elements:<a href="#appendix-C.2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-C.2.2-2">
            <dt id="appendix-C.2.2-2.1">"sig_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-C.2.2-2.2">The hash over the associated signature value (the bytes of the
     base64url-decoded signature parameter).<a href="#appendix-C.2.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-C.2.2-2.3">"sb_hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-C.2.2-2.4">The hash over all bytes signed by the associated signature
     (the JWS Signing Input according to <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span>).<a href="#appendix-C.2.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="jws-signed-data-reference">
<section id="appendix-C.2.3">
          <h4 id="name-jws-signed-data-reference-d">
<a href="#appendix-C.2.3" class="section-number selfRef">C.2.3. </a><a href="#name-jws-signed-data-reference-d" class="section-name selfRef">JWS Signed Data Reference Data</a>
          </h4>
<p id="appendix-C.2.3-1">The SVT Signature object <span class="bcp14">MUST</span> contain one instance of the "sig_data" claim (SignedData object) with the following elements:<a href="#appendix-C.2.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-C.2.3-2">
            <dt id="appendix-C.2.3-2.1">"ref":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-C.2.3-2.2">
              <p id="appendix-C.2.3-2.2.1">This parameter <span class="bcp14">MUST</span> hold one of the
         following three possible values:<a href="#appendix-C.2.3-2.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-C.2.3-2.2.2">
<li id="appendix-C.2.3-2.2.2.1">The explicit string value
              "payload" if the signed JWS Payload is embedded in a "payload"
              member of the JWS.<a href="#appendix-C.2.3-2.2.2.1" class="pilcrow">¶</a>
</li>
                <li id="appendix-C.2.3-2.2.2.2">The explicit string value "detached" if the JWS signs
                detached payload data without explicit reference.<a href="#appendix-C.2.3-2.2.2.2" class="pilcrow">¶</a>
</li>
                <li id="appendix-C.2.3-2.2.2.3">A URI that can be used to identify or fetch the detached
                Signed Data. The means to determine the URI for the detached
                Signed Data is outside the scope of this specification.<a href="#appendix-C.2.3-2.2.2.3" class="pilcrow">¶</a>
</li>
              </ol>
</dd>
            <dd class="break"></dd>
<dt id="appendix-C.2.3-2.3">"hash":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-C.2.3-2.4">The hash over the JWS Payload data bytes (not its
     base64url-encoded string representation).<a href="#appendix-C.2.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
<div id="jws-signer-certificate-references">
<section id="appendix-C.2.4">
          <h4 id="name-jws-signer-certificate-refe">
<a href="#appendix-C.2.4" class="section-number selfRef">C.2.4. </a><a href="#name-jws-signer-certificate-refe" class="section-name selfRef">JWS Signer Certificate References</a>
          </h4>
<p id="appendix-C.2.4-1">The SVT Signature object <span class="bcp14">MUST</span> contain a "signer_cert_ref" claim (CertReference object). The "type" parameter of the "signer_cert_ref" claim <span class="bcp14">MUST</span> be either "chain" or "chain_hash".<a href="#appendix-C.2.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C.2.4-2.1">The "chain" type <span class="bcp14">MUST</span> 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.<a href="#appendix-C.2.4-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-C.2.4-2.2">The "chain_hash" type <span class="bcp14">MUST</span> 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.<a href="#appendix-C.2.4-2.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
<div id="jws-svt-jose-header">
<section id="appendix-C.3">
        <h3 id="name-svt-jose-header-2">
<a href="#appendix-C.3" class="section-number selfRef">C.3. </a><a href="#name-svt-jose-header-2" class="section-name selfRef">SVT JOSE Header</a>
        </h3>
<div id="jws-svt-signing-key-reference">
<section id="appendix-C.3.1">
          <h4 id="name-svt-signing-key-reference-3">
<a href="#appendix-C.3.1" class="section-number selfRef">C.3.1. </a><a href="#name-svt-signing-key-reference-3" class="section-name selfRef">SVT Signing Key Reference</a>
          </h4>
<p id="appendix-C.3.1-1">The SVT JOSE header must contain one of the following header
          parameters in accordance with <span>[<a href="#RFC7515" class="cite xref">RFC7515</a>]</span> for storing
          a reference to the public key used to verify the signature on the
          SVT:<a href="#appendix-C.3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-C.3.1-2">
            <dt id="appendix-C.3.1-2.1">"x5c":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-C.3.1-2.2">Holds an X.509 certificate <span>[<a href="#RFC5280" class="cite xref">RFC5280</a>]</span> or a chain
     of certificates. The certificate holding the public key that
     verifies the signature on the SVT <span class="bcp14">MUST</span> be the first
     certificate in the chain.<a href="#appendix-C.3.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="appendix-C.3.1-2.3">"kid":
            </dt>
            <dd style="margin-left: 1.5em" id="appendix-C.3.1-2.4">A key identifier holding the Base64-encoded hash value of the
     certificate that can verify the signature on the SVT. The hash
     algorithm <span class="bcp14">MUST</span> be the same hash algorithm used when
     signing the SVT as specified by the "<code>alg</code>" Header Parameter.<a href="#appendix-C.3.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="schema-appendix">
<section id="appendix-D">
      <h2 id="name-schemas">
<a href="#appendix-D" class="section-number selfRef">Appendix D. </a><a href="#name-schemas" class="section-name selfRef">Schemas</a>
      </h2>
<div id="concise-data-definition-language-cddl">
<section id="appendix-D.1">
        <h3 id="name-concise-data-definition-lan">
<a href="#appendix-D.1" class="section-number selfRef">D.1. </a><a href="#name-concise-data-definition-lan" class="section-name selfRef">Concise Data Definition Language (CDDL)</a>
        </h3>
<p id="appendix-D.1-1">The following informative CDDL <span>[<a href="#RFC8610" class="cite xref">RFC8610</a>]</span> expresses the structure of an SVT token:<a href="#appendix-D.1-1" class="pilcrow">¶</a></p>
<div id="appendix-D.1-2">
<pre class="breakable lang-cddl sourcecode">
svt = {
  jti: text
  iss: text
  iat: uint
  ? aud: text / [* text]
  ? exp: uint
  sig_val_claims: SigValClaims
}

SigValClaims = {
  ver: text
  profile: text
  hash_algo: text
  sig: [+ Signature]
  ? ext: Extension
}

Signature = {
  sig_ref: SigReference
  sig_data_ref: [+ SignedDataReference]
  signer_cert_ref: CertReference
  sig_val: [+ PolicyValidation]
  ? time_val: [* TimeValidation]
  ? ext: Extension
}

SigReference = {
  ? id: text / null
  sig_hash: binary-value
  sb_hash: binary-value
}

SignedDataReference = {
  ref: text
  hash: binary-value
}


CertReference = {
  type: "chain" / "chain_hash"
  ref: [+ text]
}

PolicyValidation = {
  pol: text
  res: "PASSED" / "FAILED" / "INDETERMINATE"
  ? msg: text / null
  ? ext: Extension
}

TimeValidation = {
  "time": uint
  type: text
  iss: text
  ? id: text / null
  ? hash: binary-value / null
  ? val: [* PolicyValidation]
  ? ext: Extension
}


Extension = {
  + text =&gt; text
} / null

binary-value = text             ; base64 classic with padding
</pre><a href="#appendix-D.1-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="json-schema">
<section id="appendix-D.2">
        <h3 id="name-json-schema">
<a href="#appendix-D.2" class="section-number selfRef">D.2. </a><a href="#name-json-schema" class="section-name selfRef">JSON Schema</a>
        </h3>
<p id="appendix-D.2-1">The following informative JSON schema describes the syntax of the SVT token payload.<a href="#appendix-D.2-1" class="pilcrow">¶</a></p>
<div id="appendix-D.2-2">
<pre class="breakable lang-json sourcecode">
{
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "title": "Signature Validation Token JSON Schema",
    "description": "Schema defining the payload format for SVTs",
    "type": "object",
    "required": [
        "jti",
        "iss",
        "iat",
        "sig_val_claims"
    ],
    "properties": {
        "jti": {
            "description": "JWT ID",
            "type": "string"
        },
        "iss": {
            "description": "Issuer",
            "type": "string"
        },
        "iat": {
            "description": "Issued At",
            "type": "integer"
        },
        "aud": {
            "description": "Audience",
            "type": [
                "string",
                "array"
            ],
            "items": {"type": "string"}
        },
        "exp": {
            "description": "Expiration time (seconds since epoch)",
            "type": "integer"
        },
        "sig_val_claims": {
            "description": "Signature validation claims",
            "type": "object",
            "required": [
                "ver",
                "profile",
                "hash_algo",
                "sig"
            ],
            "properties": {
                "ver": {
                    "description": "Version",
                    "type": "string"
                },
                "profile": {
                    "description": "Implementation profile",
                    "type": "string"
                },
                "hash_algo": {
                    "description": "Hash algorithm URI",
                    "type": "string"
                },
                "sig": {
                    "description": "Validated signatures",
                    "type": "array",
                    "items": {
                        "$ref": "#/$def/Signature"
                    },
                    "minItems": 1
                },
                "ext": {
                    "description": "Extension map",
                    "$ref": "#/$def/Extension"
                }
            },
            "additionalProperties": false
        }
    },
"additionalProperties": false,
"$def": {
         "Signature":{
             "type": "object",
             "required": [
                 "sig_ref",
                 "sig_data_ref",
                 "signer_cert_ref",
                 "sig_val"
             ],
             "properties": {
                 "sig_ref": {
                     "description": "Signature Reference",
                     "$ref": "#/$def/SigReference"
                 },
                 "sig_data_ref": {
                     "description": "Signed data array",
                     "type": "array",
                     "items": {
                         "$ref" : "#/$def/SignedDataReference"
                     },
                     "minItems": 1
                 },
                 "signer_cert_ref": {
                     "description": "Signer certificate reference",
                     "$ref": "#/$def/CertReference"
                 },
                 "sig_val": {
                     "description": "Signature validation results",
                     "type": "array",
                     "items": {
                         "$ref": "#/$def/PolicyValidation"
                     },
                     "minItems": 1
                 },
                 "time_val": {
                     "description": "Time validations",
                     "type": "array",
                     "items": {
                         "$ref": "#/$def/TimeValidation"
                     }
                 },
                "ext": {
                    "description": "Extension map",
                    "$ref": "#/$def/Extension"
                }
             },
             "additionalProperties": false
         },
         "SigReference":{
             "type": "object",
             "required": [
                 "sig_hash",
                 "sb_hash"
             ],
             "properties": {
                 "sig_hash": {
                     "description": "Hash of the signature value",
                     "type": "string",
                     "format": "base64"
                 },
                 "sb_hash": {
                     "description": "Hash of the Signed Bytes",
                     "type": "string",
                     "format": "base64"
                 },
                 "id": {
                     "description": "Signature ID reference",
                     "type": ["string","null"]
                 }
             },
            "additionalProperties": false
         },
         "SignedDataReference": {
             "type": "object",
             "required": [
                 "ref",
                 "hash"
             ],
             "properties": {
                 "ref": {
                     "description": "Reference to the signed data",
                     "type": "string"
                 },
                 "hash": {
                     "description": "Signed data hash",
                     "type": "string",
                     "format": "base64"
                 }
             },
            "additionalProperties": false
         },
         "CertReference":{
             "type": "object",
             "required": [
                 "type",
                 "ref"
             ],
             "properties": {
                 "type": {
                     "description": "Type of certificate reference",
                     "type": "string",
                     "enum": ["chain","chain_hash"]
                 },
                 "ref": {
                     "description": "Certificate reference data",
                     "type": "array",
                     "items": {
                         "type": "string",
                         "format": "base64"
                     },
                     "minItems": 1
                 }
             },
            "additionalProperties": false
         },
         "PolicyValidation":{
             "type": "object",
             "required": [
                 "pol",
                 "res"
             ],
             "properties": {
                 "pol": {
                     "description": "Policy identifier",
                     "type": "string"
                 },
                 "res": {
                     "description": "Signature validation result",
                     "type": "string",
                     "enum": ["PASSED","FAILED","INDETERMINATE"]
                 },
                 "msg": {
                     "description": "Message",
                     "type": ["string","null"]
                 },
                 "ext": {
                    "description": "Extension map",
                    "$ref": "#/$def/Extension"
                }
             },
            "additionalProperties": false
         },
         "TimeValidation":{
             "type": "object",
             "required": [
                 "time",
                 "type",
                 "iss"
             ],
             "properties": {
                 "time": {
                     "description": "Verified time",
                     "type": "integer"
                 },
                 "type": {
                     "description": "Type of time validation proof",
                     "type": "string"
                 },
                 "iss": {
                     "description": "Issuer of the time proof",
                     "type": "string"
                 },
                 "id": {
                     "description": "Time evidence identifier",
                     "type": ["string","null"]

                 },
                 "hash": {
                     "description": "Hash of time evidence",
                     "type": ["string","null"],
                     "format": "base64"
                 },
                 "val": {
                     "description": "Validation result",
                     "type": "array",
                     "items": {
                         "$ref": "#/$def/PolicyValidation"
                     }
                 },
                 "ext": {
                    "description": "Extension map",
                    "$ref": "#/$def/Extension"
                }
             },
            "additionalProperties": false
         },
         "Extension": {
           "description": "Extension map",
           "type": ["object","null"],
           "required": [],
           "additionalProperties": {
               "type": "string"
           }
         }
     }
}
</pre><a href="#appendix-D.2-2" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="appendix-examples">
<section id="appendix-E">
      <h2 id="name-examples">
<a href="#appendix-E" class="section-number selfRef">Appendix E. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="appendix-E-1">The following example illustrates a basic SVT according to this specification
issued for a signed PDF document.<a href="#appendix-E-1" class="pilcrow">¶</a></p>
<p id="appendix-E-2">Note: Line breaks in the decoded example are inserted for readability. Line
breaks are not allowed in valid JSON data.<a href="#appendix-E-2" class="pilcrow">¶</a></p>
<p id="appendix-E-3">Signature validation token JWT:<a href="#appendix-E-3" class="pilcrow">¶</a></p>
<div id="appendix-E-4">
<pre class="sourcecode">
eyJraWQiOiJPZW5JKzQzNEpoYnZmRG50ZlZcLzhyT3hHN0ZrdnlqYUtWSmFWcUlG
QlhvaFZoQWU1Zks4YW5vdjFTNjg4cjdLYmFsK2Z2cGFIMWo4aWJnNTJRQnkxUFE9
PSIsInR5cCI6IkpXVCIsImFsZyI6IlJTNTEyIn0.eyJhdWQiOiJodHRwOlwvXC9l
eGFtcGxlLmNvbVwvYXVkaWVuY2UxIiwiaXNzIjoiaHR0cHM6XC9cL3N3ZWRlbmNv
bm5lY3Quc2VcL3ZhbGlkYXRvciIsImlhdCI6MTYwMzQ1ODQyMSwianRpIjoiNGQx
Mzk2ZjFmZjcyOGY0MGQ1MjQwM2I2MWM1NzQ0ODYiLCJzaWdfdmFsX2NsYWltcyI6
eyJzaWciOlt7ImV4dCI6bnVsbCwic2lnX3ZhbCI6W3sibXNnIjoiT0siLCJleHQi
Om51bGwsInJlcyI6IlBBU1NFRCIsInBvbCI6Imh0dHA6XC9cL2lkLnN3ZWRlbmNv
bm5lY3Quc2VcL3N2dFwvc2lndmFsLXBvbGljeVwvdHMtcGtpeFwvMDEifV0sInNp
Z19yZWYiOnsic2lnX2hhc2giOiJ5Y2VQVkxJemRjcEs5N0lZT2hGSWYxbnk3OUht
SUNiU1Z6SWVaTmJpem83ckdJd0hOTjB6WElTeUtHakN2bm9uT2FRR2ZMXC9QM3ZE
dEI4OHlLU1dlWGc9PSIsImlkIjoiaWQtNzM5ODljNmZjMDYzNjM2YWI1ZTc1M2Yx
MGY3NTc0NjciLCJzYl9oYXNoIjoiQm9QVjRXQ0E5c0FJYWhqSzFIYWpmRnhpK0F6
QzRKR1R1ZjM5VzNaV2pjekRDVVJ4ZGM5WWV0ZUh0Y3hHVmVnZ3B4SEo3NVwvY1E3
SE4xZERkbGl5SXdnPT0ifSwic2lnbmVyX2NlcnRfcmVmIjp7InJlZiI6WyIxK2Fh
SmV0ZzdyZWxFUmxVRFlFaVU0WklaaFQ0UlV2aUlRWnVLN28xR0ZLYVRQUTZ5K2t4
XC9QTnREcnB1cVE2WGZya0g5d1lESzRleTB5NFdyTkVybnc9PSIsImg0UER4YjVa
S214MWVUU3F2VnZZRzhnMzNzMDVKendCK05nRUhGVTRnYzl0cUcwa2dIa2Y2VzNv
THprVHd3dXJJaDZZOUFhZlpZcWMyelAycEUycDRRPT0iLCJEZDJDNXNCMElPUWVN
Vm5FQmtNNVE5Vzk2bUJITnd3YTJ0elhNcytMd3VZY09VdlBrcnlHUjBhUEc4Tzlu
SVAzbGJ3NktqUTFoRG1SazZ6Qzh4MmpkZz09Il0sInR5cGUiOiJjaGFpbl9oYXNo
In0sInNpZ19kYXRhX3JlZiI6W3sicmVmIjoiIiwiaGFzaCI6IkZjR3BPT2Y4aWxj
UHQyMUdEZDJjR25MR0R4UlM1ajdzdk00YXBwMkg0MWRERUxtMkN6Y2VUWTAybmRl
SmZXamludG1RMzc2SWxYVE9BcjMxeXpZenNnPT0ifSx7InJlZiI6IiN4YWRlcy0x
MWExNTVkOTJiZjU1Nzc0NjEzYmI3YjY2MTQ3N2NmZCIsImhhc2giOiJLUmtnYlo2
UFwvbmhVNjNJTWswR2lVZlVcL0RUd3ZlWWl0ZVFrd0dlSnFDNUJ6VE5WOGJRYnBl
ZFRUdVdKUHhxdkowUlk4NGh3bTdlWVwvZzBIckFPZWdLdz09In1dLCJ0aW1lX3Zh
bCI6W119XSwiZXh0IjpudWxsLCJ2ZXIiOiIxLjAiLCJwcm9maWxlIjoiWE1MIiwi
aGFzaF9hbGdvIjoiaHR0cDpcL1wvd3d3LnczLm9yZ1wvMjAwMVwvMDRcL3htbGVu
YyNzaGE1MTIifX0.TdHCoIUSZj2zMINKg7E44-8VE_mJq6TG1OoPwnYSs_hyUbuX
mrLJpuk8GR5YrndeOucPUYAwPxHt_f68JIQyFTi0agO9VJjn1R7Pj3Jt6WG9pYVN
n5LH-D1maxD11ZxxbcYeHbsstd2Sy2uMa3BdpsstGdPymSmc6GxY5uJoL0-5vwo_
3l-4Bb3LCTiuxYPcmztKIbDy2hEgJ3Hx1K4HF0SHgn3InpqBev3hm2SLw3hH5BCM
rywBAhHYE6OGE0aOJ6ktA5UP0jIIHfaw9i1wIiJtHTaGuvtyWSLk5cshmun9Hkdk
kRTA75bzuq0Iyd0qh070rA8Gje-s4Tw4xzttgKx1KSkvy8n5FqvzWdsZvclCG2mY
Y9rMxh_7607NXcxajAP4yDOoKNs5nm937ULe0vCN8a7WTrFuiaGjry7HhzRM4C5A
qxbDOBXPLyoMr4qn4LRJCHxOeLZ6o3ugvDOOWsyjk3eliyBwDu8qJH7UmyicLxDc
Cr0hUK_kvREqjD2Z
</pre><a href="#appendix-E-4" class="pilcrow">¶</a>
</div>
<p id="appendix-E-5">Decoded JWT Header:<a href="#appendix-E-5" class="pilcrow">¶</a></p>
<div id="appendix-E-6">
<pre class="sourcecode">
{
  "kid":"OenI+434JhbvfDntfV\/8rOxG7FkvyjaKVJaVqIFBXohVhAe5fK8anov
         1S688r7Kbal+fvpaH1j8ibg52QBy1PQ==",
  "typ":"JWT",
  "alg":"RS512"
}
</pre><a href="#appendix-E-6" class="pilcrow">¶</a>
</div>
<p id="appendix-E-7">Decoded JWT Claims:<a href="#appendix-E-7" class="pilcrow">¶</a></p>
<div id="appendix-E-8">
<pre class="sourcecode">
{
  "aud" : "http://example.com/audience1",
  "iss" : "https://swedenconnect.se/validator",
  "iat" : 1603458421,
  "jti" : "4d1396f1ff728f40d52403b61c574486",
  "sig_val_claims" : {
    "sig" : [ {
      "ext" : null,
      "sig_val" : [ {
        "msg" : "OK",
        "ext" : null,
        "res" : "PASSED",
        "pol" : "http://id.swedenconnect.se/svt/sigval-policy/
                 ts-pkix/01"
      } ],
      "sig_ref" : {
        "sig_hash" : "ycePVLIzdcpK97IYOhFIf1ny79HmICbSVzIeZNbizo7rGIw
                      HNN0zXISyKGjCvnonOaQGfL/P3vDtB88yKSWeXg==",
        "id" : "id-73989c6fc063636ab5e753f10f757467",
        "sb_hash" : "BoPV4WCA9sAIahjK1HajfFxi+AzC4JGTuf39W3ZWjczDCURx
                     dc9YeteHtcxGVeggpxHJ75/cQ7HN1dDdliyIwg=="
      },
      "signer_cert_ref" : {
        "ref" : [ "1+aaJetg7relERlUDYEiU4ZIZhT4RUviIQZuK7o1GFKaTPQ6y+
                   kx/PNtDrpuqQ6XfrkH9wYDK4ey0y4WrNErnw==",
                  "h4PDxb5ZKmx1eTSqvVvYG8g33s05JzwB+NgEHFU4gc9tqG0kgH
                   kf6W3oLzkTwwurIh6Y9AafZYqc2zP2pE2p4Q==",
                  "Dd2C5sB0IOQeMVnEBkM5Q9W96mBHNwwa2tzXMs+LwuYcOUvPkr
                   yGR0aPG8O9nIP3lbw6KjQ1hDmRk6zC8x2jdg==" ],
        "type" : "chain_hash"
      },
      "sig_data_ref" : [ {
        "ref" : "",
        "hash" : "FcGpOOf8ilcPt21GDd2cGnLGDxRS5j7svM4app2H41dDELm2Czc
                  eTY02ndeJfWjintmQ376IlXTOAr31yzYzsg=="
      }, {
        "ref" : "#xades-11a155d92bf55774613bb7b661477cfd",
        "hash" : "KRkgbZ6P/nhU63IMk0GiUfU/DTwveYiteQkwGeJqC5BzTNV8bQb
                  pedTTuWJPxqvJ0RY84hwm7eY/g0HrAOegKw=="
      } ],
      "time_val" : [ ]
    } ],
    "ext" : null,
    "ver" : "1.0",
    "profile" : "XML",
    "hash_algo" : "http://www.w3.org/2001/04/xmlenc#sha512"
  }
}
</pre><a href="#appendix-E-8" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-F">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stefan Santesson</span></div>
<div dir="auto" class="left"><span class="org">IDsec Solutions AB</span></div>
<div dir="auto" class="left"><span class="street-address">Forskningsbyn Ideon</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">223 70</span> <span class="locality">Lund</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sts@aaa-sec.com" class="email">sts@aaa-sec.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Russ Housley</span></div>
<div dir="auto" class="left"><span class="org">Vigil Security, LLC</span></div>
<div dir="auto" class="left"><span class="street-address">516 Dranesville Road</span></div>
<div dir="auto" class="left">
<span class="locality">Herndon</span>, <span class="region">VA</span> <span class="postal-code">20170</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:housley@vigilsec.com" class="email">housley@vigilsec.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>