[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                     J. Richer, Ed.
Internet-Draft                                       Bespoke Engineering
Intended status: Standards Track                            L. Johansson
Expires: March 16, 2018                       Swedish University Network
                                                      September 12, 2017


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

Abstract

   This document defines a mechanism for describing and signaling
   several aspects that are used to calculate trust placed in a digital
   identity 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 RFC
   2119 [RFC2119].

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 March 16, 2018.

Copyright Notice

   Copyright (c) 2017 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



Richer & Johansson       Expires March 16, 2018                 [Page 1]


Internet-Draft              vectors-of-trust              September 2017


   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 . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Identity Proofing . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Primary Credential Usage  . . . . . . . . . . . . . . . .   7
     2.3.  Primary Credential Management . . . . . . . . . . . . . .   7
     2.4.  Assertion Presentation  . . . . . . . . . . . . . . . . .   7
   3.  Vectors of Trust Default Component Value Definitions  . . . .   8
     3.1.  Identity Proofing . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Primary Credential Usage  . . . . . . . . . . . . . . . .   8
     3.3.  Primary Credential Management . . . . . . . . . . . . . .   9
     3.4.  Assertion Presentation  . . . . . . . . . . . . . . . . .   9
   4.  Communicating Vector Values to RPs  . . . . . . . . . . . . .  10
     4.1.  On the Wire Representation  . . . . . . . . . . . . . . .  10
     4.2.  In OpenID Connect . . . . . . . . . . . . . . . . . . . .  11
     4.3.  In SAML . . . . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Requesting Vector Values  . . . . . . . . . . . . . . . . . .  13
     5.1.  In OpenID Connect . . . . . . . . . . . . . . . . . . . .  13
     5.2.  In SAML . . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.  Defining New Vector Values  . . . . . . . . . . . . . . . . .  16
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Vector Of Trust Components Registry  . . . . . . . . . .  17
       10.1.1.  Registration Template  . . . . . . . . . . . . . . .  17
       10.1.2.  Initial Registry Contents  . . . . . . . . . . . . .  18
     10.2.  Additions to the OAuth Parameters Registry . . . . . . .  18
     10.3.  Additions to JWT Claims Registry . . . . . . . . . . . .  19
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     13.2.  Informative References . . . . . . . . . . . . . . . . .  20
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22




Richer & Johansson       Expires March 16, 2018                 [Page 2]


Internet-Draft              vectors-of-trust              September 2017


1.  Introduction

   This document defines a mechanism for measuring and signaling several
   aspects of digital identity and authentication transactions that are
   used to determine a level of trust in that transaction.  In the past,
   there have been two extremes of communicating authentication
   transaction information.

   At one extreme, all attributes can be communicated with full
   provenance and associated trust markings.  This approach seeks to
   create a fully-distributed attribute system to support functions such
   as attribute based access control (ABAC).  These attributes can be
   used to describe the end user, the identity provider, the relying
   party, or even the transaction itself.  While the information that
   can be expressed in this model is incredibly detailed and robust, the
   complexity of such a system is often prohibitive to realize,
   especially across security domains.  In particular, a large burden is
   placed on relying parties needing to process the sea of disparate
   attributes when making a security decision.

   At the other extreme there are systems that collapse all of the
   attributes and aspects into a single scalar value that communicates,
   in sum, how much a transaction can be trusted.  The NIST special
   publication 800-63 [SP-800-63-2] up to and including version 2
   defines a linear scale Level of Assurance (LoA) measure that combines
   multiple aspects about an identity transaction into such a single
   measure.  While this definition was originally narrowly targeted for
   a specific set of government use cases, the LoA scale appeared to be
   applicable with a wide variety of authentication scenarios in
   different domains.  This has led to a proliferation of incompatible
   interpretations of the same scale in different contexts, preventing
   interoperability between each LoA definition in spite of their common
   measurement.  LoA is artificially limited due to the original goal of
   creating a single linear scale.  Since identity proofing strength
   increases linearly along with credential strength in the LoA scale,
   this scale is too limited for describing many valid and useful forms
   of an identity transaction that do not fit the government's original
   model.  For example, an anonymously assigned hardware token can be
   used in cases where the real world identity of the subject cannot be
   known for privacy reasons, but the credential itself can be highly
   trusted.  This is in contrast with a government employee accessing a
   government system, where the identity of the individual would need to
   be highly proofed and strongly credentialed at the same time.  In
   fact, the latest update of NIST special publication 800-63
   [SP-800-63-3] (version 3) has done away with this single linear scale
   for exactly these reasons.





Richer & Johansson       Expires March 16, 2018                 [Page 3]


Internet-Draft              vectors-of-trust              September 2017


   The Vectors of Trust (VoT) effort seeks to find a balance between
   these two extremes by creating a data model that combines attributes
   of the user and aspects of the authentication context into several
   values that can be communicated separately but in parallel with each
   other.  This approach is both coarser grained than the distributed
   attributes model and finer grained than the single scalar model, with
   the hope that it is a viable balance of expressibility and
   processability.  Importantly, these three levels of granularity can
   be mapped to each other.  The information of several attributes can
   be folded into a vector component, while the vector itself can be
   folded into an assurance category.  As such, the vectors of trust
   seeks to complement, not replace, these other identity and trust
   mechanisms in the larger identity ecosystem while providing a single
   value for RPs to process.

1.1.  Terminology

   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 and
      identified to the relying party.

   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 verifiable attestation that a party has proved to follow
      the constraints of a trust framework.

   Trustmark Provider  A system that issues and provides verification
      for trustmarks.

   Vector  A multi-part data structure, used here for conveying
      information about an authentication transaction.





Richer & Johansson       Expires March 16, 2018                 [Page 4]


Internet-Draft              vectors-of-trust              September 2017


   Vector Component  One of several constituent parts that make up 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 is all carried by an identity assertion
   across the network to the relying party during the authentication
   transaction.

1.3.  Component Architecture

   The term Vectors of Trust is based on the mathematical construct of a
   vector, which is defined as an item composed of multiple independent
   values.

   An important goal for this work is to balance the need for simplicity
   (particularly on the part of the relying party) with the need for
   expressiveness.  As such, this vector construct is designed to be
   composable and extensible.

   All components of the vector construct MUST be orthogonal such that
   no aspect of a component overlaps an aspect of another component, as
   much as is possible.

2.  Component Definitions

   This specification defines four orthogonal components: identity
   proofing, primary credential usage, primary credential management,
   and assertion presentation.  These dimensions MUST be evaluated by
   the RP in the context of a trust framework and SHOULD be combined
   with other information when making a trust and authorization
   decision.





Richer & Johansson       Expires March 16, 2018                 [Page 5]


Internet-Draft              vectors-of-trust              September 2017


   This specification also defines values for each component to be used
   in the absence of a more specific trust framework in Section 3.  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 same context.  The RP MUST
   understand and take into account the trust framework context in which
   a vector is being expressed in order for it to be processed 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 10.  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.  For example, a
   category could define "0" as a special "empty" value while using
   letters such as "a", "b", "c" for normal values can to differentiate
   between these types of options.

   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" in a given transaction.

   Each component MAY be repeated with multiple different values within
   a single vector.  The same component and value MUST NOT be repeated
   within a single vector.

2.1.  Identity Proofing

   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.




Richer & Johansson       Expires March 16, 2018                 [Page 6]


Internet-Draft              vectors-of-trust              September 2017


   This dimension SHALL be represented by 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.  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

   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.

   This dimension SHALL be represented by 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.

2.3.  Primary Credential Management

   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.

   This dimension SHALL be represented by 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

   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



Richer & Johansson       Expires March 16, 2018                 [Page 7]


Internet-Draft              vectors-of-trust              September 2017


   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 5) and when describing the capabilities of an IdP
   (Section 7).

   This dimension SHALL be represented by 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.  Vectors of Trust Default Component Value Definitions

   This specification defines the following general-purpose component
   definitions, which MAY be used when a more specific set is
   unavailable.  These component values are referenced in a trustmark
   definition defined by [[ this document URL ]].

   Extensions of this specification SHOULD define their own component
   values as described in Section 8.

