idnits 2.17.1
draft-richer-vectors-of-trust-06.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 date (September 12, 2017) is 2417 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 789, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID'
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
-- Obsolete informational reference (is this intentional?): RFC 7525 (ref.
'BCP195') (Obsoleted by RFC 9325)
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: March 16, 2018 Swedish University Network
6 September 12, 2017
8 Vectors of Trust
9 draft-richer-vectors-of-trust-06
11 Abstract
13 This document defines a mechanism for describing and signaling
14 several aspects that are used to calculate trust placed in a digital
15 identity transaction.
17 Requirements Language
19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
21 "OPTIONAL" in this document are to be interpreted as described in RFC
22 2119 [RFC2119].
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at https://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on March 16, 2018.
41 Copyright Notice
43 Copyright (c) 2017 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (https://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
60 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5
61 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5
62 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 5
63 2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6
64 2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 7
65 2.3. Primary Credential Management . . . . . . . . . . . . . . 7
66 2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 7
67 3. Vectors of Trust Default Component Value Definitions . . . . 8
68 3.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 8
69 3.2. Primary Credential Usage . . . . . . . . . . . . . . . . 8
70 3.3. Primary Credential Management . . . . . . . . . . . . . . 9
71 3.4. Assertion Presentation . . . . . . . . . . . . . . . . . 9
72 4. Communicating Vector Values to RPs . . . . . . . . . . . . . 10
73 4.1. On the Wire Representation . . . . . . . . . . . . . . . 10
74 4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11
75 4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 12
76 5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 13
77 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 13
78 5.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 13
79 6. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 13
80 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15
81 8. Defining New Vector Values . . . . . . . . . . . . . . . . . 16
82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
84 10.1. Vector Of Trust Components Registry . . . . . . . . . . 17
85 10.1.1. Registration Template . . . . . . . . . . . . . . . 17
86 10.1.2. Initial Registry Contents . . . . . . . . . . . . . 18
87 10.2. Additions to the OAuth Parameters Registry . . . . . . . 18
88 10.3. Additions to JWT Claims Registry . . . . . . . . . . . . 19
89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
90 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
92 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
93 13.2. Informative References . . . . . . . . . . . . . . . . . 20
94 Appendix A. Document History . . . . . . . . . . . . . . . . . . 21
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
97 1. Introduction
99 This document defines a mechanism for measuring and signaling several
100 aspects of digital identity and authentication transactions that are
101 used to determine a level of trust in that transaction. In the past,
102 there have been two extremes of communicating authentication
103 transaction information.
105 At one extreme, all attributes can be communicated with full
106 provenance and associated trust markings. This approach seeks to
107 create a fully-distributed attribute system to support functions such
108 as attribute based access control (ABAC). These attributes can be
109 used to describe the end user, the identity provider, the relying
110 party, or even the transaction itself. While the information that
111 can be expressed in this model is incredibly detailed and robust, the
112 complexity of such a system is often prohibitive to realize,
113 especially across security domains. In particular, a large burden is
114 placed on relying parties needing to process the sea of disparate
115 attributes when making a security decision.
117 At the other extreme there are systems that collapse all of the
118 attributes and aspects into a single scalar value that communicates,
119 in sum, how much a transaction can be trusted. The NIST special
120 publication 800-63 [SP-800-63-2] up to and including version 2
121 defines a linear scale Level of Assurance (LoA) measure that combines
122 multiple aspects about an identity transaction into such a single
123 measure. While this definition was originally narrowly targeted for
124 a specific set of government use cases, the LoA scale appeared to be
125 applicable with a wide variety of authentication scenarios in
126 different domains. This has led to a proliferation of incompatible
127 interpretations of the same scale in different contexts, preventing
128 interoperability between each LoA definition in spite of their common
129 measurement. LoA is artificially limited due to the original goal of
130 creating a single linear scale. Since identity proofing strength
131 increases linearly along with credential strength in the LoA scale,
132 this scale is too limited for describing many valid and useful forms
133 of an identity transaction that do not fit the government's original
134 model. For example, an anonymously assigned hardware token can be
135 used in cases where the real world identity of the subject cannot be
136 known for privacy reasons, but the credential itself can be highly
137 trusted. This is in contrast with a government employee accessing a
138 government system, where the identity of the individual would need to
139 be highly proofed and strongly credentialed at the same time. In
140 fact, the latest update of NIST special publication 800-63
141 [SP-800-63-3] (version 3) has done away with this single linear scale
142 for exactly these reasons.
144 The Vectors of Trust (VoT) effort seeks to find a balance between
145 these two extremes by creating a data model that combines attributes
146 of the user and aspects of the authentication context into several
147 values that can be communicated separately but in parallel with each
148 other. This approach is both coarser grained than the distributed
149 attributes model and finer grained than the single scalar model, with
150 the hope that it is a viable balance of expressibility and
151 processability. Importantly, these three levels of granularity can
152 be mapped to each other. The information of several attributes can
153 be folded into a vector component, while the vector itself can be
154 folded into an assurance category. As such, the vectors of trust
155 seeks to complement, not replace, these other identity and trust
156 mechanisms in the larger identity ecosystem while providing a single
157 value for RPs to process.
159 1.1. Terminology
161 Identity Provider (IdP) A system that manages identity information
162 and is able to assert this information across the network through
163 an identity API.
165 Identity Subject The person (user) engaging in the identity
166 transaction, being identified by the identity provider and
167 identified to the relying party.
169 Primary Credential The means used by the identity subject to
170 authenticate to the identity provider.
172 Federated Credential The assertion presented by the IdP to the RP
173 across the network to authenticate the user.
175 Relying Party (RP) A system that consumes identity information from
176 an IdP for the purposes of authenticating the user.
178 Trust Framework A document containing business rules and legal
179 clauses that defines how different parties in an identity
180 transaction may act.
182 Trustmark A verifiable attestation that a party has proved to follow
183 the constraints of a trust framework.
185 Trustmark Provider A system that issues and provides verification
186 for trustmarks.
188 Vector A multi-part data structure, used here for conveying
189 information about an authentication transaction.
191 Vector Component One of several constituent parts that make up a
192 vector.
194 1.2. An Identity Model
196 This document assumes the following model for identity based on
197 identity federation technologies:
199 The identity subject (also known as the user) is associated with an
200 identity provider which acts as a trusted third party on behalf of
201 the user with regard to a relying party by making identity assertions
202 about the user to the relying party.
204 The real-world person represented by the identity subject is in
205 possession of a primary credential bound to the identity subject by
206 the identity provider (or an agent thereof) in such a way that the
207 binding between the credential and the real-world user is a
208 representation of the identity proofing process performed by the
209 identity provider (or an agent thereof) to verify the identity of the
210 real-world person. This is all carried by an identity assertion
211 across the network to the relying party during the authentication
212 transaction.
214 1.3. Component Architecture
216 The term Vectors of Trust is based on the mathematical construct of a
217 vector, which is defined as an item composed of multiple independent
218 values.
220 An important goal for this work is to balance the need for simplicity
221 (particularly on the part of the relying party) with the need for
222 expressiveness. As such, this vector construct is designed to be
223 composable and extensible.
225 All components of the vector construct MUST be orthogonal such that
226 no aspect of a component overlaps an aspect of another component, as
227 much as is possible.
229 2. Component Definitions
231 This specification defines four orthogonal components: identity
232 proofing, primary credential usage, primary credential management,
233 and assertion presentation. These dimensions MUST be evaluated by
234 the RP in the context of a trust framework and SHOULD be combined
235 with other information when making a trust and authorization
236 decision.
238 This specification also defines values for each component to be used
239 in the absence of a more specific trust framework in Section 3. It
240 is expected that trust frameworks will provide context, semantics,
241 and mapping to legal statutes and business rules for each value in
242 each component. Consequently, a particular vector value can only be
243 compared with vectors defined in the same context. The RP MUST
244 understand and take into account the trust framework context in which
245 a vector is being expressed in order for it to be processed securely.
247 Each component is identified by a demarcator consisting of a single
248 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD
249 reflect the category with which it is associated in a natural manner.
250 Demarcators for components MUST be registered as described in
251 Section 10. It is anticipated that trust framework definitions will
252 use this registry to define specialized components, though it is
253 RECOMMENDED that trust frameworks re-use existing components wherever
254 possible.
256 The value for a given component within a vector of trust is defined
257 by its demarcator character followed by a single digit or lowercase
258 ASCII letter in the range "[0-9a-z]". Categories which have a
259 natural ordering SHOULD use digits, with "0" as the lowest value.
260 Categories which do not have a natural ordering, or which can have an
261 ambiguous ordering, SHOULD use letters. Categories MAY use both
262 letter style and number style value indicators. For example, a
263 category could define "0" as a special "empty" value while using
264 letters such as "a", "b", "c" for normal values can to differentiate
265 between these types of options.
267 Regardless of the type of value indicator used, the values assigned
268 to each component of a vector MUST NOT be assumed always to have
269 inherent ordinal properties when compared to the same or other
270 components in the vector space. In other words, "1" is different
271 from "2", but it is dangerous to assume that "2" is always better
272 than "1" in a given transaction.
274 Each component MAY be repeated with multiple different values within
275 a single vector. The same component and value MUST NOT be repeated
276 within a single vector.
278 2.1. Identity Proofing
280 The Identity Proofing dimension defines, overall, how strongly the
281 set of identity attributes have been verified and vetted. In other
282 words, this dimension describes how likely it is that a given digital
283 identity transaction corresponds to a particular (real-world)
284 identity subject.
286 This dimension SHALL be represented by the "P" demarcator and a
287 single-character level value, such as "P0", "P1", etc. Most
288 definitions of identity proofing will have a natural ordering, as
289 more or less stringent proofing can be applied to an individual. In
290 such cases it is RECOMMENDED that a digit style value be used for
291 this component and that only a single value be allowed to be
292 communicated in a transaction.
294 2.2. Primary Credential Usage
296 The primary credential usage dimension defines how strongly the
297 primary credential can be verified by the IdP. In other words, how
298 easily that credential could be spoofed or stolen.
300 This dimension SHALL be represented by the "C" demarcator and a
301 single-character level value, such as "Ca", "Cb", etc. Most
302 definitions of credential usage will not have an overall natural
303 ordering, as there may be several equivalent classes described within
304 a trust framework. In such cases it is RECOMMENDED that a letter
305 style value be used for this component and that multiple distinct
306 credential usage factors be allowed to be communicated
307 simultaneously, such as when Multi-Factor Authentication is used.
309 2.3. Primary Credential Management
311 The primary credential management dimension conveys information about
312 the expected lifecycle of the primary credential in use, including
313 its binding, rotation, and revocation. In other words, the use and
314 strength of policies, practices, and security controls used in
315 managing the credential at the IdP and its binding to the intended
316 individual.
318 This dimension SHALL be represented by the "M" demarcator and a
319 single-character level value, such as "Ma", "Mb", etc. Most
320 definitions of credential management will not have an overall natural
321 ordering, though there can be preference and comparison between
322 values in some circumstances. In such cases it is RECOMMENDED that a
323 letter style value be used for this component and that multiple
324 distinct values be allowed to be communicated simultaneously.
326 2.4. Assertion Presentation
328 The Assertion Presentation dimension defines how well the given
329 digital identity can be communicated across the network without
330 information leaking to unintended parties, and without spoofing. In
331 other words, this dimension describes how likely it is that a given
332 digital identity was actually asserted by a given identity provider
333 for a given transaction. While this information is largely already
334 known by the RP as a side effect of processing an identity assertion,
335 this dimension is still very useful when the RP requests a login
336 (Section 5) and when describing the capabilities of an IdP
337 (Section 7).
339 This dimension SHALL be represented by the "A" demarcator and a level
340 value, such as "Aa", "Ab", etc. Most definitions of assertion
341 presentation will not have an overall natural ordering. In such
342 cases, it is RECOMMENDED that a letter style value be used for this
343 component and that multiple values be allowed to be communicated
344 simultaneously.
346 3. Vectors of Trust Default Component Value Definitions
348 This specification defines the following general-purpose component
349 definitions, which MAY be used when a more specific set is
350 unavailable. These component values are referenced in a trustmark
351 definition defined by [[ this document URL ]].
353 Extensions of this specification SHOULD define their own component
354 values as described in Section 8.
356 3.1. Identity Proofing
358 The identity proofing component of this vector definition represents
359 increasing scrutiny during the proofing process. Higher levels are
360 largely subsumptive of lower levels, such that "P2" fulfills
361 requirements for "P1", etc. Mutltiple distinct values from this
362 category MUST NOT be used in a single transaction.
364 P0 No proofing is done, data is not guaranteed to be persistent
365 across sessions
367 P1 Attributes are self-asserted but consistent over time, potentially
368 pseudonymous
370 P2 Identity has been proofed either in person or remotely using
371 trusted mechanisms (such as social proofing)
373 P3 There is a binding relationship between the identity provider and
374 the identified party (such as signed/notarized documents,
375 employment records)
377 3.2. Primary Credential Usage
379 The primary credential usage component of this vector definition
380 represents distinct categories of primary credential that MAY be used
381 together in a single transaction. Multiple distinct values from this
382 category MAY be used in a single transaction.
384 C0 No credential is used / anonymous public service
386 Ca Simple session cookies (with nothing else)
388 Cb Known device
390 Cc Shared secret such as a username and password combination
392 Cd Cryptographic proof of key possession using shared key
394 Ce Cryptographic proof of key possession using asymmetric key
396 Cf Sealed hardware token / trusted biometric / TPM-backed keys
398 3.3. Primary Credential Management
400 The primary credential management component of this vector definition
401 represents distinct categories of management that MAY be considered
402 separately or together in a single transaction. Many trust framework
403 deployments MAY use a single value for this component as a baseline
404 for all transactions and thereby omit it. Multiple distinct values
405 from this category MAY be used in a single transaction.
407 Ma Self-asserted primary credentials (user chooses their own
408 credentials and must rotate or revoke them manually) / no
409 additional verification for primary credential issuance or
410 rotation
412 Mb Remote issuance and rotation / use of backup recover credentials
413 (such as email verification) / deletion on user request
415 Mc Full proofing required for each issuance and rotation / revocation
416 on suspicious activity
418 3.4. Assertion Presentation
420 The assertion presentation component of this vector definition
421 represents distinct categories of assertion which are RECOMMENDED to
422 be used in a subsumptive manner but MAY be used together. Multiple
423 distinct values from this category MAY be used in a single
424 transaction.
426 Aa No protection / unsigned bearer identifier (such as a session
427 cookie in a web browser)
429 Ab Signed and verifiable assertion, passed through the user agent
430 (web browser)
432 Ac Signed and verifiable assertion, passed through a back channel
434 Ad Assertion encrypted to the relying parties key and audience
435 protected
437 4. Communicating Vector Values to RPs
439 A vector of trust is designed to be used in the context of an
440 identity and authentication transaction, providing information about
441 the context of a federated credential. The vector therefore needs to
442 be able to be communicated in the context of the federated credential
443 in a way that is strongly bound to the assertion representing the
444 federated credential.
446 This vector has several requirements for use.
448 o All applicable vector components and values need to be combined
449 into a single vector.
451 o The vector can be communicated across the wire unbroken and
452 untransformed.
454 o All vector components need to remain individually available, not
455 "collapsed" into a single value.
457 o The vector needs to be protected in transit.
459 o The vector needs to be cryptographically bound to the assertion
460 which it is describing.
462 These requirements lead us to defining a simple string-based
463 representation of the vector that can be incorporated within a number
464 of different locations and protocols without further encoding.
466 4.1. On the Wire Representation
468 The vector MUST be represented as a period-separated ('.') list of
469 vector components, with no specific order. A vector component type
470 MAY occur multiple times within a single vector, with each component
471 separated by periods. Multiple values for a component are considered
472 a logical AND of the values. A specific value of a vector component
473 MUST NOT occur more than once in a single vector. That is, while
474 "Cc.Cd" is a valid vector, "Cc.Cc" is not.
476 Vector components MAY be omitted from a vector. No holding space is
477 left for an omitted vector component. If a vector component is
478 omitted, the vector is making no claim for that component. This MAY
479 be distinct from a specific component value stating that a component
480 was not used.
482 Vector values MUST be communicated along side of a trustmark
483 definition to give the components context. The trustmark MUST be
484 cryptographically bound to the vector value, such as in a signed
485 assertion. A vector value without context is unprocessable, and
486 vectors defined in different contexts are not directly comparable as
487 whole values. Different trustmarks MAY re-use component definitions
488 (including their values), allowing comparison of individual
489 components across contexts without requiring complete understanding
490 of all aspects of a context. The proper processing of such cross-
491 context values is outside the scope of this specification.
493 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous,
494 proof of shared key, signed browser-passed verified assertion, and no
495 claim made toward credential management" in the context of this
496 specification's definitions (Section 3). The vector value of
497 "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for
498 issuance and rotation, cryptographic proof of possession of a shared
499 key, signed back-channel verified assertion, and no claim made toward
500 identity proofing" in the same context.
502 4.2. In OpenID Connect
504 In OpenID Connect [OpenID], the IdP MUST send the vector as a string
505 within the "vot" (vector of trust) claim in the ID token. The
506 trustmark (Section 6) that applies to this vector MUST be sent as an
507 HTTPS URL in the "vtm" (vector trust mark) claim to provide context
508 to the vector.
510 For example, the body of an ID token claiming "pseudonymous, proof of
511 shared key, signed back-channel verified token, and no claim made
512 toward credential management" could look like this JSON object
513 payload of the ID token.
515 {
516 "iss": "https://idp.example.com/",
517 "sub": "jondoe1234",
518 "vot": "P1.Cc.Ac",
519 "vtm": "https://trustmark.example.org/trustmark/idp.example.com"
520 }
522 The body of the ID token is signed and optionally encrypted using
523 JOSE, as per the OpenID Connect specification. By putting the "vot"
524 and "vtm" values inside the ID token, the vector and its context are
525 strongly bound to the federated credential represented by the ID
526 token.
528 4.3. In SAML
530 In SAML, a vector is communicated as an
531 "AuthenticationContextDeclRef". A vector is represented by prefixing
532 it with the "urn urn:ietf:param:[TBD]" to form a full URN. The
533 "AuthenticationContextDeclaration" corresponding to a given vector is
534 a "AuthenticationContextDeclaration" element containing an
535 "Extension" element with components of the vector represented by the
536 following XML schema:
538
539
543
544 This represents a set of
545 vector components.
546
547
548
549
550
551
552
553
555 For instance the vector P1.Cc.Ac is represented by the
556 AuthenticationContextDeclRef URN "urn:ietf:param:[TBD]:P1.Cc.Ac" (or
557 "urn:ietf:param:[TBD]:Cc.P1.Ac" or ...) which corresponds to the
558 following "AuthenticationContextDeclaration":
560
561
563
564 P1.Cc.Ac
565
566
568 5. Requesting Vector Values
570 In some identity protocols, the RP can request that particular vector
571 components be applied to a given identity transaction. Using the
572 same syntax as defined in Section 4.1, an RP can indicate that it
573 desires particular aspects be present in the authentication.
574 Processing and fulfillment of these requests are in the purview of
575 the IdP and details are outside the scope of this specification.
577 5.1. In OpenID Connect
579 In OpenID Connect [OpenID], the client MAY request a set of
580 acceptable VoT values with the "vtr" (vector of trust request) claim
581 request as part of the Request Object. The value of this field is an
582 array of JSON strings, each string identifying an acceptable set of
583 vector components. The component values within each vector are ANDed
584 together while the separate vectors are ORed together. For example,
585 a list of vectors in the form "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating
586 that either the full set of "P1 AND Cb AND Cc AND Ab" simultaneously
587 OR the set of "Ce AND Ab" simultaneously are acceptable to this RP
588 for this transaction.
590 Vector request values MAY omit components, indicating that any value
591 is acceptable for that component category, including omission of that
592 component in the response vector.
594 The mechanism by which the IdP processes the "vtr" and maps that to
595 the authentication transaction are out of scope of this
596 specification.
598 5.2. In SAML
600 In SAML (Section 4.3) the client can request a set of acceptable VoT
601 values by including the corresponding "AuthenticationContextDeclRef"
602 URIs together with an "AuthenticationContextClassRef" corresponding
603 to the trust mark (cf below). The processing rules in Section 4.3
604 apply.
606 6. Trustmark
608 When an RP receives a specific vector from an IdP, it needs to make a
609 decision to trust the vector within a specific context. A trust
610 framework can provide such a context, allowing legal and business
611 rules to give weight to an IdP's claims. A trustmark is a verifiable
612 claim to conform to a specific component of a trust framework, such
613 as a verified identity provider. The trustmark conveys the root of
614 trustworthiness about the claims and assertions made by the IdP,
615 including the vector itself.
617 The trustmark MUST be available from an HTTPS URL served by the trust
618 framework provider. The contents of this URL are a JSON [RFC7159]
619 document with the following fields:
621 idp The issuer URL of the identity provider that this trustmark
622 pertains to. This MUST match the corresponding issuer claim in
623 the identity token, such as the OpenID Connect "iss" field. This
624 MUST be an HTTPS URL.
626 trustmark_provider The issuer URL of the trustmark provider that
627 issues this trustmark. The URL that a trustmark is fetched from
628 MUST start with the "iss" URL in this field. This MUST be an
629 HTTPS URL.
631 Vector component values offered by this IdP are be listed in a using
632 their demarcator. For the four component categories defined in this
633 specification:
635 P Array of strings containing identity proofing values for which the
636 identity provider has been assessed and approved.
638 C Array of strings containing primary credential usage values for
639 which the identity provider has been assessed and approved.
641 M Array of strings containing primary credential management values
642 for which the identity provider has been assessed and approved.
644 A Array of strings containing assertion strength values for which
645 the identity provider has been assessed and approved.
647 For example, the following trustmark provided by the
648 trustmark.example.org organization applies to the idp.example.org
649 identity provider:
651 {
652 "idp": "https://idp.example.org/",
653 "trustmark_provider": "https://trustmark.example.org/",
654 "P": ["P0", "P1"],
655 "C": ["C0", "Ca", "Cb"],
656 "M": ["Mb"],
657 "A": ["Ab", "Ac"]
658 }
660 An RP wishing to check the claims made by an IdP can fetch the
661 information from the trustmark provider about what claims the IdP is
662 allowed to make in the first place and process them accordingly. The
663 RP MAY cache the information returned from the trustmark URL.
665 The operational aspects of the IdP MAY be included in the trustmark
666 definition. For example, if a trustmark can indicate that an IdP
667 uses multiple redundant hosts, encrypts all data at rest, or other
668 operational security mechanisms that affect the trustworthiness of
669 assertions made by the IdP. The definition of these additional
670 aspects is outside the scope of this specfication.
672 The means by which the RP decides which trustmark providers it trusts
673 is out of scope for this specification and is generally configured
674 out of band.
676 Though most trust frameworks will provide a third-party independent
677 verification service for components, an IdP MAY host its own
678 trustmark. For example, a self-hosted trustmark would look like:
680 {
681 "idp": "https://idp.example.org/",
682 "trustmark_provider": "https://idp.example.org/",
683 "P": ["P0", "P1"],
684 "C": ["C0", "Ca", "Cb"],
685 "M": ["Mb"],
686 "A": ["Ab", "Ac"]
687 }
689 7. Discovery
691 The IdP MAY list all of its available trustmarks as part of its
692 discovery document, such as the OpenID Connect Discovery server
693 configuration document. In this context, trustmarks are listed in
694 the "trustmarks" element which contains a single JSON [RFC7159]
695 object. The keys of this JSON object are trustmark provider issuer
696 URLs and the values of this object are the corresponding trustmark
697 URLs for this IdP.
699 {
700 "iss": "https://idp.example.org/",
701 "trustmarks": {
702 "https://trustmark.example.org/":
703 "https://trustmark.example.org/trustmark/idp.example.org",
704 "https://trust.example.net/":
705 "https://trust.example.net/trustmark/idp.example.org"
706 }
707 }
709 8. Defining New Vector Values
711 Vectors of Trust is meant to be a flexible and reusable framework for
712 communicating authentication data between networked parties in an
713 identity federation protocol. However, the exact nature of the
714 information needed is reliant on the parties requiring the
715 information and the relationship between them. While this document
716 does define a usable default set of values, it is anticipated that
717 many situations will require an extension of this specification for
718 their own use.
720 Components categories such as those defined in Section 2 are intended
721 to be general purpose and reusable in a variety of circumstances.
722 Extension specifications SHOULD re-use existing category definitions
723 where possible. Extensions MAY create additional categories where
724 needed by using the registry defined in Section 10. The registry
725 encourages re-use and discovery of existing categories across
726 different implementations. In other words, the "P" category in
727 another framework SHOULD be used for identity proofing and related
728 information.
730 The values of components such as those defined in Section 3 are
731 intended to be contextual to the defining trust document. While this
732 specification's component values are intended to be general-purpose
733 and extensions MAY re-use the values and their definitions,
734 extensions MUST define all allowable values. As these values are
735 always interpreted in the context of a trustmark, these values are
736 not recorded in a central registry. Consequently, a "P1" value from
737 one framework and a "P1" value from another framework could have very
738 different interpretations depending on their contextual trustmark
739 documents.
741 Extensions to this specification SHOULD choose either a numerical
742 ordering or a group category approach to component values as
743 described in . Extensions to this specification MUST specify whether
744 multiple values are allowed for each category, and while any
745 component category is generally allowed to have multiple distinct
746 values, a specific definition of a set of values in an extension MAY
747 limit a given component category to a single value per transaction.
749 9. Acknowledgements
751 The authors would like to thank the members of the Vectors of Trust
752 mailing list in the IETF for discussion and feedback on the concept
753 and document, and the members of the ISOC Trust and Identity team for
754 their support.
756 10. IANA Considerations
758 This specification creates one registry and registers several values
759 into existing registries.
761 10.1. Vector Of Trust Components Registry
763 This specification establishes the Vectors of Trust Components
764 Registry.
766 Component demarcators are registered by Specification Required
767 [RFC5226] after a two-week review period on the vot@ietf.org mailing
768 list, on the advice of one or more Designated Experts.
770 Criteria that should be applied by the Designated Experts includes
771 determining whether the proposed registration duplicates existing
772 functionality, whether it is likely to be of general applicability or
773 whether it is useful only for a single application, and whether the
774 registration description is clear.
776 Registration requests sent to the mailing list for review should use
777 an appropriate subject (e.g., "Request to register Vector of Trust
778 Component name: example"). Within the review period, the Designated
779 Expert(s) will either approve or deny the registration request,
780 communicating this decision to the review list and IANA. Denials
781 should include an explanation and, if applicable, suggestions as to
782 how to make the request successful. IANA must only accept registry
783 updates from the Designated Expert(s) and should direct all requests
784 for registration to the review mailing list.
786 10.1.1. Registration Template
788 Demarcator Symbol
789 An uppercase ASCII letter in the range [A-Z] representing this
790 component (e.g., "X").
792 Description:
793 Brief description of the component (e.g., "Example description").
795 Change controller:
796 For Standards Track RFCs, state "IESG". For other documents, give
797 the name of the responsible party. Other details (e.g., postal
798 address, email address, home page URI) may also be included.
800 Specification document(s):
801 Reference to the document(s) that specify the token endpoint
802 authorization method, preferably including a URI that can be used
803 to retrieve a copy of the document(s). An indication of the
804 relevant sections may also be included but is not required.
806 10.1.2. Initial Registry Contents
808 The Vector of Trust Components Registry contains the definitions of
809 vector components and their associated demarcators.
811 o Demarcator Symbol: P
813 o Description: Identity proofing
815 o Change Controller: IESG
817 o Specification document(s):: [[ this document ]]
819 o Demarcator Symbol: C
821 o Description: Primary credential usage
823 o Change Controller: IESG
825 o Specification document(s):: [[ this document ]]
827 o Demarcator Symbol: M
829 o Description: Primary credential management
831 o Change Controller: IESG
833 o Specification document(s):: [[ this document ]]
835 o Demarcator Symbol: A
837 o Description: Assertion presentation
839 o Change Controller: IESG
841 o Specification document(s):: [[ this document ]]
843 10.2. Additions to the OAuth Parameters Registry
845 This specification adds the following values to the OAuth Parameters
846 Registry established by [RFC6749].
848 o Demarcator Symbol: vtr
850 o Description: Vector of Trust request
851 o Change Controller: IESG
853 o Document: [[ this document ]]
855 10.3. Additions to JWT Claims Registry
857 This specification adds the following values to the JSON Web Token
858 Claims Registry established by [RFC7519].
860 o Claim name: vot
862 o Description: Vector of Trust value
864 o Change Controller: IESG
866 o Document: [[ this document ]]
868 o Demarcator Symbol: vtm
870 o Description: Vector of Trust trustmark
872 o Change Controller: IESG
874 o Document: [[ this document ]]
876 11. Security Considerations
878 The vector of trust value MUST be cryptographically protected in
879 transit, using TLS as described in [BCP195]. The vector of trust
880 value must be associated with a trustmark marker, and the two must be
881 carried together in a cryptographically bound mechanism such as a
882 signed identity assertion. A signed OpenID Connect ID Token and a
883 signed SAML assertion both fulfil this requirement.
885 The VoT framework provides a mechanism for describing and conveying
886 trust information. It does not define any policies for asserting the
887 values of the vector, nor does it define any policies for applying
888 the values of a vector to an RP's security decision process. These
889 policies must be agreed upon by the IdP and RP, and they should be
890 expressed in detail in an associated human-readable trust framework
891 document.
893 12. Privacy Considerations
895 By design, vector of trust values contain information about the
896 user's authentication and associations that can be made thereto.
897 Therefore, all aspects of a vector of trust contain potentially
898 privacy-sensitive information and must be guarded as such. Even in
899 the absence of specific attributes about a user, knowledge that the
900 user has been highly proofed or issued a strong token could provide
901 more information about the user than was intended. It is recommended
902 that systems in general use the minimum vectors applicable to their
903 use case in order to prevent inadvertent information disclosure.
905 13. References
907 13.1. Normative References
909 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
910 Core 1.0", November 2014.
912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
913 Requirement Levels", BCP 14, RFC 2119,
914 DOI 10.17487/RFC2119, March 1997,
915 .
917 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
918 IANA Considerations Section in RFCs", RFC 5226,
919 DOI 10.17487/RFC5226, May 2008,
920 .
922 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
923 RFC 6749, DOI 10.17487/RFC6749, October 2012,
924 .
926 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
927 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
928 2014, .
930 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
931 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
932 .
934 13.2. Informative References
936 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
937 "Recommendations for Secure Use of Transport Layer
938 Security (TLS) and Datagram Transport Layer Security
939 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
940 2015, .
942 [SP-800-63-2]
943 and , "Electronic Authentication Guideline", August 2013,
944 .
946 [SP-800-63-3]
947 and , "Electronic Authentication Guideline", June 2017,
948 .
950 Appendix A. Document History
952 -06
954 o Added section on extensions to VoT.
956 o Made it so that every component category could be multi-valued.
958 o Added reference to updated 800-63-3.
960 o Fixed example text width.
962 o Switched document back to standards-track from experimental now
963 that there are extensions in the wild.
965 -05
967 o Updated IANA considerations section to include instructions.
969 o Made security and privacy considerations non-normative.
971 -04
973 o Updated SAML example to be consistent.
975 -03
977 o Clarified language of LoA's in introduction.
979 o Added note on operational security in trustmarks.
981 o Removed empty sections and references.
983 -02
985 o Converted C, M, and A values to use letters instead of numbers in
986 examples.
988 o Updated SAML to a structured example pending future updates.
990 o Defined guidance for when to use letters vs. numbers in category
991 values.
993 o Restricted category demarcators to uppercase and values to
994 lowercase and digits.
996 o Applied clarifying editorial changes from list comments.
998 - 01
1000 o Added IANA registry for components.
1002 o Added preliminary security considerations and privacy
1003 considerations.
1005 o Split "credential binding" into "primary credential usage" and
1006 "primary credential management".
1008 - 00
1010 o Created initial IETF drafted based on strawman proposal discussed
1011 on VoT list.
1013 o Split vector component definitions into their own section to allow
1014 extension and override.
1016 o Solidified trustmark document definition.
1018 Authors' Addresses
1020 Justin Richer (editor)
1021 Bespoke Engineering
1023 Email: ietf@justin.richer.org
1025 Leif Johansson
1026 Swedish University Network
1027 Thulegatan 11
1028 Stockholm
1029 Sweden
1031 Email: leifj@sunet.se
1032 URI: http://www.sunet.se