idnits 2.17.1 draft-richer-vectors-of-trust-04.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 29 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 16, 2017) is 2651 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'A-Z' is mentioned on line 531, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Richer, Ed. 3 Internet-Draft Bespoke Engineering 4 Intended status: Experimental L. Johansson 5 Expires: July 20, 2017 Swedish University Network 6 January 16, 2017 8 Vectors of Trust 9 draft-richer-vectors-of-trust-04 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 RFC 22 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 20, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5 61 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 62 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 5 63 2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6 64 2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 7 65 2.3. Primary Credential Management . . . . . . . . . . . . . . 7 66 2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 7 67 3. Vectors of Trust Initial Component Value Definitions . . . . 8 68 3.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 8 69 3.2. Primary Credential Usage . . . . . . . . . . . . . . . . 8 70 3.3. Primary Credential Management . . . . . . . . . . . . . . 9 71 3.4. Assertion Presentation . . . . . . . . . . . . . . . . . 9 72 4. Communicating Vector Values to RPs . . . . . . . . . . . . . 10 73 4.1. On the Wire Representation . . . . . . . . . . . . . . . 10 74 4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11 75 4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 12 77 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12 78 5.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Vector Of Trust Components Registry . . . . . . . . . . . 15 84 9.2. Additions to JWT Claims Registry . . . . . . . . . . . . 16 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 89 12.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Appendix A. Document History . . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 This document defines a mechanism for measuring and signaling several 96 aspects of digital identity and authentication transactions that are 97 used to determine a level of trust in that transaction. In the past, 98 there have been two extremes of communicating authentication 99 transaction information. 101 At one extreme, all attributes can be communicated with full 102 provenance and associated trust markings. This approach seeks to 103 create a fully-distributed attribute system to support functions such 104 as attribute based access control (ABAC). These attributes can be 105 used to describe the end user, the identity provider, the relying 106 party, or even the transaction itself. While the information that 107 can be expressed in this model is incredibly detailed and robust, the 108 complexity of such a system is often prohibitive to realize, 109 especially across security domains. In particular, a large burden is 110 placed on relying parties needing to process the sea of disparate 111 attributes when making a security decision. 113 At the other extreme there are systems that collapse all of the 114 attributes and aspects into a single scalar value that communicates, 115 in sum, how much a transaction can be trusted. The NIST special 116 publication 800-63 [SP-800-63-2] version 2 defines a linear scale 117 Level of Assurance (LoA) measure that combines multiple attributes 118 about an identity transaction into such a single measure. While this 119 definition was originally narrowly targeted for a specific set of 120 government use cases, the LoA scale appeared to be applicable with a 121 wide variety of authentication scenarios in different domains. This 122 has led to a proliferation of incompatible interpretations of the 123 same scale in different contexts, preventing interoperability between 124 each LoA definition in spite of their common measurement. LoA is 125 artificially limited due to the original goal of creating a single 126 linear scale. Since identity proofing strength increases linearly 127 along with credential strength in the LoA scale, this scale is too 128 limited for describing many valid and useful forms of an identity 129 transaction that do not fit the government's original model. For 130 example, an anonymously assigned hardware token can be used in cases 131 where the real world identity of the subject cannot be known for 132 privacy reasons, but the credential itself can be highly trusted. 133 This is in contrast with a government employee accessing a government 134 system, where the identity of the individual would need to be highly 135 proofed and strongly credentialed at the same time. 137 The Vectors of Trust (VoT) effort seeks to find a balance between 138 these two extremes by creating a data model that combines attributes 139 of the user and aspects of the authentication context into several 140 values that can be communicated separately but in parallel with each 141 other. This approach is both coarser grained than the distributed 142 attributes model and finer grained than the single scalar model, with 143 the hope that it is a viable balance of expressibility and 144 processability. Importantly, these three levels of granularity can 145 be mapped to each other. The information of several attributes can 146 be folded into a vector component, while the vector itself can be 147 folded into an assurance category. As such, the vectors of trust 148 seeks to complement, not replace, these other identity and trust 149 mechanisms in the larger identity ecosystem while providing a single 150 value for RPs to process. 152 1.1. Terminology 154 Identity Provider (IdP) A system that manages identity information 155 and is able to assert this information across the network through 156 an identity API. 158 Identity Subject The person (user) engaging in the identity 159 transaction, being identified by the identity provider and 160 identified to the relying party. 162 Primary Credential The means used by the identity subject to 163 authenticate to the identity provider. 165 Federated Credential The assertion presented by the IdP to the RP 166 across the network to authenticate the user. 168 Relying Party (RP) A system that consumes identity information from 169 an IdP for the purposes of authenticating the user. 171 Trust Framework A document containing business rules and legal 172 clauses that defines how different parties in an identity 173 transaction may act. 175 Trustmark A verifiable attestation that a party has proved to follow 176 the constraints of a trust framework. 178 Trustmark Provider A system that issues and provides verification 179 for trustmarks. 181 Vector A multi-part data structure, used here for conveying 182 information about an authentication transaction. 184 Vector Component One of several constituent parts that make up a 185 vector. 187 1.2. An Identity Model 189 This document assumes the following model for identity based on 190 identity federation technologies: 192 The identity subject (also known as the user) is associated with an 193 identity provider which acts as a trusted third party on behalf of 194 the user with regard to a relying party by making identity assertions 195 about the user to the relying party. 197 The real-world person represented by the identity subject is in 198 possession of a primary credential bound to the identity subject by 199 the identity provider (or an agent thereof) in such a way that the 200 binding between the credential and the real-world user is a 201 representation of the identity proofing process performed by the 202 identity provider (or an agent thereof) to verify the identity of the 203 real-world person. This is all carried by an identity assertion 204 across the network to the relying party during the authentication 205 transaction. 207 1.3. Component Architecture 209 The term Vectors of Trust is based on the mathematical construct of a 210 vector, which is defined as an item composed of multiple independent 211 values. 213 An important goal for this work is to balance the need for simplicity 214 (particularly on the part of the relying party) with the need for 215 expressiveness. As such, this vector construct is designed to be 216 composable and extensible. 218 All components of the vector construct MUST be orthogonal such that 219 no aspect of a component overlaps an aspect of another component, as 220 much as is possible. 222 2. Component Definitions 224 This specification defines four orthogonal components: identity 225 proofing, primary credential usage, primary credential management, 226 and assertion presentation. These dimensions MUST be evaluated by 227 the RP in the context of a trust framework and SHOULD be combined 228 with other information when making a trust and authorization 229 decision. 231 This specification also defines values for each component to be used 232 in the absence of a more specific trust framework in Section 3. It 233 is expected that trust frameworks will provide context, semantics, 234 and mapping to legal statutes and business rules for each value in 235 each component. Consequently, a particular vector value can only be 236 compared with vectors defined in the same context. The RP MUST 237 understand and take into account the trust framework context in which 238 a vector is being expressed in order for it to be processed securely. 240 Each component is identified by a demarcator consisting of a single 241 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD 242 reflect the category with which it is associated in a natural manner. 243 Demarcators for components MUST be registered as described in 244 Section 9. It is anticipated that trust framework definitions will 245 use this registry to define specialized components, though it is 246 RECOMMENDED that trust frameworks re-use existing components wherever 247 possible. 249 The value for a given component within a vector of trust is defined 250 by its demarcator character followed by a single digit or lowercase 251 ASCII letter in the range "[0-9a-z]". Categories which have a 252 natural ordering SHOULD use digits, with "0" as the lowest value. 253 Categories which do not have a natural ordering, or which can have an 254 ambiguous ordering, SHOULD use letters. Categories MAY use both 255 letter style and number style value indicators. For example, a 256 category could define "0" as a special "empty" value while using 257 letters such as "a", "b", "c" for normal values can to differentiate 258 between these types of options. 260 Regardless of the type of value indicator used, the values assigned 261 to each component of a vector MUST NOT be assumed always to have 262 inherent ordinal properties when compared to the same or other 263 components in the vector space. In other words, "1" is different 264 from "2", but it is dangerous to assume that "2" is always better 265 than "1" in a given transaction. 267 2.1. Identity Proofing 269 The Identity Proofing dimension defines, overall, how strongly the 270 set of identity attributes have been verified and vetted. In other 271 words, this dimension describes how likely it is that a given digital 272 identity transaction corresponds to a particular (real-world) 273 identity subject. 275 This dimension SHALL be represented by the "P" demarcator and a 276 single-character level value, such as "P0", "P1", etc. Most 277 definitions of identity proofing will have a natural ordering, as 278 more or less stringent proofing can be applied to an individual. In 279 such cases it is RECOMMENDED that a digit style value be used for 280 this component. 282 2.2. Primary Credential Usage 284 The primary credential usage dimension defines how strongly the 285 primary credential can be verified by the IdP. In other words, how 286 easily that credential could be spoofed or stolen. 288 This dimension SHALL be represented by the "C" demarcator and a 289 single-character level value, such as "Ca", "Cb", etc. Most 290 definitions of credential usage will not have an overall natural 291 ordering, as there may be several equivalent classes described within 292 a trust framework. In such cases it is RECOMMENDED that a letter 293 style value be used for this component. Multiple credential usage 294 factors MAY be communicated simultaneously, such as when Multi-Factor 295 Authentication is used. 297 2.3. Primary Credential Management 299 The primary credential management dimension conveys information about 300 the expected lifecycle of the primary credential in use, including 301 its binding, rotation, and revocation. In other words, the use and 302 strength of policies, practices, and security controls used in 303 managing the credential at the IdP and its binding to the intended 304 individual. 306 This dimension SHALL be represented by the "M" demarcator and a 307 single-character level value, such as "Ma", "Mb", etc. Most 308 definitions of credential management will not have an overall natural 309 ordering, though there can be preference and comparison between 310 values in some circumstances. In such cases it is RECOMMENDED that a 311 letter style value be used for this component. 313 2.4. Assertion Presentation 315 The Assertion Presentation dimension defines how well the given 316 digital identity can be communicated across the network without 317 information leaking to unintended parties, and without spoofing. In 318 other words, this dimension describes how likely it is that a given 319 digital identity was actually asserted by a given identity provider 320 for a given transaction. While this information is largely already 321 known by the RP as a side effect of processing an identity assertion, 322 this dimension is still very useful when the RP requests a login 323 (Section 5) and when describing the capabilities of an IdP 324 (Section 7). 326 This dimension SHALL be represented by the "A" demarcator and a level 327 value, such as "Aa", "Ab", etc. Most definitions of assertion 328 presentation will not have an overall natural ordering. In such 329 cases, it is RECOMMENDED that a letter style value be used for this 330 component. 332 3. Vectors of Trust Initial Component Value Definitions 334 This specification defines the following general-purpose component 335 definitions, which MAY be used when a more specific set is 336 unavailable. These component values are referenced in a trustmark 337 definition defined by [[ this document URL ]]. 339 It is anticipated that trust frameworks and specific applications of 340 this specification will define their own component values. In order 341 to simplify processing by RPs, it is RECOMMENDED that trust framework 342 definitions carefully define component values such that they are 343 mutually exclusive or subsumptive in order to avoid repeated vector 344 components where possible. 346 3.1. Identity Proofing 348 The identity proofing component of this vector definition represents 349 increasing scrutiny during the proofing process. Higher levels are 350 largely subsumptive of lower levels, such that "P2" fulfills 351 requirements for "P1", etc. 353 P0 No proofing is done, data is not guaranteed to be persistent 354 across sessions 356 P1 Attributes are self-asserted but consistent over time, potentially 357 pseudonymous 359 P2 Identity has been proofed either in person or remotely using 360 trusted mechanisms (such as social proofing) 362 P3 There is a binding relationship between the identity provider and 363 the identified party (such as signed/notarized documents, 364 employment records) 366 3.2. Primary Credential Usage 368 The primary credential usage component of this vector definition 369 represents distinct categories of primary credential that MAY be used 370 together in a single transaction. 372 C0 No credential is used / anonymous public service 374 Ca Simple session cookies (with nothing else) 376 Cb Known device 377 Cc Shared secret such as a username and password combination 379 Cd Cryptographic proof of key possession using shared key 381 Ce Cryptographic proof of key possession using asymmetric key 383 Cf Sealed hardware token / trusted biometric / TPM-backed keys 385 3.3. Primary Credential Management 387 The primary credential management component of this vector definition 388 represents distinct categories of management that MAY be considered 389 separately or together in a single transaction. Many trust framework 390 deployments MAY use a single value for this component as a baseline 391 for all transactions and thereby omit it. 393 Ma Self-asserted primary credentials (user chooses their own 394 credentials and must rotate or revoke them manually) / no 395 additional verification for primary credential issuance or 396 rotation 398 Mb Remote issuance and rotation / use of backup recover credentials 399 (such as email verification) / deletion on user request 401 Mc Full proofing required for each issuance and rotation / revocation 402 on suspicious activity 404 3.4. Assertion Presentation 406 The assertion presentation component of this vector definition 407 represents distinct categories of assertion which are RECOMMENDED to 408 be used in a subsumptive manner but MAY be used together. 410 Aa No protection / unsigned bearer identifier (such as a session 411 cookie in a web browser) 413 Ab Signed and verifiable assertion, passed through the user agent 414 (web browser) 416 Ac Signed and verifiable assertion, passed through a back channel 418 Ad Assertion encrypted to the relying parties key and audience 419 protected 421 4. Communicating Vector Values to RPs 423 A vector of trust is designed to be used in the context of an 424 identity and authentication transaction, providing information about 425 the context of a federated credential. The vector therefore needs to 426 be able to be communicated in the context of the federated credential 427 in a way that is strongly bound to the assertion representing the 428 federated credential. 430 This vector has several requirements for use. 432 o All applicable vector components and values need to be combined 433 into a single vector. 435 o The vector can be communicated across the wire unbroken and 436 untransformed. 438 o All vector components need to remain individually available, not 439 "collapsed" into a single value. 441 o The vector needs to be protected in transit. 443 o The vector needs to be cryptographically bound to the assertion 444 which it is describing. 446 These requirements lead us to defining a simple string-based 447 representation of the vector that can be incorporated within a number 448 of different locations and protocols without further encoding. 450 4.1. On the Wire Representation 452 The vector MUST be represented as a period-separated ('.') list of 453 vector components, with no specific order. A vector component type 454 MAY occur multiple times within a single vector, with each component 455 separated by periods. Multiple values for a component are considered 456 a logical AND of the values. A specific value of a vector component 457 MUST NOT occur more than once in a single vector. That is, while 458 "Cc.Cd" is a valid vector, "Cc.Cc" is not. 460 Vector components MAY be omitted from a vector. No holding space is 461 left for an omitted vector component. If a vector component is 462 omitted, the vector is making no claim for that component. This MAY 463 be distinct from a specific component value stating that a component 464 was not used. 466 Vector values MUST be communicated along side of a trustmark 467 definition to give the components context. A vector value without 468 context is unprocessable, and vectors defined in different contexts 469 are not directly comparable as whole values. Different trustmarks 470 MAY re-use component definitions (including their values), allowing 471 comparison of individual components across contexts without requiring 472 complete understanding of all aspects of a context. The proper 473 processing of such cross-context values is outside the scope of this 474 specification. 476 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous, 477 proof of shared key, signed browser-passed verified assertion, and no 478 claim made toward credential management" in the context of this 479 specification's definitions (Section 3). The vector value of 480 "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for 481 issuance and rotation, cryptographic proof of possession of a shared 482 key, signed back-channel verified assertion, and no claim made toward 483 identity proofing" in the same context. 485 4.2. In OpenID Connect 487 In OpenID Connect [OpenID], the IdP MUST send the vector as a string 488 within the "vot" (vector of trust) claim in the ID token. The 489 trustmark (Section 6) that applies to this vector MUST be sent as an 490 HTTPS URL in the "vtm" (vector trust mark) claim to provide context 491 to the vector. 493 For example, the body of an ID token claiming "pseudonymous, proof of 494 shared key, signed back-channel verified token, and no claim made 495 toward credential management" could look like this JSON object 496 payload of the ID token. 498 { 499 "iss": "https://idp.example.com/", 500 "sub": "jondoe1234", 501 "vot": "P1.Cc.Ac", 502 "vtm": "https://trustmark.example.org/trustmark/idp.example.com" 503 } 505 The body of the ID token is signed and optionally encrypted using 506 JOSE, as per the OpenID Connect specification. By putting the "vot" 507 and "vtm" values inside the ID token, the vector and its context are 508 strongly bound to the federated credential represented by the ID 509 token. 511 4.3. In SAML 513 In SAML, a vector is communicated as an AuthenticationContextDeclRef. 514 A vector is represented by prefixing it with the urn 515 urn:ietf:param:[TBD] to form a full URN. The 516 AuthenticationContextDeclaration corresponding to a given vector is a 517 AuthenticationContextDeclaration element containing an Extension 518 element with components of the vector represented by the following 519 XML schema: 521 522 526 527 This represents a set of vector components. 528 529 530 531 532 533 534 535 537 For instance the vector P1.Cc.Ac is represented by the 538 AuthenticationContextDeclRef URN urn:ietf:param:[TBD]:P1.Cc.Ac (or 539 urn:ietf:param:[TBD]:Cc.P1.Ac or ...) which corresponds to the 540 following AuthenticationContextDeclaration: 542 543 544 545 P1.Cc.Ac 546 547 549 5. Requesting Vector Values 551 In some identity protocols, the RP can request that particular vector 552 components be applied to a given identity transaction. Using the 553 same syntax as defined in Section 4.1, an RP can indicate that it 554 desires particular aspects be present in the authentication. 555 Processing and fulfillment of these requests are in the purview of 556 the IdP and details are outside the scope of this specification. 558 5.1. In OpenID Connect 560 In OpenID Connect [OpenID], the client MAY request a set of 561 acceptable VoT values with the "vtr" (vector of trust request) claim 562 request as part of the Request Object. The value of this field is an 563 array of JSON strings, each string identifying an acceptable set of 564 vector components. The component values within each vector are ANDed 565 together while the separate vectors are ORed together. For example, 566 a list of vectors in the form "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating 567 that either the full set of "P1 AND Cb AND Cc AND Ab" simultaneously 568 OR the set of "Ce AND Ab" simultaneously are acceptable to this RP 569 for this transaction. 571 Vector request values MAY omit components, indicating that any value 572 is acceptable for that component category, including omission of that 573 component in the response vector. 575 The mechanism by which the IdP processes the "vtr" and maps that to 576 the authentication transaction are out of scope of this 577 specification. 579 5.2. In SAML 581 In SAML (Section 4.3) the client can request a set of acceptable VoT 582 values by including the corresponding AuthenticationContextDeclRef 583 URIs together with an AuthenticationContextClassRef corresponding to 584 the trust mark (cf below). The processing rules in Section 4.3 585 apply. 587 6. Trustmark 589 When an RP receives a specific vector from an IdP, it needs to make a 590 decision to trust the vector within a specific context. A trust 591 framework can provide such a context, allowing legal and business 592 rules to give weight to an IdP's claims. A trustmark is a verifiable 593 claim to conform to a specific component of a trust framework, such 594 as a verified identity provider. The trustmark conveys the root of 595 trustworthiness about the claims and assertions made by the IdP, 596 including the vector itself. 598 The trustmark MUST be available from an HTTPS URL served by the trust 599 framework provider. The contents of this URL are a JSON [RFC7159] 600 document with the following fields: 602 idp The issuer URL of the identity provider that this trustmark 603 pertains to. This MUST match the corresponding issuer claim in 604 the identity token, such as the OpenID Connect "iss" field. This 605 MUST be an HTTPS URL. 607 trustmark_provider The issuer URL of the trustmark provider that 608 issues this trustmark. The URL that a trustmark is fetched from 609 MUST start with the "iss" URL in this field. This MUST be an 610 HTTPS URL. 612 P Array of strings containing identity proofing values for which the 613 identity provider has been assessed and approved. 615 C Array of strings containing primary credential usage values for 616 which the identity provider has been assessed and approved. 618 M Array of strings containing primary credential management values 619 for which the identity provider has been assessed and approved. 621 A Array of strings containing assertion strength values for which 622 the identity provider has been assessed and approved. 624 Additional vector component values MUST be listed in a similar 625 fashion using their demarcator. 627 For example, the following trustmark provided by the 628 trustmark.example.org organization applies to the idp.example.org 629 identity provider: 631 { 632 "idp": "https://idp.example.org/", 633 "trustmark_provider": "https://trustmark.example.org/", 634 "P": ["P0", "P1"], 635 "C": ["C0", "Ca", "Cb"], 636 "M": ["Mb"], 637 "A": ["Ab", "Ac"] 638 } 640 An RP wishing to check the claims made by an IdP can fetch the 641 information from the trustmark provider about what claims the IdP is 642 allowed to make in the first place and process them accordingly. The 643 RP MAY cache the information returned from the trustmark URL. 645 The operational aspects of the IdP MAY be included in the trustmark 646 definition. For example, if a trustmark can indicate that an IdP 647 uses multiple redundant hosts, encrypts all data at rest, or other 648 operational security mechanisms that affect the trustworthiness of 649 assertions made by the IdP. The definition of these additional 650 aspects is outside the scope of this specfication. 652 The means by which the RP decides which trustmark providers it trusts 653 is out of scope for this specification and is generally configured 654 out of band. 656 Though most trust frameworks will provide a third-party independent 657 verification service for components, an IdP MAY host its own 658 trustmark. For example, a self-hosted trustmark would look like: 660 { 661 "idp": "https://idp.example.org/", 662 "trustmark_provider": "https://idp.example.org/", 663 "P": ["P0", "P1"], 664 "C": ["C0", "Ca", "Cb"], 665 "M": ["Mb"], 666 "A": ["Ab", "Ac"] 667 } 669 7. Discovery 671 The IdP MAY list all of its available trustmarks as part of its 672 discovery document, such as the OpenID Connect Discovery server 673 configuration document. In this context, trustmarks are listed in 674 the "trustmarks" element which contains a single JSON [RFC7159] 675 object. The keys of this JSON object are trustmark provider issuer 676 URLs and the values of this object are the corresponding trustmark 677 URLs for this IdP. 679 { 680 "iss": "https://idp.example.org/", 681 "trustmark": { 682 "https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/" 683 } 684 } 686 8. Acknowledgements 688 The authors would like to thank the members of the Vectors of Trust 689 mailing list in the IETF for discussion and feedback on the concept 690 and document, and the members of the ISOC Trust and Identity team for 691 their support. 693 9. IANA Considerations 695 This specification creates one registry and registers several values 696 into an existing registry. 698 9.1. Vector Of Trust Components Registry 700 The Vector of Trust Components Registry contains the definitions of 701 vector components and their associated demarcators. 703 o Demarcator Symbol: P 705 o Description: Identity proofing 707 o Document: [[ this document ]] 708 o Demarcator Symbol: C 710 o Description: Primary credential usage 712 o Document: [[ this document ]] 714 o Demarcator Symbol: M 716 o Description: Primary credential management 718 o Document: [[ this document ]] 720 o Demarcator Symbol: A 722 o Description: Assertion presentation 724 o Document: [[ this document ]] 726 9.2. Additions to JWT Claims Registry 728 This specification adds the following values to the JWT Claims 729 Registry. 731 o Claim name: vot 733 o Description: Vector of Trust value 735 o Document: [[ this document ]] 737 o Demarcator Symbol: vtm 739 o Description: Vector of Trust Trustmark 741 o Document: [[ this document ]] 743 o Demarcator Symbol: vtr 745 o Description: Vector of Trust Request 747 o Document: [[ this document ]] 749 10. Security Considerations 751 The vector of trust value MUST be cryptographically protected in 752 transit, using TLS as described in [BCP195]. The vector of trust 753 value MUST be associated with a trustmark marker, and the two MUST be 754 carried together in a cryptographically bound mechanism such as a 755 signed identity assertion. A signed OpenID Connect ID Token and a 756 signed SAML assertion both fulfil this requirement. 758 The VoT framework provides a mechanism for describing and conveying 759 trust information. It does not define any policies for asserting the 760 values of the vector, nor does it define any policies for applying 761 the values of a vector to an RP's security decision process. These 762 policies MUST be agreed upon by the IdP and RP, and they SHOULD be 763 expressed in detail in an associated trust framework. 765 11. Privacy Considerations 767 By design, vector of trust values contain information about the 768 user's authentication and associations that can be made thereto. 769 Therefore, all aspects of a vector of trust contain potentially 770 privacy-sensitive information and MUST be guarded as such. Even in 771 the absence of specific attributes about a user, knowledge that the 772 user has been highly proofed or issued a strong token could provide 773 more information about the user than was intended. It is RECOMMENDED 774 that systems in general use the minimum vectors applicable to their 775 use case in order to prevent inadvertent information disclosure. 777 12. References 779 12.1. Normative References 781 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 782 Core 1.0", November 2014. 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, 786 DOI 10.17487/RFC2119, March 1997, 787 . 789 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 790 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 791 2014, . 793 12.2. Informative References 795 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 796 "Recommendations for Secure Use of Transport Layer 797 Security (TLS) and Datagram Transport Layer Security 798 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 799 2015, . 801 [SP-800-63-2] 802 , , , , , , and , "Electronic Authentication Guideline", 803 August 2013. 805 Appendix A. Document History 807 -04 809 o Updated SAML example to be consistent. 811 -03 813 o Clarified language of LoA's in introduction. 815 o Added note on operational security in trustmarks. 817 o Removed empty sections and references. 819 -02 821 o Converted C, M, and A values to use letters instead of numbers in 822 examples. 824 o Updated SAML to a structured example pending future updates. 826 o Defined guidance for when to use letters vs. numbers in category 827 values. 829 o Restricted category demarcators to uppercase and values to 830 lowercase and digits. 832 o Applied clarifying editorial changes from list comments. 834 - 01 836 o Added IANA registry for components. 838 o Added preliminary security considerations and privacy 839 considerations. 841 o Split "credential binding" into "primary credential usage" and 842 "primary credential management". 844 - 00 846 o Created initial IETF drafted based on strawman proposal discussed 847 on VoT list. 849 o Split vector component definitions into their own section to allow 850 extension and override. 852 o Solidified trustmark document definition. 854 Authors' Addresses 856 Justin Richer (editor) 857 Bespoke Engineering 859 Email: ietf@justin.richer.org 861 Leif Johansson 862 Swedish University Network 863 Thulegatan 11 864 Stockholm 865 Sweden 867 Email: leifj@sunet.se 868 URI: http://www.sunet.se