One document matched: draft-richer-vectors-of-trust-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-richer-vectors-of-trust-01"
ipr="trust200902">
<front>
<title abbrev="vectors-of-trust">Vectors of Trust</title>
<author fullname="Justin Richer" initials="J." role="editor"
surname="Richer">
<organization>Bespoke Engineering</organization>
<address>
<email>ietf@justin.richer.org</email>
</address>
</author>
<author fullname="Leif Johansson" initials="L." surname="Johansson">
<organization>Swedish University Network</organization>
<address>
<postal>
<street>Thulegatan 11</street>
<city>Stockholm</city>
<region/>
<code/>
<country>Sweden</country>
</postal>
<phone/>
<facsimile/>
<email>leifj@sunet.se</email>
<uri>http://www.sunet.se</uri>
</address>
</author>
<date day="4" month="September" year="2015"/>
<abstract>
<t>This document defines a mechanism for describing and signaling
several aspects that are used to calculate trust placed in a digital
identity transaction.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>This document defines a mechanism for describing and signaling
several aspects of digital identity transactions that are used to
determine a level of trust in that transaction. In the past, there have
been two extremes of communicating authentication transaction
information. On one end, all attributes are communicated with full
provenance and associated trust markings. This approach seeks to create
a fully distributed attribute system that can be used for things like
attribute based access control (ABAC). These attributes can be used to
describe the end user, the identity provider, the relying party, or even
the transaction itself. While the information that can be expressed in
this model is incredible, the complexity of such a system is often
prohibitive to align across security domains, especially to relying
parties needing to process the sea of disparate attributes.</t>
<t>At the other extreme there are systems that collapse all of the
attributes and aspects into a single scalar value that communicates, in
sum, how much a transaction can be trusted. The NIST special publication
<xref target="SP-800-63">800-63</xref> defines a linear scale Level of
Assurance (LoA) measure that combines multiple attributes about an
identity transaction into a single measure of the level of trust a
relying party should place on an identity transaction. Even though this
definition was originally made for a specific government use cases, the
LoA scale appeared to be applicable with a wide variety of
authentication use cases. This has led to a proliferation of
incompatible interpretations of the same scale in different trust
frameworks, preventing interoperability between these frameworks in
spite of their common measurement. Since identity proofing strength
increases linearly along with credential strength in the LoA scale, this
scale is too limited for describing many valid and useful forms of an
identity transaction. For example, an anonymously assigned hardware
token can be used in cases where the real world identity of the subject
cannot be known, for privacy reasons, but the credential itself can be
highly trusted.</t>
<t>This work seeks to find a balance between these two extremes by
creating a data model that combines attributes of the user and aspects
of the authenticaiton context into several values that can be
communicated together. This approach is both coarser grained than the
distributed attributes model and finer grained than the single value
model, with the hope that it is a viable balance of expressivity and
processability. Importantly, these three levels of granularity can be
mapped to each other. The information of several attributes can be
folded into a vector component, while the vector itself can be folded
into an assurance category. As such, the vectors of trust seeks to
complement, not replace, these other identity and trust mechanisms.</t>
<section title="Terminology">
<t><list style="hanging">
<t hangText="Identity Provider (IdP)">A system that manages
identity information and is able to assert this information across
the network through an identity API.</t>
<t hangText="Identity Subject">The person (user) engaging in the
identity transaction, being identified by the identity provider
and identified to the relying party.</t>
<t hangText="Primary Credential">The credential used by the
identity subject to authenticate to the identity provider.</t>
<t hangText="Federated Credential">The assertion presented by the
IdP to the RP across the network to authenticate the user.</t>
<t hangText="Relying Party (RP)">A system that consumes identity
information from an IdP for the purposes of authenticating the
user.</t>
<t hangText="Trust Framework">A document containing business rules
and legal clauses that defines how different parties in an
identity transaction may act.</t>
<t hangText="Trustmark">A verifiable attestation that a party has
proved to follow the constraints of a trust framework.</t>
<t hangText="Trustmark Provider">A system that issues and provides
verification for trustmarks.</t>
<t hangText="Vector">A multi-part data structure, used here for
conveying information about an authentication transaction.</t>
<t hangText="Vector Component">One of several constituent parts
that make up a vector.</t>
</list></t>
</section>
<section anchor="Model" title="An Identity Model">
<t>This document assumes the following (incomplete) model for
identity.</t>
<t>The identity subject (aka user) is associated with an identity
provider which acts as a trusted 3rd party on behalf of the user with
regard to a relying party by making identity assertions about the user
to the relying party.</t>
<t>The real-world person represented by the identity subject is in
possession of a primary credential bound to the identity subject by
identity provider (or an agent thereof) in such a way that the binding
between the credential and the real-world user is a representation of
the identity proofing process performed by the the identity provider
(or an agent thereof) to verify the identity of the real-world
person.</t>
</section>
<section anchor="Architecture" title="Component Architecture">
<t>The term Vectors of Trust is based on the mathematical construct of
a Vector, which is defined as an item composed of multiple independent
scalar values. A vector is a set of coordinates that specifies a point
in a (multi-dimensional) Cartesian coordinate space. The reader is
encouraged to think of a vector of trust as a point in a coordinate
system, in the simples form (described below) a 3 dimensional space
that is intended to be a recognizable, if somewhat elided, model of
identity subject trust.</t>
<t>An important goal for this work is to balance the need for
simplicity (particularly on the part of the relying party) with the
need for expressiveness. As such, this vector construct is designed to
be composable and extensible.</t>
<t>All components of the vector construct MUST be orthogonal in the
sense that no aspect of a component overlap an aspect of another
component.</t>
<t>The values assigned to each component of a vector is sometimes
written as an ordinal number (e.g. an integer) but MUST NOT be assumed
as having inherent ordinal properties when compared to the same or
other components in the vector space. In other words, 1 is different
from 2, but it is dangerous to assume that 2 is always "more" (better)
than 1.</t>
</section>
</section>
<section anchor="Components" title="Core Components">
<t>This specification defines four orthogonal components: identity
proofing, primary credential usge, primary credential management, and
assertion presentation. These dimensions MUST be evaluated in the
context of a trust framework and SHOULD be combined with other
information when making a trust and authorization decision.</t>
<t>This specification also defines values for each component to be used
in the absence of a more specific trust framework. It is expected that
trust frameworks will provide context, semantics, and mapping to legal
statutes and business rules for each value in each component.
Consequently, a particular vector value can only be compared with
vectors defined in the same context. The RP MUST understand and take
into account the trust framework context in which a vector is being
expressed in order for it to be processed securely.</t>
<t>It is anticipated that trust frameworks will also define additional
components using the component registry established in <xref
target="IANA"/>.</t>
<t>Each component is identified by a demarcator consisting of a single
case-sensitive ASCII character in the range [A-Za-z]. A value for a
given component is defined by its demarcator character followed by a
single case-sensitive ASCII character in the range [0-9A-Za-z].</t>
<section anchor="IdentityProofing" title="Identity Proofing">
<t>The Identity Proofing dimension defines, overall, how strongly the
set of identity attributes have been verified and vetted, and how
strongly they are tied to a particular credential set. In other words,
this dimension describes how likely it is that a given digital
identity corresponds to a particular (real-world) identity
subject.</t>
<t>This dimension SHALL be represented by the <spanx style="verb">P</spanx>
demarcator and a single-character level value, such as <spanx
style="verb">P1</spanx>, <spanx style="verb">P2</spanx>, etc.</t>
</section>
<section anchor="Credential" title="Primary Credential Usage">
<t>The primary credential usage dimension defines how strongly the
primary credential can be verified by the IdP. In other words, and how
easily that credential could be spoofed or stolen.</t>
<t>This dimension SHALL be represented by the <spanx style="verb">C</spanx>
demarcator and a single-character level value, such as <spanx
style="verb">C1</spanx>, <spanx style="verb">C2</spanx>, etc. Multiple
credential usage factors MAY be communicated simultaneously, such as
when Multi-Factor Authentication is used.</t>
</section>
<section title="Primary Credential Management">
<t>The primary credential management dimension conveys information
about the expected lifecycle of the primary credential in use,
including its binding, rotation, and revocation. This component
defines how strongly the primary credential can be trusted to be
presented by the party represented by the credential based on
knowledge of the management of the credentials at the IdP. In other
words, this dimension describes how likely it is that the right person
is presenting the credential to the identity provider.</t>
<t>This dimension SHALL be represented by the <spanx style="verb">M</spanx>
demarcator and a single-character level value, such as <spanx
style="verb">M1</spanx>, <spanx style="verb">M2</spanx>, etc.</t>
</section>
<section anchor="AssertionPresentation" title="Assertion Presentation">
<t>The Assertion Presentation dimension defines how well the given
digital identity can be communicated across the network without
information leaking to unintended parties, and without spoofing. In
other words, this dimension describes how likely it is that a given
digital identity asserted was actually asserted by a given identity
provider for a given transaction. While this information is largely
already known by the RP by the nature of processing an identity
assertion, this dimension is still useful when the RP <xref
target="RequestingVector">requests a login</xref> and when describing
the <xref target="discovery">capabilities of an IdP</xref>.</t>
<t>This dimension SHALL be represented by the <spanx style="verb">A</spanx>
demarcator and a level value, such as <spanx style="verb">A1</spanx>,
<spanx style="verb">A2</spanx>, etc.</t>
</section>
</section>
<section anchor="default-components"
title="Vectors of Trust Inititial Component Definitions">
<t>This specification defines the following general-purpose component
definitions, which MAY be used when a more specific set is unavailable.
These component values are referenced in a trustmark definition defined
by [[ this document URL ]].</t>
<t><list style="hanging">
<t hangText="P0">No proofing is done, data is not guaranteed to be
persistent across sessions</t>
<t hangText="P1">Attributes are self-asserted but consistent over
time, potentially pseudonymous</t>
<t hangText="P2">Identity has been proofed either in person or
remotely using trusted mechanisms (such as social proofing)</t>
<t hangText="P3">There is a binding relationship between the
identity provider and the identified party (such as signed/notarized
documents, employment records)</t>
</list><list style="hanging">
<t hangText="C0">No credential is used / anonymous public service /
simple session cookies (with nothing else)</t>
<t hangText="C1">Known device</t>
<t hangText="C2">Shared secret such as a username and password
combination</t>
<t hangText="C3">Cryptographic proof of key possession using shared
key</t>
<t hangText="C4">Cryptographic proof of key possession using
asymmetric key</t>
<t hangText="C5">Sealed hardware token / trusted biometric /
TPM-backed keys</t>
</list><list style="hanging">
<t hangText="M0">Self-asserted credentials</t>
<t hangText="M1">Remote issuance and rotation / use of backup
recover credentials (such as email verification) / deletion on user
request</t>
<t hangText="M2">Full proofing required for each issuance and
rotation / revocation on suspicious activity</t>
</list><list style="hanging">
<t hangText="A0">No protection / unsigned bearer identifier (such as
a session cookie)</t>
<t hangText="A1">Signed and verifiable token, passed through the
browser</t>
<t hangText="A2">Signed and verifiable token, passed through a back
channel</t>
<t hangText="A3">Token encrypted to the relying parties key and
audience protected</t>
</list></t>
</section>
<section anchor="Combining" title="Communicating Vector Values to RPs">
<t>All four of these dimensions (and others, as they are defined in
extension work) MUST be combined into a single vector that can be
communicated across the wire unbroken. All vector components MUST be
individually available, MUST NOT be "collapsed" into a single value
without also presenting the constituent dimensions as well.</t>
<t>When communicating the vectors across the wire, they MUST be
protected in transit and MUST signed by the asserting authority (such as
the IdP).</t>
<section title="On the Wire Representation">
<t>The vector MUST be represented as a period-separated ('.') list of
vector components, with no specific order. A vector component type MAY
occur multiple times within a single vector, with each component
separated by periods. Multiple values for a component are considered
an AND of the values. A single value of a vector component MUST NOT
occur more than once in a single vector. In order to simplify
processing by RPs, it is RECOMMENDED that trust framework definitions
carefully define component values such that they are mutually
exclusive or subsumptive in order to avoid repeated vector components
where possible.</t>
<t>Vector components MAY be omitted from a vector. No holding space is
left for an omitted vector component. If a vector component is
omitted, the IdP is making no claim for that category.</t>
<t>For example, the vector value <spanx style="verb">P1.C3.A2</spanx>
translates to pseudonymous, proof of shared key, signed back-channel
verified token in the context of this specification's <xref
target="default-components">definitions</xref>.</t>
<t>Vector values MUST be communicated along side of a trustmark
definition to give the components context. A vector value without
context is unprocessable.</t>
</section>
<section anchor="OIDC" title="In OpenID Connect">
<t>In <xref target="OpenID">OpenID Connect</xref>, the IdP MUST send
the vector value as a string with the <spanx style="verb">vot</spanx>
(vector of trust) claim in the ID token. The <xref
target="Trustmark">trustmark</xref> that applies to this vector MUST
be sent as an HTTPS URL in the <spanx style="verb">vtm</spanx> (vector
trust mark) claim to provide context to the vector.</t>
<t>For example:</t>
<figure>
<artwork><![CDATA[{
"iss": "https://idp.example.com/",
"sub": "jondoe1234",
"vot": "P1.C3.A2",
"vtm": "https://trustmark.example.org/trustmark/idp.example.com"
}]]></artwork>
</figure>
</section>
<section anchor="SAML" title="In SAML">
<t>In SAML a VoT vector is communicated as an
AuthenticationContextClassRef, a sample definition of which might look
something like this:</t>
<figure>
<artwork><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:x-vot:P1:C3:A2"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:x-vot:P1.C3.A2"
finalDefault="extension"
blockDefault="substitution"
version="2.0">
<xs:redefine
schemaLocation="saml-schema-authn-context-loa-profile.xsd"/>
<xs:annotation>
<xs:documentation>VoT vector P1.C3.A2</xs:documentation>
</xs:annotation>
<xs:complexType name="GoverningAgreementRefType">
<xs:complexContent>
<xs:restriction base="GoverningAgreementRefType">
<xs:attribute name="governingAgreementRef"
type="xs:anyURI"
fixed="draft-ietf-vot-this-document-00.txt"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
</xs:schema>]]></artwork>
</figure>
</section>
</section>
<section anchor="RequestingVector" title="Requesting Vector Values">
<t>In some identity protocols, the RP can request that particular
attributes be applied to a given identity transaction.</t>
<section anchor="RequestingOIDC" title="In OpenID Connect">
<t>In <xref target="OpenID">OpenID Connect</xref>, the client can
request a set of acceptable VoT values with the <spanx style="verb">vtr</spanx>
(vector of trust request) claim request as part of the Request Object.
The value of this field is an array of JSON strings, each string
identifying an acceptable set of vector components. The components
within each vector are ANDed together while the individual vector
strings are ORed together. Vector request values MAY omit components,
indicating that any value is acceptable.</t>
<figure>
<artwork><![CDATA[{
"vtr": ["P1.C2.C3.A2", "C5.A2"]
}]]></artwork>
</figure>
</section>
</section>
<section anchor="DiscoveryAndVerification"
title="Discovery and Verification">
<section anchor="Trustmark" title="Trustmark">
<t>When an RP receives a specific vector from an IdP, it needs to make
a decision to trust the vector within a specific context. A trust
framework can provide such a context, allowing legal and business
rules to give weight to an IdP's claims. A trustmark is a verifiable
claim to conform to a specific component of a trust framework, such as
a verified identity provider. The trustmark conveys the root of
trustworthiness about the claims and assertions made by the IdP.</t>
<t>The trustmark MUST be available from an HTTPS URL served by the
trust framework provider. The contents of this URL are a <xref
target="RFC7159">JSON</xref> document with the following fields:</t>
<t><list style="hanging">
<t hangText="idp">The issuer URL of the identity provider that
this trustmark pertains to. This MUST match the corresponding
issuer claim in the identity token, such as the OpenID Connect
<spanx style="verb">iss</spanx> field. This MUST be an HTTPS
URL.</t>
<t hangText="trustmark_provider">The issuer URL of the trustmark
provider that issues this trustmark. The URL that a trustmark is
fetched from MUST start with the <spanx style="verb">iss</spanx>
URL in this field. This MUST be an HTTPS URL.</t>
<t hangText="P">Array of strings containing identity proofing
values for which the identity provider has been assessed and
approved</t>
<t hangText="C">Array of strings containing primary credential
usage values for which the identity provider has been assessed and
approved</t>
<t hangText="M">Array of strings containing primary credential
management values for which the identitity provider has been
assessed and approved</t>
<t hangText="A">Array of strings containing assertion strength
values for which the identity provider has been assessed and
approved</t>
</list></t>
<t>Additional vector component values MUST be listed in a similar
fashion using their demarcator.</t>
<t>For example, the following trustmark provided by the
trustmark.example.org organization applies to the idp.example.org
identity provider:</t>
<figure>
<artwork><![CDATA[{
"idp": "https://idp.example.org/",
"trustmark_provider": "https://trustmark.example.org/",
"P": ["P0", "P1"],
"C": ["C1", "C2", "C3"],
"M": ["M2"],
"A": ["C2", "C3"]
}]]></artwork>
</figure>
<t>A client wishing to check the claims made by an IdP can fetch the
information from the trustmark provider about what claims the IdP is
allowed to make in the first place and process them accordingly.</t>
<t>The means by which the RP decides which trustmark providers it
trusts is out of scope for this specification and is generally
configured out of band.</t>
<t>Though most trust frameworks will provide a third-party independent
verification service for components, an IdP MAY host its own
trustmark. For example, a self-hosted trustmark would look like:</t>
<figure>
<artwork><![CDATA[{
"idp": "https://idp.example.org/",
"trustmark_provider": "https://idp.example.org/",
"P": ["C0", "C1"],
"C": ["C1", "C2", "C3"],
"M": ["M2"],
"A": ["C2", "C3"]
}]]></artwork>
</figure>
</section>
<section anchor="discovery" title="Discovery">
<t>The IdP MAY list all of its available trustmarks as part of its
discovery document, such as the OpenID Connect Discovery server
configuration document. Trustmarks are listed in the trustmarks
element which contains a single <xref target="RFC7159">JSON</xref>
object. The keys of this JSON object are trustmark provider issuer
URLs and the values of this object are the corresponding trustmarks
for this IdP.</t>
<figure>
<artwork><![CDATA[{
"trustmark": {
"https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/
}
}]]></artwork>
</figure>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank the members of the Vectors of Trust
mailing list in the IETF for discussion and feedback on the concept and
document.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification creates one registry and registers several values
into an existing registry.</t>
<section title="Vector Of Trust Components Registry">
<t>The Vector of Trust Components Registry contains the definitions of
vector components and their associated demarcators.</t>
<t><list style="symbols">
<t>Demarcator Symbol: P</t>
<t>Description: Identity proofing</t>
<t>Document: [[ this document ]]</t>
</list><list style="symbols">
<t>Demarcator Symbol: C</t>
<t>Description: Primary credential usage</t>
<t>Document: [[ this document ]]</t>
</list><list style="symbols">
<t>Demarcator Symbol: M</t>
<t>Description: Primary credential management</t>
<t>Document: [[ this document ]]</t>
</list><list style="symbols">
<t>Demarcator Symbol: A</t>
<t>Description: Assertion presentation</t>
<t>Document: [[ this document ]]</t>
</list></t>
</section>
<section title="Additions to JWT Claims Registry">
<t>This specification adds the following values to the JWT Claims
Registry.</t>
<t><list style="symbols">
<t>Claim name: vot</t>
<t>Description: Vector of Trust value</t>
<t>Document: [[ this document ]]</t>
</list><list style="symbols">
<t>Demarcator Symbol: vtm</t>
<t>Description: Vector of Trust Trustmark</t>
<t>Document: [[ this document ]]</t>
</list><list style="symbols">
<t>Demarcator Symbol: vtr</t>
<t>Description: Vector of Trust Request</t>
<t>Document: [[ this document ]]</t>
</list></t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The vector of trust value MUST be cryptographically protected in
transit, using TLS. The vector of trust value MUST be associated with a
trustmark marker, and the two MUST be carried together in a
cryptographically bound mechanism such as a signed identity
assertion.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>By design, vector of trust values contain information about a user's
identity and assications that can be made thereto. Therefore, all
aspects of a vector of trust contain potentially privacy-sensitive
information and MUST be guarded as such.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'?>
<?rfc include='http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7159.xml'?>
<reference anchor="OpenID">
<front>
<title>OpenID Connect Core 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<date day="8" month="November" year="2014"/>
</front>
<format target="http://openid.net/specs/openid-connect-core-1_0.html"
type="HTML"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="SP-800-63">
<front>
<title>Electronic Authentication Guideline</title>
<author fullname="William E. Burr">
<organization/>
</author>
<author fullname="Donna F. Dodson">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Elaine M. Newton">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Ray A. Perlner">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="W. Timothy Polk">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Sarbari Gupta">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Emad A. Nabbus">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date month="August" year="2013"/>
</front>
<format type="PDF"/>
</reference>
</references>
<section title="Document History">
<t>- 01</t>
<t><list style="symbols">
<t>Added IANA registry for components.</t>
<t>Added preliminary security considerations and privacy
considerations.</t>
<t>Split "credential binding" into "primary credential usage" and
"primary credential management".</t>
</list></t>
<t>- 00</t>
<t><list style="symbols">
<t>Created initial IETF drafted based on strawman proposal discussed
on VoT list.</t>
<t>Split vector component definitions into their own section to
allow extension and override.</t>
<t>Solidified trustmark document definition.</t>
</list></t>
</section>
<section title="Example Extension">
<t>To extend the vector component definitions, a specification MUST
register its contents in the</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:10:53 |