idnits 2.17.1 draft-richer-vectors-of-trust-13.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 (August 1, 2018) is 2066 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 644, but not defined -- 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 (~~), 3 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: February 2, 2019 Swedish University Network 6 August 1, 2018 8 Vectors of Trust 9 draft-richer-vectors-of-trust-13 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 February 2, 2019. 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. Identity Model . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 64 2. Component Dimension 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 . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . 16 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 19 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 . . . . . . . . . . . . . . . . . . 21 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, 144 such as the one proposed by NISITIR 8112 [NISTIR-8112]. The RP can 145 use the vector value for most basic decisions but be able to query 146 the IdP for additional attribute metadata where needed. Furthermore, 147 it is anticipated that some trust frameworks will provide a simple 148 mapping between certain sets of vector values to LoAs, for RPs that 149 do not have a need for the vector's more fine-grained detail. In 150 such systems, an RP is given a choice of how much detail to request 151 from 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 individual (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 URL referencing a specific Trust Framework and its 195 definition of vector components and vector component values. 197 Trustmark Provider Defines the trust framework referenced by its 198 trustmark, and can verify that a given system (such as an identity 199 provider) is both capable of asserting and allowed to assert the 200 vector component values it is claiming. 202 Vector A multi-part data structure, used here for conveying 203 information about an authentication transaction. 205 Vector Component One of several constituent parts that make up a 206 vector, indicating a category of information. 208 Vector Component Value One of the values applied to a vector 209 component within a vector. 211 1.2. Identity Model 213 This document assumes the following model for identity based on 214 identity federation technologies: 216 The identity subject (also known as the user) is associated with an 217 identity provider which acts as a trusted third party on behalf of 218 the user with regard to a relying party by making identity assertions 219 about the user to the relying party. 221 The real-world individual represented by the identity subject is in 222 possession of a primary credential bound to the identity subject by 223 the identity provider (or an agent thereof) in such a way that the 224 binding between the credential and the real-world user is a 225 representation of the identity proofing process performed by the 226 identity provider (or an agent thereof) to verify the identity of the 227 real-world individual. This information is carried across the 228 network as part of an identity assertion presented to the relying 229 party during the authentication transaction. 231 1.3. Component Architecture 233 The term Vectors of Trust is inspired by the mathematical construct 234 of a vector, which is defined as an item composed of multiple 235 independent values. 237 An important goal for this work is to balance the need for simplicity 238 (particularly on the part of the relying party) with the need for 239 expressiveness. As such, this vector construct is designed to be 240 composable and extensible. 242 All components of the vector construct MUST be orthogonal such that 243 no aspect of a component overlaps an aspect of another component, as 244 much as is possible. 246 2. Component Dimension Definitions 248 This specification defines four orthogonal components: identity 249 proofing, primary credential usage, primary credential management, 250 and assertion presentation. 252 This specification also defines values for each of these component to 253 be used in the absence of a more specific trust framework in 254 Appendix A. It is expected that trust frameworks will provide 255 context, semantics, and mapping to legal statutes and business rules 256 for each value in each component. 258 Consequently, a particular vector value can only be compared with 259 vectors defined in the context of a specific trust framework. The RP 260 MUST understand and take into account the trust framework context in 261 which a vector is being expressed in order to process a vector 262 correctly. 264 Each component is identified by a demarcator consisting of a single 265 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD 266 reflect the category with which it is associated in a natural manner. 267 Demarcators for components MUST be registered as described in 268 Section 8. It is anticipated that trust framework definitions will 269 use this registry to define specialized components, though it is 270 RECOMMENDED that trust frameworks re-use existing components 271 categories wherever possible. Different trust frameworks SHOULD use 272 the same component for similar information, but since the processing 273 for all vector values is contextual to a trust framework, the exact 274 semantics of interpreting a component will vary based on the trust 275 framework in use. 277 The value for a given component within a vector of trust is defined 278 by its demarcator character followed by a single digit or lowercase 279 ASCII letter in the range "[0-9a-z]". Categories which have a 280 natural ordering SHOULD prefer digits, with larger digits indicating 281 stronger assertions than smaller digits. Categories which do not 282 have a natural ordering, or which can have an ambiguous ordering, 283 SHOULD prefer letters. Note that while letters could also imply 284 order, they can also more naturally be used mnemonically. Trust 285 frameworks MAY use any possible values within a category without the 286 need for them to be contiguous. 288 Categories MAY use both letters and digits simultaneously. For 289 example, a category could define "0" as meaning "no statement is 290 made" while using letters such as "a", "b", "c" for normal values to 291 indicate specific options. Another system could have an ordered base 292 set of digits with additional details provided by letters. 294 Each component MAY be repeated with multiple different values within 295 a single vector, representing the logical AND of the values (see 296 Section 3.1 for details). The same component and value combination 297 MUST NOT be repeated within a single vector. For example, a vector 298 could contain both "P1" and "Pa" but not two instances of "P1". A 299 trust framework MAY define additional restrictions on combinations of 300 values. 302 Regardless of the type of value, the RP MUST NOT assume that the 303 values assigned to each component of a vector have inherent ordinal 304 or subsumptive properties when compared to the same or other 305 components in the vector space without specific knowledge of the 306 trust framework in use. In other words, "1" is always different from 307 "2", but it is dangerous to assume that "2" is always better than "1" 308 or that "2" satisfies all the requirements of "1". 310 2.1. Identity Proofing (P) 312 The Identity Proofing dimension defines, overall, how strongly the 313 set of identity attributes have been verified and vetted. In other 314 words, this dimension describes how likely it is that a given digital 315 identity transaction corresponds to a particular (real-world) 316 identity subject. For example, did the user have to provide 317 documentation to a trusted party to prove their legal name and 318 address, or were they able to self-assert such values? 320 This dimension uses the "P" demarcator, such as "P0", "P1", etc. 321 Most definitions of identity proofing will have a natural ordering, 322 as more or less stringent proofing can be applied to an individual 323 being granted an account. In such cases it is RECOMMENDED that a 324 digit be used for this component and that only a single value be 325 allowed to be communicated in a transaction. 327 2.2. Primary Credential Usage (C) 329 The primary credential usage dimension defines how strongly the 330 primary credential can be verified by the IdP. In other words, how 331 easily that credential could be spoofed or stolen. For example, did 332 the user log in using a password, with a biometric, with a 333 cryptographic hardware device, or some combination of the above? 335 This dimension uses the "C" demarcator, such as "Ca", "Cb", etc. 336 Most definitions of credential usage will not have an overall natural 337 ordering, as there may be several equivalent classes described within 338 a trust framework. In such cases it is RECOMMENDED that a letter be 339 used for this component and that multiple distinct credential usage 340 factors be allowed to be communicated simultaneously, such as when 341 Multi-Factor Authentication is used. 343 2.3. Primary Credential Management (M) 345 The primary credential management dimension conveys information about 346 the expected lifecycle of the primary credential in use, including 347 its binding, rotation, and revocation. In other words, the use and 348 strength of policies, practices, and security controls used in 349 managing the credential at the IdP and its binding to the intended 350 individual. For example, can the user bring their own cryptographic 351 device or is one provided by the IdP? 353 This dimension uses the "M" demarcator, such as "Ma", "Mb", etc. 354 Most definitions of credential management will not have an overall 355 natural ordering, though there can be preference and comparison 356 between values in some circumstances. In such cases it is 357 RECOMMENDED that a letter be used for this component and that 358 multiple distinct values be allowed to be communicated 359 simultaneously. 361 2.4. Assertion Presentation (A) 363 The Assertion Presentation dimension defines how well the given 364 digital identity can be communicated across the network without 365 information leaking to unintended parties, and without spoofing. In 366 other words, this dimension describes how likely it is that a given 367 digital identity was asserted by a given identity provider for the 368 identity subject of a given transaction. While this information is 369 largely already known by the RP as a side effect of processing an 370 identity assertion in a federation protocol, this dimension is still 371 very useful when the RP requests a login (Section 4) and when 372 describing the capabilities of an IdP. This value also allows the RP 373 to detect when an assertion is presented in a manner it was not 374 intended for, as may be the case with an attack. 376 This dimension uses the "A" demarcator, such as "Aa", "Ab", etc. 377 Most definitions of assertion presentation will not have an overall 378 natural ordering. In such cases, it is RECOMMENDED that a letter be 379 used for this component and that multiple values be allowed to be 380 communicated simultaneously. 382 3. Communicating Vector Values to RPs 384 A vector of trust is designed to be used in the context of an 385 identity and authentication transaction, providing information about 386 the context of a federated credential. The vector therefore needs to 387 be able to be communicated in the context of the federated credential 388 in a way that is strongly bound to the assertion representing the 389 federated credential. 391 This vector has several requirements for use. 393 o All applicable vector components and values need to be combined 394 into a single vector. 396 o The vector can be communicated across the wire unbroken and 397 untransformed. 399 o All vector components need to remain individually available, not 400 "collapsed" into a single value. 402 o The vector needs to be protected in transit. 404 o The vector needs to be cryptographically bound to the assertion 405 which it is describing. 407 o The vector needs to be interpreted in the context of a specific 408 trust framework definition identified by a trustmark URL. 410 These requirements lead us to defining a simple string-based 411 representation of the vector that can be incorporated within a number 412 of different locations and protocols without further encoding. 414 3.1. On-the-Wire Representation 416 The vector MUST be represented as a period-separated ('.') list of 417 vector components. A vector component type can occur multiple times 418 within a single vector, but a specific value of a vector component 419 can not occur more than once in a single vector. That is, while 420 "Cc.Cd" is a valid vector, "Cc.Cc" is not. Multiple values for a 421 component are considered a logical AND of the values. 423 Vector component values MAY appear in any order within a vector, and 424 the RP MUST consider different orderings of the same vector 425 equivalent during processing. For example, "P1.Cc.Cd.Aa", 426 "Aa.Cc.Cd.P1", "Cd.P1.Cc.Aa", and "Aa.P1.Cd.Cc" are all considered 427 equivalent to each other. 429 Possible vector components MAY be omitted from a vector. No holding 430 space is left for an omitted vector component. If a vector component 431 is omitted, the vector is making no claim for that component. No 432 default values are assumed for a missing component category. 434 Vector values MUST be communicated along with a trustmark URL 435 (Section 5) to give the components and component values context. The 436 trustmark MUST be cryptographically bound to the vector value, such 437 as the two values being carried together in a signed assertion. A 438 vector value without context is unprocessable, and vectors defined in 439 different contexts are not directly comparable as whole values. 440 Different trust frameworks MAY re-use component definitions 441 (including their values), but processing of such cross-context values 442 is outside the scope of this specification. 444 For example, the vector "P1.Cc.Ab" translates to "pseudonymous, proof 445 of shared key, signed browser-passed verified assertion, and no claim 446 made toward credential management" in the context of this 447 specification's definitions (Appendix A). A different vector 448 "Cb.Mc.Cd.Ac" translates to "known device, full proofing required for 449 credential issuance and rotation, cryptographic proof of possession 450 of a shared key, signed back-channel verified assertion, and no claim 451 made toward identity proofing" in the same context. Since no claim 452 is made here for identity proofing, no specific value can be assumed 453 by the RP. Note that this doesn't mean the user wasn't proofed at 454 all: it's possible that the user was fully proofed to the highest 455 capabilities within the trust framework, but here the IdP not making 456 any specific claim about proofing to the RP, perhaps to protect the 457 user's privacy. 459 3.2. In OpenID Connect 461 In OpenID Connect [OpenID], the IdP MUST send the vector as a string 462 within the "vot" (vector of trust) claim in the ID token. The 463 trustmark (Section 5) that applies to this vector MUST be sent as an 464 URL in the "vtm" (vector trust mark) claim to provide context to the 465 vector. 467 The "vot" and "vtm" claims are interpreted by the RP to apply to the 468 entire identity transaction, and not necessarily to any one attribute 469 specifically. 471 For example, assume that for the given trustmark, the body of an ID 472 token claiming "pseudonymous, proof of shared key, signed back- 473 channel verified token, and no claim made toward credential 474 management" could look like this JSON object [RFC8259] payload of the 475 ID token. 477 { 478 "iss": "https://idp.example.com/", 479 "sub": "jondoe1234", 480 "vot": "P1.Cc.Ac", 481 "vtm": "https://example.org/vot-trust-framework" 482 } 484 The body of the ID token is signed and optionally encrypted using 485 JOSE, as per the OpenID Connect specification. By putting the "vot" 486 and "vtm" values inside the ID token, the vector and its context are 487 strongly bound to the federated credential represented by the ID 488 token. 490 Vector values MAY be returned in a token introspection [RFC7662] 491 response describing the ID token or access token issued during an 492 OpenID Connect transaction using the same claims. 494 4. Requesting Vector Values 496 In some identity protocols, the RP can request that particular vector 497 values be used for a given identity transaction. An RP can describe 498 the particular vector component values it desires the IdP assert for 499 a given identity transaction by using the same syntax as defined in 500 Section 3.1. Processing and fulfillment of these requests are in the 501 purview of the IdP and details are outside the scope of this 502 specification. 504 Future specifications MAY define alternative ways for an RP to 505 request vector values from an IdP. 507 4.1. In OpenID Connect 509 In OpenID Connect [OpenID], the client MAY request a partial set of 510 acceptable VoT values with the "vtr" (vector of trust request) claim 511 request as part of the Request Object. The value of this field is a 512 JSON array of strings [RFC8259], each string identifying an 513 acceptable set of vector components. The component values within 514 each vector are ANDed together while the separate vectors are ORed 515 together. For example, a list of vectors in the form {{ NOTE TO RFC 516 EDITOR: change outer double quotes to single quotes in text version 517 }} "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating that either the full set of 518 "P1 AND Cb AND Cc AND Ab" simultaneously OR the full set of "Ce AND 519 Ab" simultaneously are acceptable to this RP for this transaction. 521 Vector request values MAY omit components, indicating that any value 522 is acceptable for that component category, including omission of that 523 component in the response vector. 525 The mechanism by which the IdP processes the "vtr" and maps that to 526 the authentication transaction are out of scope of this 527 specification. 529 5. Trustmarks 531 A trustmark is an HTTPS URL that references a specific set of vector 532 values as defined by a trust framework. This URL MUST point to a 533 human-readable document that describes what components and values are 534 valid, how they are used together, and what practices the component 535 values represent within the trust framework. The contents of the 536 trustmark URL MUST be reachable by the operators or implementors of 537 the RP. The URL MUST be stable over time for a given trust framework 538 to allow RPs to process incoming vectors in a consistent fashion. 539 New versions of a trust framework that require different processing 540 rules MUST use a different trustmark URL. 542 For example, [[this document URL]] is used as the trustmark to 543 reference the values defined in Appendix A. 545 The process of a trustmark provider determining the ability of a 546 particular IdP to correctly assert values from a given trust 547 framework is outside the scope of this specification. Determining 548 how an RP should apply the values of a given vector to the RP's 549 processing is outside the scope of this specification. 551 6. Defining New Vector Values 553 Vectors of Trust is meant to be a flexible and reusable framework for 554 communicating authentication data between networked parties in an 555 identity federation protocol. However, the exact nature of the 556 information needed depends on the parties requiring the information 557 and the relationship between them. While this document does define a 558 usable default set of values in Appendix A, it is anticipated that 559 many situations will require an extension of this specification for 560 their own use. 562 Component categories such as those defined in Section 2 are intended 563 to be general purpose and reusable in a variety of trust frameworks. 564 Extension specifications SHOULD re-use existing category definitions 565 where possible. Extensions MAY create additional categories where 566 needed by using the registry defined in Section 8. The registry 567 encourages re-use and discovery of existing categories across 568 different implementations. In other words, the "P" category in 569 another framework SHOULD be used for identity proofing and related 570 information. 572 The values of components such as those defined in Appendix A are 573 intended to be contextual to the defining trust document. While this 574 specification's component values are intended to be general-purpose 575 and extensions MAY re-use the values and their definitions, 576 implementations MUST define all allowable values. As these values 577 are always interpreted in the context of a trustmark, these values 578 are not recorded in a central registry. Consequently, a "P1" value 579 from one framework and a "P1" value from another framework could have 580 very different interpretations depending on their contextual trust 581 framework documents, even though in both cases the "P" component is 582 used for identity proofing in some fashion. 584 Trust frameworks that implement this specification SHOULD choose 585 either a numerical ordering or a group category approach to component 586 values as described in Section 2, though combinations of both types 587 MAY be used. Implementations of this specification MUST specify 588 whether multiple values are allowed for each category, and while any 589 component category is generally allowed to have multiple distinct 590 values, a specific definition of a set of values in an extension MAY 591 limit a given component category to a single value per transaction. 592 It is RECOMMENDED that trust frameworks use a "0" value to indicate 593 an empty or null condition for a given category (for example, no 594 proofing being done or no authentication token being used). 596 Extensions and implementations of this specification MUST be 597 referenced by a unique trustmark URL (Section 5) to allow RPs to 598 differentiate between different trust frameworks. 600 7. Acknowledgements 602 The authors would like to thank the members of the Vectors of Trust 603 mailing list in the IETF for discussion and feedback on the concept 604 and document, and the members of the ISOC Trust and Identity team for 605 their support. In particular, the authors would like to thank Paul 606 Grassi, Jim Fenton, Sarah Squire, Benjamin Kaduk, John Bradley, and 607 Karen O'Donoghue. 609 8. IANA Considerations 611 This specification creates one registry and registers several values 612 into existing registries. 614 8.1. Vector of Trust Components Registry 616 This specification establishes the Vectors of Trust Components 617 Registry. 619 Component demarcators are registered by the Specification Required 620 policy documented in [RFC8126]. 622 Criteria that should be applied by the Designated Experts includes 623 determining whether the proposed registration duplicates existing 624 functionality, whether it is likely to be of general applicability or 625 whether it is useful only for limited applications (note that either 626 is permissible though the former is to be preferred), and whether the 627 registration description is clear. 629 Registration requests sent to the vot@ietf.org mailing list for 630 review should use an appropriate subject (e.g., "Request to register 631 Vector of Trust Component name: example"). The Designated Expert(s) 632 will provide review within a two-week period and either approve or 633 deny the registration request, communicating this decision to the 634 review list and IANA. Denials should include an explanation and, if 635 applicable, suggestions as to how to make the request successful. 636 IANA must only accept registry updates from the Designated Expert(s) 637 and should direct all requests for registration to the vot@ietf.org 638 mailing list. If the Designated Experts do not respond within the 639 designated period, IANA should contact the IESG for guidance. 641 8.1.1. Registration Template 643 Demarcator Symbol 644 An uppercase ASCII letter in the range [A-Z] representing this 645 component (e.g., "X"). 647 Description: 648 Brief description of the component (e.g., "Example description"). 650 Change controller: 651 For IETF-stream RFCs, state "IESG". For other documents, give the 652 name of the responsible party. 654 Specification document(s): 655 Reference to the document(s) that specify the vector component, 656 preferably including a URL that can be used to retrieve a copy of 657 the document(s). An indication of the relevant sections may also 658 be included but is not required. 660 8.1.2. Initial Registry Contents 662 The Vector of Trust Components Registry contains the definitions of 663 vector components and their associated demarcators. 665 o Demarcator Symbol: P 666 o Description: Identity proofing 668 o Change Controller: IESG 670 o Specification document(s):: [[ this document ]] 672 o Demarcator Symbol: C 674 o Description: Primary credential usage 676 o Change Controller: IESG 678 o Specification document(s):: [[ this document ]] 680 o Demarcator Symbol: M 682 o Description: Primary credential management 684 o Change Controller: IESG 686 o Specification document(s):: [[ this document ]] 688 o Demarcator Symbol: A 690 o Description: Assertion presentation 692 o Change Controller: IESG 694 o Specification document(s):: [[ this document ]] 696 8.2. Additions to the OAuth Parameters Registry 698 This specification adds the following values to the OAuth Parameters 699 Registry established by [RFC6749]. 701 o Name: vtr 703 o Description: Vector of Trust request 705 o Parameter usage location: authorization request, token request 707 o Change Controller: IESG 709 o Document: [[ this document ]] 711 8.3. Additions to JWT Claims Registry 713 This specification adds the following values to the JSON Web Token 714 Claims Registry established by [RFC7519]. 716 o Claim name: vot 718 o Description: Vector of Trust value 720 o Change Controller: IESG 722 o Document: [[ this document ]] 724 o Claim name: vtm 726 o Description: Vector of Trust trustmark URL 728 o Change Controller: IESG 730 o Document: [[ this document ]] 732 8.4. Additions to OAuth Token Introspection Response 734 This specification adds the following values to the OAuth Token 735 Introspection Response established by [RFC7662]. 737 o Name: vot 739 o Description: Vector of Trust value 741 o Change Controller: IESG 743 o Document: [[ this document ]] 745 o Name: vtm 747 o Description: Vector of Trust trustmark URL 749 o Change Controller: IESG 751 o Document: [[ this document ]] 753 9. Security Considerations 755 The vector of trust value needs to be cryptographically protected in 756 transit between parties, such as by using TLS as described in 757 [BCP195]. The vector of trust value must be associated with a 758 trustmark by the RP processing the vector. A signed OpenID Connect 759 ID Token or a similarly signed assertion from another protocol would 760 fulfill this requirement by carrying both the vector value and the 761 trustmark URL as claims. 763 The vector value is always associated with a trustmark and needs to 764 be interpreted by the RP in the context of the trust framework 765 defined by that trustmark. Different trust frameworks can apply 766 different interpretations to the same component value, much as was 767 the case with LoA. Therefore, an RP interpreting a component value 768 in the wrong context could mistakenly accept or reject a request. In 769 order to avoid this mistake, RPs need to reject vectors that are 770 defined in trust frameworks that they do not understand how to 771 interpret properly. 773 The VoT framework provides a mechanism for describing and conveying 774 trust information. It does not define any policies for an IdP 775 determining which vector component values apply to a given 776 transaction, nor does it define any policies for applying the values 777 of a vector to an RP's security decision process. These policies and 778 associated practices are to be agreed upon by the IdP and RP, and 779 they should be expressed in detail in an associated human-readable 780 trust framework document available at the trustmark URL. 782 10. Privacy Considerations 784 By design, vector of trust values contain information about the 785 user's authentication and associations that can be made thereto. 786 Therefore, all aspects of a vector of trust contain potentially 787 privacy-sensitive information and must be guarded as such. Even in 788 the absence of specific attributes about a user, knowledge that the 789 user has been highly proofed or issued a strong token could provide 790 more information about the user than was intended. It is recommended 791 that IdPs send and RPs request only the information necessary for 792 their use case in order to prevent inadvertent information 793 disclosure. 795 11. References 797 11.1. Normative References 799 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 800 Core 1.0", November 2014. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 808 RFC 6749, DOI 10.17487/RFC6749, October 2012, 809 . 811 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 812 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 813 . 815 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 816 RFC 7662, DOI 10.17487/RFC7662, October 2015, 817 . 819 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 820 Writing an IANA Considerations Section in RFCs", BCP 26, 821 RFC 8126, DOI 10.17487/RFC8126, June 2017, 822 . 824 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 825 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 826 May 2017, . 828 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 829 Interchange Format", STD 90, RFC 8259, 830 DOI 10.17487/RFC8259, December 2017, 831 . 833 11.2. Informative References 835 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 836 "Recommendations for Secure Use of Transport Layer 837 Security (TLS) and Datagram Transport Layer Security 838 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 839 2015, . 841 [NISTIR-8112] 842 National Institute of Standards and Technology, U.S. 843 Department of Commerce, "A Proposed Schema for Evaluating 844 Federated Attributes", NIST NISTIR 8112, January 2018, 845 . 847 [SP-800-63-2] 848 National Institute of Standards and Technology, U.S. 849 Department of Commerce, "Electronic Authentication 850 Guideline", NIST SP 800-63-2, 851 DOI 10.6028/NIST.SP.800-63-2, August 2013, 852 . 854 [SP-800-63-3] 855 National Institute of Standards and Technology, U.S. 856 Department of Commerce, "Digital Identity Guideline", 857 NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017, 858 . 860 Appendix A. Vectors of Trust Default Component Value Definitions 862 The following general-purpose component definitions MAY be used when 863 a more specific set is unavailable. This document defines a trust 864 framework for these component values. The trustmark URL of this 865 trust framework is [[ this document URL ]]. All normative 866 requirements following in this section apply to this trust framework 867 alone. 869 Extensions and implementations of this specification SHOULD define 870 their own component values as described in Section 6. Where 871 possible, extensions MAY re-use specific values and definitions as 872 listed here, but those specific values MUST be re-listed. 874 A.1. Identity Proofing 876 The identity proofing component of this vector definition represents 877 the level of scrutiny applied to the identity subject during the 878 proofing process. Higher levels are largely subsumptive of lower 879 levels, such that "P2" fulfills requirements for "P1", etc. Multiple 880 distinct values from this category MUST NOT be used in a single 881 transaction. 883 P0 No proofing is done, data is not guaranteed to be persistent 884 across sessions 886 P1 Attributes are self-asserted but consistent over time, potentially 887 pseudonymous 889 P2 Identity has been proofed either in person or remotely using 890 trusted mechanisms (such as social proofing) 892 P3 There is a binding relationship between the identity provider and 893 the identified party (such as signed/notarized documents, 894 employment records) 896 A.2. Primary Credential Usage 898 The primary credential usage component of this vector definition 899 represents distinct categories of primary credential that MAY be used 900 together in a single transaction. Multiple distinct values from this 901 category MAY be used in a single transaction. 903 C0 No credential is used / anonymous public service 905 Ca Simple session HTTP cookies (with nothing else) 907 Cb Known device such as indicated through device posture or device 908 management systems 910 Cc Shared secret such as a username and password combination 912 Cd Cryptographic proof of key possession using shared key 914 Ce Cryptographic proof of key possession using asymmetric key 916 Cf Sealed hardware token / keys stored in a trusted platform module 918 Cg Locally verified biometric 920 A.3. Primary Credential Management 922 The primary credential management component of this vector definition 923 represents distinct categories of management that MAY be considered 924 separately or together in a single transaction. Many trust framework 925 deployments MAY use a single value for this component as a baseline 926 for all transactions and thereby omit it. Multiple distinct values 927 from this category MAY be used in a single transaction. 929 Ma Self-asserted primary credentials (user chooses their own 930 credentials and must rotate or revoke them manually) / no 931 additional verification for primary credential issuance or 932 rotation 934 Mb Remote issuance and rotation / use of backup recover credentials 935 (such as email verification) / deletion on user request 937 Mc Full proofing required for each issuance and rotation / revocation 938 on suspicious activity 940 A.4. Assertion Presentation 942 The assertion presentation component of this vector definition 943 represents distinct categories of assertion which are RECOMMENDED to 944 be used in a subsumptive manner but MAY be used together. Multiple 945 distinct values from this category MAY be used in a single 946 transaction. 948 Aa No protection / unsigned bearer identifier (such as an HTTP 949 session cookie in a web browser) 951 Ab Signed and verifiable assertion, passed through the user agent 952 (web browser) 954 Ac Signed and verifiable assertion, passed through a back channel 956 Ad Assertion encrypted to the relying party's key 958 Appendix B. Document History 960 -13 962 o Added note that normative requirements in appendix apply only to 963 the appendix. 965 o Clarified that trustmark URLs need to be stable over time. 967 o Required trustmark URLs to be served over HTTPS. 969 o Various minor cleanups. 971 -12 973 o Replaced "person" with "individual" to constrain intent. 975 o Clarified component registration guidelines. 977 o Extended Trustmark Provider definition. 979 o Various grammatical cleanups. 981 o Call out "0" as a recommended "empty" value. 983 o Changed trustmark to URL instead of URI. 985 -11 987 o Updated IANA. 989 o Minor language tweaks from AD review. 991 o Removed SAML implementation. 993 -10 995 o Various fixes to respond to AD review. 997 o Added introspection response IANA registration. 999 o Cleaned up IANA entries. 1001 o Removed confusing per-IdP trustmark and discovery sections. 1002 Adopted single trustmark definition instead. 1004 o Added definition of identity federation. 1006 o Added definition of identity proofing. 1008 o Added examples to component sections. 1010 -08 1012 o Incorporated shepherd comments. 1014 o Updated references. 1016 o Added reference to NISTIR 8112. 1018 o Moved default component definitions to appendix. 1020 -07 1022 o Rewrote introduction to clarify focus of document. 1024 -06 1026 o Added section on extensions to VoT. 1028 o Made it so that every component category could be multi-valued. 1030 o Added reference to updated 800-63-3. 1032 o Fixed example text width. 1034 o Switched document back to standards-track from experimental now 1035 that there are extensions in the wild. 1037 -05 1039 o Updated IANA considerations section to include instructions. 1041 o Made security and privacy considerations non-normative. 1043 -04 1045 o Updated SAML example to be consistent. 1047 -03 1049 o Clarified language of LoA's in introduction. 1051 o Added note on operational security in trustmarks. 1053 o Removed empty sections and references. 1055 -02 1057 o Converted C, M, and A values to use letters instead of numbers in 1058 examples. 1060 o Updated SAML to a structured example pending future updates. 1062 o Defined guidance for when to use letters vs. numbers in category 1063 values. 1065 o Restricted category demarcators to uppercase and values to 1066 lowercase and digits. 1068 o Applied clarifying editorial changes from list comments. 1070 - 01 1072 o Added IANA registry for components. 1074 o Added preliminary security considerations and privacy 1075 considerations. 1077 o Split "credential binding" into "primary credential usage" and 1078 "primary credential management". 1080 - 00 1082 o Created initial IETF drafted based on strawman proposal discussed 1083 on VoT list. 1085 o Split vector component definitions into their own section to allow 1086 extension and override. 1088 o Solidified trustmark document definition. 1090 Authors' Addresses 1091 Justin Richer (editor) 1092 Bespoke Engineering 1094 Email: ietf@justin.richer.org 1096 Leif Johansson 1097 Swedish University Network 1098 Thulegatan 11 1099 Stockholm 1100 Sweden 1102 Email: leifj@sunet.se 1103 URI: http://www.sunet.se