3.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.  Mutltiple 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)

3.2.  Primary Credential Usage

   The primary credential usage component of this vector definition
   represents distinct categories of primary credential that MAY be used




Richer & Johansson       Expires March 16, 2018                 [Page 8]


Internet-Draft              vectors-of-trust              September 2017


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

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

3.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 a session
      cookie in a web browser)




Richer & Johansson       Expires March 16, 2018                 [Page 9]


Internet-Draft              vectors-of-trust              September 2017


   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

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

   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.

4.1.  On the Wire Representation

   The vector MUST be represented as a period-separated ('.') list of
   vector components, with no specific order.  A vector component type
   MAY occur multiple times within a single vector, with each component
   separated by periods.  Multiple values for a component are considered
   a logical AND of the values.  A specific value of a vector component
   MUST NOT occur more than once in a single vector.  That is, while
   "Cc.Cd" is a valid vector, "Cc.Cc" is not.





Richer & Johansson       Expires March 16, 2018                [Page 10]


Internet-Draft              vectors-of-trust              September 2017


   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.  This MAY
   be distinct from a specific component value stating that a component
   was not used.

   Vector values MUST be communicated along side of a trustmark
   definition to give the components context.  The trustmark MUST be
   cryptographically bound to the vector value, such as 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 trustmarks MAY re-use component definitions
   (including their values), allowing comparison of individual
   components across contexts without requiring complete understanding
   of all aspects of a context.  The proper 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 (Section 3).  The vector value of
   "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for
   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.

