doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc8485.txt b/doc/rfc/rfc8485.txt
new file mode 100644
index 0000000..37826c8
--- /dev/null
+++ b/doc/rfc/rfc8485.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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
+
+
+3.2.  In OpenID Connect
+
+   In OpenID Connect [OpenID], the IdP MUST send the vector as a string
+   within the "vot" (vector of trust) claim in the ID token.  The
+   trustmark (see Section 5) that applies to this vector MUST be sent as
+   a URL 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 [RFC8259] payload of the
+   ID token.
+
+   {
+       "iss": "https://idp.example.com/",
+       "sub": "jondoe1234",
+       "vot": "P1.Cc.Ac",
+       "vtm": "https://example.org/vot-trust-framework"
+   }
+
+   The body of the ID token is signed and optionally encrypted using
+   JSON Object Signing and Encryption (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.
+
+   Vector values MAY be returned in a token introspection [RFC7662]
+   response describing the ID token or access token issued during an
+   OpenID Connect transaction using the same claims.
+
+4.  Requesting Vector Values
+
+   In some identity protocols, the RP can request that particular vector
+   values be used for a given identity transaction.  An RP can describe
+   the particular vector component values it desires the IdP assert for
+   a given identity transaction by using the same syntax as defined in
+   Section 3.1.  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
+   request vector values from an IdP.
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 11]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+4.1.  In OpenID Connect
+
+   In OpenID Connect [OpenID], the client MAY request a partial set of
+   acceptable VoT values with the "vtr" (vector of trust) claim request
+   as part of the request object.  The value of this field is a JSON
+   array of strings [RFC8259], 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.
+
+5.  Trustmarks
+
+   A trustmark is an HTTPS URL that references a specific set of vector
+   values as defined by a trust framework.  This URL 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 URL MUST be reachable by the operators or implementors of
+   the RP.  The URL MUST be stable over time for a given trust framework
+   to allow RPs to process incoming vectors in a consistent fashion.
+   New versions of a trust framework that require different processing
+   rules MUST use a different trustmark URL.
+
+   For example, <https://www.rfc-editor.org/info/rfc8485> is used as the
+   trustmark to reference the values defined in Appendix A.
+
+   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.
+
+
+
+
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 12]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+6.  Defining New Vector Values
+
+   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 depends on the parties requiring the information
+   and the relationship between them.  While this document does define a
+   usable default set of values in Appendix A, it is anticipated that
+   many situations will require an extension of this specification for
+   their own use.
+
+   Component categories such as those defined in Section 2 are intended
+   to be general-purpose and reusable in a variety of trust frameworks.
+   Extension specifications SHOULD reuse existing category definitions
+   where possible.  Extensions MAY create additional categories where
+   needed by using the registry defined in Section 7.  The registry
+   encourages reuse and discovery of existing categories across
+   different trust frameworks.  For example, the "P" category in another
+   framework SHOULD be used for identity proofing and related
+   information.
+
+   The values of components such as those defined in Appendix A 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 reuse the values and their definitions, trust
+   frameworks 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, even though in both cases the "P" component is
+   used for identity proofing in some fashion.
+
+   Trust frameworks that implement this specification SHOULD choose
+   either a numerical ordering or a group category approach to component
+   values as described in Section 2, though combinations of both types
+   MAY be used.  Trust frameworks 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.  It is
+   RECOMMENDED that trust frameworks use a "0" value to indicate an
+   empty or null condition for a given category (for example, no
+   proofing being done or no authentication token being used).
+
+   All trust frameworks that extend and implement this specification
+   MUST be referenced by a unique trustmark URL (see Section 5) to allow
+   RPs to differentiate between different trust frameworks.
+
+
+
+Richer & Johansson           Standards Track                   [Page 13]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+7.  IANA Considerations
+
+   This specification creates one registry and registers several values
+   into existing registries.
+
+7.1.  Vector of Trust Components Registry
+
+   This specification establishes the "Vectors of Trust Components"
+   registry.
+
+   Component demarcators are registered by the Specification Required
+   policy documented in [RFC8126].
+
+   Criteria that should be applied by the designated experts includes
+   determining whether the proposed registration is distinct enough from
+   existing entries to warrant registration, whether it is likely to be
+   of general applicability, and whether the registration description is
+   clear.  Since all vector processing is contextual to a trust
+   framework, component demarcators that do not meet these criteria can
+   still be used in trust frameworks.  The registry contains vector
+   components that are believed to have general applicability that can
+   be used as well.
+
+   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.
+
+7.1.1.  Registration Template
+
+   Demarcator Symbol:
+      An uppercase ASCII letter in the range [A-Z] representing this
+      component (e.g., "X").
+
+   Description:
+      Brief description of the component (e.g., "Example description").
+
+   Change Controller:
+      For IETF-stream RFCs, state "IESG".  For other documents, give the
+      name of the responsible party.
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 14]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+   Specification document(s):
+      Reference to the document(s) that specifies the vector component,
+      preferably including a URL 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.
+
+7.1.2.  Initial Registry Contents
+
+   The "Vector of Trust Components" registry contains the definitions of
+   vector components and their associated demarcators.
+
+   o  Demarcator Symbol: P
+   o  Description: Identity proofing
+   o  Change Controller: IESG
+   o  Specification document(s): [RFC8485]
+
+   o  Demarcator Symbol: C
+   o  Description: Primary credential usage
+   o  Change Controller: IESG
+   o  Specification document(s): [RFC8485]
+
+   o  Demarcator Symbol: M
+   o  Description: Primary credential management
+   o  Change Controller: IESG
+   o  Specification document(s): [RFC8485]
+
+   o  Demarcator Symbol: A
+   o  Description: Assertion presentation
+   o  Change Controller: IESG
+   o  Specification document(s): [RFC8485]
+
+7.2.  Addition to the OAuth Parameters Registry
+
+   This specification adds the following value to the "OAuth Parameters"
+   registry established by [RFC6749].
+
+   o  Name: vtr
+   o  Description: Vector of Trust request
+   o  Parameter usage location: authorization request, token request
+   o  Change Controller: IESG
+   o  Reference: [RFC8485]
+
+
+
+
+
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 15]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+7.3.  Additions to JWT Claims Registry
+
+   This specification adds the following values to the "JSON Web Token
+   Claims" registry established by [RFC7519].
+
+   o  Claim name: vot
+   o  Claim Description: Vector of Trust value
+   o  Change Controller: IESG
+   o  Reference: [RFC8485]
+
+   o  Claim name: vtm
+   o  Claim Description: Vector of Trust trustmark URL
+   o  Change Controller: IESG
+   o  Reference: [RFC8485]
+
+7.4.  Additions to OAuth Token Introspection Response
+
+   This specification adds the following values to the "OAuth Token
+   Introspection Response" registry established by [RFC7662].
+
+   o  Name: vot
+   o  Description: Vector of Trust value
+   o  Change Controller: IESG
+   o  Reference: [RFC8485]
+
+   o  Name: vtm
+   o  Description: Vector of Trust trustmark URL
+   o  Change Controller: IESG
+   o  Reference: [RFC8485]
+
+8.  Security Considerations
+
+   The vector of trust value needs to be cryptographically protected in
+   transit between parties, such as by using TLS as described in
+   [BCP195].  The vector of trust value must be associated with a
+   trustmark by the RP processing the vector.  A signed OpenID Connect
+   ID Token or a similarly signed assertion from another protocol would
+   fulfill this requirement by carrying both the vector value and the
+   trustmark URL as claims.
+
+   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
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 16]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+   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 URL.
+
+9.  Privacy Considerations
+
+   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.
+
+10.  References
+
+10.1.  Normative References
+
+   [OpenID]   Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
+              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
+              <http://openid.net/specs/openid-connect-core-1_0.html>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
+              RFC 6749, DOI 10.17487/RFC6749, October 2012,
+              <https://www.rfc-editor.org/info/rfc6749>.
+
+   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
+              <https://www.rfc-editor.org/info/rfc7519>.
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 17]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
+              RFC 7662, DOI 10.17487/RFC7662, October 2015,
+              <https://www.rfc-editor.org/info/rfc7662>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+10.2.  Informative References
+
+   [BCP195]   Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, May 2015,
+              <https://www.rfc-editor.org/info/bcp195>.
+
+   [NISTIR-8112]
+              National Institute of Standards and Technology, "A
+              Proposed Schema for Evaluating Federated Attributes", NIST
+              Internal Report 8112, DOI 10.6028/NIST.IR.8112, January
+              2018, <https://nvlpubs.nist.gov/nistpubs/ir/2018/
+              NIST.IR.8112.pdf>.
+
+   [SP-800-63-2]
+              National Institute of Standards and Technology,
+              "Electronic Authentication Guideline", NIST Special
+              Publication SP 800-63-2, DOI 10.6028/NIST.SP.800-63-2,
+              August 2013,
+              <https://dx.doi.org/10.6028/NIST.SP.800-63-2>.
+
+   [SP-800-63-3]
+              National Institute of Standards and Technology, "Digital
+              Identity Guideline", NIST Special Publication SP 800-63-3,
+              DOI 10.6028/NIST.SP.800-63-3, June 2017,
+              <https://doi.org/10.6028/NIST.SP.800-63-3>.
+
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 18]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+Appendix A.  Vectors of Trust Default Component Value Definitions
+
+   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.  The trustmark URL of this
+   trust framework is <https://www.rfc-editor.org/info/rfc8485>.  All
+   normative requirements following in this section apply to this trust
+   framework alone.
+
+   Other trust frameworks that extend and implement this specification
+   SHOULD define their own component values as described in Section 6.
+   Where possible, extensions MAY reuse specific values and definitions
+   as listed here, but those specific values MUST be relisted.
+
+A.1.  Identity Proofing
+
+   The identity proofing component of this vector definition represents
+   the level of scrutiny applied to the identity subject 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.
+
+   P0:  No proofing is done, and data is not guaranteed to be persistent
+        across sessions
+
+   P1:  Attributes are self-asserted but consistent over time,
+        potentially pseudonymous
+
+   P2:  Identity has been proofed either in person or remotely using
+        trusted mechanisms (such as social proofing)
+
+   P3:  There is a binding relationship between the identity provider
+        and the identified party (such as signed/notarized documents and
+        employment records)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 19]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+A.2.  Primary Credential Usage
+
+   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.
+
+   C0:  No credential is used / anonymous public service
+
+   Ca:  Simple session HTTP cookies (with nothing else)
+
+   Cb:  Known device, such as those indicated through device posture or
+        device management systems
+
+   Cc:  Shared secret, such as a username and password combination
+
+   Cd:  Cryptographic proof of key possession using shared key
+
+   Ce:  Cryptographic proof of key possession using asymmetric key
+
+   Cf:  Sealed hardware token / keys stored in a trusted platform module
+
+   Cg:  Locally verified biometric
+
+A.3.  Primary Credential Management
+
+   The 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.
+
+   Ma:  Self-asserted primary credentials (user chooses their own
+        credentials and must rotate or revoke them manually) / no
+        additional verification for primary credential issuance or
+        rotation
+
+   Mb:  Remote issuance and rotation / use of backup recover credentials
+        (such as email verification) / deletion on user request
+
+   Mc:  Full proofing required for each issuance and rotation /
+        revocation on suspicious activity
+
+
+
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 20]
+
+RFC 8485                    Vectors of Trust                October 2018
+
+
+A.4.  Assertion Presentation
+
+   The assertion presentation component of this vector definition
+   represents distinct categories of assertion that 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.
+
+   Aa:  No protection / unsigned bearer identifier (such as an HTTP
+        session cookie in a web browser)
+
+   Ab:  Signed and verifiable assertion, passed through the user agent
+        (web browser)
+
+   Ac:  Signed and verifiable assertion, passed through a back channel
+
+   Ad:  Assertion encrypted to the RP's key
+
+Acknowledgements
+
+   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, as well as 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.
+
+Authors' Addresses
+
+   Justin Richer (editor)
+   Bespoke Engineering
+
+   Email: ietf@justin.richer.org
+
+
+   Leif Johansson
+   Swedish University Network
+   Thulegatan 11
+   Stockholm
+   Sweden
+
+   Email: leifj@sunet.se
+   URI:   http://www.sunet.se
+
+
+
+
+
+
+
+
+Richer & Johansson           Standards Track                   [Page 21]
+