idnits 2.17.1
draft-richer-vectors-of-trust-09.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 19, 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 20, 2018 Swedish University Network
6 March 19, 2018
8 Vectors of Trust
9 draft-richer-vectors-of-trust-09
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 20, 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 . . . . . . . . . . . . . . . . . . . . 6
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 9.4. Additions to OAuth Token Introspection Response . . . . . 17
86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
87 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
89 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
90 12.2. Informative References . . . . . . . . . . . . . . . . . 19
91 Appendix A. Vectors of Trust Default Component Value Definitions 20
92 A.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 20
93 A.2. Primary Credential Usage . . . . . . . . . . . . . . . . 21
94 A.3. Primary Credential Management . . . . . . . . . . . . . . 21
95 A.4. Assertion Presentation . . . . . . . . . . . . . . . . . 22
96 Appendix B. Document History . . . . . . . . . . . . . . . . . . 22
97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
99 1. Introduction
101 Methods for measuring trust in digital identity transactions have
102 historically fallen into two main categories: either all measurements
103 are combined into a single scalar value, or trust decisions are
104 calculated locally based on a detailed set of attribute metadata.
105 This document defines a method of conveying trust information that is
106 more expressive than a single value but less complex than
107 comprehensive attribute metadata.
109 Prior to the third edition [SP-800-63-3] published in 2017, NIST
110 Special Publication 800-63 [SP-800-63-2] used a single scalar
111 measurement of trust called a Level of Assurance (LoA). An LoA can
112 be used to compare different transactions within a system at a coarse
113 level. For instance, an LoA4 transaction is generally considered
114 more trusted (across all measured categories) than an LoA2
115 transaction. The LoA for a given transaction is computed by the
116 identity provider (IdP) and is consumed by a relying party (RP).
117 Since the trust measurement is a simple numeric value, it's trivial
118 for RPs to process and compare. However, since each LoA encompasses
119 many different aspects of a transaction, it can't express many real-
120 world situations. For instance, an anonymous user account might have
121 a very strong credential, such as would be common of a whistle-blower
122 or political dissident. Despite the strong credential, the lack of
123 identity proofing would make any transactions conducted by the
124 account to fall into a low LoA. Furthermore, different use cases and
125 domains require subtly different definitions for their LoA
126 categories, and one group's LoA2 is not equivalent or even comparable
127 to another group's LoA2.
129 Attribute based access control (ABAC) systems used by RPs may need to
130 know details about a user's attributes, such as how recently the
131 attribute data was verified and by whom. Attribute metadata systems
132 are capable of expressing extremely fine-grained detail about the
133 transaction. However, this approach requires the IdP to collect,
134 store, and transmit all of this attribute data for the RP's
135 consumption. The RP must process this data, which may be prohibitive
136 for trivial security decisions.
138 Vectors of Trust (VoT) seeks a balance between these two alternatives
139 by allowing expression of multiple aspects of an identity transaction
140 (including but not limited to identity proofing, credential strength,
141 credential management, and assertion strength), without requiring
142 full attribute metadata descriptions. This method of measurement
143 gives more actionable data and expressiveness than an LoA, but is
144 still relatively easy for the RP to process. It is anticipated that
145 VoT can be used alongside more detailed attribute metadata systems as
146 has that proposed by NISITIR 8112 [NISTIR-8112]. The RP can use the
147 vector value for most basic decisions but be able to query the IdP
148 for additional attribute metadata where needed. Furthermore, it is
149 anticipated that some trust frameworks will provide a simple mapping
150 between certain sets of vector values to LoAs, for RPs that do not
151 have a need for the vector's more fine-grained detail. In such
152 systems, an RP is given a choice of how much detail it needs in order
153 to process a given request.
155 This document defines a data model for these vectors and an on-the-
156 wire format for conveying them between parties, anchored in a trust
157 definition. This document also provides guidance for defining values
158 for use in conveying this information, including four component
159 categories and guidance on defining values within those categories.
160 Additionally, this document defines a general-purpose set of
161 component values in an appendix (Appendix A) for use cases that do
162 not need something more specific.
164 1.1. Terminology
166 Identity Provider (IdP) A system that manages identity information
167 and is able to assert this information across the network through
168 an identity API.
170 Identity Subject The person (user) engaging in the identity
171 transaction, being identified by the identity provider and
172 identified to the relying party.
174 Primary Credential The means used by the identity subject to
175 authenticate to the identity provider.
177 Federated Credential The assertion presented by the IdP to the RP
178 across the network to authenticate the user.
180 Relying Party (RP) A system that consumes identity information from
181 an IdP for the purposes of authenticating the user.
183 Trust Framework A document containing business rules and legal
184 clauses that defines how different parties in an identity
185 transaction may act.
187 Trustmark A verifiable attestation that a party has proved to follow
188 the constraints of a trust framework.
190 Trustmark Provider A system that issues and provides verification
191 for trustmarks.
193 Vector A multi-part data structure, used here for conveying
194 information about an authentication transaction.
196 Vector Component One of several constituent parts that make up a
197 vector.
199 Vector Component Value One of the values applied to a vector
200 component within a vector.
202 1.2. An Identity Model
204 This document assumes the following model for identity based on
205 identity federation technologies:
207 The identity subject (also known as the user) is associated with an
208 identity provider which acts as a trusted third party on behalf of
209 the user with regard to a relying party by making identity assertions
210 about the user to the relying party.
212 The real-world person represented by the identity subject is in
213 possession of a primary credential bound to the identity subject by
214 the identity provider (or an agent thereof) in such a way that the
215 binding between the credential and the real-world user is a
216 representation of the identity proofing process performed by the
217 identity provider (or an agent thereof) to verify the identity of the
218 real-world person. This is all carried by an identity assertion
219 across the network to the relying party during the authentication
220 transaction.
222 1.3. Component Architecture
224 The term Vectors of Trust is based on the mathematical construct of a
225 vector, which is defined as an item composed of multiple independent
226 values.
228 An important goal for this work is to balance the need for simplicity
229 (particularly on the part of the relying party) with the need for
230 expressiveness. As such, this vector construct is designed to be
231 composable and extensible.
233 All components of the vector construct MUST be orthogonal such that
234 no aspect of a component overlaps an aspect of another component, as
235 much as is possible.
237 2. Component Definitions
239 This specification defines four orthogonal components: identity
240 proofing, primary credential usage, primary credential management,
241 and assertion presentation. These dimensions MUST be evaluated by
242 the RP in the context of a trust framework and SHOULD be combined
243 with other information when making a trust and authorization
244 decision.
246 This specification also defines values for each component to be used
247 in the absence of a more specific trust framework in Appendix A. It
248 is expected that trust frameworks will provide context, semantics,
249 and mapping to legal statutes and business rules for each value in
250 each component. Consequently, a particular vector value can only be
251 compared with vectors defined in the same context. The RP MUST
252 understand and take into account the trust framework context in which
253 a vector is being expressed in order for to process a vector
254 securely.
256 Each component is identified by a demarcator consisting of a single
257 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD
258 reflect the category with which it is associated in a natural manner.
259 Demarcators for components MUST be registered as described in
260 Section 9. It is anticipated that trust framework definitions will
261 use this registry to define specialized components, though it is
262 RECOMMENDED that trust frameworks re-use existing components wherever
263 possible.
265 The value for a given component within a vector of trust is defined
266 by its demarcator character followed by a single digit or lowercase
267 ASCII letter in the range "[0-9a-z]". Categories which have a
268 natural ordering SHOULD use digits, with "0" as the lowest value.
269 Categories which do not have a natural ordering, or which can have an
270 ambiguous ordering, SHOULD use letters. Categories MAY use both
271 letter style and number style value indicators simultaneously. For
272 example, a category could define "0" as a special "empty" value while
273 using letters such as "a", "b", "c" for normal values can to
274 differentiate between these types of options. Another system could
275 have a base category with a numeric value with additonal details
276 provided by letter values.
278 Regardless of the type of value indicator used, the values assigned
279 to each component of a vector MUST NOT be assumed always to have
280 inherent ordinal properties when compared to the same or other
281 components in the vector space. In other words, "1" is different
282 from "2", but it is dangerous to assume that "2" is always better
283 than "1" in a given transaction.
285 Each component MAY be repeated with multiple different values within
286 a single vector. The same component and value combination MUST NOT
287 be repeated within a single vector.
289 2.1. Identity Proofing (P)
291 The Identity Proofing dimension defines, overall, how strongly the
292 set of identity attributes have been verified and vetted. In other
293 words, this dimension describes how likely it is that a given digital
294 identity transaction corresponds to a particular (real-world)
295 identity subject.
297 This dimension SHALL be represented by the "P" demarcator and a
298 single-character level value, such as "P0", "P1", etc. Most
299 definitions of identity proofing will have a natural ordering, as
300 more or less stringent proofing can be applied to an individual. In
301 such cases it is RECOMMENDED that a digit style value be used for
302 this component and that only a single value be allowed to be
303 communicated in a transaction.
305 2.2. Primary Credential Usage (C)
307 The primary credential usage dimension defines how strongly the
308 primary credential can be verified by the IdP. In other words, how
309 easily that credential could be spoofed or stolen.
311 This dimension SHALL be represented by the "C" demarcator and a
312 single-character level value, such as "Ca", "Cb", etc. Most
313 definitions of credential usage will not have an overall natural
314 ordering, as there may be several equivalent classes described within
315 a trust framework. In such cases it is RECOMMENDED that a letter
316 style value be used for this component and that multiple distinct
317 credential usage factors be allowed to be communicated
318 simultaneously, such as when Multi-Factor Authentication is used.
320 2.3. Primary Credential Management (M)
322 The primary credential management dimension conveys information about
323 the expected lifecycle of the primary credential in use, including
324 its binding, rotation, and revocation. In other words, the use and
325 strength of policies, practices, and security controls used in
326 managing the credential at the IdP and its binding to the intended
327 individual.
329 This dimension SHALL be represented by the "M" demarcator and a
330 single-character level value, such as "Ma", "Mb", etc. Most
331 definitions of credential management will not have an overall natural
332 ordering, though there can be preference and comparison between
333 values in some circumstances. In such cases it is RECOMMENDED that a
334 letter style value be used for this component and that multiple
335 distinct values be allowed to be communicated simultaneously.
337 2.4. Assertion Presentation (A)
339 The Assertion Presentation dimension defines how well the given
340 digital identity can be communicated across the network without
341 information leaking to unintended parties, and without spoofing. In
342 other words, this dimension describes how likely it is that a given
343 digital identity was actually asserted by a given identity provider
344 for a given transaction. While this information is largely already
345 known by the RP as a side effect of processing an identity assertion,
346 this dimension is still very useful when the RP requests a login
347 (Section 4) and when describing the capabilities of an IdP
348 (Section 6).
350 This dimension SHALL be represented by the "A" demarcator and a level
351 value, such as "Aa", "Ab", etc. Most definitions of assertion
352 presentation will not have an overall natural ordering. In such
353 cases, it is RECOMMENDED that a letter style value be used for this
354 component and that multiple values be allowed to be communicated
355 simultaneously.
357 3. Communicating Vector Values to RPs
359 A vector of trust is designed to be used in the context of an
360 identity and authentication transaction, providing information about
361 the context of a federated credential. The vector therefore needs to
362 be able to be communicated in the context of the federated credential
363 in a way that is strongly bound to the assertion representing the
364 federated credential.
366 This vector has several requirements for use.
368 o All applicable vector components and values need to be combined
369 into a single vector.
371 o The vector can be communicated across the wire unbroken and
372 untransformed.
374 o All vector components need to remain individually available, not
375 "collapsed" into a single value.
377 o The vector needs to be protected in transit.
379 o The vector needs to be cryptographically bound to the assertion
380 which it is describing.
382 o The vector needs to be interpreted in the context of a specific
383 trust framework definition.
385 These requirements lead us to defining a simple string-based
386 representation of the vector that can be incorporated within a number
387 of different locations and protocols without further encoding.
389 3.1. On the Wire Representation
391 The vector MUST be represented as a period-separated ('.') list of
392 vector components, with no specific order. A vector component type
393 MAY occur multiple times within a single vector, with each component
394 separated by periods. Multiple values for a component are considered
395 a logical AND of the values. A specific value of a vector component
396 MUST NOT occur more than once in a single vector. That is, while
397 "Cc.Cd" is a valid vector, "Cc.Cc" is not.
399 Vector components MAY be omitted from a vector. No holding space is
400 left for an omitted vector component. If a vector component is
401 omitted, the vector is making no claim for that component. This MAY
402 be distinct from a specific component value stating that a component
403 was not used.
405 Vector values MUST be communicated along side of a trustmark
406 definition to give the components context. The trustmark MUST be
407 cryptographically bound to the vector value, such as in a signed
408 assertion. A vector value without context is unprocessable, and
409 vectors defined in different contexts are not directly comparable as
410 whole values. Different trustmarks MAY re-use component definitions
411 (including their values), allowing comparison of individual
412 components across contexts without requiring complete understanding
413 of all aspects of a context. The proper processing of such cross-
414 context values is outside the scope of this specification.
416 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous,
417 proof of shared key, signed browser-passed verified assertion, and no
418 claim made toward credential management" in the context of this
419 specification's definitions (Appendix A). The vector value of
420 "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for
421 issuance and rotation, cryptographic proof of possession of a shared
422 key, signed back-channel verified assertion, and no claim made toward
423 identity proofing" in the same context.
425 3.2. In OpenID Connect
427 In OpenID Connect [OpenID], the IdP MUST send the vector as a string
428 within the "vot" (vector of trust) claim in the ID token. The
429 trustmark (Section 5) that applies to this vector MUST be sent as an
430 HTTPS URL in the "vtm" (vector trust mark) claim to provide context
431 to the vector.
433 For example, the body of an ID token claiming "pseudonymous, proof of
434 shared key, signed back-channel verified token, and no claim made
435 toward credential management" could look like this JSON object
436 payload of the ID token.
438 {
439 "iss": "https://idp.example.com/",
440 "sub": "jondoe1234",
441 "vot": "P1.Cc.Ac",
442 "vtm": "https://trustmark.example.org/trustmark/idp.example.com"
443 }
445 The body of the ID token is signed and optionally encrypted using
446 JOSE, as per the OpenID Connect specification. By putting the "vot"
447 and "vtm" values inside the ID token, the vector and its context are
448 strongly bound to the federated credential represented by the ID
449 token.
451 3.3. In SAML
453 In SAML, a vector is communicated as an
454 "AuthenticationContextDeclRef". A vector is represented by prefixing
455 it with the "urn urn:ietf:param:[TBD]" to form a full URN. The
456 "AuthenticationContextDeclaration" corresponding to a given vector is
457 a "AuthenticationContextDeclaration" element containing an
458 "Extension" element with components of the vector represented by the
459 following XML schema:
461
462
466
467 This represents a set of
468 vector components.
469
470
471
472
473
474
475
476
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 Name: vtr
773 o Description: Vector of Trust request
775 o Parmater usage location: authorization request, token request
777 o Change Controller: IESG
779 o Document: [[ this document ]]
781 9.3. Additions to JWT Claims Registry
783 This specification adds the following values to the JSON Web Token
784 Claims Registry established by [RFC7519].
786 o Claim name: vot
788 o Description: Vector of Trust value
790 o Change Controller: IESG
792 o Document: [[ this document ]]
794 o Claim name: vtm
796 o Description: Vector of Trust trustmark
798 o Change Controller: IESG
800 o Document: [[ this document ]]
802 9.4. Additions to OAuth Token Introspection Response
804 This specification adds the following values to the OAuth Token
805 Introspection Response established by [RFC7662].
807 o Name: vot
809 o Description: Vector of Trust value
811 o Change Controller: IESG
813 o Document: [[ this document ]]
814 o Name: vtm
816 o Description: Vector of Trust trustmark
818 o Change Controller: IESG
820 o Document: [[ this document ]]
822 10. Security Considerations
824 The vector of trust value MUST be cryptographically protected in
825 transit, using TLS as described in [BCP195]. The vector of trust
826 value must be associated with a trustmark marker, and the two must be
827 carried together in a cryptographically bound mechanism such as a
828 signed identity assertion. A signed OpenID Connect ID Token and a
829 signed SAML assertion both fulfil this requirement.
831 The vector value is always associated with a trustmark and needs to
832 be interpreted by the RP in the context of that trustmark. Different
833 trust frameworks can apply different interpretations to the same
834 component value, much as was the case with LoA. Therefore, an RP
835 interpreting a component value in the the wrong context could
836 mistakenly accept or reject a request. In order to avoid this
837 mistake, RPs need to reject vectors that are defined in trust
838 frameworks that they do not understand how to interpret properly.
840 The VoT framework provides a mechanism for describing and conveying
841 trust information. It does not define any policies for asserting the
842 values of the vector, nor does it define any policies for applying
843 the values of a vector to an RP's security decision process. These
844 policies must be agreed upon by the IdP and RP, and they should be
845 expressed in detail in an associated human-readable trust framework
846 document.
848 11. Privacy Considerations
850 By design, vector of trust values contain information about the
851 user's authentication and associations that can be made thereto.
852 Therefore, all aspects of a vector of trust contain potentially
853 privacy-sensitive information and must be guarded as such. Even in
854 the absence of specific attributes about a user, knowledge that the
855 user has been highly proofed or issued a strong token could provide
856 more information about the user than was intended. It is recommended
857 that systems in general use the minimum vectors applicable to their
858 use case in order to prevent inadvertent information disclosure.
860 12. References
862 12.1. Normative References
864 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
865 Core 1.0", November 2014.
867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
868 Requirement Levels", BCP 14, RFC 2119,
869 DOI 10.17487/RFC2119, March 1997,
870 .
872 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
873 RFC 6749, DOI 10.17487/RFC6749, October 2012,
874 .
876 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
877 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
878 .
880 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
881 RFC 7662, DOI 10.17487/RFC7662, October 2015,
882 .
884 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
885 Writing an IANA Considerations Section in RFCs", BCP 26,
886 RFC 8126, DOI 10.17487/RFC8126, June 2017,
887 .
889 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
890 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
891 May 2017, .
893 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
894 Interchange Format", STD 90, RFC 8259,
895 DOI 10.17487/RFC8259, December 2017,
896 .
898 12.2. Informative References
900 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
901 "Recommendations for Secure Use of Transport Layer
902 Security (TLS) and Datagram Transport Layer Security
903 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
904 2015, .
906 [NISTIR-8112]
907 National Institute of Standards and Technology, U.S.
908 Department of Commerce, "A Proposed Schema for Evaluating
909 Federated Attributes", NIST NISTIR 8112, January 2018,
910 .
912 [SP-800-63-2]
913 National Institute of Standards and Technology, U.S.
914 Department of Commerce, "Electronic Authentication
915 Guideline", NIST SP 800-63-2,
916 DOI 10.6028/NIST.SP.800-63-2, August 2013,
917 .
919 [SP-800-63-3]
920 National Institute of Standards and Technology, U.S.
921 Department of Commerce, "Digital Identity Guideline",
922 NIST SP 800-63-3, DOI 10.6028/NIST.SP.800-63-3, June 2017,
923 .
925 Appendix A. Vectors of Trust Default Component Value Definitions
927 The following general-purpose component definitions MAY be used when
928 a more specific set is unavailable. These component values are
929 referenced in a trustmark definition defined by [[ this document URL
930 ]].
932 Extensions of this specification SHOULD define their own component
933 values as described in Section 7. Where possible, extensions MAY re-
934 use specific values here.
936 A.1. Identity Proofing
938 The identity proofing component of this vector definition represents
939 increasing scrutiny during the proofing process. Higher levels are
940 largely subsumptive of lower levels, such that "P2" fulfills
941 requirements for "P1", etc. Mutltiple distinct values from this
942 category MUST NOT be used in a single transaction.
944 P0 No proofing is done, data is not guaranteed to be persistent
945 across sessions
947 P1 Attributes are self-asserted but consistent over time, potentially
948 pseudonymous
950 P2 Identity has been proofed either in person or remotely using
951 trusted mechanisms (such as social proofing)
953 P3 There is a binding relationship between the identity provider and
954 the identified party (such as signed/notarized documents,
955 employment records)
957 A.2. Primary Credential Usage
959 The primary credential usage component of this vector definition
960 represents distinct categories of primary credential that MAY be used
961 together in a single transaction. Multiple distinct values from this
962 category MAY be used in a single transaction.
964 C0 No credential is used / anonymous public service
966 Ca Simple session HTTP cookies (with nothing else)
968 Cb Known device
970 Cc Shared secret such as a username and password combination
972 Cd Cryptographic proof of key possession using shared key
974 Ce Cryptographic proof of key possession using asymmetric key
976 Cf Sealed hardware token / trusted biometric / TPM-backed keys
978 A.3. Primary Credential Management
980 The primary credential management component of this vector definition
981 represents distinct categories of management that MAY be considered
982 separately or together in a single transaction. Many trust framework
983 deployments MAY use a single value for this component as a baseline
984 for all transactions and thereby omit it. Multiple distinct values
985 from this category MAY be used in a single transaction.
987 Ma Self-asserted primary credentials (user chooses their own
988 credentials and must rotate or revoke them manually) / no
989 additional verification for primary credential issuance or
990 rotation
992 Mb Remote issuance and rotation / use of backup recover credentials
993 (such as email verification) / deletion on user request
995 Mc Full proofing required for each issuance and rotation / revocation
996 on suspicious activity
998 A.4. Assertion Presentation
1000 The assertion presentation component of this vector definition
1001 represents distinct categories of assertion which are RECOMMENDED to
1002 be used in a subsumptive manner but MAY be used together. Multiple
1003 distinct values from this category MAY be used in a single
1004 transaction.
1006 Aa No protection / unsigned bearer identifier (such as an HTTP
1007 session cookie in a web browser)
1009 Ab Signed and verifiable assertion, passed through the user agent
1010 (web browser)
1012 Ac Signed and verifiable assertion, passed through a back channel
1014 Ad Assertion encrypted to the relying parties key and audience
1015 protected
1017 Appendix B. Document History
1019 -09
1021 o Added introspection response IANA registration.
1023 o Cleaned up IANA entries.
1025 -08
1027 o Incorporated shepherd comments.
1029 o Updated references.
1031 o Added reference to NISTIR 8112.
1033 o Moved default component definitions to appendix.
1035 -07
1037 o Rewrote introduction to clarify focus of document.
1039 -06
1041 o Added section on extensions to VoT.
1043 o Made it so that every component category could be multi-valued.
1045 o Added reference to updated 800-63-3.
1047 o Fixed example text width.
1049 o Switched document back to standards-track from experimental now
1050 that there are extensions in the wild.
1052 -05
1054 o Updated IANA considerations section to include instructions.
1056 o Made security and privacy considerations non-normative.
1058 -04
1060 o Updated SAML example to be consistent.
1062 -03
1064 o Clarified language of LoA's in introduction.
1066 o Added note on operational security in trustmarks.
1068 o Removed empty sections and references.
1070 -02
1072 o Converted C, M, and A values to use letters instead of numbers in
1073 examples.
1075 o Updated SAML to a structured example pending future updates.
1077 o Defined guidance for when to use letters vs. numbers in category
1078 values.
1080 o Restricted category demarcators to uppercase and values to
1081 lowercase and digits.
1083 o Applied clarifying editorial changes from list comments.
1085 - 01
1087 o Added IANA registry for components.
1089 o Added preliminary security considerations and privacy
1090 considerations.
1092 o Split "credential binding" into "primary credential usage" and
1093 "primary credential management".
1095 - 00
1097 o Created initial IETF drafted based on strawman proposal discussed
1098 on VoT list.
1100 o Split vector component definitions into their own section to allow
1101 extension and override.
1103 o Solidified trustmark document definition.
1105 Authors' Addresses
1107 Justin Richer (editor)
1108 Bespoke Engineering
1110 Email: ietf@justin.richer.org
1112 Leif Johansson
1113 Swedish University Network
1114 Thulegatan 11
1115 Stockholm
1116 Sweden
1118 Email: leifj@sunet.se
1119 URI: http://www.sunet.se