4.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 6) that applies to this vector MUST be sent as an
   HTTPS URL in the "vtm" (vector trust mark) claim to provide context
   to the vector.

   For example, 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://trustmark.example.org/trustmark/idp.example.com"
   }

   The body of the ID token is signed and optionally encrypted using
   JOSE, as per the OpenID Connect specification.  By putting the "vot"



Richer & Johansson       Expires March 16, 2018                [Page 11]


Internet-Draft              vectors-of-trust              September 2017


   and "vtm" values inside the ID token, the vector and its context are
   strongly bound to the federated credential represented by the ID
   token.

4.3.  In SAML

   In SAML, a vector is communicated as an
   "AuthenticationContextDeclRef".  A vector is represented by prefixing
   it with the "urn urn:ietf:param:[TBD]" to form a full URN.  The
   "AuthenticationContextDeclaration" corresponding to a given vector is
   a "AuthenticationContextDeclaration" element containing an
   "Extension" element with components of the vector represented by the
   following XML schema:

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema
       targetNamespace="urn:ietf:param:[TBD]:schema"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
      <xs:element name="Vector">
         <xs:annotation>
            <xs:documentation>This represents a set of
                vector components.</xs:documentation>
         </xs:annotation>
         <xs:simpleType>
            <xs:restriction base="xsd:token">
               <xs:pattern value="([A-Z][a-z0-9])(\.[A-Z][a-z0-9])*"/>
            </xs:restriction>
         </xs:simpleType>
      </xs:element>
   </xs:schema>

   For instance the vector P1.Cc.Ac is represented by the
   AuthenticationContextDeclRef URN "urn:ietf:param:[TBD]:P1.Cc.Ac" (or
   "urn:ietf:param:[TBD]:Cc.P1.Ac" or ...) which corresponds to the
   following "AuthenticationContextDeclaration":

   <?xml version="1.0" encoding="UTF-8"?>
   <AuthenticationContextDeclaration
     xmlns="urn:oasis:names:tc:SAML:2.0:ac">
      <Extension>
         <vot:Vector>P1.Cc.Ac</vot:Vector>
      </Extension>
   </AuthenticationContextDeclaration>








Richer & Johansson       Expires March 16, 2018                [Page 12]


Internet-Draft              vectors-of-trust              September 2017


5.  Requesting Vector Values

   In some identity protocols, the RP can request that particular vector
   components be applied to a given identity transaction.  Using the
   same syntax as defined in Section 4.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.

