[Gen-art] Genart last call review of draft-richer-vectors-of-trust-11

Dale Worley <worley@ariadne.com> Mon, 11 June 2018 03:23 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89D1277C8; Sun, 10 Jun 2018 20:23:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dale Worley <worley@ariadne.com>
To: <gen-art@ietf.org>
Cc: draft-richer-vectors-of-trust.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152868743416.32020.14837101169101933221@ietfa.amsl.com>
Date: Sun, 10 Jun 2018 20:23:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/o0_SCTv7khNI-7OIM87OHEgpMoU>
Subject: [Gen-art] Genart last call review of draft-richer-vectors-of-trust-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.26
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2018 03:23:55 -0000

Reviewer: Dale Worley
Review result: Ready with Nits





Network Working Group                                     J. Richer, Ed.
Internet-Draft                                       Bespoke Engineering
Intended status: Standards Track                            L. Johansson
Expires: November 19, 2018                    Swedish University Network
                                                            May 18, 2018


                            Vectors of Trust
                    draft-richer-vectors-of-trust-11

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.

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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 19, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Richer & Johansson      Expires November 19, 2018               [Page 1]

Internet-Draft              vectors-of-trust                    May 2018


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  An Identity Model . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Component Architecture  . . . . . . . . . . . . . . . . .   5
   2.  Component Definitions . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Identity Proofing (P) . . . . . . . . . . . . . . . . . .   7
     2.2.  Primary Credential Usage (C)  . . . . . . . . . . . . . .   7
     2.3.  Primary Credential Management (M) . . . . . . . . . . . .   8
     2.4.  Assertion Presentation (A)  . . . . . . . . . . . . . . .   8
   3.  Communicating Vector Values to RPs  . . . . . . . . . . . . .   8
     3.1.  On the Wire Representation  . . . . . . . . . . . . . . .   9
     3.2.  In OpenID Connect . . . . . . . . . . . . . . . . . . . .  10
   4.  Requesting Vector Values  . . . . . . . . . . . . . . . . . .  11
     4.1.  In OpenID Connect . . . . . . . . . . . . . . . . . . . .  11
   5.  Trustmarks  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Defining New Vector Values  . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.1.  Vector Of Trust Components Registry . . . . . . . . . . .  13
       8.1.1.  Registration Template . . . . . . . . . . . . . . . .  14
       8.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  14
     8.2.  Additions to the OAuth Parameters Registry  . . . . . . .  15
     8.3.  Additions to JWT Claims Registry  . . . . . . . . . . . .  15
     8.4.  Additions to OAuth Token Introspection Response . . . . .  16
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Appendix A.  Vectors of Trust Default Component Value Definitions  18
     A.1.  Identity Proofing . . . . . . . . . . . . . . . . . . . .  19
     A.2.  Primary Credential Usage  . . . . . . . . . . . . . . . .  19
     A.3.  Primary Credential Management . . . . . . . . . . . . . .  20
     A.4.  Assertion Presentation  . . . . . . . . . . . . . . . . .  20
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23



Richer & Johansson      Expires November 19, 2018               [Page 2]

Internet-Draft              vectors-of-trust                    May 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.

   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 [NISTIR-8112].  The RP can use the



Richer & Johansson      Expires November 19, 2018               [Page 3]

Internet-Draft              vectors-of-trust                    May 2018


   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 (Appendix A) for use cases that do
   not need something more specific.

1.1.  Terminology

   Identity Federation  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".

   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 person (user) engaging in the identity
      transaction, being identified by the identity provider to the
      relying party.

   Identity Proofing  The process of verifying and validating that a set
      of identity attributes belongs to a real-world identity subject.

   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.



Richer & Johansson      Expires November 19, 2018               [Page 4]

Internet-Draft              vectors-of-trust                    May 2018


   Trustmark  A URI referencing a specific Trust Framework and its
      definition of vector components and vector component values.

   Trustmark Provider  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.

   Vector  A multi-part data structure, 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.2.  An 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 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.

1.3.  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 relying party) with the need for
   expressiveness.  As such, this vector construct is designed to be
   composable and extensible.





