idnits 2.17.1 draft-richer-vectors-of-trust-08.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 (March 18, 2018) is 2230 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 712, 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: September 19, 2018 Swedish University Network 6 March 18, 2018 8 Vectors of Trust 9 draft-richer-vectors-of-trust-08 11 Abstract 13 This document defines a mechanism for describing and signaling 14 several aspects that are used to calculate trust placed in a digital 15 identity transaction. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 21 "OPTIONAL" in this document are to be interpreted as described in BCP 22 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 23 appear in all capitals, as shown here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 19, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 63 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7 65 2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 7 66 2.3. Primary Credential Management (M) . . . . . . . . . . . . 7 67 2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8 68 3. Communicating Vector Values to RPs . . . . . . . . . . . . . 8 69 3.1. On the Wire Representation . . . . . . . . . . . . . . . 9 70 3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 9 71 3.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11 73 4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11 74 4.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Defining New Vector Values . . . . . . . . . . . . . . . . . 14 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9.1. Vector Of Trust Components Registry . . . . . . . . . . . 15 81 9.1.1. Registration Template . . . . . . . . . . . . . . . . 15 82 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16 83 9.2. Additions to the OAuth Parameters Registry . . . . . . . 17 84 9.3. Additions to JWT Claims Registry . . . . . . . . . . . . 17 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 12.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Appendix A. Vectors of Trust Default Component Value Definitions 19 91 A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 20 92 A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 20 93 A.3. Primary Credential Management . . . . . . . . . . . . . . 20 94 A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 21 95 Appendix B. Document History . . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 Methods for measuring trust in digital identity transactions have 101 historically fallen into two main categories: either all measurements 102 are combined into a single scalar value, or trust decisions are 103 calculated locally based on a detailed set of attribute metadata. 104 This document defines a method of conveying trust information that is 105 more expressive than a single value but less complex than 106 comprehensive attribute metadata. 108 Prior to the third edition [SP-800-63-3] published in 2017, NIST 109 Special Publication 800-63 [SP-800-63-2] used a single scalar 110 measurement of trust called a Level of Assurance (LoA). An LoA can 111 be used to compare different transactions within a system at a coarse 112 level. For instance, an LoA4 transaction is generally considered 113 more trusted (across all measured categories) than an LoA2 114 transaction. The LoA for a given transaction is computed by the 115 identity provider (IdP) and is consumed by a relying party (RP). 116 Since the trust measurement is a simple numeric value, it's trivial 117 for RPs to process and compare. However, since each LoA encompasses 118 many different aspects of a transaction, it can't express many real- 119 world situations. For instance, an anonymous user account might have 120 a very strong credential, such as would be common of a whistle-blower 121 or political dissident. Despite the strong credential, the lack of 122 identity proofing would make any transactions conducted by the 123 account to fall into a low LoA. Furthermore, different use cases and 124 domains require subtly different definitions for their LoA 125 categories, and one group's LoA2 is not equivalent or even comparable 126 to another group's LoA2. 128 Attribute based access control (ABAC) systems used by RPs may need to 129 know details about a user's attributes, such as how recently the 130 attribute data was verified and by whom. Attribute metadata systems 131 are capable of expressing extremely fine-grained detail about the 132 transaction. However, this approach requires the IdP to collect, 133 store, and transmit all of this attribute data for the RP's 134 consumption. The RP must process this data, which may be prohibitive 135 for trivial security decisions. 137 Vectors of Trust (VoT) seeks a balance between these two alternatives 138 by allowing expression of multiple aspects of an identity transaction 139 (including but not limited to identity proofing, credential strength, 140 credential management, and assertion strength), without requiring 141 full attribute metadata descriptions. This method of measurement 142 gives more actionable data and expressiveness than an LoA, but is 143 still relatively easy for the RP to process. It is anticipated that 144 VoT can be used alongside more detailed attribute metadata systems as 145 has that proposed by NISITIR 8112 [NISTIR-8112]. The RP can use the 146 vector value for most basic decisions but be able to query the IdP 147 for additional attribute metadata where needed. Furthermore, it is 148 anticipated that some trust frameworks will provide a simple mapping 149 between certain sets of vector values to LoAs, for RPs that do not 150 have a need for the vector's more fine-grained detail. In such 151 systems, an RP is given a choice of how much detail it needs in order 152 to process a given request. 154 This document defines a data model for these vectors and an on-the- 155 wire format for conveying them between parties, anchored in a trust 156 definition. This document also provides guidance for defining values 157 for use in conveying this information, including four component 158 categories and guidance on defining values within those categories. 159 Additionally, this document defines a general-purpose set of 160 component values in an appendix (Appendix A) for use cases that do 161 not need something more specific. 163 1.1. Terminology 165 Identity Provider (IdP) A system that manages identity information 166 and is able to assert this information across the network through 167 an identity API. 169 Identity Subject The person (user) engaging in the identity 170 transaction, being identified by the identity provider and 171 identified to the relying party. 173 Primary Credential The means used by the identity subject to 174 authenticate to the identity provider. 176 Federated Credential The assertion presented by the IdP to the RP 177 across the network to authenticate the user. 179 Relying Party (RP) A system that consumes identity information from 180 an IdP for the purposes of authenticating the user. 182 Trust Framework A document containing business rules and legal 183 clauses that defines how different parties in an identity 184 transaction may act. 186 Trustmark A verifiable attestation that a party has proved to follow 187 the constraints of a trust framework. 189 Trustmark Provider A system that issues and provides verification 190 for trustmarks. 192 Vector A multi-part data structure, used here for conveying 193 information about an authentication transaction. 195 Vector Component One of several constituent parts that make up a 196 vector. 198 Vector Component Value One of the values applied to a vector 199 component within a vector. 201 1.2. An Identity Model 203 This document assumes the following model for identity based on 204 identity federation technologies: 206 The identity subject (also known as the user) is associated with an 207 identity provider which acts as a trusted third party on behalf of 208 the user with regard to a relying party by making identity assertions 209 about the user to the relying party. 211 The real-world person represented by the identity subject is in 212 possession of a primary credential bound to the identity subject by 213 the identity provider (or an agent thereof) in such a way that the 214 binding between the credential and the real-world user is a 215 representation of the identity proofing process performed by the 216 identity provider (or an agent thereof) to verify the identity of the 217 real-world person. This is all carried by an identity assertion 218 across the network to the relying party during the authentication 219 transaction. 221 1.3. Component Architecture 223 The term Vectors of Trust is based on the mathematical construct of a 224 vector, which is defined as an item composed of multiple independent 225 values. 227 An important goal for this work is to balance the need for simplicity 228 (particularly on the part of the relying party) with the need for 229 expressiveness. As such, this vector construct is designed to be 230 composable and extensible. 232 All components of the vector construct MUST be orthogonal such that 233 no aspect of a component overlaps an aspect of another component, as 234 much as is possible. 236 2. Component Definitions 238 This specification defines four orthogonal components: identity 239 proofing, primary credential usage, primary credential management, 240 and assertion presentation. These dimensions MUST be evaluated by 241 the RP in the context of a trust framework and SHOULD be combined 242 with other information when making a trust and authorization 243 decision. 245 This specification also defines values for each component to be used 246 in the absence of a more specific trust framework in Appendix A. It 247 is expected that trust frameworks will provide context, semantics, 248 and mapping to legal statutes and business rules for each value in 249 each component. Consequently, a particular vector value can only be 250 compared with vectors defined in the same context. The RP MUST 251 understand and take into account the trust framework context in which 252 a vector is being expressed in order for to process a vector 253 securely. 255 Each component is identified by a demarcator consisting of a single 256 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD 257 reflect the category with which it is associated in a natural manner. 258 Demarcators for components MUST be registered as described in 259 Section 9. It is anticipated that trust framework definitions will 260 use this registry to define specialized components, though it is 261 RECOMMENDED that trust frameworks re-use existing components wherever 262 possible. 264 The value for a given component within a vector of trust is defined 265 by its demarcator character followed by a single digit or lowercase 266 ASCII letter in the range "[0-9a-z]". Categories which have a 267 natural ordering SHOULD use digits, with "0" as the lowest value. 268 Categories which do not have a natural ordering, or which can have an 269 ambiguous ordering, SHOULD use letters. Categories MAY use both 270 letter style and number style value indicators simultaneously. For 271 example, a category could define "0" as a special "empty" value while 272 using letters such as "a", "b", "c" for normal values can to 273 differentiate between these types of options. Another system could 274 have a base category with a numeric value with additonal details 275 provided by letter values. 277 Regardless of the type of value indicator used, the values assigned 278 to each component of a vector MUST NOT be assumed always to have 279 inherent ordinal properties when compared to the same or other 280 components in the vector space. In other words, "1" is different 281 from "2", but it is dangerous to assume that "2" is always better 282 than "1" in a given transaction. 284 Each component MAY be repeated with multiple different values within 285 a single vector. The same component and value combination MUST NOT 286 be repeated within a single vector. 288 2.1. Identity Proofing (P) 290 The Identity Proofing dimension defines, overall, how strongly the 291 set of identity attributes have been verified and vetted. In other 292 words, this dimension describes how likely it is that a given digital 293 identity transaction corresponds to a particular (real-world) 294 identity subject. 296 This dimension SHALL be represented by the "P" demarcator and a 297 single-character level value, such as "P0", "P1", etc. Most 298 definitions of identity proofing will have a natural ordering, as 299 more or less stringent proofing can be applied to an individual. In 300 such cases it is RECOMMENDED that a digit style value be used for 301 this component and that only a single value be allowed to be 302 communicated in a transaction. 304 2.2. Primary Credential Usage (C) 306 The primary credential usage dimension defines how strongly the 307 primary credential can be verified by the IdP. In other words, how 308 easily that credential could be spoofed or stolen. 310 This dimension SHALL be represented by the "C" demarcator and a 311 single-character level value, such as "Ca", "Cb", etc. Most 312 definitions of credential usage will not have an overall natural 313 ordering, as there may be several equivalent classes described within 314 a trust framework. In such cases it is RECOMMENDED that a letter 315 style value be used for this component and that multiple distinct 316 credential usage factors be allowed to be communicated 317 simultaneously, such as when Multi-Factor Authentication is used. 319 2.3. Primary Credential Management (M) 321 The primary credential management dimension conveys information about 322 the expected lifecycle of the primary credential in use, including 323 its binding, rotation, and revocation. In other words, the use and 324 strength of policies, practices, and security controls used in 325 managing the credential at the IdP and its binding to the intended 326 individual. 328 This dimension SHALL be represented by the "M" demarcator and a 329 single-character level value, such as "Ma", "Mb", etc. Most 330 definitions of credential management will not have an overall natural 331 ordering, though there can be preference and comparison between 332 values in some circumstances. In such cases it is RECOMMENDED that a 333 letter style value be used for this component and that multiple 334 distinct values be allowed to be communicated simultaneously. 336 2.4. Assertion Presentation (A) 338 The Assertion Presentation dimension defines how well the given 339 digital identity can be communicated across the network without 340 information leaking to unintended parties, and without spoofing. In 341 other words, this dimension describes how likely it is that a given 342 digital identity was actually asserted by a given identity provider 343 for a given transaction. While this information is largely already 344 known by the RP as a side effect of processing an identity assertion, 345 this dimension is still very useful when the RP requests a login 346 (Section 4) and when describing the capabilities of an IdP 347 (Section 6). 349 This dimension SHALL be represented by the "A" demarcator and a level 350 value, such as "Aa", "Ab", etc. Most definitions of assertion 351 presentation will not have an overall natural ordering. In such 352 cases, it is RECOMMENDED that a letter style value be used for this 353 component and that multiple values be allowed to be communicated 354 simultaneously. 356 3. Communicating Vector Values to RPs 358 A vector of trust is designed to be used in the context of an 359 identity and authentication transaction, providing information about 360 the context of a federated credential. The vector therefore needs to 361 be able to be communicated in the context of the federated credential 362 in a way that is strongly bound to the assertion representing the 363 federated credential. 365 This vector has several requirements for use. 367 o All applicable vector components and values need to be combined 368 into a single vector. 370 o The vector can be communicated across the wire unbroken and 371 untransformed. 373 o All vector components need to remain individually available, not 374 "collapsed" into a single value. 376 o The vector needs to be protected in transit. 378 o The vector needs to be cryptographically bound to the assertion 379 which it is describing. 381 o The vector needs to be interpreted in the context of a specific 382 trust framework definition. 384 These requirements lead us to defining a simple string-based 385 representation of the vector that can be incorporated within a number 386 of different locations and protocols without further encoding. 388 3.1. On the Wire Representation 390 The vector MUST be represented as a period-separated ('.') list of 391 vector components, with no specific order. A vector component type 392 MAY occur multiple times within a single vector, with each component 393 separated by periods. Multiple values for a component are considered 394 a logical AND of the values. A specific value of a vector component 395 MUST NOT occur more than once in a single vector. That is, while 396 "Cc.Cd" is a valid vector, "Cc.Cc" is not. 398 Vector components MAY be omitted from a vector. No holding space is 399 left for an omitted vector component. If a vector component is 400 omitted, the vector is making no claim for that component. This MAY 401 be distinct from a specific component value stating that a component 402 was not used. 404 Vector values MUST be communicated along side of a trustmark 405 definition to give the components context. The trustmark MUST be 406 cryptographically bound to the vector value, such as in a signed 407 assertion. A vector value without context is unprocessable, and 408 vectors defined in different contexts are not directly comparable as 409 whole values. Different trustmarks MAY re-use component definitions 410 (including their values), allowing comparison of individual 411 components across contexts without requiring complete understanding 412 of all aspects of a context. The proper processing of such cross- 413 context values is outside the scope of this specification. 415 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous, 416 proof of shared key, signed browser-passed verified assertion, and no 417 claim made toward credential management" in the context of this 418 specification's definitions (Appendix A). The vector value of 419 "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for 420 issuance and rotation, cryptographic proof of possession of a shared 421 key, signed back-channel verified assertion, and no claim made toward 422 identity proofing" in the same context. 424 3.2. In OpenID Connect 426 In OpenID Connect [OpenID], the IdP MUST send the vector as a string 427 within the "vot" (vector of trust) claim in the ID token. The 428 trustmark (Section 5) that applies to this vector MUST be sent as an 429 HTTPS URL in the "vtm" (vector trust mark) claim to provide context 430 to the vector. 432 For example, the body of an ID token claiming "pseudonymous, proof of 433 shared key, signed back-channel verified token, and no claim made 434 toward credential management" could look like this JSON object 435 payload of the ID token. 437 { 438 "iss": "https://idp.example.com/", 439 "sub": "jondoe1234", 440 "vot": "P1.Cc.Ac", 441 "vtm": "https://trustmark.example.org/trustmark/idp.example.com" 442 } 444 The body of the ID token is signed and optionally encrypted using 445 JOSE, as per the OpenID Connect specification. By putting the "vot" 446 and "vtm" values inside the ID token, the vector and its context are 447 strongly bound to the federated credential represented by the ID 448 token. 450 3.3. In SAML 452 In SAML, a vector is communicated as an 453 "AuthenticationContextDeclRef". A vector is represented by prefixing 454 it with the "urn urn:ietf:param:[TBD]" to form a full URN. The 455 "AuthenticationContextDeclaration" corresponding to a given vector is 456 a "AuthenticationContextDeclaration" element containing an 457 "Extension" element with components of the vector represented by the 458 following XML schema: 460 461 465 466 This represents a set of 467 vector components. 468 469 470 471 472 473 474 475 477 For instance the vector P1.Cc.Ac is represented by the 478 AuthenticationContextDeclRef URN "urn:ietf:param:[TBD]:P1.Cc.Ac" (or 479 "urn:ietf:param:[TBD]:Cc.P1.Ac" or ...) which corresponds to the 480 following "AuthenticationContextDeclaration": 482 483 485 486 P1.Cc.Ac 487 488 490 4. Requesting Vector Values 492 In some identity protocols, the RP can request that particular vector 493 components be applied to a given identity transaction. Using the 494 same syntax as defined in Section 3.1, an RP can indicate that it 495 desires particular aspects be present in the authentication. 496 Processing and fulfillment of these requests are in the purview of 497 the IdP and details are outside the scope of this specification. 499 4.1. In OpenID Connect 501 In OpenID Connect [OpenID], the client MAY request a set of 502 acceptable VoT values with the "vtr" (vector of trust request) claim 503 request as part of the Request Object. The value of this field is an 504 array of JSON strings, each string identifying an acceptable set of 505 vector components. The component values within each vector are ANDed 506 together while the separate vectors are ORed together. For example, 507 a list of vectors in the form "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating 508 that either the full set of "P1 AND Cb AND Cc AND Ab" simultaneously 509 OR the full set of "Ce AND Ab" simultaneously are acceptable to this 510 RP for this transaction. 512 Vector request values MAY omit components, indicating that any value 513 is acceptable for that component category, including omission of that 514 component in the response vector. 516 The mechanism by which the IdP processes the "vtr" and maps that to 517 the authentication transaction are out of scope of this 518 specification. 520 4.2. In SAML 522 In SAML (Section 3.3) the client can request a set of acceptable VoT 523 values by including the corresponding "AuthenticationContextDeclRef" 524 URIs together with an "AuthenticationContextClassRef" corresponding 525 to the trust mark (cf below). The processing rules in Section 3.3 526 apply. 528 5. Trustmark 530 When an RP receives a specific vector from an IdP, it needs to make a 531 decision to trust the vector within a specific context. A trust 532 framework can provide such a context, allowing legal and business 533 rules to give weight to an IdP's claims. A trustmark is a verifiable 534 claim to conform to a specific component of a trust framework, such 535 as a verified identity provider. The trustmark conveys the root of 536 trustworthiness about the claims and assertions made by the IdP, 537 including the vector itself. 539 The trustmark MUST be available from an HTTPS URL served by the trust 540 framework provider. The contents of this URL are a JSON [RFC8259] 541 document with the following fields: 543 idp The issuer URL of the identity provider that this trustmark 544 pertains to. This MUST match the corresponding issuer claim in 545 the identity token, such as the OpenID Connect "iss" field. This 546 MUST be an HTTPS URL. 548 trustmark_provider The issuer URL of the trustmark provider that 549 issues this trustmark. The URL that a trustmark is fetched from 550 MUST start with the "iss" URL in this field. This MUST be an 551 HTTPS URL. 553 Vector component values offered by this IdP are be listed in a using 554 their demarcator. For the four component categories defined in this 555 specification: 557 P Array of strings containing identity proofing values for which the 558 identity provider has been assessed and approved. 560 C Array of strings containing primary credential usage values for 561 which the identity provider has been assessed and approved. 563 M Array of strings containing primary credential management values 564 for which the identity provider has been assessed and approved. 566 A Array of strings containing assertion strength values for which 567 the identity provider has been assessed and approved. 569 For example, the following trustmark provided by the 570 trustmark.example.org organization applies to the idp.example.org 571 identity provider: 573 { 574 "idp": "https://idp.example.org/", 575 "trustmark_provider": "https://trustmark.example.org/", 576 "P": ["P0", "P1"], 577 "C": ["C0", "Ca", "Cb"], 578 "M": ["Mb"], 579 "A": ["Ab", "Ac"] 580 } 582 An RP wishing to check the claims made by an IdP can fetch the 583 information from the trustmark provider about what claims the IdP is 584 allowed to make in the first place and process them accordingly. The 585 RP MAY cache the information returned from the trustmark URL. 587 The operational aspects of the IdP MAY be included in the trustmark 588 definition. For example, if a trustmark can indicate that an IdP 589 uses multiple redundant hosts, encrypts all data at rest, or other 590 operational security mechanisms that affect the trustworthiness of 591 assertions made by the IdP. The definition of these additional 592 aspects is outside the scope of this specfication. 594 The means by which the RP decides which trustmark providers it trusts 595 is out of scope for this specification and is generally configured 596 out of band. 598 Though most trust frameworks will provide a third-party independent 599 verification service for components, an IdP MAY host its own 600 trustmark. For example, a self-hosted trustmark would look like: 602 { 603 "idp": "https://idp.example.org/", 604 "trustmark_provider": "https://idp.example.org/", 605 "P": ["P0", "P1"], 606 "C": ["C0", "Ca", "Cb"], 607 "M": ["Mb"], 608 "A": ["Ab", "Ac"] 609 } 611 6. Discovery 613 The IdP MAY list all of its available trustmarks as part of its 614 discovery document, such as the OpenID Connect Discovery server 615 configuration document. In this context, trustmarks are listed in 616 the "trustmarks" element which contains a single JSON [RFC8259] 617 object. The keys of this JSON object are trustmark provider issuer 618 URLs and the values of this object are the corresponding trustmark 619 URLs for this IdP. 621 { 622 "iss": "https://idp.example.org/", 623 "trustmarks": { 624 "https://trustmark.example.org/": 625 "https://trustmark.example.org/trustmark/idp.example.org", 626 "https://trust.example.net/": 627 "https://trust.example.net/trustmark/idp.example.org" 628 } 629 } 631 7. Defining New Vector Values 633 Vectors of Trust is meant to be a flexible and reusable framework for 634 communicating authentication data between networked parties in an 635 identity federation protocol. However, the exact nature of the 636 information needed is reliant on the parties requiring the 637 information and the relationship between them. While this document 638 does define a usable default set of values in Appendix A, it is 639 anticipated that many situations will require an extension of this 640 specification for their own use. 642 Components categories such as those defined in Section 2 are intended 643 to be general purpose and reusable in a variety of circumstances. 644 Extension specifications SHOULD re-use existing category definitions 645 where possible. Extensions MAY create additional categories where 646 needed by using the registry defined in Section 9. The registry 647 encourages re-use and discovery of existing categories across 648 different implementations. In other words, the "P" category in 649 another framework SHOULD be used for identity proofing and related 650 information. 652 The values of components such as those defined in Appendix A are 653 intended to be contextual to the defining trust document. While this 654 specification's component values are intended to be general-purpose 655 and extensions MAY re-use the values and their definitions, 656 extensions MUST define all allowable values. As these values are 657 always interpreted in the context of a trustmark, these values are 658 not recorded in a central registry. Consequently, a "P1" value from 659 one framework and a "P1" value from another framework could have very 660 different interpretations depending on their contextual trustmark 661 documents. 663 Extensions to this specification SHOULD choose either a numerical 664 ordering or a group category approach to component values as 665 described in Section 2, though combinations of both types MAY be 666 used. Extensions to this specification MUST specify whether multiple 667 values are allowed for each category, and while any component 668 category is generally allowed to have multiple distinct values, a 669 specific definition of a set of values in an extension MAY limit a 670 given component category to a single value per transaction. 672 8. Acknowledgements 674 The authors would like to thank the members of the Vectors of Trust 675 mailing list in the IETF for discussion and feedback on the concept 676 and document, and the members of the ISOC Trust and Identity team for 677 their support. 679 9. IANA Considerations 681 This specification creates one registry and registers several values 682 into existing registries. 684 9.1. Vector Of Trust Components Registry 686 This specification establishes the Vectors of Trust Components 687 Registry. 689 Component demarcators are registered by Specification Required 690 [RFC8126] after a two-week review period on the vot@ietf.org mailing 691 list, on the advice of one or more Designated Experts. 693 Criteria that should be applied by the Designated Experts includes 694 determining whether the proposed registration duplicates existing 695 functionality, whether it is likely to be of general applicability or 696 whether it is useful only for a single application, and whether the 697 registration description is clear. 699 Registration requests sent to the mailing list for review should use 700 an appropriate subject (e.g., "Request to register Vector of Trust 701 Component name: example"). Within the review period, the Designated 702 Expert(s) will either approve or deny the registration request, 703 communicating this decision to the review list and IANA. Denials 704 should include an explanation and, if applicable, suggestions as to 705 how to make the request successful. IANA must only accept registry 706 updates from the Designated Expert(s) and should direct all requests 707 for registration to the review mailing list. 709 9.1.1. Registration Template 711 Demarcator Symbol 712 An uppercase ASCII letter in the range [A-Z] representing this 713 component (e.g., "X"). 715 Description: 716 Brief description of the component (e.g., "Example description"). 718 Change controller: 719 For Standards Track RFCs, state "IESG". For other documents, give 720 the name of the responsible party. Other details (e.g., postal 721 address, email address, home page URI) may also be included. 723 Specification document(s): 724 Reference to the document(s) that specify the token endpoint 725 authorization method, preferably including a URI that can be used 726 to retrieve a copy of the document(s). An indication of the 727 relevant sections may also be included but is not required. 729 9.1.2. Initial Registry Contents 731 The Vector of Trust Components Registry contains the definitions of 732 vector components and their associated demarcators. 734 o Demarcator Symbol: P 736 o Description: Identity proofing 738 o Change Controller: IESG 740 o Specification document(s):: [[ this document ]] 742 o Demarcator Symbol: C 744 o Description: Primary credential usage 746 o Change Controller: IESG 748 o Specification document(s):: [[ this document ]] 750 o Demarcator Symbol: M 752 o Description: Primary credential management 754 o Change Controller: IESG 756 o Specification document(s):: [[ this document ]] 758 o Demarcator Symbol: A 760 o Description: Assertion presentation 762 o Change Controller: IESG 764 o Specification document(s):: [[ this document ]] 766 9.2. Additions to the OAuth Parameters Registry 768 This specification adds the following values to the OAuth Parameters 769 Registry established by [RFC6749]. 771 o Demarcator Symbol: vtr 773 o Description: Vector of Trust request 775 o Change Controller: IESG 777 o Document: [[ this document ]] 779 9.3. Additions to JWT Claims Registry 781 This specification adds the following values to the JSON Web Token 782 Claims Registry established by [RFC7519]. 784 o Claim name: vot 786 o Description: Vector of Trust value 788 o Change Controller: IESG 790 o Document: [[ this document ]] 792 o Demarcator Symbol: vtm 794 o Description: Vector of Trust trustmark 796 o Change Controller: IESG 798 o Document: [[ this document ]] 800 10. Security Considerations 802 The vector of trust value MUST be cryptographically protected in 803 transit, using TLS as described in [BCP195]. The vector of trust 804 value must be associated with a trustmark marker, and the two must be 805 carried together in a cryptographically bound mechanism such as a 806 signed identity assertion. A signed OpenID Connect ID Token and a 807 signed SAML assertion both fulfil this requirement. 809 The vector value is always associated with a trustmark and needs to 810 be interpreted by the RP in the context of that trustmark. Different 811 trust frameworks can apply different interpretations to the same 812 component value, much as was the case with LoA. Therefore, an RP 813 interpreting a component value in the the wrong context could 814 mistakenly accept or reject a request. In order to avoid this 815 mistake, RPs need to reject vectors that are defined in trust 816 frameworks that they do not understand how to interpret properly. 818 The VoT framework provides a mechanism for describing and conveying 819 trust information. It does not define any policies for asserting the 820 values of the vector, nor does it define any policies for applying 821 the values of a vector to an RP's security decision process. These 822 policies must be agreed upon by the IdP and RP, and they should be 823 expressed in detail in an associated human-readable trust framework 824 document. 826 11. Privacy Considerations 828 By design, vector of trust values contain information about the 829 user's authentication and associations that can be made thereto. 830 Therefore, all aspects of a vector of trust contain potentially 831 privacy-sensitive information and must be guarded as such. Even in 832 the absence of specific attributes about a user, knowledge that the 833 user has been highly proofed or issued a strong token could provide 834 more information about the user than was intended. It is recommended 835 that systems in general use the minimum vectors applicable to their 836 use case in order to prevent inadvertent information disclosure. 838 12. References 840 12.1. Normative References 842 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 843 Core 1.0", November 2014. 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, 847 DOI 10.17487/RFC2119, March 1997, 848 . 850 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 851 RFC 6749, DOI 10.17487/RFC6749, October 2012, 852 . 854 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 855 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 856 . 858 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 859 Writing an IANA Considerations Section in RFCs", BCP 26, 860 RFC 8126, DOI 10.17487/RFC8126, June 2017, 861 . 863 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 864 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 865 May 2017, . 867 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 868 Interchange Format", STD 90, RFC 8259, 869 DOI 10.17487/RFC8259, December 2017, 870 . 872 12.2. Informative References 874 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 875 "Recommendations for Secure Use of Transport Layer 876 Security (TLS) and Datagram Transport Layer Security 877 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 878 2015, . 880 [NISTIR-8112] 881 National Institute of Standards and Technology, U.S. 882 Department of Commerce, "A Proposed Schema for Evaluating 883 Federated Attributes", NIST NISTIR 8112, January 2018, 884 . 886 [SP-800-63-2] 887 National Institute of Standards and Technology, U.S. 888 Department of Commerce, "Electronic Authentication 889 Guideline", NIST SP 800-63-2, 890 DOI 10.6028/NIST.SP.800-63-2, August 2013, 891 . 893 [SP-800-63-3] 894 National Institute of Standards and Technology, U.S. 895 Department of Commerce, "Digital Identity Guideline", 896 NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017, 897 . 899 Appendix A. Vectors of Trust Default Component Value Definitions 901 The following general-purpose component definitions MAY be used when 902 a more specific set is unavailable. These component values are 903 referenced in a trustmark definition defined by [[ this document URL 904 ]]. 906 Extensions of this specification SHOULD define their own component 907 values as described in Section 7. Where possible, extensions MAY re- 908 use specific values here. 910 A.1. Identity Proofing 912 The identity proofing component of this vector definition represents 913 increasing scrutiny during the proofing process. Higher levels are 914 largely subsumptive of lower levels, such that "P2" fulfills 915 requirements for "P1", etc. Mutltiple distinct values from this 916 category MUST NOT be used in a single transaction. 918 P0 No proofing is done, data is not guaranteed to be persistent 919 across sessions 921 P1 Attributes are self-asserted but consistent over time, potentially 922 pseudonymous 924 P2 Identity has been proofed either in person or remotely using 925 trusted mechanisms (such as social proofing) 927 P3 There is a binding relationship between the identity provider and 928 the identified party (such as signed/notarized documents, 929 employment records) 931 A.2. Primary Credential Usage 933 The primary credential usage component of this vector definition 934 represents distinct categories of primary credential that MAY be used 935 together in a single transaction. Multiple distinct values from this 936 category MAY be used in a single transaction. 938 C0 No credential is used / anonymous public service 940 Ca Simple session HTTP cookies (with nothing else) 942 Cb Known device 944 Cc Shared secret such as a username and password combination 946 Cd Cryptographic proof of key possession using shared key 948 Ce Cryptographic proof of key possession using asymmetric key 950 Cf Sealed hardware token / trusted biometric / TPM-backed keys 952 A.3. Primary Credential Management 954 The primary credential management component of this vector definition 955 represents distinct categories of management that MAY be considered 956 separately or together in a single transaction. Many trust framework 957 deployments MAY use a single value for this component as a baseline 958 for all transactions and thereby omit it. Multiple distinct values 959 from this category MAY be used in a single transaction. 961 Ma Self-asserted primary credentials (user chooses their own 962 credentials and must rotate or revoke them manually) / no 963 additional verification for primary credential issuance or 964 rotation 966 Mb Remote issuance and rotation / use of backup recover credentials 967 (such as email verification) / deletion on user request 969 Mc Full proofing required for each issuance and rotation / revocation 970 on suspicious activity 972 A.4. Assertion Presentation 974 The assertion presentation component of this vector definition 975 represents distinct categories of assertion which are RECOMMENDED to 976 be used in a subsumptive manner but MAY be used together. Multiple 977 distinct values from this category MAY be used in a single 978 transaction. 980 Aa No protection / unsigned bearer identifier (such as an HTTP 981 session cookie in a web browser) 983 Ab Signed and verifiable assertion, passed through the user agent 984 (web browser) 986 Ac Signed and verifiable assertion, passed through a back channel 988 Ad Assertion encrypted to the relying parties key and audience 989 protected 991 Appendix B. Document History 993 -08 995 o Incorporated shepherd comments. 997 o Updated references. 999 o Added reference to NISTIR 8112. 1001 o Moved default component definitions to appendix. 1003 -07 1005 o Rewrote introduction to clarify focus of document. 1007 -06 1009 o Added section on extensions to VoT. 1011 o Made it so that every component category could be multi-valued. 1013 o Added reference to updated 800-63-3. 1015 o Fixed example text width. 1017 o Switched document back to standards-track from experimental now 1018 that there are extensions in the wild. 1020 -05 1022 o Updated IANA considerations section to include instructions. 1024 o Made security and privacy considerations non-normative. 1026 -04 1028 o Updated SAML example to be consistent. 1030 -03 1032 o Clarified language of LoA's in introduction. 1034 o Added note on operational security in trustmarks. 1036 o Removed empty sections and references. 1038 -02 1040 o Converted C, M, and A values to use letters instead of numbers in 1041 examples. 1043 o Updated SAML to a structured example pending future updates. 1045 o Defined guidance for when to use letters vs. numbers in category 1046 values. 1048 o Restricted category demarcators to uppercase and values to 1049 lowercase and digits. 1051 o Applied clarifying editorial changes from list comments. 1053 - 01 1054 o Added IANA registry for components. 1056 o Added preliminary security considerations and privacy 1057 considerations. 1059 o Split "credential binding" into "primary credential usage" and 1060 "primary credential management". 1062 - 00 1064 o Created initial IETF drafted based on strawman proposal discussed 1065 on VoT list. 1067 o Split vector component definitions into their own section to allow 1068 extension and override. 1070 o Solidified trustmark document definition. 1072 Authors' Addresses 1074 Justin Richer (editor) 1075 Bespoke Engineering 1077 Email: ietf@justin.richer.org 1079 Leif Johansson 1080 Swedish University Network 1081 Thulegatan 11 1082 Stockholm 1083 Sweden 1085 Email: leifj@sunet.se 1086 URI: http://www.sunet.se