5.1.  In OpenID Connect

   In OpenID Connect [OpenID], the client MAY request a set of
   acceptable VoT 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 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.2.  In SAML

   In SAML (Section 4.3) the client can request a set of acceptable VoT
   values by including the corresponding "AuthenticationContextDeclRef"
   URIs together with an "AuthenticationContextClassRef" corresponding
   to the trust mark (cf below).  The processing rules in Section 4.3
   apply.

6.  Trustmark

   When an RP receives a specific vector from an IdP, it needs to make a
   decision to trust the vector within a specific context.  A trust
   framework can provide such a context, allowing legal and business
   rules to give weight to an IdP's claims.  A trustmark is a verifiable
   claim to conform to a specific component of a trust framework, such
   as a verified identity provider.  The trustmark conveys the root of
   trustworthiness about the claims and assertions made by the IdP,
   including the vector itself.



Richer & Johansson       Expires March 16, 2018                [Page 13]


Internet-Draft              vectors-of-trust              September 2017


   The trustmark MUST be available from an HTTPS URL served by the trust
   framework provider.  The contents of this URL are a JSON [RFC7159]
   document with the following fields:

   idp  The issuer URL of the identity provider that this trustmark
      pertains to.  This MUST match the corresponding issuer claim in
      the identity token, such as the OpenID Connect "iss" field.  This
      MUST be an HTTPS URL.

   trustmark_provider  The issuer URL of the trustmark provider that
      issues this trustmark.  The URL that a trustmark is fetched from
      MUST start with the "iss" URL in this field.  This MUST be an
      HTTPS URL.

   Vector component values offered by this IdP are be listed in a using
   their demarcator.  For the four component categories defined in this
   specification:

   P  Array of strings containing identity proofing values for which the
      identity provider has been assessed and approved.

   C  Array of strings containing primary credential usage values for
      which the identity provider has been assessed and approved.

   M  Array of strings containing primary credential management values
      for which the identity provider has been assessed and approved.

   A  Array of strings containing assertion strength values for which
      the identity provider has been assessed and approved.

   For example, the following trustmark provided by the
   trustmark.example.org organization applies to the idp.example.org
   identity provider:

   {
     "idp": "https://idp.example.org/",
     "trustmark_provider": "https://trustmark.example.org/",
     "P": ["P0", "P1"],
     "C": ["C0", "Ca", "Cb"],
     "M": ["Mb"],
     "A": ["Ab", "Ac"]
   }

   An RP wishing to check the claims made by an IdP can fetch the
   information from the trustmark provider about what claims the IdP is
   allowed to make in the first place and process them accordingly.  The
   RP MAY cache the information returned from the trustmark URL.




Richer & Johansson       Expires March 16, 2018                [Page 14]


Internet-Draft              vectors-of-trust              September 2017


   The operational aspects of the IdP MAY be included in the trustmark
   definition.  For example, if a trustmark can indicate that an IdP
   uses multiple redundant hosts, encrypts all data at rest, or other
   operational security mechanisms that affect the trustworthiness of
   assertions made by the IdP.  The definition of these additional
   aspects is outside the scope of this specfication.

   The means by which the RP decides which trustmark providers it trusts
   is out of scope for this specification and is generally configured
   out of band.

   Though most trust frameworks will provide a third-party independent
   verification service for components, an IdP MAY host its own
   trustmark.  For example, a self-hosted trustmark would look like:

   {
     "idp": "https://idp.example.org/",
     "trustmark_provider": "https://idp.example.org/",
     "P": ["P0", "P1"],
     "C": ["C0", "Ca", "Cb"],
     "M": ["Mb"],
     "A": ["Ab", "Ac"]
   }

7.  Discovery

   The IdP MAY list all of its available trustmarks as part of its
   discovery document, such as the OpenID Connect Discovery server
   configuration document.  In this context, trustmarks are listed in
   the "trustmarks" element which contains a single JSON [RFC7159]
   object.  The keys of this JSON object are trustmark provider issuer
   URLs and the values of this object are the corresponding trustmark
   URLs for this IdP.

   {
     "iss": "https://idp.example.org/",
     "trustmarks": {
       "https://trustmark.example.org/":
         "https://trustmark.example.org/trustmark/idp.example.org",
       "https://trust.example.net/":
         "https://trust.example.net/trustmark/idp.example.org"
     }
   }








