Network Working Group J. Richer, Ed. Internet-Draft Bespoke Engineering Intended status: Standards Track L. Johansson Expires: September 20, 2018 Swedish University Network March 19, 2018 Vectors of Trust draft-richer-vectors-of-trust-09 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 BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 20, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Richer & Johansson Expires September 20, 2018 [Page 1] Internet-Draft vectors-of-trust March 2018 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 6 2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7 2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 7 2.3. Primary Credential Management (M) . . . . . . . . . . . . 7 2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8 3. Communicating Vector Values to RPs . . . . . . . . . . . . . 8 3.1. On the Wire Representation . . . . . . . . . . . . . . . 9 3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 9 3.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11 4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11 4.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Defining New Vector Values . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Vector Of Trust Components Registry . . . . . . . . . . . 15 9.1.1. Registration Template . . . . . . . . . . . . . . . . 15 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16 9.2. Additions to the OAuth Parameters Registry . . . . . . . 17 9.3. Additions to JWT Claims Registry . . . . . . . . . . . . 17 9.4. Additions to OAuth Token Introspection Response . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Vectors of Trust Default Component Value Definitions 20 A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 20 A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 21 A.3. Primary Credential Management . . . . . . . . . . . . . . 21 A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 22 Appendix B. Document History . . . . . . . . . . . . . . . . . . 22 Richer & Johansson Expires September 20, 2018 [Page 2] Internet-Draft vectors-of-trust March 2018 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 1. Introduction Methods for measuring trust in digital identity transactions have historically fallen into two main categories: either all measurements are combined into a single scalar value, or trust decisions are calculated locally based on a detailed set of attribute metadata. This document defines a method of conveying trust information that is more expressive than a single value but less complex than comprehensive attribute metadata. Prior to the third edition [SP-800-63-3] published in 2017, NIST Special Publication 800-63 [SP-800-63-2] used a single scalar measurement of trust called a Level of Assurance (LoA). An LoA can be used to compare different transactions within a system at a coarse level. For instance, an LoA4 transaction is generally considered more trusted (across all measured categories) than an LoA2 transaction. The LoA for a given transaction is computed by the identity provider (IdP) and is consumed by a relying party (RP). Since the trust measurement is a simple numeric value, it's trivial for RPs to process and compare. However, since each LoA encompasses many different aspects of a transaction, it can't express many real- world situations. For instance, an anonymous user account might have a very strong credential, such as would be common of a whistle-blower or political dissident. Despite the strong credential, the lack of identity proofing would make any transactions conducted by the account to fall into a low LoA. Furthermore, different use cases and domains require subtly different definitions for their LoA categories, and one group's LoA2 is not equivalent or even comparable to another group's LoA2. Attribute based access control (ABAC) systems used by RPs may need to know details about a user's attributes, such as how recently the attribute data was verified and by whom. Attribute metadata systems are capable of expressing extremely fine-grained detail about the transaction. However, this approach requires the IdP to collect, store, and transmit all of this attribute data for the RP's consumption. The RP must process this data, which may be prohibitive for trivial security decisions. Vectors of Trust (VoT) seeks a balance between these two alternatives by allowing expression of multiple aspects of an identity transaction (including but not limited to identity proofing, credential strength, credential management, and assertion strength), without requiring full attribute metadata descriptions. This method of measurement gives more actionable data and expressiveness than an LoA, but is still relatively easy for the RP to process. It is anticipated that Richer & Johansson Expires September 20, 2018 [Page 3] Internet-Draft vectors-of-trust March 2018 VoT can be used alongside more detailed attribute metadata systems as has that proposed by NISITIR 8112 [NISTIR-8112]. The RP can use the vector value for most basic decisions but be able to query the IdP for additional attribute metadata where needed. Furthermore, it is anticipated that some trust frameworks will provide a simple mapping between certain sets of vector values to LoAs, for RPs that do not have a need for the vector's more fine-grained detail. In such systems, an RP is given a choice of how much detail it needs in order to process a given request. This document defines a data model for these vectors and an on-the- wire format for conveying them between parties, anchored in a trust definition. This document also provides guidance for defining values for use in conveying this information, including four component categories and guidance on defining values within those categories. Additionally, this document defines a general-purpose set of component values in an appendix (Appendix A) for use cases that do not need something more specific. 1.1. Terminology Identity 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. Richer & Johansson Expires September 20, 2018 [Page 4] Internet-Draft vectors-of-trust March 2018 Vector A multi-part data structure, used here for conveying information about an authentication transaction. Vector Component One of several constituent parts that make up a vector. Vector Component Value One of the values applied to a vector component within a vector. 1.2. An Identity Model This document assumes the following model for identity based on identity federation technologies: The identity subject (also known as the user) is associated with an identity provider which acts as a trusted third party on behalf of the user with regard to a relying party by making identity assertions about the user to the relying party. The real-world person represented by the identity subject is in possession of a primary credential bound to the identity subject by the identity provider (or an agent thereof) in such a way that the binding between the credential and the real-world user is a representation of the identity proofing process performed by the identity provider (or an agent thereof) to verify the identity of the real-world person. This 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. Richer & Johansson Expires September 20, 2018 [Page 5] Internet-Draft vectors-of-trust March 2018 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. This specification also defines values for each component to be used in the absence of a more specific trust framework in Appendix A. It is expected that trust frameworks will provide context, semantics, and mapping to legal statutes and business rules for each value in each component. Consequently, a particular vector value can only be compared with vectors defined in the same context. The RP MUST understand and take into account the trust framework context in which a vector is being expressed in order for to process a vector securely. Each component is identified by a demarcator consisting of a single uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD reflect the category with which it is associated in a natural manner. Demarcators for components MUST be registered as described in Section 9. It is anticipated that trust framework definitions will use this registry to define specialized components, though it is RECOMMENDED that trust frameworks re-use existing components wherever possible. The value for a given component within a vector of trust is defined by its demarcator character followed by a single digit or lowercase ASCII letter in the range "[0-9a-z]". Categories which have a natural ordering SHOULD use digits, with "0" as the lowest value. Categories which do not have a natural ordering, or which can have an ambiguous ordering, SHOULD use letters. Categories MAY use both letter style and number style value indicators simultaneously. For example, a category could define "0" as a special "empty" value while using letters such as "a", "b", "c" for normal values can to differentiate between these types of options. Another system could have a base category with a numeric value with additonal details provided by letter values. Regardless of the type of value indicator used, the values assigned to each component of a vector MUST NOT be assumed always to have inherent ordinal properties when compared to the same or other components in the vector space. In other words, "1" is different from "2", but it is dangerous to assume that "2" is always better than "1" in a given transaction. Richer & Johansson Expires September 20, 2018 [Page 6] Internet-Draft vectors-of-trust March 2018 Each component MAY be repeated with multiple different values within a single vector. The same component and value combination MUST NOT be repeated within a single vector. 2.1. Identity Proofing (P) The Identity Proofing dimension defines, overall, how strongly the set of identity attributes have been verified and vetted. In other words, this dimension describes how likely it is that a given digital identity transaction corresponds to a particular (real-world) identity subject. 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 (C) The primary credential usage dimension defines how strongly the primary credential can be verified by the IdP. In other words, how easily that credential could be spoofed or stolen. 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 (M) The primary credential management dimension conveys information about the expected lifecycle of the primary credential in use, including its binding, rotation, and revocation. In other words, the use and strength of policies, practices, and security controls used in managing the credential at the IdP and its binding to the intended individual. 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 Richer & Johansson Expires September 20, 2018 [Page 7] Internet-Draft vectors-of-trust March 2018 values in some circumstances. In such cases it is RECOMMENDED that a letter style value be used for this component and that multiple distinct values be allowed to be communicated simultaneously. 2.4. Assertion Presentation (A) The Assertion Presentation dimension defines how well the given digital identity can be communicated across the network without information leaking to unintended parties, and without spoofing. In other words, this dimension describes how likely it is that a given digital identity was actually asserted by a given identity provider for a given transaction. While this information is largely already known by the RP as a side effect of processing an identity assertion, this dimension is still very useful when the RP requests a login (Section 4) and when describing the capabilities of an IdP (Section 6). 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. 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. Richer & Johansson Expires September 20, 2018 [Page 8] Internet-Draft vectors-of-trust March 2018 o The vector needs to be interpreted in the context of a specific trust framework definition. These requirements lead us to defining a simple string-based representation of the vector that can be incorporated within a number of different locations and protocols without further encoding. 3.1. On the Wire Representation The vector MUST be represented as a period-separated ('.') list of vector components, 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. 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 (Appendix A). 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. 3.2. In OpenID Connect In OpenID Connect [OpenID], the IdP MUST send the vector as a string within the "vot" (vector of trust) claim in the ID token. The trustmark (Section 5) that applies to this vector MUST be sent as an Richer & Johansson Expires September 20, 2018 [Page 9] Internet-Draft vectors-of-trust March 2018 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" and "vtm" values inside the ID token, the vector and its context are strongly bound to the federated credential represented by the ID token. 3.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: This represents a set of vector components. Richer & Johansson Expires September 20, 2018 [Page 10] Internet-Draft vectors-of-trust March 2018 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": P1.Cc.Ac 4. 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 3.1, an RP can indicate that it desires particular aspects be present in the authentication. Processing and fulfillment of these requests are in the purview of the IdP and details are outside the scope of this specification. 4.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 full set of "Ce AND Ab" simultaneously are acceptable to this RP for this transaction. Vector request values MAY omit components, indicating that any value is acceptable for that component category, including omission of that component in the response vector. The mechanism by which the IdP processes the "vtr" and maps that to the authentication transaction are out of scope of this specification. 4.2. In SAML In SAML (Section 3.3) the client can request a set of acceptable VoT values by including the corresponding "AuthenticationContextDeclRef" URIs together with an "AuthenticationContextClassRef" corresponding Richer & Johansson Expires September 20, 2018 [Page 11] Internet-Draft vectors-of-trust March 2018 to the trust mark (cf below). The processing rules in Section 3.3 apply. 5. 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. The trustmark MUST be available from an HTTPS URL served by the trust framework provider. The contents of this URL are a JSON [RFC8259] 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: Richer & Johansson Expires September 20, 2018 [Page 12] Internet-Draft vectors-of-trust March 2018 { "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. 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"] } 6. 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 [RFC8259] 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. Richer & Johansson Expires September 20, 2018 [Page 13] Internet-Draft vectors-of-trust March 2018 { "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" } } 7. Defining New Vector Values Vectors of Trust is meant to be a flexible and reusable framework for communicating authentication data between networked parties in an identity federation protocol. However, the exact nature of the information needed is reliant on the parties requiring the information and the relationship between them. While this document does define a usable default set of values in Appendix A, it is anticipated that many situations will require an extension of this specification for their own use. 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 9. The registry encourages re-use and discovery of existing categories across different implementations. In other words, the "P" category in another framework SHOULD be used for identity proofing and related information. The values of components such as those defined in Appendix A are intended to be contextual to the defining trust document. While this specification's component values are intended to be general-purpose and extensions MAY re-use the values and their definitions, 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 Section 2, though combinations of both types MAY be used. 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 Richer & Johansson Expires September 20, 2018 [Page 14] Internet-Draft vectors-of-trust March 2018 specific definition of a set of values in an extension MAY limit a given component category to a single value per transaction. 8. 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. 9. IANA Considerations This specification creates one registry and registers several values into existing registries. 9.1. Vector Of Trust Components Registry This specification establishes the Vectors of Trust Components Registry. Component demarcators are registered by Specification Required [RFC8126] 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. 9.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"). Richer & Johansson Expires September 20, 2018 [Page 15] Internet-Draft vectors-of-trust March 2018 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 to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required. 9.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 ]] Richer & Johansson Expires September 20, 2018 [Page 16] Internet-Draft vectors-of-trust March 2018 9.2. Additions to the OAuth Parameters Registry This specification adds the following values to the OAuth Parameters Registry established by [RFC6749]. o Name: vtr o Description: Vector of Trust request o Parmater usage location: authorization request, token request o Change Controller: IESG o Document: [[ this document ]] 9.3. Additions to JWT Claims Registry This specification adds the following values to the JSON Web Token Claims Registry established by [RFC7519]. o Claim name: vot o Description: Vector of Trust value o Change Controller: IESG o Document: [[ this document ]] o Claim name: vtm o Description: Vector of Trust trustmark o Change Controller: IESG o Document: [[ this document ]] 9.4. Additions to OAuth Token Introspection Response This specification adds the following values to the OAuth Token Introspection Response established by [RFC7662]. o Name: vot o Description: Vector of Trust value o Change Controller: IESG o Document: [[ this document ]] Richer & Johansson Expires September 20, 2018 [Page 17] Internet-Draft vectors-of-trust March 2018 o Name: vtm o Description: Vector of Trust trustmark o Change Controller: IESG o Document: [[ this document ]] 10. 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 vector value is always associated with a trustmark and needs to be interpreted by the RP in the context of that trustmark. Different trust frameworks can apply different interpretations to the same component value, much as was the case with LoA. Therefore, an RP interpreting a component value in the the wrong context could mistakenly accept or reject a request. In order to avoid this mistake, RPs need to reject vectors that are defined in trust frameworks that they do not understand how to interpret properly. The VoT framework provides a mechanism for describing and conveying trust information. It does not define any policies for 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. 11. Privacy Considerations By design, vector of trust values contain information about the user's authentication and associations that can be made thereto. Therefore, all aspects of a vector of trust contain potentially privacy-sensitive information and must be guarded as such. Even in the absence of specific attributes about a user, knowledge that the user has been highly proofed or issued a strong token could provide more information about the user than was intended. It is recommended that systems in general use the minimum vectors applicable to their use case in order to prevent inadvertent information disclosure. Richer & Johansson Expires September 20, 2018 [Page 18] Internet-Draft vectors-of-trust March 2018 12. References 12.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, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 12.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, . Richer & Johansson Expires September 20, 2018 [Page 19] Internet-Draft vectors-of-trust March 2018 [NISTIR-8112] National Institute of Standards and Technology, U.S. Department of Commerce, "A Proposed Schema for Evaluating Federated Attributes", NIST NISTIR 8112, January 2018, . [SP-800-63-2] National Institute of Standards and Technology, U.S. Department of Commerce, "Electronic Authentication Guideline", NIST SP 800-63-2, DOI 10.6028/NIST.SP.800-63-2, August 2013, . [SP-800-63-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Identity Guideline", NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017, . Appendix A. Vectors of Trust Default Component Value Definitions The following general-purpose component definitions MAY be used when a more specific set is unavailable. 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 7. Where possible, extensions MAY re- use specific values here. A.1. Identity Proofing The identity proofing component of this vector definition represents increasing scrutiny during the proofing process. Higher levels are largely subsumptive of lower levels, such that "P2" fulfills requirements for "P1", etc. 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) Richer & Johansson Expires September 20, 2018 [Page 20] Internet-Draft vectors-of-trust March 2018 P3 There is a binding relationship between the identity provider and the identified party (such as signed/notarized documents, employment records) A.2. Primary Credential Usage The primary credential usage component of this vector definition represents distinct categories of primary credential that MAY be used together in a single transaction. Multiple distinct values from this category MAY be used in a single transaction. C0 No credential is used / anonymous public service Ca Simple session HTTP cookies (with nothing else) Cb Known device Cc Shared secret such as a username and password combination Cd Cryptographic proof of key possession using shared key Ce Cryptographic proof of key possession using asymmetric key Cf Sealed hardware token / trusted biometric / TPM-backed keys A.3. Primary Credential Management The primary credential management component of this vector definition represents distinct categories of management that MAY be considered separately or together in a single transaction. Many trust framework deployments MAY use a single value for this component as a baseline for all transactions and thereby omit it. Multiple distinct values from this category MAY be used in a single transaction. Ma Self-asserted primary credentials (user chooses their own credentials and must rotate or revoke them manually) / no additional verification for primary credential issuance or rotation Mb Remote issuance and rotation / use of backup recover credentials (such as email verification) / deletion on user request Mc Full proofing required for each issuance and rotation / revocation on suspicious activity Richer & Johansson Expires September 20, 2018 [Page 21] Internet-Draft vectors-of-trust March 2018 A.4. Assertion Presentation The assertion presentation component of this vector definition represents distinct categories of assertion which are RECOMMENDED to be used in a subsumptive manner but MAY be used together. Multiple distinct values from this category MAY be used in a single transaction. Aa No protection / unsigned bearer identifier (such as an HTTP session cookie in a web browser) Ab Signed and verifiable assertion, passed through the user agent (web browser) Ac Signed and verifiable assertion, passed through a back channel Ad Assertion encrypted to the relying parties key and audience protected Appendix B. Document History -09 o Added introspection response IANA registration. o Cleaned up IANA entries. -08 o Incorporated shepherd comments. o Updated references. o Added reference to NISTIR 8112. o Moved default component definitions to appendix. -07 o Rewrote introduction to clarify focus of document. -06 o Added section on extensions to VoT. o Made it so that every component category could be multi-valued. o Added reference to updated 800-63-3. Richer & Johansson Expires September 20, 2018 [Page 22] Internet-Draft vectors-of-trust March 2018 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. 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". Richer & Johansson Expires September 20, 2018 [Page 23] Internet-Draft vectors-of-trust March 2018 - 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 September 20, 2018 [Page 24]