< draft-richer-vectors-of-trust-05.txt   draft-richer-vectors-of-trust-06.txt >
Network Working Group J. Richer, Ed. Network Working Group J. Richer, Ed.
Internet-Draft Bespoke Engineering Internet-Draft Bespoke Engineering
Intended status: Experimental L. Johansson Intended status: Standards Track L. Johansson
Expires: October 5, 2017 Swedish University Network Expires: March 16, 2018 Swedish University Network
April 3, 2017 September 12, 2017
Vectors of Trust Vectors of Trust
draft-richer-vectors-of-trust-05 draft-richer-vectors-of-trust-06
Abstract Abstract
This document defines a mechanism for describing and signaling This document defines a mechanism for describing and signaling
several aspects that are used to calculate trust placed in a digital several aspects that are used to calculate trust placed in a digital
identity transaction. identity transaction.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 33 skipping to change at page 1, line 33
2119 [RFC2119]. 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2017. This Internet-Draft will expire on March 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5
1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5
2. Component Definitions . . . . . . . . . . . . . . . . . . . . 5 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 5
2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6 2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6
2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 7 2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 7
2.3. Primary Credential Management . . . . . . . . . . . . . . 7 2.3. Primary Credential Management . . . . . . . . . . . . . . 7
2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 7 2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 7
3. Vectors of Trust Initial Component Value Definitions . . . . 8 3. Vectors of Trust Default Component Value Definitions . . . . 8
3.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 8 3.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 8
3.2. Primary Credential Usage . . . . . . . . . . . . . . . . 8 3.2. Primary Credential Usage . . . . . . . . . . . . . . . . 8
3.3. Primary Credential Management . . . . . . . . . . . . . . 9 3.3. Primary Credential Management . . . . . . . . . . . . . . 9
3.4. Assertion Presentation . . . . . . . . . . . . . . . . . 9 3.4. Assertion Presentation . . . . . . . . . . . . . . . . . 9
4. Communicating Vector Values to RPs . . . . . . . . . . . . . 10 4. Communicating Vector Values to RPs . . . . . . . . . . . . . 10
4.1. On the Wire Representation . . . . . . . . . . . . . . . 10 4.1. On the Wire Representation . . . . . . . . . . . . . . . 10
4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11 4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11
4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 12 5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 13
5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 13
5.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. Defining New Vector Values . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Vector Of Trust Components Registry . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1.1. Registration Template . . . . . . . . . . . . . . . . 16 10.1. Vector Of Trust Components Registry . . . . . . . . . . 17
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16 10.1.1. Registration Template . . . . . . . . . . . . . . . 17
9.1.3. Additions to JWT Claims Registry . . . . . . . . . . 17 10.1.2. Initial Registry Contents . . . . . . . . . . . . . 18
9.1.4. Additions to the OAuth . . . . . . . . . . . . . . . 18 10.2. Additions to the OAuth Parameters Registry . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10.3. Additions to JWT Claims Registry . . . . . . . . . . . . 19
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Document History . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Document History . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document defines a mechanism for measuring and signaling several This document defines a mechanism for measuring and signaling several
aspects of digital identity and authentication transactions that are aspects of digital identity and authentication transactions that are
used to determine a level of trust in that transaction. In the past, used to determine a level of trust in that transaction. In the past,
there have been two extremes of communicating authentication there have been two extremes of communicating authentication
transaction information. transaction information.
At one extreme, all attributes can be communicated with full At one extreme, all attributes can be communicated with full
skipping to change at page 3, line 28 skipping to change at page 3, line 28
party, or even the transaction itself. While the information that party, or even the transaction itself. While the information that
can be expressed in this model is incredibly detailed and robust, the can be expressed in this model is incredibly detailed and robust, the
complexity of such a system is often prohibitive to realize, complexity of such a system is often prohibitive to realize,
especially across security domains. In particular, a large burden is especially across security domains. In particular, a large burden is
placed on relying parties needing to process the sea of disparate placed on relying parties needing to process the sea of disparate
attributes when making a security decision. attributes when making a security decision.
At the other extreme there are systems that collapse all of the At the other extreme there are systems that collapse all of the
attributes and aspects into a single scalar value that communicates, attributes and aspects into a single scalar value that communicates,
in sum, how much a transaction can be trusted. The NIST special in sum, how much a transaction can be trusted. The NIST special
publication 800-63 [SP-800-63-2] version 2 defines a linear scale publication 800-63 [SP-800-63-2] up to and including version 2
Level of Assurance (LoA) measure that combines multiple attributes defines a linear scale Level of Assurance (LoA) measure that combines
about an identity transaction into such a single measure. While this multiple aspects about an identity transaction into such a single
definition was originally narrowly targeted for a specific set of measure. While this definition was originally narrowly targeted for
government use cases, the LoA scale appeared to be applicable with a a specific set of government use cases, the LoA scale appeared to be
wide variety of authentication scenarios in different domains. This applicable with a wide variety of authentication scenarios in
has led to a proliferation of incompatible interpretations of the different domains. This has led to a proliferation of incompatible
same scale in different contexts, preventing interoperability between interpretations of the same scale in different contexts, preventing
each LoA definition in spite of their common measurement. LoA is interoperability between each LoA definition in spite of their common
artificially limited due to the original goal of creating a single measurement. LoA is artificially limited due to the original goal of
linear scale. Since identity proofing strength increases linearly creating a single linear scale. Since identity proofing strength
along with credential strength in the LoA scale, this scale is too increases linearly along with credential strength in the LoA scale,
limited for describing many valid and useful forms of an identity this scale is too limited for describing many valid and useful forms
transaction that do not fit the government's original model. For of an identity transaction that do not fit the government's original
example, an anonymously assigned hardware token can be used in cases model. For example, an anonymously assigned hardware token can be
where the real world identity of the subject cannot be known for used in cases where the real world identity of the subject cannot be
privacy reasons, but the credential itself can be highly trusted. known for privacy reasons, but the credential itself can be highly
This is in contrast with a government employee accessing a government trusted. This is in contrast with a government employee accessing a
system, where the identity of the individual would need to be highly government system, where the identity of the individual would need to
proofed and strongly credentialed at the same time. 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.
The Vectors of Trust (VoT) effort seeks to find a balance between The Vectors of Trust (VoT) effort seeks to find a balance between
these two extremes by creating a data model that combines attributes these two extremes by creating a data model that combines attributes
of the user and aspects of the authentication context into several of the user and aspects of the authentication context into several
values that can be communicated separately but in parallel with each values that can be communicated separately but in parallel with each
other. This approach is both coarser grained than the distributed other. This approach is both coarser grained than the distributed
attributes model and finer grained than the single scalar model, with attributes model and finer grained than the single scalar model, with
the hope that it is a viable balance of expressibility and the hope that it is a viable balance of expressibility and
processability. Importantly, these three levels of granularity can processability. Importantly, these three levels of granularity can
be mapped to each other. The information of several attributes can be mapped to each other. The information of several attributes can
skipping to change at page 6, line 13 skipping to change at page 6, line 18
and mapping to legal statutes and business rules for each value in and mapping to legal statutes and business rules for each value in
each component. Consequently, a particular vector value can only be each component. Consequently, a particular vector value can only be
compared with vectors defined in the same context. The RP MUST compared with vectors defined in the same context. The RP MUST
understand and take into account the trust framework context in which understand and take into account the trust framework context in which
a vector is being expressed in order for it to be processed securely. a vector is being expressed in order for it to be processed securely.
Each component is identified by a demarcator consisting of a single Each component is identified by a demarcator consisting of a single
uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD
reflect the category with which it is associated in a natural manner. reflect the category with which it is associated in a natural manner.
Demarcators for components MUST be registered as described in Demarcators for components MUST be registered as described in
Section 9. It is anticipated that trust framework definitions will Section 10. It is anticipated that trust framework definitions will
use this registry to define specialized components, though it is use this registry to define specialized components, though it is
RECOMMENDED that trust frameworks re-use existing components wherever RECOMMENDED that trust frameworks re-use existing components wherever
possible. possible.
The value for a given component within a vector of trust is defined The value for a given component within a vector of trust is defined
by its demarcator character followed by a single digit or lowercase by its demarcator character followed by a single digit or lowercase
ASCII letter in the range "[0-9a-z]". Categories which have a ASCII letter in the range "[0-9a-z]". Categories which have a
natural ordering SHOULD use digits, with "0" as the lowest value. natural ordering SHOULD use digits, with "0" as the lowest value.
Categories which do not have a natural ordering, or which can have an Categories which do not have a natural ordering, or which can have an
ambiguous ordering, SHOULD use letters. Categories MAY use both ambiguous ordering, SHOULD use letters. Categories MAY use both
skipping to change at page 6, line 36 skipping to change at page 6, line 41
letters such as "a", "b", "c" for normal values can to differentiate letters such as "a", "b", "c" for normal values can to differentiate
between these types of options. between these types of options.
Regardless of the type of value indicator used, the values assigned Regardless of the type of value indicator used, the values assigned
to each component of a vector MUST NOT be assumed always to have to each component of a vector MUST NOT be assumed always to have
inherent ordinal properties when compared to the same or other inherent ordinal properties when compared to the same or other
components in the vector space. In other words, "1" is different components in the vector space. In other words, "1" is different
from "2", but it is dangerous to assume that "2" is always better from "2", but it is dangerous to assume that "2" is always better
than "1" in a given transaction. 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 2.1. Identity Proofing
The Identity Proofing dimension defines, overall, how strongly the The Identity Proofing dimension defines, overall, how strongly the
set of identity attributes have been verified and vetted. In other set of identity attributes have been verified and vetted. In other
words, this dimension describes how likely it is that a given digital words, this dimension describes how likely it is that a given digital
identity transaction corresponds to a particular (real-world) identity transaction corresponds to a particular (real-world)
identity subject. identity subject.
This dimension SHALL be represented by the "P" demarcator and a This dimension SHALL be represented by the "P" demarcator and a
single-character level value, such as "P0", "P1", etc. Most single-character level value, such as "P0", "P1", etc. Most
definitions of identity proofing will have a natural ordering, as definitions of identity proofing will have a natural ordering, as
more or less stringent proofing can be applied to an individual. In 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 such cases it is RECOMMENDED that a digit style value be used for
this component. this component and that only a single value be allowed to be
communicated in a transaction.
2.2. Primary Credential Usage 2.2. Primary Credential Usage
The primary credential usage dimension defines how strongly the The primary credential usage dimension defines how strongly the
primary credential can be verified by the IdP. In other words, how primary credential can be verified by the IdP. In other words, how
easily that credential could be spoofed or stolen. easily that credential could be spoofed or stolen.
This dimension SHALL be represented by the "C" demarcator and a This dimension SHALL be represented by the "C" demarcator and a
single-character level value, such as "Ca", "Cb", etc. Most single-character level value, such as "Ca", "Cb", etc. Most
definitions of credential usage will not have an overall natural definitions of credential usage will not have an overall natural
ordering, as there may be several equivalent classes described within ordering, as there may be several equivalent classes described within
a trust framework. In such cases it is RECOMMENDED that a letter a trust framework. In such cases it is RECOMMENDED that a letter
style value be used for this component. Multiple credential usage style value be used for this component and that multiple distinct
factors MAY be communicated simultaneously, such as when Multi-Factor credential usage factors be allowed to be communicated
Authentication is used. simultaneously, such as when Multi-Factor Authentication is used.
2.3. Primary Credential Management 2.3. Primary Credential Management
The primary credential management dimension conveys information about The primary credential management dimension conveys information about
the expected lifecycle of the primary credential in use, including the expected lifecycle of the primary credential in use, including
its binding, rotation, and revocation. In other words, the use and its binding, rotation, and revocation. In other words, the use and
strength of policies, practices, and security controls used in strength of policies, practices, and security controls used in
managing the credential at the IdP and its binding to the intended managing the credential at the IdP and its binding to the intended
individual. individual.
This dimension SHALL be represented by the "M" demarcator and a This dimension SHALL be represented by the "M" demarcator and a
single-character level value, such as "Ma", "Mb", etc. Most single-character level value, such as "Ma", "Mb", etc. Most
definitions of credential management will not have an overall natural definitions of credential management will not have an overall natural
ordering, though there can be preference and comparison between ordering, though there can be preference and comparison between
values in some circumstances. In such cases it is RECOMMENDED that a values in some circumstances. In such cases it is RECOMMENDED that a
letter style value be used for this component. letter style value be used for this component and that multiple
distinct values be allowed to be communicated simultaneously.
2.4. Assertion Presentation 2.4. Assertion Presentation
The Assertion Presentation dimension defines how well the given The Assertion Presentation dimension defines how well the given
digital identity can be communicated across the network without digital identity can be communicated across the network without
information leaking to unintended parties, and without spoofing. In information leaking to unintended parties, and without spoofing. In
other words, this dimension describes how likely it is that a given other words, this dimension describes how likely it is that a given
digital identity was actually asserted by a given identity provider digital identity was actually asserted by a given identity provider
for a given transaction. While this information is largely already for a given transaction. While this information is largely already
known by the RP as a side effect of processing an identity assertion, 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 this dimension is still very useful when the RP requests a login
(Section 5) and when describing the capabilities of an IdP (Section 5) and when describing the capabilities of an IdP
(Section 7). (Section 7).
This dimension SHALL be represented by the "A" demarcator and a level This dimension SHALL be represented by the "A" demarcator and a level
value, such as "Aa", "Ab", etc. Most definitions of assertion value, such as "Aa", "Ab", etc. Most definitions of assertion
presentation will not have an overall natural ordering. In such presentation will not have an overall natural ordering. In such
cases, it is RECOMMENDED that a letter style value be used for this cases, it is RECOMMENDED that a letter style value be used for this
component. component and that multiple values be allowed to be communicated
simultaneously.
3. Vectors of Trust Initial Component Value Definitions 3. Vectors of Trust Default Component Value Definitions
This specification defines the following general-purpose component This specification defines the following general-purpose component
definitions, which MAY be used when a more specific set is definitions, which MAY be used when a more specific set is
unavailable. These component values are referenced in a trustmark unavailable. These component values are referenced in a trustmark
definition defined by [[ this document URL ]]. definition defined by [[ this document URL ]].
It is anticipated that trust frameworks and specific applications of Extensions of this specification SHOULD define their own component
this specification will define their own component values. In order values as described in Section 8.
to simplify processing by RPs, it is RECOMMENDED that trust framework
definitions carefully define component values such that they are
mutually exclusive or subsumptive in order to avoid repeated vector
components where possible.
3.1. Identity Proofing 3.1. Identity Proofing
The identity proofing component of this vector definition represents The identity proofing component of this vector definition represents
increasing scrutiny during the proofing process. Higher levels are increasing scrutiny during the proofing process. Higher levels are
largely subsumptive of lower levels, such that "P2" fulfills largely subsumptive of lower levels, such that "P2" fulfills
requirements for "P1", etc. 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 P0 No proofing is done, data is not guaranteed to be persistent
across sessions across sessions
P1 Attributes are self-asserted but consistent over time, potentially P1 Attributes are self-asserted but consistent over time, potentially
pseudonymous pseudonymous
P2 Identity has been proofed either in person or remotely using P2 Identity has been proofed either in person or remotely using
trusted mechanisms (such as social proofing) trusted mechanisms (such as social proofing)
P3 There is a binding relationship between the identity provider and P3 There is a binding relationship between the identity provider and
the identified party (such as signed/notarized documents, the identified party (such as signed/notarized documents,
employment records) employment records)
3.2. Primary Credential Usage 3.2. Primary Credential Usage
The primary credential usage component of this vector definition The primary credential usage component of this vector definition
represents distinct categories of primary credential that MAY be used represents distinct categories of primary credential that MAY be used
together in a single transaction. 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 C0 No credential is used / anonymous public service
Ca Simple session cookies (with nothing else) Ca Simple session cookies (with nothing else)
Cb Known device Cb Known device
Cc Shared secret such as a username and password combination Cc Shared secret such as a username and password combination
Cd Cryptographic proof of key possession using shared key Cd Cryptographic proof of key possession using shared key
Ce Cryptographic proof of key possession using asymmetric key Ce Cryptographic proof of key possession using asymmetric key
Cf Sealed hardware token / trusted biometric / TPM-backed keys Cf Sealed hardware token / trusted biometric / TPM-backed keys
3.3. Primary Credential Management 3.3. Primary Credential Management
skipping to change at page 9, line 18 skipping to change at page 9, line 27
Ce Cryptographic proof of key possession using asymmetric key Ce Cryptographic proof of key possession using asymmetric key
Cf Sealed hardware token / trusted biometric / TPM-backed keys Cf Sealed hardware token / trusted biometric / TPM-backed keys
3.3. Primary Credential Management 3.3. Primary Credential Management
The primary credential management component of this vector definition The primary credential management component of this vector definition
represents distinct categories of management that MAY be considered represents distinct categories of management that MAY be considered
separately or together in a single transaction. Many trust framework separately or together in a single transaction. Many trust framework
deployments MAY use a single value for this component as a baseline deployments MAY use a single value for this component as a baseline
for all transactions and thereby omit it. 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 Ma Self-asserted primary credentials (user chooses their own
credentials and must rotate or revoke them manually) / no credentials and must rotate or revoke them manually) / no
additional verification for primary credential issuance or additional verification for primary credential issuance or
rotation rotation
Mb Remote issuance and rotation / use of backup recover credentials Mb Remote issuance and rotation / use of backup recover credentials
(such as email verification) / deletion on user request (such as email verification) / deletion on user request
Mc Full proofing required for each issuance and rotation / revocation Mc Full proofing required for each issuance and rotation / revocation
on suspicious activity on suspicious activity
3.4. Assertion Presentation 3.4. Assertion Presentation
The assertion presentation component of this vector definition The assertion presentation component of this vector definition
represents distinct categories of assertion which are RECOMMENDED to represents distinct categories of assertion which are RECOMMENDED to
be used in a subsumptive manner but MAY be used together. 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 Aa No protection / unsigned bearer identifier (such as a session
cookie in a web browser) cookie in a web browser)
Ab Signed and verifiable assertion, passed through the user agent Ab Signed and verifiable assertion, passed through the user agent
(web browser) (web browser)
Ac Signed and verifiable assertion, passed through a back channel Ac Signed and verifiable assertion, passed through a back channel
Ad Assertion encrypted to the relying parties key and audience Ad Assertion encrypted to the relying parties key and audience
skipping to change at page 11, line 49 skipping to change at page 12, line 10
} }
The body of the ID token is signed and optionally encrypted using The body of the ID token is signed and optionally encrypted using
JOSE, as per the OpenID Connect specification. By putting the "vot" JOSE, as per the OpenID Connect specification. By putting the "vot"
and "vtm" values inside the ID token, the vector and its context are and "vtm" values inside the ID token, the vector and its context are
strongly bound to the federated credential represented by the ID strongly bound to the federated credential represented by the ID
token. token.
4.3. In SAML 4.3. In SAML
In SAML, a vector is communicated as an AuthenticationContextDeclRef. In SAML, a vector is communicated as an
A vector is represented by prefixing it with the urn "AuthenticationContextDeclRef". A vector is represented by prefixing
urn:ietf:param:[TBD] to form a full URN. The it with the "urn urn:ietf:param:[TBD]" to form a full URN. The
AuthenticationContextDeclaration corresponding to a given vector is a "AuthenticationContextDeclaration" corresponding to a given vector is
AuthenticationContextDeclaration element containing an Extension a "AuthenticationContextDeclaration" element containing an
element with components of the vector represented by the following "Extension" element with components of the vector represented by the
XML schema: following XML schema:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:param:[TBD]:schema" targetNamespace="urn:ietf:param:[TBD]:schema"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
<xs:element name="Vector"> <xs:element name="Vector">
<xs:annotation> <xs:annotation>
<xs:documentation>This represents a set of vector components.</xs:documentation> <xs:documentation>This represents a set of
</xs:annotation> vector components.</xs:documentation>
<xs:simpleType> </xs:annotation>
<xs:restriction base="xsd:token"> <xs:simpleType>
<xs:pattern value="([A-Z][a-z0-9])(\.[A-Z][a-z0-9])*"/> <xs:restriction base="xsd:token">
</xs:restriction> <xs:pattern value="([A-Z][a-z0-9])(\.[A-Z][a-z0-9])*"/>
</xs:simpleType> </xs:restriction>
</xs:element> </xs:simpleType>
</xs:schema> </xs:element>
</xs:schema>
For instance the vector P1.Cc.Ac is represented by the For instance the vector P1.Cc.Ac is represented by the
AuthenticationContextDeclRef URN urn:ietf:param:[TBD]:P1.Cc.Ac (or AuthenticationContextDeclRef URN "urn:ietf:param:[TBD]:P1.Cc.Ac" (or
urn:ietf:param:[TBD]:Cc.P1.Ac or ...) which corresponds to the "urn:ietf:param:[TBD]:Cc.P1.Ac" or ...) which corresponds to the
following AuthenticationContextDeclaration: following "AuthenticationContextDeclaration":
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<AuthenticationContextDeclaration xmlns="urn:oasis:names:tc:SAML:2.0:ac"> <AuthenticationContextDeclaration
<Extension> xmlns="urn:oasis:names:tc:SAML:2.0:ac">
<vot:Vector>P1.Cc.Ac</vot:Vector> <Extension>
</Extension> <vot:Vector>P1.Cc.Ac</vot:Vector>
</AuthenticationContextDeclaration> </Extension>
</AuthenticationContextDeclaration>
5. Requesting Vector Values 5. Requesting Vector Values
In some identity protocols, the RP can request that particular vector In some identity protocols, the RP can request that particular vector
components be applied to a given identity transaction. Using the components be applied to a given identity transaction. Using the
same syntax as defined in Section 4.1, an RP can indicate that it same syntax as defined in Section 4.1, an RP can indicate that it
desires particular aspects be present in the authentication. desires particular aspects be present in the authentication.
Processing and fulfillment of these requests are in the purview of Processing and fulfillment of these requests are in the purview of
the IdP and details are outside the scope of this specification. the IdP and details are outside the scope of this specification.
skipping to change at page 13, line 22 skipping to change at page 13, line 38
is acceptable for that component category, including omission of that is acceptable for that component category, including omission of that
component in the response vector. component in the response vector.
The mechanism by which the IdP processes the "vtr" and maps that to The mechanism by which the IdP processes the "vtr" and maps that to
the authentication transaction are out of scope of this the authentication transaction are out of scope of this
specification. specification.
5.2. In SAML 5.2. In SAML
In SAML (Section 4.3) the client can request a set of acceptable VoT In SAML (Section 4.3) the client can request a set of acceptable VoT
values by including the corresponding AuthenticationContextDeclRef values by including the corresponding "AuthenticationContextDeclRef"
URIs together with an AuthenticationContextClassRef corresponding to URIs together with an "AuthenticationContextClassRef" corresponding
the trust mark (cf below). The processing rules in Section 4.3 to the trust mark (cf below). The processing rules in Section 4.3
apply. apply.
6. Trustmark 6. Trustmark
When an RP receives a specific vector from an IdP, it needs to make a 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 decision to trust the vector within a specific context. A trust
framework can provide such a context, allowing legal and business framework can provide such a context, allowing legal and business
rules to give weight to an IdP's claims. A trustmark is a verifiable 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 claim to conform to a specific component of a trust framework, such
as a verified identity provider. The trustmark conveys the root of as a verified identity provider. The trustmark conveys the root of
skipping to change at page 15, line 24 skipping to change at page 15, line 39
7. Discovery 7. Discovery
The IdP MAY list all of its available trustmarks as part of its The IdP MAY list all of its available trustmarks as part of its
discovery document, such as the OpenID Connect Discovery server discovery document, such as the OpenID Connect Discovery server
configuration document. In this context, trustmarks are listed in configuration document. In this context, trustmarks are listed in
the "trustmarks" element which contains a single JSON [RFC7159] the "trustmarks" element which contains a single JSON [RFC7159]
object. The keys of this JSON object are trustmark provider issuer object. The keys of this JSON object are trustmark provider issuer
URLs and the values of this object are the corresponding trustmark URLs and the values of this object are the corresponding trustmark
URLs for this IdP. URLs for this IdP.
{ {
"iss": "https://idp.example.org/", "iss": "https://idp.example.org/",
"trustmark": { "trustmarks": {
"https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/" "https://trustmark.example.org/":
} "https://trustmark.example.org/trustmark/idp.example.org",
} "https://trust.example.net/":
"https://trust.example.net/trustmark/idp.example.org"
}
}
8. Acknowledgements 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 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 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 and document, and the members of the ISOC Trust and Identity team for
their support. their support.
9. IANA Considerations 10. IANA Considerations
This specification creates one registry and registers several values This specification creates one registry and registers several values
into existing registries. into existing registries.
9.1. Vector Of Trust Components Registry 10.1. Vector Of Trust Components Registry
This specification establishes the Vectors of Trust Components This specification establishes the Vectors of Trust Components
Registry. Registry.
Component demarcators are registered by Specification Required Component demarcators are registered by Specification Required
[RFC5226] after a two-week review period on the vot@ietf.org mailing [RFC5226] after a two-week review period on the vot@ietf.org mailing
list, on the advice of one or more Designated Experts. list, on the advice of one or more Designated Experts.
Criteria that should be applied by the Designated Experts includes Criteria that should be applied by the Designated Experts includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
skipping to change at page 16, line 21 skipping to change at page 17, line 35
Registration requests sent to the mailing list for review should use Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register Vector of Trust an appropriate subject (e.g., "Request to register Vector of Trust
Component name: example"). Within the review period, the Designated Component name: example"). Within the review period, the Designated
Expert(s) will either approve or deny the registration request, Expert(s) will either approve or deny the registration request,
communicating this decision to the review list and IANA. Denials communicating this decision to the review list and IANA. Denials
should include an explanation and, if applicable, suggestions as to should include an explanation and, if applicable, suggestions as to
how to make the request successful. IANA must only accept registry how to make the request successful. IANA must only accept registry
updates from the Designated Expert(s) and should direct all requests updates from the Designated Expert(s) and should direct all requests
for registration to the review mailing list. for registration to the review mailing list.
9.1.1. Registration Template 10.1.1. Registration Template
Demarcator Symbol Demarcator Symbol
An uppercase ASCII letter in the range [A-Z] representing this An uppercase ASCII letter in the range [A-Z] representing this
component (e.g., "X"). component (e.g., "X").
Description: Description:
Brief description of the component (e.g., "Example description"). Brief description of the component (e.g., "Example description").
Change controller: Change controller:
For Standards Track RFCs, state "IESG". For other documents, give For Standards Track RFCs, state "IESG". For other documents, give
the name of the responsible party. Other details (e.g., postal the name of the responsible party. Other details (e.g., postal
address, email address, home page URI) may also be included. address, email address, home page URI) may also be included.
Specification document(s): Specification document(s):
Reference to the document(s) that specify the token endpoint Reference to the document(s) that specify the token endpoint
authorization method, preferably including a URI that can be used authorization method, preferably including a URI that can be used
to retrieve a copy of the document(s). An indication of the to retrieve a copy of the document(s). An indication of the
relevant sections may also be included but is not required. relevant sections may also be included but is not required.
9.1.2. Initial Registry Contents 10.1.2. Initial Registry Contents
The Vector of Trust Components Registry contains the definitions of The Vector of Trust Components Registry contains the definitions of
vector components and their associated demarcators. vector components and their associated demarcators.
o Demarcator Symbol: P o Demarcator Symbol: P
o Description: Identity proofing o Description: Identity proofing
o Change Controller: IESG o Change Controller: IESG
skipping to change at page 17, line 28 skipping to change at page 18, line 44
o Specification document(s):: [[ this document ]] o Specification document(s):: [[ this document ]]
o Demarcator Symbol: A o Demarcator Symbol: A
o Description: Assertion presentation o Description: Assertion presentation
o Change Controller: IESG o Change Controller: IESG
o Specification document(s):: [[ this document ]] o Specification document(s):: [[ this document ]]
9.1.3. Additions to JWT Claims Registry 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
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 This specification adds the following values to the JSON Web Token
Claims Registry established by [RFC7519]. Claims Registry established by [RFC7519].
o Claim name: vot o Claim name: vot
o Description: Vector of Trust value o Description: Vector of Trust value
o Change Controller: IESG o Change Controller: IESG
o Document: [[ this document ]] o Document: [[ this document ]]
o Demarcator Symbol: vtm o Demarcator Symbol: vtm
o Description: Vector of Trust trustmark o Description: Vector of Trust trustmark
o Change Controller: IESG o Change Controller: IESG
o Document: [[ this document ]] o Document: [[ this document ]]
9.1.4. Additions to the OAuth 11. Security Considerations
This specification adds the following values to the OAuth Parameters
Registry established by [RFC6749].
o Demarcator Symbol: vtr
o Description: Vector of Trust request
o Change Controller: IESG
o Document: [[ this document ]]
10. Security Considerations
The vector of trust value MUST be cryptographically protected in The vector of trust value MUST be cryptographically protected in
transit, using TLS as described in [BCP195]. The vector of trust transit, using TLS as described in [BCP195]. The vector of trust
value must be associated with a trustmark marker, and the two must be value must be associated with a trustmark marker, and the two must be
carried together in a cryptographically bound mechanism such as a carried together in a cryptographically bound mechanism such as a
signed identity assertion. A signed OpenID Connect ID Token and a signed identity assertion. A signed OpenID Connect ID Token and a
signed SAML assertion both fulfil this requirement. signed SAML assertion both fulfil this requirement.
The VoT framework provides a mechanism for describing and conveying The VoT framework provides a mechanism for describing and conveying
trust information. It does not define any policies for asserting the trust information. It does not define any policies for asserting the
values of the vector, nor does it define any policies for applying 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 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 policies must be agreed upon by the IdP and RP, and they should be
expressed in detail in an associated human-readable trust framework expressed in detail in an associated human-readable trust framework
document. document.
11. Privacy Considerations 12. Privacy Considerations
By design, vector of trust values contain information about the By design, vector of trust values contain information about the
user's authentication and associations that can be made thereto. user's authentication and associations that can be made thereto.
Therefore, all aspects of a vector of trust contain potentially Therefore, all aspects of a vector of trust contain potentially
privacy-sensitive information and must be guarded as such. Even in privacy-sensitive information and must be guarded as such. Even in
the absence of specific attributes about a user, knowledge that the the absence of specific attributes about a user, knowledge that the
user has been highly proofed or issued a strong token could provide user has been highly proofed or issued a strong token could provide
more information about the user than was intended. It is recommended more information about the user than was intended. It is recommended
that systems in general use the minimum vectors applicable to their that systems in general use the minimum vectors applicable to their
use case in order to prevent inadvertent information disclosure. use case in order to prevent inadvertent information disclosure.
12. References 13. References
12.1. Normative References
13.1. Normative References
[OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
Core 1.0", November 2014. Core 1.0", November 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
12.2. Informative References 13.2. Informative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/bcp195>. 2015, <http://www.rfc-editor.org/info/bcp195>.
[SP-800-63-2] [SP-800-63-2]
, , , , , , and , "Electronic Authentication Guideline", and , "Electronic Authentication Guideline", August 2013,
August 2013. <https://dx.doi.org/10.6028/NIST.SP.800-63-2>.
[SP-800-63-3]
and , "Electronic Authentication Guideline", June 2017,
<https://doi.org/10.6028/NIST.SP.800-63-3>.
Appendix A. Document History 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 -05
o Updated IANA considerations section to include instructions. o Updated IANA considerations section to include instructions.
o Made security and privacy considerations non-normative. o Made security and privacy considerations non-normative.
-04 -04
o Updated SAML example to be consistent. o Updated SAML example to be consistent.
-03 -03
o Clarified language of LoA's in introduction. o Clarified language of LoA's in introduction.
o Added note on operational security in trustmarks. o Added note on operational security in trustmarks.
o Removed empty sections and references. o Removed empty sections and references.
 End of changes. 47 change blocks. 
135 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/