Richer & Johansson       Expires March 16, 2018                [Page 15]


Internet-Draft              vectors-of-trust              September 2017


8.  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, it is anticipated that
   many situations will require an extension of this specification for
   their own use.

   Components 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 10.  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 Section 3 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,
   extensions 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 trustmark
   documents.

   Extensions to this specification SHOULD choose either a numerical
   ordering or a group category approach to component values as
   described in . Extensions to 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.

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





Richer & Johansson       Expires March 16, 2018                [Page 16]


Internet-Draft              vectors-of-trust              September 2017


10.  IANA Considerations

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

10.1.  Vector Of Trust Components Registry

   This specification establishes the Vectors of Trust Components
   Registry.

   Component demarcators are registered by Specification Required
   [RFC5226] after a two-week review period on the vot@ietf.org mailing
   list, on the advice of one or more Designated Experts.

   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 mailing list for review should use
   an appropriate subject (e.g., "Request to register Vector of Trust
   Component name: example").  Within the review period, the Designated
   Expert(s) will 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 review mailing list.

10.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 Standards Track RFCs, state "IESG".  For other documents, give
      the name of the responsible party.  Other details (e.g., postal
      address, email address, home page URI) may also be included.

   Specification document(s):
      Reference to the document(s) that specify the token endpoint
      authorization method, preferably including a URI that can be used




Richer & Johansson       Expires March 16, 2018                [Page 17]


Internet-Draft              vectors-of-trust              September 2017


      to retrieve a copy of the document(s).  An indication of the
      relevant sections may also be included but is not required.

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

   o  Demarcator Symbol: A

   o  Description: Assertion presentation

   o  Change Controller: IESG

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

10.2.  Additions to the OAuth Parameters Registry

   This specification adds the following values to the OAuth Parameters
   Registry established by [RFC6749].

   o  Demarcator Symbol: vtr

   o  Description: Vector of Trust request



Richer & Johansson       Expires March 16, 2018                [Page 18]


Internet-Draft              vectors-of-trust              September 2017


   o  Change Controller: IESG

   o  Document: [[ this document ]]

10.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  Demarcator Symbol: vtm

   o  Description: Vector of Trust trustmark

   o  Change Controller: IESG

   o  Document: [[ this document ]]

11.  Security Considerations

   The vector of trust value MUST be cryptographically protected in
   transit, using TLS as described in [BCP195].  The vector of trust
   value must be associated with a trustmark marker, and the two must be
   carried together in a cryptographically bound mechanism such as a
   signed identity assertion.  A signed OpenID Connect ID Token and a
   signed SAML assertion both fulfil this requirement.

   The VoT framework provides a mechanism for describing and conveying
   trust information.  It does not define any policies for asserting the
   values of the vector, nor does it define any policies for applying
   the values of a vector to an RP's security decision process.  These
   policies must be agreed upon by the IdP and RP, and they should be
   expressed in detail in an associated human-readable trust framework
   document.

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



Richer & Johansson       Expires March 16, 2018                [Page 19]


Internet-Draft              vectors-of-trust              September 2017


   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 systems in general use the minimum vectors applicable to their
   use case in order to prevent inadvertent information disclosure.

13.  References

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

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

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

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

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

   [SP-800-63-2]
              and , "Electronic Authentication Guideline", August 2013,
              <https://dx.doi.org/10.6028/NIST.SP.800-63-2>.





Richer & Johansson       Expires March 16, 2018                [Page 20]


Internet-Draft              vectors-of-trust              September 2017


   [SP-800-63-3]
              and , "Electronic Authentication Guideline", June 2017,
              <https://doi.org/10.6028/NIST.SP.800-63-3>.

Appendix A.  Document History

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

   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.





Richer & Johansson       Expires March 16, 2018                [Page 21]


Internet-Draft              vectors-of-trust              September 2017


   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.

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 March 16, 2018                [Page 22]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/