Vectors of TrustBespoke Engineeringietf@justin.richer.orgSwedish University NetworkThulegatan 11StockholmSwedenleifj@sunet.sehttp://www.sunet.seThis document defines a mechanism for describing and signaling
several aspects of a digital identity transaction and its participants.
These aspects are used to determine the trust to be placed in that
transaction.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
RFC 2119RFC
8174 when, and only when, they appear in all capitals, as shown
here.Methods for measuring trust in digital identity transactions have
historically fallen into two main categories: either all measurements
are combined into a single scalar value, or trust decisions are
calculated locally based on a detailed set of attribute metadata. This
document defines a method of conveying trust information that is more
expressive than a single value but less complex than comprehensive
attribute metadata.Prior to the third edition
published in 2017, NIST Special Publication
800-63 used a single scalar measurement of trust called a Level
of Assurance (LoA). An LoA can be used to compare different transactions
within a system at a coarse level. For instance, an LoA4 transaction is
generally considered more trusted (across all measured categories) than
an LoA2 transaction. The LoA for a given transaction is computed by the
identity provider (IdP) and is consumed by a relying party (RP). Since
the trust measurement is a simple numeric value, it's trivial for RPs to
process and compare. However, since each LoA encompasses many different
aspects of a transaction, it can't express many real-world situations.
For instance, an anonymous user account might have a very strong
credential, such as would be common of a whistle-blower or political
dissident. Despite the strong credential, the lack of identity proofing
would make any transactions conducted by the account to fall into a low
LoA. Furthermore, different use cases and domains require subtly
different definitions for their LoA categories, and one group's LoA2 is
not equivalent or even comparable to another group's LoA2.Attribute based access control (ABAC) systems used by RPs may need to
know details about a user's attributes, such as how recently the
attribute data was verified and by whom. Attribute metadata systems are
capable of expressing extremely fine-grained detail about the
transaction. However, this approach requires the IdP to collect, store,
and transmit all of this attribute data for the RP's consumption. The RP
must process this data, which may be prohibitive for trivial security
decisions.Vectors of Trust (VoT) seeks a balance between these two alternatives
by allowing expression of multiple aspects of an identity transaction
(including but not limited to identity proofing, credential strength,
credential management, and assertion strength), without requiring full
attribute metadata descriptions. This method of measurement gives more
actionable data and expressiveness than an LoA, but is still relatively
easy for the RP to process. It is anticipated that VoT can be used
alongside more detailed attribute metadata systems as has that proposed
by NISITIR 8112. The RP can use the
vector value for most basic decisions but be able to query the IdP for
additional attribute metadata where needed. Furthermore, it is
anticipated that some trust frameworks will provide a simple mapping
between certain sets of vector values to LoAs, for RPs that do not have
a need for the vector's more fine-grained detail. In such systems, an RP
is given a choice of how much detail to request from the IdP in order to
process a given transaction.This document defines a data model for these vectors and an
on-the-wire format for conveying them between parties, anchored in a
trust definition. This document also provides guidance for defining
values for use in conveying this information, including four component
categories and guidance on defining values within those categories.
Additionally, this document defines a general-purpose set of component
values in an appendix for use
cases that do not need something more specific.A protocol in which an Identity
Provider (IdP) asserts a user's identity information to a relying
party (RP) through the use of a cryptographic assertion or other
verifiable mechanism, or a system implementing such a protocol.
Also referred to simply as "federation".A system that manages
identity information and is able to assert this information across
the network through an identity API.The person (user) engaging in the
identity transaction, being identified by the identity provider to
the relying party.The process of verifying and
validating that a set of identity attributes belongs to a
real-world identity subject.The means used by the identity
subject to authenticate to the identity provider.The assertion presented by the
IdP to the RP across the network to authenticate the user.A system that consumes identity
information from an IdP for the purposes of authenticating the
user.A document containing business rules
and legal clauses that defines how different parties in an
identity transaction may act.A URI referencing a specific Trust
Framework and its definition of vector components and vector
component values.A system that can verify that a
given system (such as an identity provider) is both capable of
asserting and allowed to assert the vector component values it is
claiming.A multi-part data structure, used here for
conveying information about an authentication transaction.One of several constituent parts
that make up a vector, indicating a category of information.One of the values applied to
a vector component within a vector.This document assumes the following model for identity based on
identity federation technologies:The identity subject (also known as the user) is associated with an
identity provider which acts as a trusted third party on behalf of the
user with regard to a relying party by making identity assertions
about the user to the relying party.The real-world person represented by the identity subject is in
possession of a primary credential bound to the identity subject by
the 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
identity provider (or an agent thereof) to verify the identity of the
real-world person. This information is carried across the network as
part of an identity assertion presented to the relying party during
the authentication transaction.The term Vectors of Trust is inspired by the mathematical construct
of a vector, which is defined as an item composed of multiple
independent values.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.All components of the vector construct MUST be orthogonal such that
no aspect of a component overlaps an aspect of another component, as
much as is possible.This specification defines four orthogonal components: identity
proofing, primary credential usage, primary credential management, and
assertion presentation.This specification also defines values for each of these component to
be used in the absence of a more specific trust framework in . 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 context of a specific trust framework. The RP
MUST understand and take into account the trust framework context in
which a vector is being expressed in order for to process a vector
securely.Each component is identified by a demarcator consisting of a single
uppercase ASCII letter in the range [A-Z].
The demarcator SHOULD reflect the category with which it is associated
in a natural manner. Demarcators for components MUST be registered as
described in . It is anticipated that trust
framework definitions will use this registry to define specialized
components, though it is RECOMMENDED that trust frameworks re-use
existing components wherever possible.The value for a given component within a vector of trust is defined
by its demarcator character followed by a single digit or lowercase
ASCII letter in the range [0-9a-z].
Categories which have a natural ordering SHOULD use digits, with 0 as the lowest value. Categories which do not have
a natural ordering, or which can have an ambiguous ordering, SHOULD use
letters. Categories MAY use both letter style and number style value
indicators simultaneously. For example, a category could define 0 as a special "empty" value while using letters
such as a, b,
c for normal values to differentiate between
these types of options. Another system could have a base category with a
numeric value with additional details provided by letter values. Each component MAY be repeated with multiple different values within
a single vector (see for details). The
same component and value combination MUST NOT be repeated within a
single vector. A trust framework MAY define additional restrictions on
combinations of values.Regardless of the type of value indicator used, the values assigned
to each component of a vector MUST NOT be assumed always to have
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 better than 1.The Identity Proofing dimension defines, overall, how strongly the
set of identity attributes have been verified and vetted. In other
words, this dimension describes how likely it is that a given digital
identity transaction corresponds to a particular (real-world) identity
subject. For example, did the user have to provide documentation to a
trusted party to prove their legal name and address, or were they able
to self-assert such values?This dimension uses the P demarcator
and a single-character level value, such as P0,
P1, etc. Most definitions of identity
proofing will have a natural ordering, as more or less stringent
proofing can be applied to an individual being granted an account. In
such cases it is RECOMMENDED that a digit style value be used for this
component and that only a single value be allowed to be communicated
in a transaction.The primary credential usage dimension defines how strongly the
primary credential can be verified by the IdP. In other words, how
easily that credential could be spoofed or stolen. For example, did
the user log in using a password, with a biometric, with a
cryptographic hardware device, or some combination of the above?This dimension uses the C demarcator
and a single-character level value, such as Ca,
Cb, etc. Most definitions of credential
usage will not have an overall natural ordering, as there may be
several equivalent classes described within a trust framework. In such
cases it is RECOMMENDED that a letter style value be used for this
component and that multiple distinct credential usage factors be
allowed to be communicated simultaneously, such as when Multi-Factor
Authentication is used.The primary credential management dimension conveys information
about the expected lifecycle of the primary credential in use,
including its binding, rotation, and revocation. In other words, the
use and strength of policies, practices, and security controls used in
managing the credential at the IdP and its binding to the intended
individual. For example, can the user bring their own cryptographic
device or is one provided by the IdP?This dimension uses the M demarcator
and a single-character level value, such as Ma,
Mb, etc. Most definitions of credential
management will not have an overall natural ordering, though there can
be preference and comparison between values in some circumstances. In
such cases it is RECOMMENDED that a letter style value be used for
this component and that multiple distinct values be allowed to be
communicated simultaneously.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 was actually asserted by a given identity provider
for a given transaction. While this information is largely already
known by the RP as a side effect of processing an identity assertion,
this dimension is still very useful when the RP requests a login and when describing
the capabilities of an IdP.This dimension uses the A demarcator
and a level value, such as Aa, Ab, etc. Most definitions of assertion
presentation will not have an overall natural ordering. In such cases,
it is RECOMMENDED that a letter style value be used for this component
and that multiple values be allowed to be communicated
simultaneously.A vector of trust is designed to be used in the context of an
identity and authentication transaction, providing information about the
context of a federated credential. The vector therefore needs to be able
to be communicated in the context of the federated credential in a way
that is strongly bound to the assertion representing the federated
credential.This vector has several requirements for use.All applicable vector components and values need to be combined
into a single vector.The vector can be communicated across the wire unbroken and
untransformed.All vector components need to remain individually available, not
"collapsed" into a single value.The vector needs to be protected in transit.The vector needs to be cryptographically bound to the assertion
which it is describing.The vector needs to be interpreted in the context of a specific
trust framework definition identified by a trustmark URI.These requirements lead us to defining a simple string-based
representation of the vector that can be incorporated within a number of
different locations and protocols without further encoding.The vector MUST be represented as a period-separated ('.') list of
vector components. A vector component type can occur multiple times
within a single vector, but a specific value of a vector component can
not occur more than once in a single vector. That is, while Cc.Cd is a valid vector, Cc.Cc
is not. Multiple values for a component are considered a logical AND
of the values. Vector component values MAY appear in any order within a vector,
and different orderings of the same vector values MUST be considered
equivalent. For example, P1.Cc.Cd.Aa,
Aa.Cc.Cd.P1, Cd.P1.Cc.Aa,
and Aa.P1.Cd.Cc are all considered the
same vector value.Possible 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 vector is making no claim for that component. Trust
frameworks MAY define a distinct value for a component category to
indicate that a category was not used at all. Vector values MUST be communicated along with of a trustmark URI to give the components and
component values context. The trustmark MUST be cryptographically
bound to the vector value, such as the two values being carried
together in a signed assertion. A vector value without context is
unprocessable, and vectors defined in different contexts are not
directly comparable as whole values. Different trust frameworks MAY
re-use component definitions (including their values), but processing
of such cross-context values is outside the scope of this
specification.For example, the vector value P1.Cc.Ab
translates to "pseudonymous, proof of shared key, signed
browser-passed verified assertion, and no claim made toward credential
management" in the context of this specification's definitions. A different vector
value of Cb.Mc.Cd.Ac translates to "known
device, full proofing required for credential issuance and rotation,
cryptographic proof of possession of a shared key, signed back-channel
verified assertion, and no claim made toward identity proofing" in the
same context. Since no claim is made here for identity proofing, no
specific value can be assumed by the RP. Note that this doesn't mean
the user wasn't proofed at all: it's possible that the user was fully
proofed to the highest capabilities within the trust framework, but
here the IdP is making no statement to that to the RP.In OpenID Connect, the IdP MUST send
the vector as a string within the vot
(vector of trust) claim in the ID token. The trustmark that applies to this vector MUST
be sent as an URI in the vtm (vector trust
mark) claim to provide context to the vector.The vot and vtm
claims are interpreted by the RP to apply to the entire identity
transaction, and not necessarily to any one attribute specifically.
For example, assume that for the given trustmark, the body of an ID
token claiming "pseudonymous, proof of shared key, signed back-channel
verified token, and no claim made toward credential management" could
look like this JSON object payload of the ID token.The body of the ID token is signed and optionally encrypted using
JOSE, as per the OpenID Connect specification. By putting the vot and vtm values
inside the ID token, the vector and its context are strongly bound to
the federated credential represented by the ID token.In SAML, a vector is communicated as an AuthenticationContextDeclRef.
A vector is represented by prefixing it with the urn urn:ietf:param:[TBD]
to form a full URN. The AuthenticationContextDeclaration
corresponding to a given vector is a AuthenticationContextDeclaration
element containing an Extension element
with components of the vector represented by the following XML
schema:For instance the vector P1.Cc.Ac is represented by the
AuthenticationContextDeclRef URN urn:ietf:param:[TBD]:P1.Cc.Ac
(or urn:ietf:param:[TBD]:Cc.P1.Ac or ...)
which corresponds to the following AuthenticationContextDeclaration:In some identity protocols, the RP can request that particular vector
component values be used for a given identity transaction. Using the
same syntax as defined in , an RP can
indicate that it desires particular aspects be present in the
authentication. Processing and fulfillment of these requests are in the
purview of the IdP and details are outside the scope of this
specification.Future specifications MAY define alternative ways for an RP to retest
vector component values from an IdP.In OpenID Connect, the client MAY
request a partial set of acceptable VoT component values with the
vtr (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 component values within each vector are ANDed
together while the separate vectors are ORed together. For example, a
list of vectors in the form ["P1.Cb.Cc.Ab", "Ce.Ab"]
is stating that either the full set of "P1 AND Cb AND Cc AND Ab"
simultaneously OR the full set of "Ce AND Ab" simultaneously are
acceptable to this RP for this transaction.Vector request values MAY omit components, indicating that any
value is acceptable for that component category, including omission of
that component in the response vector.The mechanism by which the IdP processes the vtr
and maps that to the authentication transaction are out of scope of
this specification.In SAML the client can request a set of
acceptable VoT values by including the corresponding AuthenticationContextDeclRef URIs together with
an AuthenticationContextClassRef
corresponding to the trustmark. The
processing rules in apply.A trustmark is a URI that references a specific set of vector values
as defined by a trust framework. This URI MUST point to a human-readable
document that describes what components and values are valid, how they
are used together, and what practices the component values represent
within the trust framework. The contents of the trustmark URI MUST be
reachable by the operators or implementors of the RP. The URI SHOULD be
stable over time for a given trust framework.For example, [[this document URI]] is used as a trustmark to
reference the values defined in .
The process of a trustmark provider determining the ability of a
particular IdP to correctly assert values from a given trust framework
is outside the scope of this specification. Determining how an RP should
apply the values of a given vector to the RP's processing is outside the
scope of this specification.Vectors of Trust is meant to be a flexible and reusable framework for
communicating authentication data between networked parties in an
identity federation protocol. However, the exact nature of the
information needed is reliant on the parties requiring the information
and the relationship between them. While this document does define a
usable default set of values in , it
is anticipated that many situations will require an extension of this
specification for their own use.Component categories such as those defined in are intended to be general purpose and reusable in
a variety of circumstances. Extension specifications SHOULD re-use
existing category definitions where possible. Extensions MAY create
additional categories where needed by using the registry defined in
. The registry encourages re-use and discovery of
existing categories across different implementations. In other words,
the P category in another framework SHOULD
be used for identity proofing and related information.The values of components such as those defined in are intended to be contextual to the
defining trust document. While this specification's component values are
intended to be general-purpose and extensions MAY re-use the values and
their definitions, implementations MUST define all allowable values. As
these values are always interpreted in the context of a trustmark, these
values are not recorded in a central registry. Consequently, a P1 value from one framework and a P1 value from another framework could have very
different interpretations depending on their contextual trust framework
documents.Implementations of this specification SHOULD choose either a
numerical ordering or a group category approach to component values as
described in , though combinations of both
types MAY be used. Implementations of this specification MUST specify
whether multiple values are allowed for each category, and while any
component category is generally allowed to have multiple distinct
values, a specific definition of a set of values in an extension MAY
limit a given component category to a single value per transaction.Extensions and implementations of this specification MUST be
referenced by a unique trustmark URI to
allow RPs to differentiate between different trust frameworks.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, and the members of the ISOC Trust and Identity team for their
support. In particular, the authors would like to thank Paul Grassi, Jim
Fenton, Sarah Squire, Benjamin Kaduk, John Bradley, and Karen
O'Donoghue.This specification creates one registry and registers several values
into existing registries.This specification establishes the Vectors of Trust Components
Registry.Component demarcators are registered by Specification Required.Criteria that should be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing
functionality, whether it is likely to be of general applicability or
whether it is useful only for a single application, and whether the
registration description is clear.Registration requests sent to the vot@ietf.org mailing list for
review should use an appropriate subject (e.g., "Request to register
Vector of Trust Component name: example"). The Designated Expert(s)
will provide review within a two-week period and either approve or
deny the registration request, communicating this decision to the
review list and IANA. Denials should include an explanation and, if
applicable, suggestions as to how to make the request successful. IANA
must only accept registry updates from the Designated Expert(s) and
should direct all requests for registration to the vot@ietf.org
mailing list. If the Designated Experts do not respond within the
designated period, IANA should contact the IESG for guidance.An uppercase ASCII
letter in the range [A-Z] representing this component (e.g.,
"X"). Brief description of the
component (e.g., "Example description"). For IETF-stream RFCs,
state "IESG". For other documents, give the name of the
responsible party. Reference to
the document(s) that specify the vector component, preferably
including a URI that can be used to retrieve a copy of the
document(s). An indication of the relevant sections may also be
included but is not required.The Vector of Trust Components Registry contains the definitions
of vector components and their associated demarcators.Demarcator Symbol: PDescription: Identity proofingChange Controller: IESGSpecification document(s):: [[ this document ]]Demarcator Symbol: CDescription: Primary credential usageChange Controller: IESGSpecification document(s):: [[ this document ]]Demarcator Symbol: MDescription: Primary credential managementChange Controller: IESGSpecification document(s):: [[ this document ]]Demarcator Symbol: ADescription: Assertion presentationChange Controller: IESGSpecification document(s):: [[ this document ]]This specification adds the following values to the OAuth
Parameters Registry established by .Name: vtrDescription: Vector of Trust requestParameter usage location: authorization request, token
requestChange Controller: IESGDocument: [[ this document ]]This specification adds the following values to the JSON Web Token
Claims Registry established by .Claim name: votDescription: Vector of Trust valueChange Controller: IESGDocument: [[ this document ]]Claim name: vtmDescription: Vector of Trust trustmark URIChange Controller: IESGDocument: [[ this document ]]This specification adds the following values to the OAuth Token
Introspection Response established by .Name: votDescription: Vector of Trust valueChange Controller: IESGDocument: [[ this document ]]Name: vtmDescription: Vector of Trust trustmark URIChange Controller: IESGDocument: [[ this document ]]The vector of trust value needs to be cryptographically protected in
transit between parties, such as by using TLS as described in . The vector of trust value must be associated with a
trustmark by the RP processing the vector. By carrying both the vector
value and the trustmark URI, a signed OpenID Connect ID Token and a
signed SAML assertion both fulfil this requirement.The vector value is always associated with a trustmark and needs to
be interpreted by the RP in the context of the trust framework defined
by that trustmark. Different trust frameworks can apply different
interpretations to the same component value, much as was the case with
LoA. Therefore, an RP interpreting a component value in the wrong
context could mistakenly accept or reject a request. In order to avoid
this mistake, RPs need to reject vectors that are defined in trust
frameworks that they do not understand how to interpret properly.The VoT framework provides a mechanism for describing and conveying
trust information. It does not define any policies for an IdP
determining which vector component values apply to a given transaction,
nor does it define any policies for applying the values of a vector to
an RP's security decision process. These policies and associated
practices are to be agreed upon by the IdP and RP, and they should be
expressed in detail in an associated human-readable trust framework
document available at the trustmark URI.By design, vector of trust values contain information about the
user's authentication and associations that can be made thereto.
Therefore, all aspects of a vector of trust contain potentially
privacy-sensitive information and must be guarded as such. Even in the
absence of specific attributes about a user, knowledge that the user has
been highly proofed or issued a strong token could provide more
information about the user than was intended. It is recommended that
IdPs send and RPs request only the information necessary for their use
case in order to prevent inadvertent information disclosure.OpenID Connect Core 1.0Nomura Research Institute,
Ltd.Ping IdentityMicrosoftElectronic Authentication GuidelineNational Institute of Standards and Technology, U.S.
Department of CommerceDigital Identity GuidelineNational Institute of Standards and Technology, U.S.
Department of CommerceA Proposed Schema for Evaluating Federated AttributesNational Institute of Standards and Technology, U.S.
Department of CommerceRecommendations for Secure Use of Transport Layer Security
(TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer
Security (DTLS) are widely used to protect data exchanged over
application protocols such as HTTP, SMTP, IMAP, POP, SIP, and
XMPP. Over the last few years, several serious attacks on TLS have
emerged, including attacks on its most commonly used cipher suites
and their modes of operation. This document provides
recommendations for improving the security of deployed services
that use TLS and DTLS. The recommendations are applicable to the
majority of use cases.The following general-purpose component definitions MAY be used when
a more specific set is unavailable. This document defines a trust
framework for these component values. This trust framework referenced in
a trustmark URI of [[ this document URL ]].Extensions and implementations of this specification SHOULD define
their own component values as described in .
Where possible, extensions MAY re-use specific values and definitions as
listed here, but those specific values MUST be re-listed.The identity proofing component of this vector definition
represents increasing scrutiny during the proofing process. Higher
levels are largely subsumptive of lower levels, such that P2 fulfills requirements for P1,
etc. Multiple distinct values from this category MUST NOT be used in a
single transaction.No proofing is done, data is not guaranteed to be
persistent across sessionsAttributes are self-asserted but consistent over
time, potentially pseudonymousIdentity has been proofed either in person or
remotely using trusted mechanisms (such as social proofing)There is a binding relationship between the
identity provider and the identified party (such as
signed/notarized documents, employment records)The primary credential usage component of this vector definition
represents distinct categories of primary credential that MAY be used
together in a single transaction. Multiple distinct values from this
category MAY be used in a single transaction.No credential is used / anonymous public
serviceSimple session HTTP cookies (with nothing
else)Known deviceShared secret such as a username and password
combinationCryptographic proof of key possession using
shared keyCryptographic proof of key possession using
asymmetric keySealed hardware token / TPM-backed keysLocally verified biometricThe primary credential management component of this vector
definition represents distinct categories of management that MAY be
considered separately or together in a single transaction. Many trust
framework deployments MAY use a single value for this component as a
baseline for all transactions and thereby omit it. Multiple distinct
values from this category MAY be used in a single transaction.Self-asserted primary credentials (user chooses
their own credentials and must rotate or revoke them manually) /
no additional verification for primary credential issuance or
rotationRemote issuance and rotation / use of backup
recover credentials (such as email verification) / deletion on
user requestFull proofing required for each issuance and
rotation / revocation on suspicious activityThe assertion presentation component of this vector definition
represents distinct categories of assertion which are RECOMMENDED to
be used in a subsumptive manner but MAY be used together. Multiple
distinct values from this category MAY be used in a single
transaction.No protection / unsigned bearer identifier (such
as an HTTP session cookie in a web browser)Signed and verifiable assertion, passed through
the user agent (web browser)Signed and verifiable assertion, passed through a
back channelAssertion encrypted to the relying parties key
and audience protected-09Various fixes to respond to AD review.Added introspection response IANA registration.Cleaned up IANA entries.Removed confusing per-IdP trustmark and discovery sections.
Adopted single trustmark definition instead.Added definition of identity federation.Added definition of identity proofing.Added examples to component sections.-08Incorporated shepherd comments.Updated references.Added reference to NISTIR 8112.Moved default component definitions to appendix.-07Rewrote introduction to clarify focus of document.-06Added section on extensions to VoT.Made it so that every component category could be
multi-valued.Added reference to updated 800-63-3.Fixed example text width.Switched document back to standards-track from experimental now
that there are extensions in the wild.-05Updated IANA considerations section to include instructions.Made security and privacy considerations non-normative.-04Updated SAML example to be consistent.-03Clarified language of LoA's in introduction.Added note on operational security in trustmarks.Removed empty sections and references.-02Converted C, M, and A values to use letters instead of numbers in
examples.Updated SAML to a structured example pending future updates.Defined guidance for when to use letters vs. numbers in category
values.Restricted category demarcators to uppercase and values to
lowercase and digits.Applied clarifying editorial changes from list comments.- 01Added IANA registry for components.Added preliminary security considerations and privacy
considerations.Split "credential binding" into "primary credential usage" and
"primary credential management".- 00Created initial IETF drafted based on strawman proposal discussed
on VoT list.Split vector component definitions into their own section to
allow extension and override.Solidified trustmark document definition.