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