idnits 2.17.1 draft-richer-vectors-of-trust-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 28 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2015) is 3226 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Richer, Ed. 3 Internet-Draft Bespoke Engineering 4 Intended status: Standards Track L. Johansson 5 Expires: December 28, 2015 Swedish University Network 6 June 26, 2015 8 Vectors of Trust 9 draft-richer-vectors-of-trust-00 11 Abstract 13 This document defines a mechanism for describing and signaling 14 several aspects that go into a determination of trust placed in a 15 digital identity transaction. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 28, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Background and Motivation . . . . . . . . . . . . . . . . . . 3 60 2.1. An Identity Model . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Component Architecture . . . . . . . . . . . . . . . . . 4 62 3. Core components . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Credential Management . . . . . . . . . . . . . . . . . . 5 65 3.3. Assertion Presentation . . . . . . . . . . . . . . . . . 5 66 4. Vectors of Trust Inititial component definitions . . . . . . 6 67 5. Communicating Vector Values to RPs . . . . . . . . . . . . . 7 68 5.1. On the Wire Representation . . . . . . . . . . . . . . . 7 69 5.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 7 70 5.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Requesting Vector Values . . . . . . . . . . . . . . . . . . 8 72 6.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 9 73 7. Discovery and Verification . . . . . . . . . . . . . . . . . 9 74 7.1. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Appendix A. Document History . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 This document defines a mechanism for describing and signaling 86 several aspects that go into a determination of trust placed in a 87 digital identity transaction. Instead of communicating 89 1.1. Terminology 91 Identity Provider (IdP) A system that manages identity information 92 and is able to assert this information across the network through 93 an identity API. 95 Relying Party (RP) A system that consumes identity information from 96 an IdP for the purposes of logging users in. 98 Trust Framework A document containing business rules and legal 99 clauses that defines how different parties in an identity 100 transaction may act. 102 Trustmark A verifiable attestation that a party has proved to follow 103 the constraints of a trust framework. 105 Trustmark Provider A system that issues and provides verification 106 for trustmarks. 108 Vector A multi-part data structure, used here for conveying 109 information about an authentication transaction. 111 Vector Component One of several constituent parts that make up a 112 vector. 114 2. Background and Motivation 116 The NIST special publication 800-63 [SP-800-63] defines a linear 117 scale Level of Assurance (LoA) measure that combines multiple 118 attributes about an identity transaction into a single measure of the 119 level of trust a relying party should place on an identity 120 transaction. Even though this definition was originally made for a 121 specific government use cases, the LoA scale appeared to be 122 applicable with a wide variety of authentication use cases. This has 123 led to a proliferation of incompatible interpretations of the same 124 scale in different trust frameworks, preventing interoperability 125 between these frameworks in spite of their common measurement. 127 Since identity proofing strength increases linearly along with 128 credential strength, the LoA scale is also too limited for describing 129 many valid and useful forms of an identity transaction. For example, 130 an anonymously assigned hardware token can be used in cases where the 131 real world identity of the subject cannot be known or is verified 132 through some out of band mechanism. 134 This work seeks to decompose the elements of the LoA values in a way 135 that they can be independently communicated from an Identity Provider 136 to a Relying Party, making comparison between trust frameworks 137 possible. 139 2.1. An Identity Model 141 This document assumes the following (incomplete) model for identity. 143 The identity subject (aka user) is associated with an identity 144 provider which acts as a trusted 3rd party on behalf of the user with 145 regard to a relying party by making identity assertions about the 146 user to the relying party. 148 The real-world person represented by the identity subject is in 149 possession of a (cryptographic) primary credential bound to the user 150 by (an agent of) identity provider in such a way that the binding 151 between the credential and the real-world user is a representation of 152 the identity proofing process performed by the (agent of) the 153 identity provider to verify the identity of the real-world person. 155 2.2. Component Architecture 157 The term Vectors of Trust is based on the mathematical construct of a 158 Vector, which is defined as an item composed of multiple independent 159 scalar values. A vector is a set of coordinates that specifies a 160 point in a (multi-dimensional) Cartesian coordinate space. The 161 reader is encouraged to think of a vector of trust as a point in a 162 coordinate system, in the simples form (described below) a 3 163 dimensional space that is intended to be a recognizable, if somewhat 164 elided, model of identity subject trust. 166 An important goal for this work is to balance the need for simplicity 167 (particularly on the part of the relying party) with the need for 168 expressiveness. As such, this vector construct is designed to be 169 composable and extensible. 171 All components of the vector construct MUST be orthogonal in the 172 sense that no aspect of a component overlap an aspect of another 173 component. 175 The values assigned to each component of a vector is sometimes 176 written as an ordinal number (e.g. an integer) but MUST NOT be 177 assumed as having inherent ordinal properties when compared to the 178 same or other components in the vector space. In other words, 1 is 179 different from 2, but it is dangerous to assume that 2 is always 180 "more" (better) than 1. 182 3. Core components 184 This specification defines three orthogonal components: identity 185 proofing, credential binding, and assertion presentation. These 186 dimensions (as described below) are intentionally elided and SHOULD 187 be combined with other information to form trust frameworks can be 188 used as a basis for audits of identity providers and relying parties. 190 This specification also defines values for each component to be used 191 in the absence of a more specific trust framework. It is expected 192 that trust frameworks will provide context, semantics, and mapping to 193 legal statutes and business rules for each value in each component. 194 Consequently, a particular vector value can only be compared with 195 vectors defined in the same context. The RP MUST understand and take 196 into account the trust framework context in which a vector is being 197 expressed in order for it to be processed securely. 199 It is anticipated that trust frameworks will also define additional 200 components. 202 3.1. Identity Proofing 204 The Identity Proofing dimension defines, overall, how strongly the 205 set of identity attributes have been verified and vetted, and how 206 strongly they are tied to a particular credential set. In other 207 words, this dimension describes how likely it is that a given digital 208 identity corresponds to a particular (real-world) identity subject. 210 This dimension SHALL be represented by the "P" demarcator and a level 211 value, such as "P1", "P2", etc. 213 3.2. Credential Management 215 Below we use the term "credential" to denote the credential used by 216 the identity subject to authenticate to the identity provider. 218 The Credential Binding dimension defines how strongly the credential 219 can be verified by the IdP and trusted to be presented by the party 220 represented by a given credential. In other words, this dimension 221 describes how likely it is that the right person is presenting the 222 credential to the identity provider, and how easily that credential 223 could be spoofed or stolen. This component is intended to be a 224 general category 226 This dimension SHALL be represented by the "C" demarcator and a level 227 value, such as "C1", "C2", etc. Multiple credential factors MAY be 228 communicated simultaneously, such as when Multi-Factor Authentication 229 is used. 231 3.3. Assertion Presentation 233 The Assertion Presentation dimension defines how well the given 234 digital identity can be communicated across the network without 235 information leaking to unintended parties, and without spoofing. In 236 other words, this dimension describes how likely it is that a given 237 digital identity asserted was actually asserted by a given identity 238 provider for a given transaction. 240 This dimension SHALL be represented by the "A" demarcator and a level 241 value, such as "A1", "A2", etc. 243 4. Vectors of Trust Inititial component definitions 245 This specification defines the following general-purpose component 246 definitions, which MAY be used when a more specific set is 247 unavailable. These component values are referenced in a trustmark 248 definition 250 P0 No proofing is done, data is not guaranteed to be persistent 251 across sessions 253 P1 Attributes are self-asserted but consistent over time, potentially 254 pseudonymous 256 P2 Identity has been proofed either in person or remotely using 257 trusted mechanisms (such as social proofing) 259 P3 There is a legal or contractual relationship between the identity 260 provider and the identified party (such as signed/notarized 261 documents, employment records) 263 C0 No credential is used / anonymous public service / simple session 264 cookies (with nothing else) 266 C1 Shared secret such as a username and password combination 268 C2 Known device with trusted enrollment process 270 C3 Cryptographic proof of key possession using shared key 272 C4 Cryptographic proof of key possession using asymmetric key 274 C5 Sealed hardware token / trusted biometric / TPM-backed keys 276 A0 No protection / unsigned bearer identifier (such as a session 277 cookie) 279 A1 Signed and verifiable token, passed through the browser 281 A2 Signed and verifiable token, passed through a back channel 283 A3 Token encrypted to the relying parties key and audience protected 285 5. Communicating Vector Values to RPs 287 All three of these dimensions (and others, as they are defined in 288 extension work) MUST be combined into a single vector that can be 289 communicated across the wire unbroken. 291 All vector components MUST be individually available, MUST NOT be 292 "collapsed" into a single value without also presenting the 293 constituent dimensions as well. 295 When communicating the vectors across the wire, they MUST be 296 protected in transit and signed by the asserting authority (such as 297 the IdP). 299 5.1. On the Wire Representation 301 The vector MUST be represented as a period-separated ('.') list of 302 vector components, with no specific order. A vector component type 303 MAY occur multiple times within a single vector, separated by 304 periods, in which case it is considered an AND of the two values. In 305 order to simplify processing by RPs, it is RECOMMENDED that trust 306 framework definitions carefully define component values such that 307 they are mutually exclusive or subsumptive in order to avoid this 308 situation where possible. 310 Vector components MAY be omitted from a vector. No holding space is 311 left for an omitted vector component. If a vector component is 312 omitted, the IdP is making no claim for that category. 314 For example, the vector value "P1.C3.A2" translates to pseudonymous, 315 proof of shared key, signed back-channel verified token in the 316 context of this specification's definitions (Section 4). 318 Vector values MUST be communicated along side of a trustmark 319 definition to give the components context. 321 5.2. In OpenID Connect 323 In OpenID Connect [OpenID], the IdP MUST send the vector value as a 324 string with the "vot" (vector of trust) claim in the ID token. The 325 trustmark (Section 7.1) that applies to this vector MUST be sent as 326 an HTTPS URL in the "vtm" (vector trust mark) claim to provide 327 context to the vector. 329 For example: 331 { 332 "iss": "https://idp.example.com/", 333 "sub": "jondoe1234", 334 "vot": "P1.C3.A2", 335 "vtm": "https://trustmark.example.org/trustmark/idp.example.com" 336 } 338 5.3. In SAML 340 In SAML a VoT vector is communicated as an 341 AuthenticationContextClassRef, a sample definition of which might 342 look something like this: 344 345 352 354 355 VoT vector P1.C3.A2 356 357 358 359 360 364 365 366 367 368 370 6. Requesting Vector Values 372 In some identity protocols, the RP can request that particular 373 attributes be applied to a given identity transaction. 375 6.1. In OpenID Connect 377 In OpenID Connect [OpenID], the client can request a set of 378 acceptable VoT values with the "vtr" (vector of trust request) claim 379 request as part of the Request Object. The value of this field is an 380 array of JSON strings, each string identifying an acceptable set of 381 vector components. The components are ANDed together while the 382 individual vector strings are ORed together. Vector request values 383 MAY omit components, indicating that any value is acceptable. 385 { 386 "vtr": ["P1.C2.C3.A2", "C5.A2"] 387 } 389 7. Discovery and Verification 391 7.1. Trustmark 393 When an RP receives a specific vector from an IdP, it needs to make a 394 decision to trust the vector within a specific context. A trust 395 framework can provide such a context, allowing legal and business 396 rules to give weight to an IdP's claims. A trustmark is a verifiable 397 claim to conform to a specific component of a trust framework, such 398 as a verified identity provider. The trustmark conveys the root of 399 trustworthiness about the claims and assertions made by the IdP. 401 The trustmark MUST be available from an HTTPS URL by the trust 402 framework provider. The contents of this URL are a JSON [RFC7159] 403 document with the following fields: 405 sub The issuer URL of the identity provider that this trustmark 406 pertains to. This MUST match the corresponding issuer claim in 407 the identity token, such as the OpenID Connect "iss" field. This 408 MUST be an HTTPS URL. 410 iss The issuer URL of the trustmark provider that issues this 411 trustmark. The URL that a trustmark is fetched from MUST start 412 with the "iss" URL in this field. This MUST be an HTTPS URL. 414 P Array of strings containing identity proofing values for which the 415 identity provider has been assessed and approved 417 C Array of strings containing credential strength values for which 418 the identity provider has been assessed and approved 420 A Array of strings containing assertion strength values for which 421 the identity provider has been assessed and approved 423 For example, the following trustmark provided by the 424 trustmark.example.org organization applies to the idp.example.org 425 identity provider: 427 { 428 "sub": "https://idp.example.org/", 429 "iss": "https://trustmark.example.org/", 430 "P": ["0", "1"], 431 "C": ["1", "2", "3"], 432 "A": ["2", "3"] 433 } 435 A client wishing to check the claims made by an IdP can fetch the 436 information from the trustmark provider about what claims the IdP is 437 allowed to make in the first place and process them accordingly. 439 The means by which the RP decides which trustmark providers it trusts 440 is out of scope for this specification and is generally configured 441 out of band. 443 Though most trust frameworks will provide a third-party independent 444 verification service for components, an IdP MAY host its own 445 trustmark. For example, a self-hosted trustmark would look like: 447 { 448 "sub": "https://idp.example.org/", 449 "iss": "https://idp.example.org/", 450 "P": ["0", "1"], 451 "C": ["1", "2", "3"], 452 "A": ["2", "3"] 453 } 455 7.2. Discovery 457 The IdP MAY list all of its available trustmarks as part of its 458 discovery document. Trustmarks are listed in the trustmarks element 459 which contains a single JSON [RFC7159] object. The keys of this JSON 460 object are trustmark provider issuer URLs and the values of this 461 object are the corresponding trustmarks for this IdP. 463 { 464 "trustmark": { 465 "https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/ 466 } 467 } 468 8. Acknowledgements 470 The authors would like to thank the members of the Vectors of Trust 471 mailing list in the IETF for discussion and feedback on the concept 472 and document. 474 9. References 476 9.1. Normative References 478 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 479 Core 1.0", November 2014. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 485 Interchange Format", RFC 7159, March 2014. 487 9.2. Informative References 489 [SP-800-63] 490 , , , , , , and , "Electronic Authentication Guideline", 491 August 2013. 493 Appendix A. Document History 495 - 00 497 o Created initial IETF drafted based on strawman proposal discussed 498 on VoT list. 500 o Split vector component definitions into their own section to allow 501 extension and override. 503 o Solidified trustmark document definition. 505 Authors' Addresses 507 Justin Richer (editor) 508 Bespoke Engineering 510 Email: ietf@justin.richer.org 511 Leif Johansson 512 Swedish University Network 513 Thulegatan 11 514 Stockholm 515 Sweden 517 Email: leifj@sunet.se 518 URI: http://www.sunet.se