Vectors of Trust
Extracted elements (28)
Component values are not recorded in a central registry because they are always interpreted in the context of a specific trustmark. A 'P1' from one trust framework and a 'P1' from another may have very different meanings; only the component demarcators (P, C, M, A) are registered centrally to encourage reuse across frameworks.
Vectors of Trust was designed to occupy the middle ground between single-scalar Level of Assurance (LoA) values and full attribute metadata systems. LoA collapses too much context into one number (an anonymous user with a strong credential still gets a low LoA), while ABAC attribute metadata is prohibitively complex for simple RP decisions. VoT provides multiple orthogonal components without requiring full attribute descriptions.
Different trust frameworks MAY reuse component definitions and values, but processing of cross-context vector values is explicitly outside the scope of this specification. Trust frameworks SHOULD reuse existing component categories (e.g., 'P' for identity proofing) to encourage consistency across deployments.
Component demarcators consisting of a single uppercase ASCII letter MUST be registered as described in Section 7. The same demarcator MUST NOT be used for two different dimensions.
In OpenID Connect, the IdP MUST send the vector as a string in the 'vot' claim in the ID token. The trustmark URL MUST be sent in the 'vtm' claim. Both are placed inside the signed (and optionally encrypted) ID token, ensuring cryptographic binding.
New versions of a trust framework that require different processing rules MUST use a different trustmark URL. All trust frameworks that extend this specification MUST be referenced by a unique trustmark URL so RPs can differentiate between frameworks.
The RP MUST NOT assume that values assigned to vector components have inherent ordinal or subsumptive properties without specific knowledge of the trust framework in use. '1' is always different from '2', but '2' does not necessarily imply superiority or fulfillment of '1' requirements.
The RP MUST understand and take into account the trust framework context in which a vector is expressed in order to process it correctly. A vector value without context is unprocessable, and vectors from different contexts are not directly comparable.
The same component and value combination MUST NOT be repeated within a single vector (e.g., two instances of 'P1' in one vector is invalid). A component type may appear multiple times with different values, representing the logical AND of those values.
The vector MUST be represented as a period-separated list of vector components. The RP MUST consider different orderings of the same vector equivalent during processing.
Trust frameworks that implement this specification MUST define all allowable component values. Trust frameworks MUST specify whether multiple values are allowed for each category.
Vector values MUST be communicated along with a trustmark URL to provide context. The trustmark MUST be cryptographically bound to the vector value (e.g., both carried in a signed assertion). A vector value without an associated trustmark is unprocessable.
All aspects of a vector of trust contain potentially privacy-sensitive information. Even the absence of specific attributes, or the presence of high proofing or strong token indicators, can reveal more about a user than intended. IdPs and RPs should exchange only the information necessary for the use case.
A trustmark is an HTTPS URL referencing a specific set of vector values as defined by a trust framework. It MUST point to a human-readable document describing valid components, values, and their practices. The trustmark URL MUST remain stable over time for a given trust framework.
A Vector of Trust is composed of four orthogonal component dimensions: Identity Proofing (P), Primary Credential Usage (C), Primary Credential Management (M), and Assertion Presentation (A). Each component is identified by a single uppercase ASCII demarcator letter and a single digit or lowercase letter value.
Assertion Presentation (A) describes how the federated identity assertion is conveyed across the network — covering protection against information leakage and spoofing. Values include unsigned bearer identifiers (Aa), signed browser-passed assertions (Ab), signed back-channel assertions (Ac), and RP-key-encrypted assertions (Ad).
Identity Proofing (P) captures how strongly identity attributes were verified. The 'P' demarcator is used with digits (e.g., P0–P3) reflecting ordered strength of proofing. Only a single value is recommended per transaction. Higher values are largely subsumptive of lower values in the default framework.
Primary Credential Management (M) conveys information about the expected lifecycle of the primary credential, including binding, rotation, and revocation policies. Multiple distinct values may be communicated simultaneously using letters (Ma, Mb, Mc).
Primary Credential Usage (C) captures how strongly the user's credential can be verified and how easily it could be spoofed or stolen (e.g., password, biometric, cryptographic hardware). Multiple values may be asserted simultaneously (e.g., for multi-factor authentication), using letters (Ca, Cb, ...) due to lack of natural ordering.
The 'vot' claim carries the vector of trust string value and 'vtm' carries the trustmark URL in OpenID Connect ID tokens and token introspection responses. These claims are interpreted as applying to the entire identity transaction.
The 'vtr' (vector of trust request) parameter allows an RP to request a partial set of acceptable VoT values in an OpenID Connect authorization or token request. Its value is a JSON array of strings; values within each string are ANDed together while separate array elements are ORed.
This document adds the 'vtr' (Vector of Trust request) parameter to the OAuth Parameters registry established by RFC 6749, for use in authorization and token requests.
This document adds 'vot' (Vector of Trust value) and 'vtm' (Vector of Trust trustmark URL) to the JSON Web Token Claims registry (RFC 7519) and to the OAuth Token Introspection Response registry (RFC 7662).
This document establishes the 'Vectors of Trust Components' registry with Specification Required policy. Initial entries are: P (Identity proofing), C (Primary credential usage), M (Primary credential management), A (Assertion presentation). Registration requests go to [email protected] for expert review.
RPs must reject vectors defined in trust frameworks they do not understand. Different trust frameworks can apply different interpretations to the same component value, so processing a vector in the wrong context could lead to mistakenly accepting or rejecting a request.
The vector of trust value MUST be cryptographically protected in transit (e.g., via TLS per BCP 195) and MUST be associated with a trustmark, such as by being carried together in a signed OpenID Connect ID token or equivalent signed assertion.
VoT defines no policies for IdPs determining which vector values apply to a transaction, nor for RPs applying vector values to security decisions. These policies must be agreed upon by IdP and RP and documented in the human-readable trust framework at the trustmark URL.
The VoT vector is represented as a period-separated ('.') string of component values, e.g., 'P1.Cc.Ab'. Component ordering within the string is insignificant; 'P1.Cc.Ab' and 'Ab.Cc.P1' are equivalent. Omitted components make no claim for that dimension.