Network Working Group J. Richer, Ed. Internet-Draft Bespoke Engineering Intended status: Standards Track L. Johansson Expires: March 7, 2016 Swedish University Network September 4, 2015 Vectors of Trust draft-richer-vectors-of-trust-01 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 7, 2016. Copyright Notice Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Richer & Johansson Expires March 7, 2016 [Page 1] Internet-Draft vectors-of-trust September 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 4 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 2. Core Components . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6 2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 6 2.3. Primary Credential Management . . . . . . . . . . . . . . 6 2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 6 3. Vectors of Trust Inititial Component Definitions . . . . . . 7 4. Communicating Vector Values to RPs . . . . . . . . . . . . . 8 4.1. On the Wire Representation . . . . . . . . . . . . . . . 8 4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 9 4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 10 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 10 6. Discovery and Verification . . . . . . . . . . . . . . . . . 10 6.1. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8.1. Vector Of Trust Components Registry . . . . . . . . . . . 12 8.2. Additions to JWT Claims Registry . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Document History . . . . . . . . . . . . . . . . . . 14 Appendix B. Example Extension . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction This document defines a mechanism for describing and signaling several aspects of digital identity transactions that are used to determine a level of trust in that transaction. In the past, there have been two extremes of communicating authentication transaction information. On one end, all attributes are communicated with full provenance and associated trust markings. This approach seeks to Richer & Johansson Expires March 7, 2016 [Page 2] Internet-Draft vectors-of-trust September 2015 create a fully distributed attribute system that can be used for things like attribute based access control (ABAC). These attributes can be used to describe the end user, the identity provider, the relying party, or even the transaction itself. While the information that can be expressed in this model is incredible, the complexity of such a system is often prohibitive to align across security domains, especially to relying parties needing to process the sea of disparate attributes. At the other extreme there are systems that collapse all of the attributes and aspects into a single scalar value that communicates, in sum, how much a transaction can be trusted. The NIST special publication 800-63 [SP-800-63] defines a linear scale Level of Assurance (LoA) measure that combines multiple attributes about an identity transaction into a single measure of the level of trust a relying party should place on an identity transaction. Even though this definition was originally made for a specific government use cases, the LoA scale appeared to be applicable with a wide variety of authentication use cases. This has led to a proliferation of incompatible interpretations of the same scale in different trust frameworks, preventing interoperability between these frameworks in spite of their common measurement. Since identity proofing strength increases linearly along with credential strength in the LoA scale, this scale is too limited for describing many valid and useful forms of an identity transaction. For example, an anonymously assigned hardware token can be used in cases where the real world identity of the subject cannot be known, for privacy reasons, but the credential itself can be highly trusted. This work seeks to find a balance between these two extremes by creating a data model that combines attributes of the user and aspects of the authenticaiton context into several values that can be communicated together. This approach is both coarser grained than the distributed attributes model and finer grained than the single value model, with the hope that it is a viable balance of expressivity and processability. Importantly, these three levels of granularity can be mapped to each other. The information of several attributes can be folded into a vector component, while the vector itself can be folded into an assurance category. As such, the vectors of trust seeks to complement, not replace, these other identity and trust mechanisms. 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. Richer & Johansson Expires March 7, 2016 [Page 3] Internet-Draft vectors-of-trust September 2015 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 credential used by the identity subject to authenticate to the identity provider. Federated Credential The assertion presented by the IdP to the RP across the network to authenticate the user. Relying Party (RP) A system that consumes identity information from an IdP for the purposes of authenticating the user. Trust Framework A document containing business rules and legal clauses that defines how different parties in an identity transaction may act. Trustmark A verifiable attestation that a party has proved to follow the constraints of a trust framework. Trustmark Provider A system that issues and provides verification for trustmarks. Vector A multi-part data structure, used here for conveying information about an authentication transaction. Vector Component One of several constituent parts that make up a vector. 1.2. An Identity Model This document assumes the following (incomplete) model for identity. The identity subject (aka user) is associated with an identity provider which acts as a trusted 3rd 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 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 the identity provider (or an agent thereof) to verify the identity of the real-world person. Richer & Johansson Expires March 7, 2016 [Page 4] Internet-Draft vectors-of-trust September 2015 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 scalar values. A vector is a set of coordinates that specifies a point in a (multi-dimensional) Cartesian coordinate space. The reader is encouraged to think of a vector of trust as a point in a coordinate system, in the simples form (described below) a 3 dimensional space that is intended to be a recognizable, if somewhat elided, model of identity subject trust. 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 in the sense that no aspect of a component overlap an aspect of another component. The values assigned to each component of a vector is sometimes written as an ordinal number (e.g. an integer) but MUST NOT be assumed as having 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 "more" (better) than 1. 2. Core Components This specification defines four orthogonal components: identity proofing, primary credential usge, primary credential management, and assertion presentation. These dimensions MUST be evaluated 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. It is expected that trust frameworks will provide context, semantics, and mapping to legal statutes and business rules for each value in each component. Consequently, a particular vector value can only be compared with vectors defined in the same context. The RP MUST understand and take into account the trust framework context in which a vector is being expressed in order for it to be processed securely. It is anticipated that trust frameworks will also define additional components using the component registry established in Section 8. Richer & Johansson Expires March 7, 2016 [Page 5] Internet-Draft vectors-of-trust September 2015 Each component is identified by a demarcator consisting of a single case-sensitive ASCII character in the range [A-Za-z]. A value for a given component is defined by its demarcator character followed by a single case-sensitive ASCII character in the range [0-9A-Za-z]. 2.1. Identity Proofing The Identity Proofing dimension defines, overall, how strongly the set of identity attributes have been verified and vetted, and how strongly they are tied to a particular credential set. In other words, this dimension describes how likely it is that a given digital identity 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 "P1", "P2", etc. 2.2. Primary Credential Usage The primary credential usage dimension defines how strongly the primary credential can be verified by the IdP. In other words, and 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 "C1", "C2", etc. Multiple credential usage factors MAY be communicated simultaneously, such as when Multi-Factor Authentication is used. 2.3. Primary Credential Management The primary credential management dimension conveys information about the expected lifecycle of the primary credential in use, including its binding, rotation, and revocation. This component defines how strongly the primary credential can be trusted to be presented by the party represented by the credential based on knowledge of the management of the credentials at the IdP. In other words, this dimension describes how likely it is that the right person is presenting the credential to the identity provider. This dimension SHALL be represented by the "M" demarcator and a single-character level value, such as "M1", "M2", etc. 2.4. Assertion Presentation The Assertion Presentation dimension defines how well the given digital identity can be communicated across the network without information leaking to unintended parties, and without spoofing. In other words, this dimension describes how likely it is that a given digital identity asserted was actually asserted by a given identity Richer & Johansson Expires March 7, 2016 [Page 6] Internet-Draft vectors-of-trust September 2015 provider for a given transaction. While this information is largely already known by the RP by the nature of processing an identity assertion, this dimension is still useful when the RP requests a login (Section 5) and when describing the capabilities of an IdP (Section 6.2). This dimension SHALL be represented by the "A" demarcator and a level value, such as "A1", "A2", etc. 3. Vectors of Trust Inititial Component Definitions This specification defines the following general-purpose component definitions, which MAY be used when a more specific set is unavailable. These component values are referenced in a trustmark definition defined by [[ this document URL ]]. P0 No proofing is done, data is not guaranteed to be persistent across sessions P1 Attributes are self-asserted but consistent over time, potentially pseudonymous P2 Identity has been proofed either in person or remotely using trusted mechanisms (such as social proofing) P3 There is a binding relationship between the identity provider and the identified party (such as signed/notarized documents, employment records) C0 No credential is used / anonymous public service / simple session cookies (with nothing else) C1 Known device C2 Shared secret such as a username and password combination C3 Cryptographic proof of key possession using shared key C4 Cryptographic proof of key possession using asymmetric key C5 Sealed hardware token / trusted biometric / TPM-backed keys M0 Self-asserted credentials M1 Remote issuance and rotation / use of backup recover credentials (such as email verification) / deletion on user request Richer & Johansson Expires March 7, 2016 [Page 7] Internet-Draft vectors-of-trust September 2015 M2 Full proofing required for each issuance and rotation / revocation on suspicious activity A0 No protection / unsigned bearer identifier (such as a session cookie) A1 Signed and verifiable token, passed through the browser A2 Signed and verifiable token, passed through a back channel A3 Token encrypted to the relying parties key and audience protected 4. Communicating Vector Values to RPs All four of these dimensions (and others, as they are defined in extension work) MUST be combined into a single vector that can be communicated across the wire unbroken. All vector components MUST be individually available, MUST NOT be "collapsed" into a single value without also presenting the constituent dimensions as well. When communicating the vectors across the wire, they MUST be protected in transit and MUST signed by the asserting authority (such as the IdP). 4.1. On the Wire Representation The vector MUST be represented as a period-separated ('.') list of vector components, with no specific order. A vector component type MAY occur multiple times within a single vector, with each component separated by periods. Multiple values for a component are considered an AND of the values. A single value of a vector component MUST NOT occur more than once in a single vector. In order 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. 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 IdP is making no claim for that category. For example, the vector value "P1.C3.A2" translates to pseudonymous, proof of shared key, signed back-channel verified token in the context of this specification's definitions (Section 3). Vector values MUST be communicated along side of a trustmark definition to give the components context. A vector value without context is unprocessable. Richer & Johansson Expires March 7, 2016 [Page 8] Internet-Draft vectors-of-trust September 2015 4.2. In OpenID Connect In OpenID Connect [OpenID], the IdP MUST send the vector value as a string with the "vot" (vector of trust) claim in the ID token. The trustmark (Section 6.1) that applies to this vector MUST be sent as an HTTPS URL in the "vtm" (vector trust mark) claim to provide context to the vector. For example: { "iss": "https://idp.example.com/", "sub": "jondoe1234", "vot": "P1.C3.A2", "vtm": "https://trustmark.example.org/trustmark/idp.example.com" } 4.3. In SAML In SAML a VoT vector is communicated as an AuthenticationContextClassRef, a sample definition of which might look something like this: VoT vector P1.C3.A2 Richer & Johansson Expires March 7, 2016 [Page 9] Internet-Draft vectors-of-trust September 2015 5. Requesting Vector Values In some identity protocols, the RP can request that particular attributes be applied to a given identity transaction. 5.1. In OpenID Connect In OpenID Connect [OpenID], the client can 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 components within each vector are ANDed together while the individual vector strings are ORed together. Vector request values MAY omit components, indicating that any value is acceptable. { "vtr": ["P1.C2.C3.A2", "C5.A2"] } 6. Discovery and Verification 6.1. 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. The trustmark MUST be available from an HTTPS URL served by the trust framework provider. The contents of this URL are a JSON [RFC7159] document with the following fields: idp The issuer URL of the identity provider that this trustmark pertains to. This MUST match the corresponding issuer claim in the identity token, such as the OpenID Connect "iss" field. This MUST be an HTTPS URL. trustmark_provider The issuer URL of the trustmark provider that issues this trustmark. The URL that a trustmark is fetched from MUST start with the "iss" URL in this field. This MUST be an HTTPS URL. P Array of strings containing identity proofing values for which the identity provider has been assessed and approved Richer & Johansson Expires March 7, 2016 [Page 10] Internet-Draft vectors-of-trust September 2015 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 identitity provider has been assessed and approved A Array of strings containing assertion strength values for which the identity provider has been assessed and approved Additional vector component values MUST be listed in a similar fashion using their demarcator. For example, the following trustmark provided by the trustmark.example.org organization applies to the idp.example.org identity provider: { "idp": "https://idp.example.org/", "trustmark_provider": "https://trustmark.example.org/", "P": ["P0", "P1"], "C": ["C1", "C2", "C3"], "M": ["M2"], "A": ["C2", "C3"] } A client 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 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": ["C0", "C1"], "C": ["C1", "C2", "C3"], "M": ["M2"], "A": ["C2", "C3"] } Richer & Johansson Expires March 7, 2016 [Page 11] Internet-Draft vectors-of-trust September 2015 6.2. 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. Trustmarks are listed in the trustmarks element which contains a single JSON [RFC7159] object. The keys of this JSON object are trustmark provider issuer URLs and the values of this object are the corresponding trustmarks for this IdP. { "trustmark": { "https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/ } } 7. Acknowledgements The authors would like to thank the members of the Vectors of Trust mailing list in the IETF for discussion and feedback on the concept and document. 8. IANA Considerations This specification creates one registry and registers several values into an existing registry. 8.1. Vector Of Trust Components Registry 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 Document: [[ this document ]] o Demarcator Symbol: C o Description: Primary credential usage o Document: [[ this document ]] o Demarcator Symbol: M o Description: Primary credential management o Document: [[ this document ]] Richer & Johansson Expires March 7, 2016 [Page 12] Internet-Draft vectors-of-trust September 2015 o Demarcator Symbol: A o Description: Assertion presentation o Document: [[ this document ]] 8.2. Additions to JWT Claims Registry This specification adds the following values to the JWT Claims Registry. o Claim name: vot o Description: Vector of Trust value o Document: [[ this document ]] o Demarcator Symbol: vtm o Description: Vector of Trust Trustmark o Document: [[ this document ]] o Demarcator Symbol: vtr o Description: Vector of Trust Request o Document: [[ this document ]] 9. Security Considerations The vector of trust value MUST be cryptographically protected in transit, using TLS. 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. 10. Privacy Considerations By design, vector of trust values contain information about a user's identity and assications that can be made thereto. Therefore, all aspects of a vector of trust contain potentially privacy-sensitive information and MUST be guarded as such. Richer & Johansson Expires March 7, 2016 [Page 13] Internet-Draft vectors-of-trust September 2015 11. References 11.1. Normative References [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Core 1.0", November 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . 11.2. Informative References [SP-800-63] , , , , , , and , "Electronic Authentication Guideline", August 2013. Appendix A. Document History - 01 o Added IANA registry for components. o Added preliminary security considerations and privacy considerations. o Split "credential binding" into "primary credential usage" and "primary credential management". - 00 o Created initial IETF drafted based on strawman proposal discussed on VoT list. o Split vector component definitions into their own section to allow extension and override. o Solidified trustmark document definition. Richer & Johansson Expires March 7, 2016 [Page 14] Internet-Draft vectors-of-trust September 2015 Appendix B. Example Extension To extend the vector component definitions, a specification MUST register its contents in the Authors' Addresses Justin Richer (editor) Bespoke Engineering Email: ietf@justin.richer.org Leif Johansson Swedish University Network Thulegatan 11 Stockholm Sweden Email: leifj@sunet.se URI: http://www.sunet.se Richer & Johansson Expires March 7, 2016 [Page 15]