Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 8485 Bespoke Engineering
Category: Standards Track L. Johansson
ISSN: 2070-1721 Swedish University Network
October 2018
Vectors of Trust
Abstract
This 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 amount of
trust to be placed in that transaction.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8485.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Richer & Johansson Standards Track [Page 1]
RFC 8485 Vectors of Trust October 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Identity Model . . . . . . . . . . . . . . . . . . . . . 5
1.4. Component Architecture . . . . . . . . . . . . . . . . . 6
2. Component Dimension Definitions . . . . . . . . . . . . . . . 6
2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7
2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 8
2.3. Primary Credential Management (M) . . . . . . . . . . . . 8
2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8
3. Communicating Vector Values to RPs . . . . . . . . . . . . . 9
3.1. On-the-Wire Representation . . . . . . . . . . . . . . . 10
3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11
4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11
4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12
5. Trustmarks . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Defining New Vector Values . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Vector of Trust Components Registry . . . . . . . . . . . 14
7.1.1. Registration Template . . . . . . . . . . . . . . . . 14
7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15
7.2. Addition to the OAuth Parameters Registry . . . . . . . . 15
7.3. Additions to JWT Claims Registry . . . . . . . . . . . . 16
7.4. Additions to OAuth Token Introspection Response . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Vectors of Trust Default Component Value Definitions 19
A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 19
A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 20
A.3. Primary Credential Management . . . . . . . . . . . . . . 20
A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Richer & Johansson Standards Track [Page 2]
RFC 8485 Vectors of Trust October 2018
1. Introduction
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 [SP-800-63-3] published in 2017, NIST
Special Publication 800-63 [SP-800-63-2] 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.
The Vectors of Trust (VoT) approach proposed in this document 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 it is still
relatively easy for the RP to process. It is anticipated that VoT
can be used alongside more detailed attribute metadata systems, such
Richer & Johansson Standards Track [Page 3]
RFC 8485 Vectors of Trust October 2018
as the one proposed by NISITIR 8112 [NISTIR-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, for
RPs that do not have a need for the vector's more fine-grained
detail, it is anticipated that some trust frameworks will provide a
simple mapping between certain sets of vector values to LoAs. 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. The values of the
vectors defined by the data model are 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 (Appendix A) for use cases that do not need something more
specific.
1.1. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
Identity Federation: A protocol in which an Identity Provider (IdP)
asserts a user's identity information to an RP. through the use
of a cryptographic assertion or other verifiable mechanism, or a
system implementing such a protocol. It is also referred to
simply as "federation".
Identity Provider (IdP): A system that manages identity information
and is able to assert this information across the network through
an identity API.
Identity Subject: The individual (user) engaging in the identity
transaction, that is, being identified by the identity provider to
the RP.
Identity Proofing: The process of verifying and validating that a
set of identity attributes belongs to a real-world identity
subject.
Richer & Johansson Standards Track [Page 4]
RFC 8485 Vectors of Trust October 2018
Primary Credential: The means used by the identity subject to
authenticate to the identity provider.
Federated Credential: The assertion presented by the IdP to the RP
across the network to authenticate the user.
Relying Party (RP): A system that consumes identity information from
an IdP for the purposes of authenticating the user.
Trust Framework: A document containing business rules and legal
clauses that defines how different parties in an identity
transaction may act.
Trustmark: A URL referencing a specific trust framework and its
definition of vector components and vector component values.
Trustmark Provider: Defines the trust framework referenced by its
trustmark and 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.
Vector: A multi-part data structure, which is used here for
conveying information about an authentication transaction.
Vector Component: One of several constituent parts that make up a
vector, indicating a category of information.
Vector Component Value: One of the values applied to a vector
component within a vector.
1.3. Identity Model
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 that acts as a trusted third party on behalf of the
user, with regard to an RP by making identity assertions about the
user to the RP.
The real-world individual 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
Richer & Johansson Standards Track [Page 5]
RFC 8485 Vectors of Trust October 2018
real-world individual. This information is carried across the
network as part of an identity assertion presented to the RP during
the authentication transaction.
1.4. Component Architecture
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 RP) with the need for
expressiveness. As such, this vector construct is designed to be
composable and extensible.
The vector is constructed of orthogonal components, such that no
aspect of a component overlaps an aspect of another component, as
much as is possible.
2. Component Dimension Definitions
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 components
to be used in the absence of a more specific trust framework in
Appendix A. 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 to process a vector
correctly.
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
Section 7. It is anticipated that trust framework definitions will
use this registry to define specialized components, but it is
RECOMMENDED that trust frameworks reuse existing components
categories wherever possible. The same demarcator MUST NOT be used
for two different dimensions, and different trust frameworks SHOULD
use the same demarcator for similar information. It is further
anticipated that there will be relatively few component dimensions
Richer & Johansson Standards Track [Page 6]
RFC 8485 Vectors of Trust October 2018
over time, and this specification defines four general-purpose
categories in this section. Note that since the processing for all
vector values is contextual to a trust framework, the exact semantics
of interpreting a component will vary based on the trust framework in
use.
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 that have a natural
ordering SHOULD prefer digits, with larger digits indicating stronger
assertions than smaller digits. Categories that do not have a
natural ordering, or that can have an ambiguous ordering, SHOULD
prefer letters. Note that while letters could also imply order, they
can also more naturally be used mnemonically. Trust frameworks MAY
use any possible values within a category without the need for them
to be contiguous.
Categories MAY use both letters and digits simultaneously. For
example, a category could define "0" as meaning "no statement is
made" while using letters such as "a", "b", and "c" for normal values
to indicate specific options. Another system could have an ordered
base set of digits with additional details provided by letters.
Each component MAY be repeated with multiple different values within
a single vector, representing the logical AND of the values (see
Section 3.1 for details). The same component and value combination
MUST NOT be repeated within a single vector. For example, a vector
could contain both "P1" and "Pa" but not two instances of "P1". A
trust framework MAY define additional restrictions on combinations of
values.
Regardless of the type of value, the RP MUST NOT assume that the
values assigned to each component of a vector have inherent ordinal
or subsumptive properties when compared to the same or other
components in the vector space without specific knowledge of the
trust framework in use. In other words, "1" is always different from
"2", but it is dangerous to assume that "2" is always better than "1"
or that "2" satisfies all the requirements of "1".
2.1. Identity Proofing (P)
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?
Richer & Johansson Standards Track [Page 7]
RFC 8485 Vectors of Trust October 2018
This dimension uses the "P" demarcator, 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 be used for this component and that only a single value be
allowed to be communicated in a transaction.
2.2. Primary Credential Usage (C)
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 with a password, a biometric, a cryptographic
hardware device, or some combination of the above?
This dimension uses the "C" demarcator, 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 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.
2.3. Primary Credential Management (M)
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, 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 be used for this component and that
multiple distinct values be allowed to be communicated
simultaneously.
2.4. Assertion Presentation (A)
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 asserted by a given identity provider for the
Richer & Johansson Standards Track [Page 8]
RFC 8485 Vectors of Trust October 2018
identity subject of a given transaction. While this information is
largely already known by the RP as a side effect of processing an
identity assertion in a federation protocol, this dimension is still
very useful when the RP requests a login (see Section 4) and when
describing the capabilities of an IdP. This value also allows the RP
to detect when an assertion is presented in a manner it was not
intended for, as may be the case with an attack.
This dimension uses the "A" demarcator, 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 be
used for this component and that multiple values be allowed to be
communicated simultaneously.
3. Communicating Vector Values to RPs
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.
o All applicable vector components and values need to be combined
into a single vector.
o The vector can be communicated across the wire unbroken and
untransformed.
o All vector components need to remain individually available, not
"collapsed" into a single value.
o The vector needs to be protected in transit.
o The vector needs to be cryptographically bound to the assertion
that it is describing.
o The vector needs to be interpreted in the context of a specific
trust framework definition identified by a trustmark URL.
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.
Richer & Johansson Standards Track [Page 9]
RFC 8485 Vectors of Trust October 2018
3.1. On-the-Wire Representation
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
cannot 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
the RP MUST consider different orderings of the same vector
equivalent during processing. For example, "P1.Cc.Cd.Aa",
"Aa.Cc.Cd.P1", "Cd.P1.Cc.Aa", and "Aa.P1.Cd.Cc" are all considered
equivalent to each other.
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. No
default values are assumed for a missing component category.
Vector values MUST be communicated along with a trustmark URL (see
Section 5) 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 reuse component definitions (including
their values), but processing of such cross-context values is outside
the scope of this specification.
For example, the vector "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 (see Appendix A). A different vector
"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 not
making any specific claim about proofing to the RP, perhaps to
protect the user's privacy.
Richer & Johansson Standards Track [Page 10]
RFC 8485 Vectors of Trust October 2018