idnits 2.17.1 draft-richer-vectors-of-trust-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 9, 2018) is 2178 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) == Missing Reference: 'A-Z' is mentioned on line 669, but not defined == Unused Reference: 'RFC8259' is defined on line 852, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' -- Obsolete informational reference (is this intentional?): RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: November 10, 2018 Swedish University Network 6 May 9, 2018 8 Vectors of Trust 9 draft-richer-vectors-of-trust-10 11 Abstract 13 This document defines a mechanism for describing and signaling 14 several aspects of a digital identity transaction and its 15 participants. These aspects are used to determine the trust to be 16 placed in that transaction. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in BCP 23 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 24 appear in all capitals, as shown here. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on November 10, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 64 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 6 65 2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7 66 2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 7 67 2.3. Primary Credential Management (M) . . . . . . . . . . . . 8 68 2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8 69 3. Communicating Vector Values to RPs . . . . . . . . . . . . . 8 70 3.1. On the Wire Representation . . . . . . . . . . . . . . . 9 71 3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 10 72 3.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11 74 4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12 75 4.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 5. Trustmarks . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6. Defining New Vector Values . . . . . . . . . . . . . . . . . 13 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Vector Of Trust Components Registry . . . . . . . . . . . 14 81 8.1.1. Registration Template . . . . . . . . . . . . . . . . 14 82 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 15 83 8.2. Additions to the OAuth Parameters Registry . . . . . . . 16 84 8.3. Additions to JWT Claims Registry . . . . . . . . . . . . 16 85 8.4. Additions to OAuth Token Introspection Response . . . . . 16 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 11.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Appendix A. Vectors of Trust Default Component Value Definitions 19 92 A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 19 93 A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 20 94 A.3. Primary Credential Management . . . . . . . . . . . . . . 20 95 A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 21 97 Appendix B. Document History . . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 Methods for measuring trust in digital identity transactions have 103 historically fallen into two main categories: either all measurements 104 are combined into a single scalar value, or trust decisions are 105 calculated locally based on a detailed set of attribute metadata. 106 This document defines a method of conveying trust information that is 107 more expressive than a single value but less complex than 108 comprehensive attribute metadata. 110 Prior to the third edition [SP-800-63-3] published in 2017, NIST 111 Special Publication 800-63 [SP-800-63-2] used a single scalar 112 measurement of trust called a Level of Assurance (LoA). An LoA can 113 be used to compare different transactions within a system at a coarse 114 level. For instance, an LoA4 transaction is generally considered 115 more trusted (across all measured categories) than an LoA2 116 transaction. The LoA for a given transaction is computed by the 117 identity provider (IdP) and is consumed by a relying party (RP). 118 Since the trust measurement is a simple numeric value, it's trivial 119 for RPs to process and compare. However, since each LoA encompasses 120 many different aspects of a transaction, it can't express many real- 121 world situations. For instance, an anonymous user account might have 122 a very strong credential, such as would be common of a whistle-blower 123 or political dissident. Despite the strong credential, the lack of 124 identity proofing would make any transactions conducted by the 125 account to fall into a low LoA. Furthermore, different use cases and 126 domains require subtly different definitions for their LoA 127 categories, and one group's LoA2 is not equivalent or even comparable 128 to another group's LoA2. 130 Attribute based access control (ABAC) systems used by RPs may need to 131 know details about a user's attributes, such as how recently the 132 attribute data was verified and by whom. Attribute metadata systems 133 are capable of expressing extremely fine-grained detail about the 134 transaction. However, this approach requires the IdP to collect, 135 store, and transmit all of this attribute data for the RP's 136 consumption. The RP must process this data, which may be prohibitive 137 for trivial security decisions. 139 Vectors of Trust (VoT) seeks a balance between these two alternatives 140 by allowing expression of multiple aspects of an identity transaction 141 (including but not limited to identity proofing, credential strength, 142 credential management, and assertion strength), without requiring 143 full attribute metadata descriptions. This method of measurement 144 gives more actionable data and expressiveness than an LoA, but is 145 still relatively easy for the RP to process. It is anticipated that 146 VoT can be used alongside more detailed attribute metadata systems as 147 has that proposed by NISITIR 8112 [NISTIR-8112]. The RP can use the 148 vector value for most basic decisions but be able to query the IdP 149 for additional attribute metadata where needed. Furthermore, it is 150 anticipated that some trust frameworks will provide a simple mapping 151 between certain sets of vector values to LoAs, for RPs that do not 152 have a need for the vector's more fine-grained detail. In such 153 systems, an RP is given a choice of how much detail to request from 154 the IdP in order to process a given transaction. 156 This document defines a data model for these vectors and an on-the- 157 wire format for conveying them between parties, anchored in a trust 158 definition. This document also provides guidance for defining values 159 for use in conveying this information, including four component 160 categories and guidance on defining values within those categories. 161 Additionally, this document defines a general-purpose set of 162 component values in an appendix (Appendix A) for use cases that do 163 not need something more specific. 165 1.1. Terminology 167 Identity Federation A protocol in which an Identity Provider (IdP) 168 asserts a user's identity information to a relying party (RP) 169 through the use of a cryptographic assertion or other verifiable 170 mechanism, or a system implementing such a protocol. Also 171 referred to simply as "federation". 173 Identity Provider (IdP) A system that manages identity information 174 and is able to assert this information across the network through 175 an identity API. 177 Identity Subject The person (user) engaging in the identity 178 transaction, being identified by the identity provider to the 179 relying party. 181 Identity Proofing The process of verifying and validating that a set 182 of identity attributes belongs to a real-world identity subject. 184 Primary Credential The means used by the identity subject to 185 authenticate to the identity provider. 187 Federated Credential The assertion presented by the IdP to the RP 188 across the network to authenticate the user. 190 Relying Party (RP) A system that consumes identity information from 191 an IdP for the purposes of authenticating the user. 193 Trust Framework A document containing business rules and legal 194 clauses that defines how different parties in an identity 195 transaction may act. 197 Trustmark A URI referencing a specific Trust Framework and its 198 definition of vector components and vector component values. 200 Trustmark Provider A system that can verify that a given system 201 (such as an identity provider) is both capable of asserting and 202 allowed to assert the vector component values it is claiming. 204 Vector A multi-part data structure, used here for conveying 205 information about an authentication transaction. 207 Vector Component One of several constituent parts that make up a 208 vector, indicating a category of information. 210 Vector Component Value One of the values applied to a vector 211 component within a vector. 213 1.2. An Identity Model 215 This document assumes the following model for identity based on 216 identity federation technologies: 218 The identity subject (also known as the user) is associated with an 219 identity provider which acts as a trusted third party on behalf of 220 the user with regard to a relying party by making identity assertions 221 about the user to the relying party. 223 The real-world person represented by the identity subject is in 224 possession of a primary credential bound to the identity subject by 225 the identity provider (or an agent thereof) in such a way that the 226 binding between the credential and the real-world user is a 227 representation of the identity proofing process performed by the 228 identity provider (or an agent thereof) to verify the identity of the 229 real-world person. This information is carried across the network as 230 part of an identity assertion presented to the relying party during 231 the authentication transaction. 233 1.3. Component Architecture 235 The term Vectors of Trust is inspired by the mathematical construct 236 of a vector, which is defined as an item composed of multiple 237 independent values. 239 An important goal for this work is to balance the need for simplicity 240 (particularly on the part of the relying party) with the need for 241 expressiveness. As such, this vector construct is designed to be 242 composable and extensible. 244 All components of the vector construct MUST be orthogonal such that 245 no aspect of a component overlaps an aspect of another component, as 246 much as is possible. 248 2. Component Definitions 250 This specification defines four orthogonal components: identity 251 proofing, primary credential usage, primary credential management, 252 and assertion presentation. 254 This specification also defines values for each of these component to 255 be used in the absence of a more specific trust framework in 256 Appendix A. It is expected that trust frameworks will provide 257 context, semantics, and mapping to legal statutes and business rules 258 for each value in each component. 260 Consequently, a particular vector value can only be compared with 261 vectors defined in the context of a specific trust framework. The RP 262 MUST understand and take into account the trust framework context in 263 which a vector is being expressed in order for to process a vector 264 securely. 266 Each component is identified by a demarcator consisting of a single 267 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD 268 reflect the category with which it is associated in a natural manner. 269 Demarcators for components MUST be registered as described in 270 Section 8. It is anticipated that trust framework definitions will 271 use this registry to define specialized components, though it is 272 RECOMMENDED that trust frameworks re-use existing components wherever 273 possible. 275 The value for a given component within a vector of trust is defined 276 by its demarcator character followed by a single digit or lowercase 277 ASCII letter in the range "[0-9a-z]". Categories which have a 278 natural ordering SHOULD use digits, with "0" as the lowest value. 279 Categories which do not have a natural ordering, or which can have an 280 ambiguous ordering, SHOULD use letters. Categories MAY use both 281 letter style and number style value indicators simultaneously. For 282 example, a category could define "0" as a special "empty" value while 283 using letters such as "a", "b", "c" for normal values to 284 differentiate between these types of options. Another system could 285 have a base category with a numeric value with additional details 286 provided by letter values. 288 Each component MAY be repeated with multiple different values within 289 a single vector (see Section 3.1 for details). The same component 290 and value combination MUST NOT be repeated within a single vector. A 291 trust framework MAY define additional restrictions on combinations of 292 values. 294 Regardless of the type of value indicator used, the values assigned 295 to each component of a vector MUST NOT be assumed always to have 296 inherent ordinal properties when compared to the same or other 297 components in the vector space. In other words, "1" is different 298 from "2", but it is dangerous to assume that "2" is always better 299 than "1." 301 2.1. Identity Proofing (P) 303 The Identity Proofing dimension defines, overall, how strongly the 304 set of identity attributes have been verified and vetted. In other 305 words, this dimension describes how likely it is that a given digital 306 identity transaction corresponds to a particular (real-world) 307 identity subject. For example, did the user have to provide 308 documentation to a trusted party to prove their legal name and 309 address, or were they able to self-assert such values? 311 This dimension uses the "P" demarcator and a single-character level 312 value, such as "P0", "P1", etc. Most definitions of identity 313 proofing will have a natural ordering, as more or less stringent 314 proofing can be applied to an individual being granted an account. 315 In such cases it is RECOMMENDED that a digit style value be used for 316 this component and that only a single value be allowed to be 317 communicated in a transaction. 319 2.2. Primary Credential Usage (C) 321 The primary credential usage dimension defines how strongly the 322 primary credential can be verified by the IdP. In other words, how 323 easily that credential could be spoofed or stolen. For example, did 324 the user log in using a password, with a biometric, with a 325 cryptographic hardware device, or some combination of the above? 327 This dimension uses the "C" demarcator and a single-character level 328 value, such as "Ca", "Cb", etc. Most definitions of credential usage 329 will not have an overall natural ordering, as there may be several 330 equivalent classes described within a trust framework. In such cases 331 it is RECOMMENDED that a letter style value be used for this 332 component and that multiple distinct credential usage factors be 333 allowed to be communicated simultaneously, such as when Multi-Factor 334 Authentication is used. 336 2.3. Primary Credential Management (M) 338 The primary credential management dimension conveys information about 339 the expected lifecycle of the primary credential in use, including 340 its binding, rotation, and revocation. In other words, the use and 341 strength of policies, practices, and security controls used in 342 managing the credential at the IdP and its binding to the intended 343 individual. For example, can the user bring their own cryptographic 344 device or is one provided by the IdP? 346 This dimension uses the "M" demarcator and a single-character level 347 value, such as "Ma", "Mb", etc. Most definitions of credential 348 management will not have an overall natural ordering, though there 349 can be preference and comparison between values in some 350 circumstances. In such cases it is RECOMMENDED that a letter style 351 value be used for this component and that multiple distinct values be 352 allowed to be communicated simultaneously. 354 2.4. Assertion Presentation (A) 356 The Assertion Presentation dimension defines how well the given 357 digital identity can be communicated across the network without 358 information leaking to unintended parties, and without spoofing. In 359 other words, this dimension describes how likely it is that a given 360 digital identity was actually asserted by a given identity provider 361 for a given transaction. While this information is largely already 362 known by the RP as a side effect of processing an identity assertion, 363 this dimension is still very useful when the RP requests a login 364 (Section 4) and when describing the capabilities of an IdP. 366 This dimension uses the "A" demarcator and a level value, such as 367 "Aa", "Ab", etc. Most definitions of assertion presentation will not 368 have an overall natural ordering. In such cases, it is RECOMMENDED 369 that a letter style value be used for this component and that 370 multiple values be allowed to be communicated simultaneously. 372 3. Communicating Vector Values to RPs 374 A vector of trust is designed to be used in the context of an 375 identity and authentication transaction, providing information about 376 the context of a federated credential. The vector therefore needs to 377 be able to be communicated in the context of the federated credential 378 in a way that is strongly bound to the assertion representing the 379 federated credential. 381 This vector has several requirements for use. 383 o All applicable vector components and values need to be combined 384 into a single vector. 386 o The vector can be communicated across the wire unbroken and 387 untransformed. 389 o All vector components need to remain individually available, not 390 "collapsed" into a single value. 392 o The vector needs to be protected in transit. 394 o The vector needs to be cryptographically bound to the assertion 395 which it is describing. 397 o The vector needs to be interpreted in the context of a specific 398 trust framework definition identified by a trustmark URI. 400 These requirements lead us to defining a simple string-based 401 representation of the vector that can be incorporated within a number 402 of different locations and protocols without further encoding. 404 3.1. On the Wire Representation 406 The vector MUST be represented as a period-separated ('.') list of 407 vector components. A vector component type can occur multiple times 408 within a single vector, but a specific value of a vector component 409 can not occur more than once in a single vector. That is, while 410 "Cc.Cd" is a valid vector, "Cc.Cc" is not. Multiple values for a 411 component are considered a logical AND of the values. 413 Vector component values MAY appear in any order within a vector, and 414 different orderings of the same vector values MUST be considered 415 equivalent. For example, "P1.Cc.Cd.Aa", "Aa.Cc.Cd.P1", 416 "Cd.P1.Cc.Aa", and "Aa.P1.Cd.Cc" are all considered the same vector 417 value. 419 Possible vector components MAY be omitted from a vector. No holding 420 space is left for an omitted vector component. If a vector component 421 is omitted, the vector is making no claim for that component. Trust 422 frameworks MAY define a distinct value for a component category to 423 indicate that a category was not used at all. 425 Vector values MUST be communicated along with of a trustmark URI 426 (Section 5) to give the components and component values context. The 427 trustmark MUST be cryptographically bound to the vector value, such 428 as the two values being carried together in a signed assertion. A 429 vector value without context is unprocessable, and vectors defined in 430 different contexts are not directly comparable as whole values. 432 Different trust frameworks MAY re-use component definitions 433 (including their values), but processing of such cross-context values 434 is outside the scope of this specification. 436 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous, 437 proof of shared key, signed browser-passed verified assertion, and no 438 claim made toward credential management" in the context of this 439 specification's definitions (Appendix A). A different vector value 440 of "Cb.Mc.Cd.Ac" translates to "known device, full proofing required 441 for credential issuance and rotation, cryptographic proof of 442 possession of a shared key, signed back-channel verified assertion, 443 and no claim made toward identity proofing" in the same context. 444 Since no claim is made here for identity proofing, no specific value 445 can be assumed by the RP. Note that this doesn't mean the user 446 wasn't proofed at all: it's possible that the user was fully proofed 447 to the highest capabilities within the trust framework, but here the 448 IdP is making no statement to that to the RP. 450 3.2. In OpenID Connect 452 In OpenID Connect [OpenID], the IdP MUST send the vector as a string 453 within the "vot" (vector of trust) claim in the ID token. The 454 trustmark (Section 5) that applies to this vector MUST be sent as an 455 URI in the "vtm" (vector trust mark) claim to provide context to the 456 vector. 458 The "vot" and "vtm" claims are interpreted by the RP to apply to the 459 entire identity transaction, and not necessarily to any one attribute 460 specifically. 462 For example, assume that for the given trustmark, the body of an ID 463 token claiming "pseudonymous, proof of shared key, signed back- 464 channel verified token, and no claim made toward credential 465 management" could look like this JSON object payload of the ID token. 467 { 468 "iss": "https://idp.example.com/", 469 "sub": "jondoe1234", 470 "vot": "P1.Cc.Ac", 471 "vtm": "https://example.org/vot-trust-framework" 472 } 474 The body of the ID token is signed and optionally encrypted using 475 JOSE, as per the OpenID Connect specification. By putting the "vot" 476 and "vtm" values inside the ID token, the vector and its context are 477 strongly bound to the federated credential represented by the ID 478 token. 480 3.3. In SAML 482 In SAML, a vector is communicated as an 483 "AuthenticationContextDeclRef". A vector is represented by prefixing 484 it with the "urn urn:ietf:param:[TBD]" to form a full URN. The 485 "AuthenticationContextDeclaration" corresponding to a given vector is 486 a "AuthenticationContextDeclaration" element containing an 487 "Extension" element with components of the vector represented by the 488 following XML schema: 490 491 495 496 This represents a set of 497 vector components. 498 499 500 501 502 503 504 505 507 For instance the vector P1.Cc.Ac is represented by the 508 AuthenticationContextDeclRef URN "urn:ietf:param:[TBD]:P1.Cc.Ac" (or 509 "urn:ietf:param:[TBD]:Cc.P1.Ac" or ...) which corresponds to the 510 following "AuthenticationContextDeclaration": 512 513 515 516 P1.Cc.Ac 517 518 520 4. Requesting Vector Values 522 In some identity protocols, the RP can request that particular vector 523 component values be used for a given identity transaction. Using the 524 same syntax as defined in Section 3.1, an RP can indicate that it 525 desires particular aspects be present in the authentication. 526 Processing and fulfillment of these requests are in the purview of 527 the IdP and details are outside the scope of this specification. 529 Future specifications MAY define alternative ways for an RP to retest 530 vector component values from an IdP. 532 4.1. In OpenID Connect 534 In OpenID Connect [OpenID], the client MAY request a partial set of 535 acceptable VoT component values with the "vtr" (vector of trust 536 request) claim request as part of the Request Object. The value of 537 this field is an array of JSON strings, each string identifying an 538 acceptable set of vector components. The component values within 539 each vector are ANDed together while the separate vectors are ORed 540 together. For example, a list of vectors in the form 541 "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating that either the full set of "P1 542 AND Cb AND Cc AND Ab" simultaneously OR the full set of "Ce AND Ab" 543 simultaneously are acceptable to this RP for this transaction. 545 Vector request values MAY omit components, indicating that any value 546 is acceptable for that component category, including omission of that 547 component in the response vector. 549 The mechanism by which the IdP processes the "vtr" and maps that to 550 the authentication transaction are out of scope of this 551 specification. 553 4.2. In SAML 555 In SAML (Section 3.3) the client can request a set of acceptable VoT 556 values by including the corresponding "AuthenticationContextDeclRef" 557 URIs together with an "AuthenticationContextClassRef" corresponding 558 to the trustmark (Section 5). The processing rules in Section 3.3 559 apply. 561 5. Trustmarks 563 A trustmark is a URI that references a specific set of vector values 564 as defined by a trust framework. This URI MUST point to a human- 565 readable document that describes what components and values are 566 valid, how they are used together, and what practices the component 567 values represent within the trust framework. The contents of the 568 trustmark URI MUST be reachable by the operators or implementors of 569 the RP. The URI SHOULD be stable over time for a given trust 570 framework. 572 For example, [[this document URI]] is used as a trustmark to 573 reference the values defined in Appendix A. 575 The process of a trustmark provider determining the ability of a 576 particular IdP to correctly assert values from a given trust 577 framework is outside the scope of this specification. Determining 578 how an RP should apply the values of a given vector to the RP's 579 processing is outside the scope of this specification. 581 6. Defining New Vector Values 583 Vectors of Trust is meant to be a flexible and reusable framework for 584 communicating authentication data between networked parties in an 585 identity federation protocol. However, the exact nature of the 586 information needed is reliant on the parties requiring the 587 information and the relationship between them. While this document 588 does define a usable default set of values in Appendix A, it is 589 anticipated that many situations will require an extension of this 590 specification for their own use. 592 Component categories such as those defined in Section 2 are intended 593 to be general purpose and reusable in a variety of circumstances. 594 Extension specifications SHOULD re-use existing category definitions 595 where possible. Extensions MAY create additional categories where 596 needed by using the registry defined in Section 8. The registry 597 encourages re-use and discovery of existing categories across 598 different implementations. In other words, the "P" category in 599 another framework SHOULD be used for identity proofing and related 600 information. 602 The values of components such as those defined in Appendix A are 603 intended to be contextual to the defining trust document. While this 604 specification's component values are intended to be general-purpose 605 and extensions MAY re-use the values and their definitions, 606 implementations MUST define all allowable values. As these values 607 are always interpreted in the context of a trustmark, these values 608 are not recorded in a central registry. Consequently, a "P1" value 609 from one framework and a "P1" value from another framework could have 610 very different interpretations depending on their contextual trust 611 framework documents. 613 Implementations of this specification SHOULD choose either a 614 numerical ordering or a group category approach to component values 615 as described in Section 2, though combinations of both types MAY be 616 used. Implementations of this specification MUST specify whether 617 multiple values are allowed for each category, and while any 618 component category is generally allowed to have multiple distinct 619 values, a specific definition of a set of values in an extension MAY 620 limit a given component category to a single value per transaction. 622 Extensions and implementations of this specification MUST be 623 referenced by a unique trustmark URI (Section 5) to allow RPs to 624 differentiate between different trust frameworks. 626 7. Acknowledgements 628 The authors would like to thank the members of the Vectors of Trust 629 mailing list in the IETF for discussion and feedback on the concept 630 and document, and the members of the ISOC Trust and Identity team for 631 their support. In particular, the authors would like to thank Paul 632 Grassi, Jim Fenton, Sarah Squire, Benjamin Kaduk, John Bradley, and 633 Karen O'Donoghue. 635 8. IANA Considerations 637 This specification creates one registry and registers several values 638 into existing registries. 640 8.1. Vector Of Trust Components Registry 642 This specification establishes the Vectors of Trust Components 643 Registry. 645 Component demarcators are registered by Specification Required 646 [RFC8126]. 648 Criteria that should be applied by the Designated Experts includes 649 determining whether the proposed registration duplicates existing 650 functionality, whether it is likely to be of general applicability or 651 whether it is useful only for a single application, and whether the 652 registration description is clear. 654 Registration requests sent to the vot@ietf.org mailing list for 655 review should use an appropriate subject (e.g., "Request to register 656 Vector of Trust Component name: example"). The Designated Expert(s) 657 will provide review within a two-week period and either approve or 658 deny the registration request, communicating this decision to the 659 review list and IANA. Denials should include an explanation and, if 660 applicable, suggestions as to how to make the request successful. 661 IANA must only accept registry updates from the Designated Expert(s) 662 and should direct all requests for registration to the vot@ietf.org 663 mailing list. If the Designated Experts do not respond within the 664 designated period, IANA should contact the IESG for guidance. 666 8.1.1. Registration Template 668 Demarcator Symbol 669 An uppercase ASCII letter in the range [A-Z] representing this 670 component (e.g., "X"). 672 Description: 673 Brief description of the component (e.g., "Example description"). 675 Change controller: 676 For IETF-stream RFCs, state "IESG". For other documents, give the 677 name of the responsible party. 679 Specification document(s): 680 Reference to the document(s) that specify the vector component, 681 preferably including a URI that can be used to retrieve a copy of 682 the document(s). An indication of the relevant sections may also 683 be included but is not required. 685 8.1.2. Initial Registry Contents 687 The Vector of Trust Components Registry contains the definitions of 688 vector components and their associated demarcators. 690 o Demarcator Symbol: P 692 o Description: Identity proofing 694 o Change Controller: IESG 696 o Specification document(s):: [[ this document ]] 698 o Demarcator Symbol: C 700 o Description: Primary credential usage 702 o Change Controller: IESG 704 o Specification document(s):: [[ this document ]] 706 o Demarcator Symbol: M 708 o Description: Primary credential management 710 o Change Controller: IESG 712 o Specification document(s):: [[ this document ]] 714 o Demarcator Symbol: A 716 o Description: Assertion presentation 718 o Change Controller: IESG 720 o Specification document(s):: [[ this document ]] 722 8.2. Additions to the OAuth Parameters Registry 724 This specification adds the following values to the OAuth Parameters 725 Registry established by [RFC6749]. 727 o Name: vtr 729 o Description: Vector of Trust request 731 o Parameter usage location: authorization request, token request 733 o Change Controller: IESG 735 o Document: [[ this document ]] 737 8.3. Additions to JWT Claims Registry 739 This specification adds the following values to the JSON Web Token 740 Claims Registry established by [RFC7519]. 742 o Claim name: vot 744 o Description: Vector of Trust value 746 o Change Controller: IESG 748 o Document: [[ this document ]] 750 o Claim name: vtm 752 o Description: Vector of Trust trustmark URI 754 o Change Controller: IESG 756 o Document: [[ this document ]] 758 8.4. Additions to OAuth Token Introspection Response 760 This specification adds the following values to the OAuth Token 761 Introspection Response established by [RFC7662]. 763 o Name: vot 765 o Description: Vector of Trust value 767 o Change Controller: IESG 769 o Document: [[ this document ]] 770 o Name: vtm 772 o Description: Vector of Trust trustmark URI 774 o Change Controller: IESG 776 o Document: [[ this document ]] 778 9. Security Considerations 780 The vector of trust value needs to be cryptographically protected in 781 transit between parties, such as by using TLS as described in 782 [BCP195]. The vector of trust value must be associated with a 783 trustmark by the RP processing the vector. By carrying both the 784 vector value and the trustmark URI, a signed OpenID Connect ID Token 785 and a signed SAML assertion both fulfil this requirement. 787 The vector value is always associated with a trustmark and needs to 788 be interpreted by the RP in the context of the trust framework 789 defined by that trustmark. Different trust frameworks can apply 790 different interpretations to the same component value, much as was 791 the case with LoA. Therefore, an RP interpreting a component value 792 in the wrong context could mistakenly accept or reject a request. In 793 order to avoid this mistake, RPs need to reject vectors that are 794 defined in trust frameworks that they do not understand how to 795 interpret properly. 797 The VoT framework provides a mechanism for describing and conveying 798 trust information. It does not define any policies for an IdP 799 determining which vector component values apply to a given 800 transaction, nor does it define any policies for applying the values 801 of a vector to an RP's security decision process. These policies and 802 associated practices are to be agreed upon by the IdP and RP, and 803 they should be expressed in detail in an associated human-readable 804 trust framework document available at the trustmark URI. 806 10. Privacy Considerations 808 By design, vector of trust values contain information about the 809 user's authentication and associations that can be made thereto. 810 Therefore, all aspects of a vector of trust contain potentially 811 privacy-sensitive information and must be guarded as such. Even in 812 the absence of specific attributes about a user, knowledge that the 813 user has been highly proofed or issued a strong token could provide 814 more information about the user than was intended. It is recommended 815 that IdPs send and RPs request only the information necessary for 816 their use case in order to prevent inadvertent information 817 disclosure. 819 11. References 821 11.1. Normative References 823 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 824 Core 1.0", November 2014. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 832 RFC 6749, DOI 10.17487/RFC6749, October 2012, 833 . 835 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 836 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 837 . 839 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 840 RFC 7662, DOI 10.17487/RFC7662, October 2015, 841 . 843 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 844 Writing an IANA Considerations Section in RFCs", BCP 26, 845 RFC 8126, DOI 10.17487/RFC8126, June 2017, 846 . 848 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 849 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 850 May 2017, . 852 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 853 Interchange Format", STD 90, RFC 8259, 854 DOI 10.17487/RFC8259, December 2017, 855 . 857 11.2. Informative References 859 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 860 "Recommendations for Secure Use of Transport Layer 861 Security (TLS) and Datagram Transport Layer Security 862 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 863 2015, . 865 [NISTIR-8112] 866 National Institute of Standards and Technology, U.S. 867 Department of Commerce, "A Proposed Schema for Evaluating 868 Federated Attributes", NIST NISTIR 8112, January 2018, 869 . 871 [SP-800-63-2] 872 National Institute of Standards and Technology, U.S. 873 Department of Commerce, "Electronic Authentication 874 Guideline", NIST SP 800-63-2, 875 DOI 10.6028/NIST.SP.800-63-2, August 2013, 876 . 878 [SP-800-63-3] 879 National Institute of Standards and Technology, U.S. 880 Department of Commerce, "Digital Identity Guideline", 881 NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017, 882 . 884 Appendix A. Vectors of Trust Default Component Value Definitions 886 The following general-purpose component definitions MAY be used when 887 a more specific set is unavailable. This document defines a trust 888 framework for these component values. This trust framework 889 referenced in a trustmark URI of [[ this document URL ]]. 891 Extensions and implementations of this specification SHOULD define 892 their own component values as described in Section 6. Where 893 possible, extensions MAY re-use specific values and definitions as 894 listed here, but those specific values MUST be re-listed. 896 A.1. Identity Proofing 898 The identity proofing component of this vector definition represents 899 increasing scrutiny during the proofing process. Higher levels are 900 largely subsumptive of lower levels, such that "P2" fulfills 901 requirements for "P1", etc. Multiple distinct values from this 902 category MUST NOT be used in a single transaction. 904 P0 No proofing is done, data is not guaranteed to be persistent 905 across sessions 907 P1 Attributes are self-asserted but consistent over time, potentially 908 pseudonymous 910 P2 Identity has been proofed either in person or remotely using 911 trusted mechanisms (such as social proofing) 913 P3 There is a binding relationship between the identity provider and 914 the identified party (such as signed/notarized documents, 915 employment records) 917 A.2. Primary Credential Usage 919 The primary credential usage component of this vector definition 920 represents distinct categories of primary credential that MAY be used 921 together in a single transaction. Multiple distinct values from this 922 category MAY be used in a single transaction. 924 C0 No credential is used / anonymous public service 926 Ca Simple session HTTP cookies (with nothing else) 928 Cb Known device 930 Cc Shared secret such as a username and password combination 932 Cd Cryptographic proof of key possession using shared key 934 Ce Cryptographic proof of key possession using asymmetric key 936 Cf Sealed hardware token / TPM-backed keys 938 Cg Locally verified biometric 940 A.3. Primary Credential Management 942 The primary credential management component of this vector definition 943 represents distinct categories of management that MAY be considered 944 separately or together in a single transaction. Many trust framework 945 deployments MAY use a single value for this component as a baseline 946 for all transactions and thereby omit it. Multiple distinct values 947 from this category MAY be used in a single transaction. 949 Ma Self-asserted primary credentials (user chooses their own 950 credentials and must rotate or revoke them manually) / no 951 additional verification for primary credential issuance or 952 rotation 954 Mb Remote issuance and rotation / use of backup recover credentials 955 (such as email verification) / deletion on user request 957 Mc Full proofing required for each issuance and rotation / revocation 958 on suspicious activity 960 A.4. Assertion Presentation 962 The assertion presentation component of this vector definition 963 represents distinct categories of assertion which are RECOMMENDED to 964 be used in a subsumptive manner but MAY be used together. Multiple 965 distinct values from this category MAY be used in a single 966 transaction. 968 Aa No protection / unsigned bearer identifier (such as an HTTP 969 session cookie in a web browser) 971 Ab Signed and verifiable assertion, passed through the user agent 972 (web browser) 974 Ac Signed and verifiable assertion, passed through a back channel 976 Ad Assertion encrypted to the relying parties key and audience 977 protected 979 Appendix B. Document History 981 -09 983 o Various fixes to respond to AD review. 985 o Added introspection response IANA registration. 987 o Cleaned up IANA entries. 989 o Removed confusing per-IdP trustmark and discovery sections. 990 Adopted single trustmark definition instead. 992 o Added definition of identity federation. 994 o Added definition of identity proofing. 996 o Added examples to component sections. 998 -08 1000 o Incorporated shepherd comments. 1002 o Updated references. 1004 o Added reference to NISTIR 8112. 1006 o Moved default component definitions to appendix. 1008 -07 1010 o Rewrote introduction to clarify focus of document. 1012 -06 1014 o Added section on extensions to VoT. 1016 o Made it so that every component category could be multi-valued. 1018 o Added reference to updated 800-63-3. 1020 o Fixed example text width. 1022 o Switched document back to standards-track from experimental now 1023 that there are extensions in the wild. 1025 -05 1027 o Updated IANA considerations section to include instructions. 1029 o Made security and privacy considerations non-normative. 1031 -04 1033 o Updated SAML example to be consistent. 1035 -03 1037 o Clarified language of LoA's in introduction. 1039 o Added note on operational security in trustmarks. 1041 o Removed empty sections and references. 1043 -02 1045 o Converted C, M, and A values to use letters instead of numbers in 1046 examples. 1048 o Updated SAML to a structured example pending future updates. 1050 o Defined guidance for when to use letters vs. numbers in category 1051 values. 1053 o Restricted category demarcators to uppercase and values to 1054 lowercase and digits. 1056 o Applied clarifying editorial changes from list comments. 1058 - 01 1060 o Added IANA registry for components. 1062 o Added preliminary security considerations and privacy 1063 considerations. 1065 o Split "credential binding" into "primary credential usage" and 1066 "primary credential management". 1068 - 00 1070 o Created initial IETF drafted based on strawman proposal discussed 1071 on VoT list. 1073 o Split vector component definitions into their own section to allow 1074 extension and override. 1076 o Solidified trustmark document definition. 1078 Authors' Addresses 1080 Justin Richer (editor) 1081 Bespoke Engineering 1083 Email: ietf@justin.richer.org 1085 Leif Johansson 1086 Swedish University Network 1087 Thulegatan 11 1088 Stockholm 1089 Sweden 1091 Email: leifj@sunet.se 1092 URI: http://www.sunet.se