Richer & Johansson      Expires November 19, 2018               [Page 5]

Internet-Draft              vectors-of-trust                    May 2018


   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.

2.  Component 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 component 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 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
   Section 8.  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 Section 3.1 for details).  The same component
   and value combination MUST NOT be repeated within a single vector.  A




Richer & Johansson      Expires November 19, 2018               [Page 6]

Internet-Draft              vectors-of-trust                    May 2018


   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."

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?

   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.

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 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.







Richer & Johansson      Expires November 19, 2018               [Page 7]

Internet-Draft              vectors-of-trust                    May 2018


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 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.

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 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
   (Section 4) 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.

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.





Richer & Johansson      Expires November 19, 2018               [Page 8]

Internet-Draft              vectors-of-trust                    May 2018


   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
      which it is describing.

   o  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.

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
   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
   (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.



Richer & Johansson      Expires November 19, 2018               [Page 9]

Internet-Draft              vectors-of-trust                    May 2018


   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 (Appendix A).  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.

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 (Section 5) 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.

   {
       "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
   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.




Richer & Johansson      Expires November 19, 2018              [Page 10]

Internet-Draft              vectors-of-trust                    May 2018


4.  Requesting Vector Values

   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 Section 3.1, 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
   request vector component values from an IdP.

4.1.  In OpenID Connect

   In OpenID Connect [OpenID], 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.

5.  Trustmarks

   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 Appendix A.





Richer & Johansson      Expires November 19, 2018              [Page 11]

Internet-Draft              vectors-of-trust                    May 2018


   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.

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 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 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 circumstances.
   Extension specifications SHOULD re-use existing category definitions
   where possible.  Extensions MAY create additional categories where
   needed by using the registry defined in Section 8.  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 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 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 Section 2, 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.





Richer & Johansson      Expires November 19, 2018              [Page 12]

Internet-Draft              vectors-of-trust                    May 2018


   Extensions and implementations of this specification MUST be
   referenced by a unique trustmark URI (Section 5) to allow RPs to
   differentiate between different trust frameworks.

7.  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, 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.

8.  IANA Considerations

   This specification creates one registry and registers several values
   into existing registries.

8.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 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.








Richer & Johansson      Expires November 19, 2018              [Page 13]

Internet-Draft              vectors-of-trust                    May 2018


8.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.

   Specification document(s):
      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.

8.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):: [[ this document ]]

   o  Demarcator Symbol: C

   o  Description: Primary credential usage

   o  Change Controller: IESG

   o  Specification document(s):: [[ this document ]]

   o  Demarcator Symbol: M

   o  Description: Primary credential management

   o  Change Controller: IESG

   o  Specification document(s):: [[ this document ]]




Richer & Johansson      Expires November 19, 2018              [Page 14]

Internet-Draft              vectors-of-trust                    May 2018


   o  Demarcator Symbol: A

   o  Description: Assertion presentation

   o  Change Controller: IESG

   o  Specification document(s):: [[ this document ]]

8.2.  Additions to the OAuth Parameters Registry

   This specification adds the following values 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  Document: [[ this document ]]

8.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  Description: Vector of Trust value

   o  Change Controller: IESG

   o  Document: [[ this document ]]

   o  Claim name: vtm

   o  Description: Vector of Trust trustmark URI

   o  Change Controller: IESG

   o  Document: [[ this document ]]








Richer & Johansson      Expires November 19, 2018              [Page 15]

Internet-Draft              vectors-of-trust                    May 2018


8.4.  Additions to OAuth Token Introspection Response

   This specification adds the following values to the OAuth Token
   Introspection Response established by [RFC7662].

   o  Name: vot

   o  Description: Vector of Trust value

   o  Change Controller: IESG

   o  Document: [[ this document ]]

   o  Name: vtm

   o  Description: Vector of Trust trustmark URI

   o  Change Controller: IESG

   o  Document: [[ this document ]]

9.  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.  By carrying both the
   vector value and the trustmark URI, a signed OpenID Connect ID Token
   or a similarly signed assertion from another protocol would 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




Richer & Johansson      Expires November 19, 2018              [Page 16]

Internet-Draft              vectors-of-trust                    May 2018


   they should be expressed in detail in an associated human-readable
   trust framework document available at the trustmark URI.

10.  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.

11.  References

11.1.  Normative References

   [OpenID]   Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
              Core 1.0", November 2014.

   [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>;.

   [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>;.



Richer & Johansson      Expires November 19, 2018              [Page 17]

Internet-Draft              vectors-of-trust                    May 2018


   [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>;.

11.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, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/bcp195>;.

   [NISTIR-8112]
              National Institute of Standards and Technology, U.S.
              Department of Commerce, "A Proposed Schema for Evaluating
              Federated Attributes", NIST NISTIR 8112, January 2018,
              <https://pages.nist.gov/NISTIR-8112/NISTIR-8112.html>;.

   [SP-800-63-2]
              National Institute of Standards and Technology, U.S.
              Department of Commerce, "Electronic Authentication
              Guideline", NIST 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, U.S.
              Department of Commerce, "Digital Identity Guideline",
              NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017,
              <https://doi.org/10.6028/NIST.SP.800-63-3>;.

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.  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 Section 6.  Where
   possible, extensions MAY re-use specific values and definitions as
   listed here, but those specific values MUST be re-listed.








Richer & Johansson      Expires November 19, 2018              [Page 18]

Internet-Draft              vectors-of-trust                    May 2018


A.1.  Identity Proofing

   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.

   P0 No proofing is done, 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,
      employment records)

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

   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 / TPM-backed keys

   Cg Locally verified biometric








Richer & Johansson      Expires November 19, 2018              [Page 19]

Internet-Draft              vectors-of-trust                    May 2018


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

A.4.  Assertion Presentation

   The 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.

   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 relying parties key and audience
      protected

Appendix B.  Document History

   -11

   o  Updated IANA.

   o  Minor language tweaks from AD review.

   o  Removed SAML implementation.



Richer & Johansson      Expires November 19, 2018              [Page 20]

Internet-Draft              vectors-of-trust                    May 2018


   -10

   o  Various fixes to respond to AD review.

   o  Added introspection response IANA registration.

   o  Cleaned up IANA entries.

   o  Removed confusing per-IdP trustmark and discovery sections.
      Adopted single trustmark definition instead.

   o  Added definition of identity federation.

   o  Added definition of identity proofing.

   o  Added examples to component sections.

   -08

   o  Incorporated shepherd comments.

   o  Updated references.

   o  Added reference to NISTIR 8112.

   o  Moved default component definitions to appendix.

   -07

   o  Rewrote introduction to clarify focus of document.

   -06

   o  Added section on extensions to VoT.

   o  Made it so that every component category could be multi-valued.

   o  Added reference to updated 800-63-3.

   o  Fixed example text width.

   o  Switched document back to standards-track from experimental now
      that there are extensions in the wild.

   -05

   o  Updated IANA considerations section to include instructions.




Richer & Johansson      Expires November 19, 2018              [Page 21]

Internet-Draft              vectors-of-trust                    May 2018


   o  Made security and privacy considerations non-normative.

   -04

   o  Updated SAML example to be consistent.

   -03

   o  Clarified language of LoA's in introduction.

   o  Added note on operational security in trustmarks.

   o  Removed empty sections and references.

   -02

   o  Converted C, M, and A values to use letters instead of numbers in
      examples.

   o  Updated SAML to a structured example pending future updates.

   o  Defined guidance for when to use letters vs. numbers in category
      values.

   o  Restricted category demarcators to uppercase and values to
      lowercase and digits.

   o  Applied clarifying editorial changes from list comments.

   - 01

   o  Added IANA registry for components.

   o  Added preliminary security considerations and privacy
      considerations.

   o  Split "credential binding" into "primary credential usage" and
      "primary credential management".

   - 00

   o  Created initial IETF drafted based on strawman proposal discussed
      on VoT list.

   o  Split vector component definitions into their own section to allow
      extension and override.

   o  Solidified trustmark document definition.



Richer & Johansson      Expires November 19, 2018              [Page 22]

Internet-Draft              vectors-of-trust                    May 2018


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      Expires November 19, 2018              [Page 23]