idnits 2.17.1 draft-richer-vectors-of-trust-11.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 18, 2018) is 2142 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 618, but not defined == Unused Reference: 'RFC8259' is defined on line 802, 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 19, 2018 Swedish University Network 6 May 18, 2018 8 Vectors of Trust 9 draft-richer-vectors-of-trust-11 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 amount of 16 trust to be 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 19, 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 4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11 73 4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11 74 5. Trustmarks . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Defining New Vector Values . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 8.1. Vector Of Trust Components Registry . . . . . . . . . . . 13 79 8.1.1. Registration Template . . . . . . . . . . . . . . . . 14 80 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14 81 8.2. Additions to the OAuth Parameters Registry . . . . . . . 15 82 8.3. Additions to JWT Claims Registry . . . . . . . . . . . . 15 83 8.4. Additions to OAuth Token Introspection Response . . . . . 16 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 11.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Appendix A. Vectors of Trust Default Component Value Definitions 18 90 A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 19 91 A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 19 92 A.3. Primary Credential Management . . . . . . . . . . . . . . 20 93 A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 20 94 Appendix B. Document History . . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 Methods for measuring trust in digital identity transactions have 100 historically fallen into two main categories: either all measurements 101 are combined into a single scalar value, or trust decisions are 102 calculated locally based on a detailed set of attribute metadata. 103 This document defines a method of conveying trust information that is 104 more expressive than a single value but less complex than 105 comprehensive attribute metadata. 107 Prior to the third edition [SP-800-63-3] published in 2017, NIST 108 Special Publication 800-63 [SP-800-63-2] used a single scalar 109 measurement of trust called a Level of Assurance (LoA). An LoA can 110 be used to compare different transactions within a system at a coarse 111 level. For instance, an LoA4 transaction is generally considered 112 more trusted (across all measured categories) than an LoA2 113 transaction. The LoA for a given transaction is computed by the 114 identity provider (IdP) and is consumed by a relying party (RP). 115 Since the trust measurement is a simple numeric value, it's trivial 116 for RPs to process and compare. However, since each LoA encompasses 117 many different aspects of a transaction, it can't express many real- 118 world situations. For instance, an anonymous user account might have 119 a very strong credential, such as would be common of a whistle-blower 120 or political dissident. Despite the strong credential, the lack of 121 identity proofing would make any transactions conducted by the 122 account to fall into a low LoA. Furthermore, different use cases and 123 domains require subtly different definitions for their LoA 124 categories, and one group's LoA2 is not equivalent or even comparable 125 to another group's LoA2. 127 Attribute based access control (ABAC) systems used by RPs may need to 128 know details about a user's attributes, such as how recently the 129 attribute data was verified and by whom. Attribute metadata systems 130 are capable of expressing extremely fine-grained detail about the 131 transaction. However, this approach requires the IdP to collect, 132 store, and transmit all of this attribute data for the RP's 133 consumption. The RP must process this data, which may be prohibitive 134 for trivial security decisions. 136 Vectors of Trust (VoT) seeks a balance between these two alternatives 137 by allowing expression of multiple aspects of an identity transaction 138 (including but not limited to identity proofing, credential strength, 139 credential management, and assertion strength), without requiring 140 full attribute metadata descriptions. This method of measurement 141 gives more actionable data and expressiveness than an LoA, but is 142 still relatively easy for the RP to process. It is anticipated that 143 VoT can be used alongside more detailed attribute metadata systems as 144 has that proposed by NISITIR 8112 [NISTIR-8112]. The RP can use the 145 vector value for most basic decisions but be able to query the IdP 146 for additional attribute metadata where needed. Furthermore, it is 147 anticipated that some trust frameworks will provide a simple mapping 148 between certain sets of vector values to LoAs, for RPs that do not 149 have a need for the vector's more fine-grained detail. In such 150 systems, an RP is given a choice of how much detail to request from 151 the IdP in order to process a given transaction. 153 This document defines a data model for these vectors and an on-the- 154 wire format for conveying them between parties, anchored in a trust 155 definition. This document also provides guidance for defining values 156 for use in conveying this information, including four component 157 categories and guidance on defining values within those categories. 158 Additionally, this document defines a general-purpose set of 159 component values in an appendix (Appendix A) for use cases that do 160 not need something more specific. 162 1.1. Terminology 164 Identity Federation A protocol in which an Identity Provider (IdP) 165 asserts a user's identity information to a relying party (RP) 166 through the use of a cryptographic assertion or other verifiable 167 mechanism, or a system implementing such a protocol. Also 168 referred to simply as "federation". 170 Identity Provider (IdP) A system that manages identity information 171 and is able to assert this information across the network through 172 an identity API. 174 Identity Subject The person (user) engaging in the identity 175 transaction, being identified by the identity provider to the 176 relying party. 178 Identity Proofing The process of verifying and validating that a set 179 of identity attributes belongs to a real-world identity subject. 181 Primary Credential The means used by the identity subject to 182 authenticate to the identity provider. 184 Federated Credential The assertion presented by the IdP to the RP 185 across the network to authenticate the user. 187 Relying Party (RP) A system that consumes identity information from 188 an IdP for the purposes of authenticating the user. 190 Trust Framework A document containing business rules and legal 191 clauses that defines how different parties in an identity 192 transaction may act. 194 Trustmark A URI referencing a specific Trust Framework and its 195 definition of vector components and vector component values. 197 Trustmark Provider A system that can verify that a given system 198 (such as an identity provider) is both capable of asserting and 199 allowed to assert the vector component values it is claiming. 201 Vector A multi-part data structure, used here for conveying 202 information about an authentication transaction. 204 Vector Component One of several constituent parts that make up a 205 vector, indicating a category of information. 207 Vector Component Value One of the values applied to a vector 208 component within a vector. 210 1.2. An Identity Model 212 This document assumes the following model for identity based on 213 identity federation technologies: 215 The identity subject (also known as the user) is associated with an 216 identity provider which acts as a trusted third party on behalf of 217 the user with regard to a relying party by making identity assertions 218 about the user to the relying party. 220 The real-world person represented by the identity subject is in 221 possession of a primary credential bound to the identity subject by 222 the identity provider (or an agent thereof) in such a way that the 223 binding between the credential and the real-world user is a 224 representation of the identity proofing process performed by the 225 identity provider (or an agent thereof) to verify the identity of the 226 real-world person. This information is carried across the network as 227 part of an identity assertion presented to the relying party during 228 the authentication transaction. 230 1.3. Component Architecture 232 The term Vectors of Trust is inspired by the mathematical construct 233 of a vector, which is defined as an item composed of multiple 234 independent values. 236 An important goal for this work is to balance the need for simplicity 237 (particularly on the part of the relying party) with the need for 238 expressiveness. As such, this vector construct is designed to be 239 composable and extensible. 241 All components of the vector construct MUST be orthogonal such that 242 no aspect of a component overlaps an aspect of another component, as 243 much as is possible. 245 2. Component Definitions 247 This specification defines four orthogonal components: identity 248 proofing, primary credential usage, primary credential management, 249 and assertion presentation. 251 This specification also defines values for each of these component to 252 be used in the absence of a more specific trust framework in 253 Appendix A. It is expected that trust frameworks will provide 254 context, semantics, and mapping to legal statutes and business rules 255 for each value in each component. 257 Consequently, a particular vector value can only be compared with 258 vectors defined in the context of a specific trust framework. The RP 259 MUST understand and take into account the trust framework context in 260 which a vector is being expressed in order for to process a vector 261 securely. 263 Each component is identified by a demarcator consisting of a single 264 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD 265 reflect the category with which it is associated in a natural manner. 266 Demarcators for components MUST be registered as described in 267 Section 8. It is anticipated that trust framework definitions will 268 use this registry to define specialized components, though it is 269 RECOMMENDED that trust frameworks re-use existing components wherever 270 possible. 272 The value for a given component within a vector of trust is defined 273 by its demarcator character followed by a single digit or lowercase 274 ASCII letter in the range "[0-9a-z]". Categories which have a 275 natural ordering SHOULD use digits, with "0" as the lowest value. 276 Categories which do not have a natural ordering, or which can have an 277 ambiguous ordering, SHOULD use letters. Categories MAY use both 278 letter style and number style value indicators simultaneously. For 279 example, a category could define "0" as a special "empty" value while 280 using letters such as "a", "b", "c" for normal values to 281 differentiate between these types of options. Another system could 282 have a base category with a numeric value with additional details 283 provided by letter values. 285 Each component MAY be repeated with multiple different values within 286 a single vector (see Section 3.1 for details). The same component 287 and value combination MUST NOT be repeated within a single vector. A 288 trust framework MAY define additional restrictions on combinations of 289 values. 291 Regardless of the type of value indicator used, the values assigned 292 to each component of a vector MUST NOT be assumed always to have 293 inherent ordinal properties when compared to the same or other 294 components in the vector space. In other words, "1" is different 295 from "2", but it is dangerous to assume that "2" is always better 296 than "1." 298 2.1. Identity Proofing (P) 300 The Identity Proofing dimension defines, overall, how strongly the 301 set of identity attributes have been verified and vetted. In other 302 words, this dimension describes how likely it is that a given digital 303 identity transaction corresponds to a particular (real-world) 304 identity subject. For example, did the user have to provide 305 documentation to a trusted party to prove their legal name and 306 address, or were they able to self-assert such values? 308 This dimension uses the "P" demarcator and a single-character level 309 value, such as "P0", "P1", etc. Most definitions of identity 310 proofing will have a natural ordering, as more or less stringent 311 proofing can be applied to an individual being granted an account. 312 In such cases it is RECOMMENDED that a digit style value be used for 313 this component and that only a single value be allowed to be 314 communicated in a transaction. 316 2.2. Primary Credential Usage (C) 318 The primary credential usage dimension defines how strongly the 319 primary credential can be verified by the IdP. In other words, how 320 easily that credential could be spoofed or stolen. For example, did 321 the user log in using a password, with a biometric, with a 322 cryptographic hardware device, or some combination of the above? 324 This dimension uses the "C" demarcator and a single-character level 325 value, such as "Ca", "Cb", etc. Most definitions of credential usage 326 will not have an overall natural ordering, as there may be several 327 equivalent classes described within a trust framework. In such cases 328 it is RECOMMENDED that a letter style value be used for this 329 component and that multiple distinct credential usage factors be 330 allowed to be communicated simultaneously, such as when Multi-Factor 331 Authentication is used. 333 2.3. Primary Credential Management (M) 335 The primary credential management dimension conveys information about 336 the expected lifecycle of the primary credential in use, including 337 its binding, rotation, and revocation. In other words, the use and 338 strength of policies, practices, and security controls used in 339 managing the credential at the IdP and its binding to the intended 340 individual. For example, can the user bring their own cryptographic 341 device or is one provided by the IdP? 343 This dimension uses the "M" demarcator and a single-character level 344 value, such as "Ma", "Mb", etc. Most definitions of credential 345 management will not have an overall natural ordering, though there 346 can be preference and comparison between values in some 347 circumstances. In such cases it is RECOMMENDED that a letter style 348 value be used for this component and that multiple distinct values be 349 allowed to be communicated simultaneously. 351 2.4. Assertion Presentation (A) 353 The Assertion Presentation dimension defines how well the given 354 digital identity can be communicated across the network without 355 information leaking to unintended parties, and without spoofing. In 356 other words, this dimension describes how likely it is that a given 357 digital identity was actually asserted by a given identity provider 358 for a given transaction. While this information is largely already 359 known by the RP as a side effect of processing an identity assertion, 360 this dimension is still very useful when the RP requests a login 361 (Section 4) and when describing the capabilities of an IdP. 363 This dimension uses the "A" demarcator and a level value, such as 364 "Aa", "Ab", etc. Most definitions of assertion presentation will not 365 have an overall natural ordering. In such cases, it is RECOMMENDED 366 that a letter style value be used for this component and that 367 multiple values be allowed to be communicated simultaneously. 369 3. Communicating Vector Values to RPs 371 A vector of trust is designed to be used in the context of an 372 identity and authentication transaction, providing information about 373 the context of a federated credential. The vector therefore needs to 374 be able to be communicated in the context of the federated credential 375 in a way that is strongly bound to the assertion representing the 376 federated credential. 378 This vector has several requirements for use. 380 o All applicable vector components and values need to be combined 381 into a single vector. 383 o The vector can be communicated across the wire unbroken and 384 untransformed. 386 o All vector components need to remain individually available, not 387 "collapsed" into a single value. 389 o The vector needs to be protected in transit. 391 o The vector needs to be cryptographically bound to the assertion 392 which it is describing. 394 o The vector needs to be interpreted in the context of a specific 395 trust framework definition identified by a trustmark URI. 397 These requirements lead us to defining a simple string-based 398 representation of the vector that can be incorporated within a number 399 of different locations and protocols without further encoding. 401 3.1. On the Wire Representation 403 The vector MUST be represented as a period-separated ('.') list of 404 vector components. A vector component type can occur multiple times 405 within a single vector, but a specific value of a vector component 406 can not occur more than once in a single vector. That is, while 407 "Cc.Cd" is a valid vector, "Cc.Cc" is not. Multiple values for a 408 component are considered a logical AND of the values. 410 Vector component values MAY appear in any order within a vector, and 411 different orderings of the same vector values MUST be considered 412 equivalent. For example, "P1.Cc.Cd.Aa", "Aa.Cc.Cd.P1", 413 "Cd.P1.Cc.Aa", and "Aa.P1.Cd.Cc" are all considered the same vector 414 value. 416 Possible vector components MAY be omitted from a vector. No holding 417 space is left for an omitted vector component. If a vector component 418 is omitted, the vector is making no claim for that component. Trust 419 frameworks MAY define a distinct value for a component category to 420 indicate that a category was not used at all. 422 Vector values MUST be communicated along with of a trustmark URI 423 (Section 5) to give the components and component values context. The 424 trustmark MUST be cryptographically bound to the vector value, such 425 as the two values being carried together in a signed assertion. A 426 vector value without context is unprocessable, and vectors defined in 427 different contexts are not directly comparable as whole values. 429 Different trust frameworks MAY re-use component definitions 430 (including their values), but processing of such cross-context values 431 is outside the scope of this specification. 433 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous, 434 proof of shared key, signed browser-passed verified assertion, and no 435 claim made toward credential management" in the context of this 436 specification's definitions (Appendix A). A different vector value 437 of "Cb.Mc.Cd.Ac" translates to "known device, full proofing required 438 for credential issuance and rotation, cryptographic proof of 439 possession of a shared key, signed back-channel verified assertion, 440 and no claim made toward identity proofing" in the same context. 441 Since no claim is made here for identity proofing, no specific value 442 can be assumed by the RP. Note that this doesn't mean the user 443 wasn't proofed at all: it's possible that the user was fully proofed 444 to the highest capabilities within the trust framework, but here the 445 IdP is making no statement to that to the RP. 447 3.2. In OpenID Connect 449 In OpenID Connect [OpenID], the IdP MUST send the vector as a string 450 within the "vot" (vector of trust) claim in the ID token. The 451 trustmark (Section 5) that applies to this vector MUST be sent as an 452 URI in the "vtm" (vector trust mark) claim to provide context to the 453 vector. 455 The "vot" and "vtm" claims are interpreted by the RP to apply to the 456 entire identity transaction, and not necessarily to any one attribute 457 specifically. 459 For example, assume that for the given trustmark, the body of an ID 460 token claiming "pseudonymous, proof of shared key, signed back- 461 channel verified token, and no claim made toward credential 462 management" could look like this JSON object payload of the ID token. 464 { 465 "iss": "https://idp.example.com/", 466 "sub": "jondoe1234", 467 "vot": "P1.Cc.Ac", 468 "vtm": "https://example.org/vot-trust-framework" 469 } 471 The body of the ID token is signed and optionally encrypted using 472 JOSE, as per the OpenID Connect specification. By putting the "vot" 473 and "vtm" values inside the ID token, the vector and its context are 474 strongly bound to the federated credential represented by the ID 475 token. 477 4. Requesting Vector Values 479 In some identity protocols, the RP can request that particular vector 480 component values be used for a given identity transaction. Using the 481 same syntax as defined in Section 3.1, an RP can indicate that it 482 desires particular aspects be present in the authentication. 483 Processing and fulfillment of these requests are in the purview of 484 the IdP and details are outside the scope of this specification. 486 Future specifications MAY define alternative ways for an RP to 487 request vector component values from an IdP. 489 4.1. In OpenID Connect 491 In OpenID Connect [OpenID], the client MAY request a partial set of 492 acceptable VoT component values with the "vtr" (vector of trust 493 request) claim request as part of the Request Object. The value of 494 this field is an array of JSON strings, each string identifying an 495 acceptable set of vector components. The component values within 496 each vector are ANDed together while the separate vectors are ORed 497 together. For example, a list of vectors in the form 498 "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating that either the full set of "P1 499 AND Cb AND Cc AND Ab" simultaneously OR the full set of "Ce AND Ab" 500 simultaneously are acceptable to this RP for this transaction. 502 Vector request values MAY omit components, indicating that any value 503 is acceptable for that component category, including omission of that 504 component in the response vector. 506 The mechanism by which the IdP processes the "vtr" and maps that to 507 the authentication transaction are out of scope of this 508 specification. 510 5. Trustmarks 512 A trustmark is a URI that references a specific set of vector values 513 as defined by a trust framework. This URI MUST point to a human- 514 readable document that describes what components and values are 515 valid, how they are used together, and what practices the component 516 values represent within the trust framework. The contents of the 517 trustmark URI MUST be reachable by the operators or implementors of 518 the RP. The URI SHOULD be stable over time for a given trust 519 framework. 521 For example, [[this document URI]] is used as a trustmark to 522 reference the values defined in Appendix A. 524 The process of a trustmark provider determining the ability of a 525 particular IdP to correctly assert values from a given trust 526 framework is outside the scope of this specification. Determining 527 how an RP should apply the values of a given vector to the RP's 528 processing is outside the scope of this specification. 530 6. Defining New Vector Values 532 Vectors of Trust is meant to be a flexible and reusable framework for 533 communicating authentication data between networked parties in an 534 identity federation protocol. However, the exact nature of the 535 information needed is reliant on the parties requiring the 536 information and the relationship between them. While this document 537 does define a usable default set of values in Appendix A, it is 538 anticipated that many situations will require an extension of this 539 specification for their own use. 541 Component categories such as those defined in Section 2 are intended 542 to be general purpose and reusable in a variety of circumstances. 543 Extension specifications SHOULD re-use existing category definitions 544 where possible. Extensions MAY create additional categories where 545 needed by using the registry defined in Section 8. The registry 546 encourages re-use and discovery of existing categories across 547 different implementations. In other words, the "P" category in 548 another framework SHOULD be used for identity proofing and related 549 information. 551 The values of components such as those defined in Appendix A are 552 intended to be contextual to the defining trust document. While this 553 specification's component values are intended to be general-purpose 554 and extensions MAY re-use the values and their definitions, 555 implementations MUST define all allowable values. As these values 556 are always interpreted in the context of a trustmark, these values 557 are not recorded in a central registry. Consequently, a "P1" value 558 from one framework and a "P1" value from another framework could have 559 very different interpretations depending on their contextual trust 560 framework documents. 562 Implementations of this specification SHOULD choose either a 563 numerical ordering or a group category approach to component values 564 as described in Section 2, though combinations of both types MAY be 565 used. Implementations of this specification MUST specify whether 566 multiple values are allowed for each category, and while any 567 component category is generally allowed to have multiple distinct 568 values, a specific definition of a set of values in an extension MAY 569 limit a given component category to a single value per transaction. 571 Extensions and implementations of this specification MUST be 572 referenced by a unique trustmark URI (Section 5) to allow RPs to 573 differentiate between different trust frameworks. 575 7. Acknowledgements 577 The authors would like to thank the members of the Vectors of Trust 578 mailing list in the IETF for discussion and feedback on the concept 579 and document, and the members of the ISOC Trust and Identity team for 580 their support. In particular, the authors would like to thank Paul 581 Grassi, Jim Fenton, Sarah Squire, Benjamin Kaduk, John Bradley, and 582 Karen O'Donoghue. 584 8. IANA Considerations 586 This specification creates one registry and registers several values 587 into existing registries. 589 8.1. Vector Of Trust Components Registry 591 This specification establishes the Vectors of Trust Components 592 Registry. 594 Component demarcators are registered by the Specification Required 595 policy documented in [RFC8126]. 597 Criteria that should be applied by the Designated Experts includes 598 determining whether the proposed registration duplicates existing 599 functionality, whether it is likely to be of general applicability or 600 whether it is useful only for a single application, and whether the 601 registration description is clear. 603 Registration requests sent to the vot@ietf.org mailing list for 604 review should use an appropriate subject (e.g., "Request to register 605 Vector of Trust Component name: example"). The Designated Expert(s) 606 will provide review within a two-week period and either approve or 607 deny the registration request, communicating this decision to the 608 review list and IANA. Denials should include an explanation and, if 609 applicable, suggestions as to how to make the request successful. 610 IANA must only accept registry updates from the Designated Expert(s) 611 and should direct all requests for registration to the vot@ietf.org 612 mailing list. If the Designated Experts do not respond within the 613 designated period, IANA should contact the IESG for guidance. 615 8.1.1. Registration Template 617 Demarcator Symbol 618 An uppercase ASCII letter in the range [A-Z] representing this 619 component (e.g., "X"). 621 Description: 622 Brief description of the component (e.g., "Example description"). 624 Change controller: 625 For IETF-stream RFCs, state "IESG". For other documents, give the 626 name of the responsible party. 628 Specification document(s): 629 Reference to the document(s) that specify the vector component, 630 preferably including a URI that can be used to retrieve a copy of 631 the document(s). An indication of the relevant sections may also 632 be included but is not required. 634 8.1.2. Initial Registry Contents 636 The Vector of Trust Components Registry contains the definitions of 637 vector components and their associated demarcators. 639 o Demarcator Symbol: P 641 o Description: Identity proofing 643 o Change Controller: IESG 645 o Specification document(s):: [[ this document ]] 647 o Demarcator Symbol: C 649 o Description: Primary credential usage 651 o Change Controller: IESG 653 o Specification document(s):: [[ this document ]] 655 o Demarcator Symbol: M 657 o Description: Primary credential management 659 o Change Controller: IESG 661 o Specification document(s):: [[ this document ]] 662 o Demarcator Symbol: A 664 o Description: Assertion presentation 666 o Change Controller: IESG 668 o Specification document(s):: [[ this document ]] 670 8.2. Additions to the OAuth Parameters Registry 672 This specification adds the following values to the OAuth Parameters 673 Registry established by [RFC6749]. 675 o Name: vtr 677 o Description: Vector of Trust request 679 o Parameter usage location: authorization request, token request 681 o Change Controller: IESG 683 o Document: [[ this document ]] 685 8.3. Additions to JWT Claims Registry 687 This specification adds the following values to the JSON Web Token 688 Claims Registry established by [RFC7519]. 690 o Claim name: vot 692 o Description: Vector of Trust value 694 o Change Controller: IESG 696 o Document: [[ this document ]] 698 o Claim name: vtm 700 o Description: Vector of Trust trustmark URI 702 o Change Controller: IESG 704 o Document: [[ this document ]] 706 8.4. Additions to OAuth Token Introspection Response 708 This specification adds the following values to the OAuth Token 709 Introspection Response established by [RFC7662]. 711 o Name: vot 713 o Description: Vector of Trust value 715 o Change Controller: IESG 717 o Document: [[ this document ]] 719 o Name: vtm 721 o Description: Vector of Trust trustmark URI 723 o Change Controller: IESG 725 o Document: [[ this document ]] 727 9. Security Considerations 729 The vector of trust value needs to be cryptographically protected in 730 transit between parties, such as by using TLS as described in 731 [BCP195]. The vector of trust value must be associated with a 732 trustmark by the RP processing the vector. By carrying both the 733 vector value and the trustmark URI, a signed OpenID Connect ID Token 734 or a similarly signed assertion from another protocol would fulfil 735 this requirement. 737 The vector value is always associated with a trustmark and needs to 738 be interpreted by the RP in the context of the trust framework 739 defined by that trustmark. Different trust frameworks can apply 740 different interpretations to the same component value, much as was 741 the case with LoA. Therefore, an RP interpreting a component value 742 in the wrong context could mistakenly accept or reject a request. In 743 order to avoid this mistake, RPs need to reject vectors that are 744 defined in trust frameworks that they do not understand how to 745 interpret properly. 747 The VoT framework provides a mechanism for describing and conveying 748 trust information. It does not define any policies for an IdP 749 determining which vector component values apply to a given 750 transaction, nor does it define any policies for applying the values 751 of a vector to an RP's security decision process. These policies and 752 associated practices are to be agreed upon by the IdP and RP, and 753 they should be expressed in detail in an associated human-readable 754 trust framework document available at the trustmark URI. 756 10. Privacy Considerations 758 By design, vector of trust values contain information about the 759 user's authentication and associations that can be made thereto. 760 Therefore, all aspects of a vector of trust contain potentially 761 privacy-sensitive information and must be guarded as such. Even in 762 the absence of specific attributes about a user, knowledge that the 763 user has been highly proofed or issued a strong token could provide 764 more information about the user than was intended. It is recommended 765 that IdPs send and RPs request only the information necessary for 766 their use case in order to prevent inadvertent information 767 disclosure. 769 11. References 771 11.1. Normative References 773 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 774 Core 1.0", November 2014. 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 782 RFC 6749, DOI 10.17487/RFC6749, October 2012, 783 . 785 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 786 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 787 . 789 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 790 RFC 7662, DOI 10.17487/RFC7662, October 2015, 791 . 793 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 794 Writing an IANA Considerations Section in RFCs", BCP 26, 795 RFC 8126, DOI 10.17487/RFC8126, June 2017, 796 . 798 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 799 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 800 May 2017, . 802 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 803 Interchange Format", STD 90, RFC 8259, 804 DOI 10.17487/RFC8259, December 2017, 805 . 807 11.2. Informative References 809 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 810 "Recommendations for Secure Use of Transport Layer 811 Security (TLS) and Datagram Transport Layer Security 812 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 813 2015, . 815 [NISTIR-8112] 816 National Institute of Standards and Technology, U.S. 817 Department of Commerce, "A Proposed Schema for Evaluating 818 Federated Attributes", NIST NISTIR 8112, January 2018, 819 . 821 [SP-800-63-2] 822 National Institute of Standards and Technology, U.S. 823 Department of Commerce, "Electronic Authentication 824 Guideline", NIST SP 800-63-2, 825 DOI 10.6028/NIST.SP.800-63-2, August 2013, 826 . 828 [SP-800-63-3] 829 National Institute of Standards and Technology, U.S. 830 Department of Commerce, "Digital Identity Guideline", 831 NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017, 832 . 834 Appendix A. Vectors of Trust Default Component Value Definitions 836 The following general-purpose component definitions MAY be used when 837 a more specific set is unavailable. This document defines a trust 838 framework for these component values. This trust framework 839 referenced in a trustmark URI of [[ this document URL ]]. 841 Extensions and implementations of this specification SHOULD define 842 their own component values as described in Section 6. Where 843 possible, extensions MAY re-use specific values and definitions as 844 listed here, but those specific values MUST be re-listed. 846 A.1. Identity Proofing 848 The identity proofing component of this vector definition represents 849 increasing scrutiny during the proofing process. Higher levels are 850 largely subsumptive of lower levels, such that "P2" fulfills 851 requirements for "P1", etc. Multiple distinct values from this 852 category MUST NOT be used in a single transaction. 854 P0 No proofing is done, data is not guaranteed to be persistent 855 across sessions 857 P1 Attributes are self-asserted but consistent over time, potentially 858 pseudonymous 860 P2 Identity has been proofed either in person or remotely using 861 trusted mechanisms (such as social proofing) 863 P3 There is a binding relationship between the identity provider and 864 the identified party (such as signed/notarized documents, 865 employment records) 867 A.2. Primary Credential Usage 869 The primary credential usage component of this vector definition 870 represents distinct categories of primary credential that MAY be used 871 together in a single transaction. Multiple distinct values from this 872 category MAY be used in a single transaction. 874 C0 No credential is used / anonymous public service 876 Ca Simple session HTTP cookies (with nothing else) 878 Cb Known device 880 Cc Shared secret such as a username and password combination 882 Cd Cryptographic proof of key possession using shared key 884 Ce Cryptographic proof of key possession using asymmetric key 886 Cf Sealed hardware token / TPM-backed keys 888 Cg Locally verified biometric 890 A.3. Primary Credential Management 892 The primary credential management component of this vector definition 893 represents distinct categories of management that MAY be considered 894 separately or together in a single transaction. Many trust framework 895 deployments MAY use a single value for this component as a baseline 896 for all transactions and thereby omit it. Multiple distinct values 897 from this category MAY be used in a single transaction. 899 Ma Self-asserted primary credentials (user chooses their own 900 credentials and must rotate or revoke them manually) / no 901 additional verification for primary credential issuance or 902 rotation 904 Mb Remote issuance and rotation / use of backup recover credentials 905 (such as email verification) / deletion on user request 907 Mc Full proofing required for each issuance and rotation / revocation 908 on suspicious activity 910 A.4. Assertion Presentation 912 The assertion presentation component of this vector definition 913 represents distinct categories of assertion which are RECOMMENDED to 914 be used in a subsumptive manner but MAY be used together. Multiple 915 distinct values from this category MAY be used in a single 916 transaction. 918 Aa No protection / unsigned bearer identifier (such as an HTTP 919 session cookie in a web browser) 921 Ab Signed and verifiable assertion, passed through the user agent 922 (web browser) 924 Ac Signed and verifiable assertion, passed through a back channel 926 Ad Assertion encrypted to the relying parties key and audience 927 protected 929 Appendix B. Document History 931 -11 933 o Updated IANA. 935 o Minor language tweaks from AD review. 937 o Removed SAML implementation. 939 -10 941 o Various fixes to respond to AD review. 943 o Added introspection response IANA registration. 945 o Cleaned up IANA entries. 947 o Removed confusing per-IdP trustmark and discovery sections. 948 Adopted single trustmark definition instead. 950 o Added definition of identity federation. 952 o Added definition of identity proofing. 954 o Added examples to component sections. 956 -08 958 o Incorporated shepherd comments. 960 o Updated references. 962 o Added reference to NISTIR 8112. 964 o Moved default component definitions to appendix. 966 -07 968 o Rewrote introduction to clarify focus of document. 970 -06 972 o Added section on extensions to VoT. 974 o Made it so that every component category could be multi-valued. 976 o Added reference to updated 800-63-3. 978 o Fixed example text width. 980 o Switched document back to standards-track from experimental now 981 that there are extensions in the wild. 983 -05 985 o Updated IANA considerations section to include instructions. 987 o Made security and privacy considerations non-normative. 989 -04 991 o Updated SAML example to be consistent. 993 -03 995 o Clarified language of LoA's in introduction. 997 o Added note on operational security in trustmarks. 999 o Removed empty sections and references. 1001 -02 1003 o Converted C, M, and A values to use letters instead of numbers in 1004 examples. 1006 o Updated SAML to a structured example pending future updates. 1008 o Defined guidance for when to use letters vs. numbers in category 1009 values. 1011 o Restricted category demarcators to uppercase and values to 1012 lowercase and digits. 1014 o Applied clarifying editorial changes from list comments. 1016 - 01 1018 o Added IANA registry for components. 1020 o Added preliminary security considerations and privacy 1021 considerations. 1023 o Split "credential binding" into "primary credential usage" and 1024 "primary credential management". 1026 - 00 1028 o Created initial IETF drafted based on strawman proposal discussed 1029 on VoT list. 1031 o Split vector component definitions into their own section to allow 1032 extension and override. 1034 o Solidified trustmark document definition. 1036 Authors' Addresses 1038 Justin Richer (editor) 1039 Bespoke Engineering 1041 Email: ietf@justin.richer.org 1043 Leif Johansson 1044 Swedish University Network 1045 Thulegatan 11 1046 Stockholm 1047 Sweden 1049 Email: leifj@sunet.se 1050 URI: http://www.sunet.se