idnits 2.17.1
draft-richer-vectors-of-trust-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 3 instances of too long lines in the document, the longest one
being 29 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (April 3, 2017) is 2551 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'A-Z' is mentioned on line 731, but not defined
** 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Richer, Ed.
3 Internet-Draft Bespoke Engineering
4 Intended status: Experimental L. Johansson
5 Expires: October 5, 2017 Swedish University Network
6 April 3, 2017
8 Vectors of Trust
9 draft-richer-vectors-of-trust-05
11 Abstract
13 This document defines a mechanism for describing and signaling
14 several aspects that are used to calculate trust placed in a digital
15 identity transaction.
17 Requirements Language
19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
21 "OPTIONAL" in this document are to be interpreted as described in RFC
22 2119 [RFC2119].
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on October 5, 2017.
41 Copyright Notice
43 Copyright (c) 2017 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
60 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5
61 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5
62 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 5
63 2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6
64 2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 7
65 2.3. Primary Credential Management . . . . . . . . . . . . . . 7
66 2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 7
67 3. Vectors of Trust Initial Component Value Definitions . . . . 8
68 3.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 8
69 3.2. Primary Credential Usage . . . . . . . . . . . . . . . . 8
70 3.3. Primary Credential Management . . . . . . . . . . . . . . 9
71 3.4. Assertion Presentation . . . . . . . . . . . . . . . . . 9
72 4. Communicating Vector Values to RPs . . . . . . . . . . . . . 10
73 4.1. On the Wire Representation . . . . . . . . . . . . . . . 10
74 4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11
75 4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 11
76 5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 12
77 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 12
78 5.2. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 13
79 6. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . . . 13
80 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 15
81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
83 9.1. Vector Of Trust Components Registry . . . . . . . . . . . 15
84 9.1.1. Registration Template . . . . . . . . . . . . . . . . 16
85 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 16
86 9.1.3. Additions to JWT Claims Registry . . . . . . . . . . 17
87 9.1.4. Additions to the OAuth . . . . . . . . . . . . . . . 18
88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
89 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
91 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
92 12.2. Informative References . . . . . . . . . . . . . . . . . 19
93 Appendix A. Document History . . . . . . . . . . . . . . . . . . 19
94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
96 1. Introduction
98 This document defines a mechanism for measuring and signaling several
99 aspects of digital identity and authentication transactions that are
100 used to determine a level of trust in that transaction. In the past,
101 there have been two extremes of communicating authentication
102 transaction information.
104 At one extreme, all attributes can be communicated with full
105 provenance and associated trust markings. This approach seeks to
106 create a fully-distributed attribute system to support functions such
107 as attribute based access control (ABAC). These attributes can be
108 used to describe the end user, the identity provider, the relying
109 party, or even the transaction itself. While the information that
110 can be expressed in this model is incredibly detailed and robust, the
111 complexity of such a system is often prohibitive to realize,
112 especially across security domains. In particular, a large burden is
113 placed on relying parties needing to process the sea of disparate
114 attributes when making a security decision.
116 At the other extreme there are systems that collapse all of the
117 attributes and aspects into a single scalar value that communicates,
118 in sum, how much a transaction can be trusted. The NIST special
119 publication 800-63 [SP-800-63-2] version 2 defines a linear scale
120 Level of Assurance (LoA) measure that combines multiple attributes
121 about an identity transaction into such a single measure. While this
122 definition was originally narrowly targeted for a specific set of
123 government use cases, the LoA scale appeared to be applicable with a
124 wide variety of authentication scenarios in different domains. This
125 has led to a proliferation of incompatible interpretations of the
126 same scale in different contexts, preventing interoperability between
127 each LoA definition in spite of their common measurement. LoA is
128 artificially limited due to the original goal of creating a single
129 linear scale. Since identity proofing strength increases linearly
130 along with credential strength in the LoA scale, this scale is too
131 limited for describing many valid and useful forms of an identity
132 transaction that do not fit the government's original model. For
133 example, an anonymously assigned hardware token can be used in cases
134 where the real world identity of the subject cannot be known for
135 privacy reasons, but the credential itself can be highly trusted.
136 This is in contrast with a government employee accessing a government
137 system, where the identity of the individual would need to be highly
138 proofed and strongly credentialed at the same time.
140 The Vectors of Trust (VoT) effort seeks to find a balance between
141 these two extremes by creating a data model that combines attributes
142 of the user and aspects of the authentication context into several
143 values that can be communicated separately but in parallel with each
144 other. This approach is both coarser grained than the distributed
145 attributes model and finer grained than the single scalar model, with
146 the hope that it is a viable balance of expressibility and
147 processability. Importantly, these three levels of granularity can
148 be mapped to each other. The information of several attributes can
149 be folded into a vector component, while the vector itself can be
150 folded into an assurance category. As such, the vectors of trust
151 seeks to complement, not replace, these other identity and trust
152 mechanisms in the larger identity ecosystem while providing a single
153 value for RPs to process.
155 1.1. Terminology
157 Identity Provider (IdP) A system that manages identity information
158 and is able to assert this information across the network through
159 an identity API.
161 Identity Subject The person (user) engaging in the identity
162 transaction, being identified by the identity provider and
163 identified to the relying party.
165 Primary Credential The means used by the identity subject to
166 authenticate to the identity provider.
168 Federated Credential The assertion presented by the IdP to the RP
169 across the network to authenticate the user.
171 Relying Party (RP) A system that consumes identity information from
172 an IdP for the purposes of authenticating the user.
174 Trust Framework A document containing business rules and legal
175 clauses that defines how different parties in an identity
176 transaction may act.
178 Trustmark A verifiable attestation that a party has proved to follow
179 the constraints of a trust framework.
181 Trustmark Provider A system that issues and provides verification
182 for trustmarks.
184 Vector A multi-part data structure, used here for conveying
185 information about an authentication transaction.
187 Vector Component One of several constituent parts that make up a
188 vector.
190 1.2. An Identity Model
192 This document assumes the following model for identity based on
193 identity federation technologies:
195 The identity subject (also known as the user) is associated with an
196 identity provider which acts as a trusted third party on behalf of
197 the user with regard to a relying party by making identity assertions
198 about the user to the relying party.
200 The real-world person represented by the identity subject is in
201 possession of a primary credential bound to the identity subject by
202 the identity provider (or an agent thereof) in such a way that the
203 binding between the credential and the real-world user is a
204 representation of the identity proofing process performed by the
205 identity provider (or an agent thereof) to verify the identity of the
206 real-world person. This is all carried by an identity assertion
207 across the network to the relying party during the authentication
208 transaction.
210 1.3. Component Architecture
212 The term Vectors of Trust is based on the mathematical construct of a
213 vector, which is defined as an item composed of multiple independent
214 values.
216 An important goal for this work is to balance the need for simplicity
217 (particularly on the part of the relying party) with the need for
218 expressiveness. As such, this vector construct is designed to be
219 composable and extensible.
221 All components of the vector construct MUST be orthogonal such that
222 no aspect of a component overlaps an aspect of another component, as
223 much as is possible.
225 2. Component Definitions
227 This specification defines four orthogonal components: identity
228 proofing, primary credential usage, primary credential management,
229 and assertion presentation. These dimensions MUST be evaluated by
230 the RP in the context of a trust framework and SHOULD be combined
231 with other information when making a trust and authorization
232 decision.
234 This specification also defines values for each component to be used
235 in the absence of a more specific trust framework in Section 3. It
236 is expected that trust frameworks will provide context, semantics,
237 and mapping to legal statutes and business rules for each value in
238 each component. Consequently, a particular vector value can only be
239 compared with vectors defined in the same context. The RP MUST
240 understand and take into account the trust framework context in which
241 a vector is being expressed in order for it to be processed securely.
243 Each component is identified by a demarcator consisting of a single
244 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD
245 reflect the category with which it is associated in a natural manner.
246 Demarcators for components MUST be registered as described in
247 Section 9. It is anticipated that trust framework definitions will
248 use this registry to define specialized components, though it is
249 RECOMMENDED that trust frameworks re-use existing components wherever
250 possible.
252 The value for a given component within a vector of trust is defined
253 by its demarcator character followed by a single digit or lowercase
254 ASCII letter in the range "[0-9a-z]". Categories which have a
255 natural ordering SHOULD use digits, with "0" as the lowest value.
256 Categories which do not have a natural ordering, or which can have an
257 ambiguous ordering, SHOULD use letters. Categories MAY use both
258 letter style and number style value indicators. For example, a
259 category could define "0" as a special "empty" value while using
260 letters such as "a", "b", "c" for normal values can to differentiate
261 between these types of options.
263 Regardless of the type of value indicator used, the values assigned
264 to each component of a vector MUST NOT be assumed always to have
265 inherent ordinal properties when compared to the same or other
266 components in the vector space. In other words, "1" is different
267 from "2", but it is dangerous to assume that "2" is always better
268 than "1" in a given transaction.
270 2.1. Identity Proofing
272 The Identity Proofing dimension defines, overall, how strongly the
273 set of identity attributes have been verified and vetted. In other
274 words, this dimension describes how likely it is that a given digital
275 identity transaction corresponds to a particular (real-world)
276 identity subject.
278 This dimension SHALL be represented by the "P" demarcator and a
279 single-character level value, such as "P0", "P1", etc. Most
280 definitions of identity proofing will have a natural ordering, as
281 more or less stringent proofing can be applied to an individual. In
282 such cases it is RECOMMENDED that a digit style value be used for
283 this component.
285 2.2. Primary Credential Usage
287 The primary credential usage dimension defines how strongly the
288 primary credential can be verified by the IdP. In other words, how
289 easily that credential could be spoofed or stolen.
291 This dimension SHALL be represented by the "C" demarcator and a
292 single-character level value, such as "Ca", "Cb", etc. Most
293 definitions of credential usage will not have an overall natural
294 ordering, as there may be several equivalent classes described within
295 a trust framework. In such cases it is RECOMMENDED that a letter
296 style value be used for this component. Multiple credential usage
297 factors MAY be communicated simultaneously, such as when Multi-Factor
298 Authentication is used.
300 2.3. Primary Credential Management
302 The primary credential management dimension conveys information about
303 the expected lifecycle of the primary credential in use, including
304 its binding, rotation, and revocation. In other words, the use and
305 strength of policies, practices, and security controls used in
306 managing the credential at the IdP and its binding to the intended
307 individual.
309 This dimension SHALL be represented by the "M" demarcator and a
310 single-character level value, such as "Ma", "Mb", etc. Most
311 definitions of credential management will not have an overall natural
312 ordering, though there can be preference and comparison between
313 values in some circumstances. In such cases it is RECOMMENDED that a
314 letter style value be used for this component.
316 2.4. Assertion Presentation
318 The Assertion Presentation dimension defines how well the given
319 digital identity can be communicated across the network without
320 information leaking to unintended parties, and without spoofing. In
321 other words, this dimension describes how likely it is that a given
322 digital identity was actually asserted by a given identity provider
323 for a given transaction. While this information is largely already
324 known by the RP as a side effect of processing an identity assertion,
325 this dimension is still very useful when the RP requests a login
326 (Section 5) and when describing the capabilities of an IdP
327 (Section 7).
329 This dimension SHALL be represented by the "A" demarcator and a level
330 value, such as "Aa", "Ab", etc. Most definitions of assertion
331 presentation will not have an overall natural ordering. In such
332 cases, it is RECOMMENDED that a letter style value be used for this
333 component.
335 3. Vectors of Trust Initial Component Value Definitions
337 This specification defines the following general-purpose component
338 definitions, which MAY be used when a more specific set is
339 unavailable. These component values are referenced in a trustmark
340 definition defined by [[ this document URL ]].
342 It is anticipated that trust frameworks and specific applications of
343 this specification will define their own component values. In order
344 to simplify processing by RPs, it is RECOMMENDED that trust framework
345 definitions carefully define component values such that they are
346 mutually exclusive or subsumptive in order to avoid repeated vector
347 components where possible.
349 3.1. Identity Proofing
351 The identity proofing component of this vector definition represents
352 increasing scrutiny during the proofing process. Higher levels are
353 largely subsumptive of lower levels, such that "P2" fulfills
354 requirements for "P1", etc.
356 P0 No proofing is done, data is not guaranteed to be persistent
357 across sessions
359 P1 Attributes are self-asserted but consistent over time, potentially
360 pseudonymous
362 P2 Identity has been proofed either in person or remotely using
363 trusted mechanisms (such as social proofing)
365 P3 There is a binding relationship between the identity provider and
366 the identified party (such as signed/notarized documents,
367 employment records)
369 3.2. Primary Credential Usage
371 The primary credential usage component of this vector definition
372 represents distinct categories of primary credential that MAY be used
373 together in a single transaction.
375 C0 No credential is used / anonymous public service
377 Ca Simple session cookies (with nothing else)
379 Cb Known device
380 Cc Shared secret such as a username and password combination
382 Cd Cryptographic proof of key possession using shared key
384 Ce Cryptographic proof of key possession using asymmetric key
386 Cf Sealed hardware token / trusted biometric / TPM-backed keys
388 3.3. Primary Credential Management
390 The primary credential management component of this vector definition
391 represents distinct categories of management that MAY be considered
392 separately or together in a single transaction. Many trust framework
393 deployments MAY use a single value for this component as a baseline
394 for all transactions and thereby omit it.
396 Ma Self-asserted primary credentials (user chooses their own
397 credentials and must rotate or revoke them manually) / no
398 additional verification for primary credential issuance or
399 rotation
401 Mb Remote issuance and rotation / use of backup recover credentials
402 (such as email verification) / deletion on user request
404 Mc Full proofing required for each issuance and rotation / revocation
405 on suspicious activity
407 3.4. Assertion Presentation
409 The assertion presentation component of this vector definition
410 represents distinct categories of assertion which are RECOMMENDED to
411 be used in a subsumptive manner but MAY be used together.
413 Aa No protection / unsigned bearer identifier (such as a session
414 cookie in a web browser)
416 Ab Signed and verifiable assertion, passed through the user agent
417 (web browser)
419 Ac Signed and verifiable assertion, passed through a back channel
421 Ad Assertion encrypted to the relying parties key and audience
422 protected
424 4. Communicating Vector Values to RPs
426 A vector of trust is designed to be used in the context of an
427 identity and authentication transaction, providing information about
428 the context of a federated credential. The vector therefore needs to
429 be able to be communicated in the context of the federated credential
430 in a way that is strongly bound to the assertion representing the
431 federated credential.
433 This vector has several requirements for use.
435 o All applicable vector components and values need to be combined
436 into a single vector.
438 o The vector can be communicated across the wire unbroken and
439 untransformed.
441 o All vector components need to remain individually available, not
442 "collapsed" into a single value.
444 o The vector needs to be protected in transit.
446 o The vector needs to be cryptographically bound to the assertion
447 which it is describing.
449 These requirements lead us to defining a simple string-based
450 representation of the vector that can be incorporated within a number
451 of different locations and protocols without further encoding.
453 4.1. On the Wire Representation
455 The vector MUST be represented as a period-separated ('.') list of
456 vector components, with no specific order. A vector component type
457 MAY occur multiple times within a single vector, with each component
458 separated by periods. Multiple values for a component are considered
459 a logical AND of the values. A specific value of a vector component
460 MUST NOT occur more than once in a single vector. That is, while
461 "Cc.Cd" is a valid vector, "Cc.Cc" is not.
463 Vector components MAY be omitted from a vector. No holding space is
464 left for an omitted vector component. If a vector component is
465 omitted, the vector is making no claim for that component. This MAY
466 be distinct from a specific component value stating that a component
467 was not used.
469 Vector values MUST be communicated along side of a trustmark
470 definition to give the components context. The trustmark MUST be
471 cryptographically bound to the vector value, such as in a signed
472 assertion. A vector value without context is unprocessable, and
473 vectors defined in different contexts are not directly comparable as
474 whole values. Different trustmarks MAY re-use component definitions
475 (including their values), allowing comparison of individual
476 components across contexts without requiring complete understanding
477 of all aspects of a context. The proper processing of such cross-
478 context values is outside the scope of this specification.
480 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous,
481 proof of shared key, signed browser-passed verified assertion, and no
482 claim made toward credential management" in the context of this
483 specification's definitions (Section 3). The vector value of
484 "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for
485 issuance and rotation, cryptographic proof of possession of a shared
486 key, signed back-channel verified assertion, and no claim made toward
487 identity proofing" in the same context.
489 4.2. In OpenID Connect
491 In OpenID Connect [OpenID], the IdP MUST send the vector as a string
492 within the "vot" (vector of trust) claim in the ID token. The
493 trustmark (Section 6) that applies to this vector MUST be sent as an
494 HTTPS URL in the "vtm" (vector trust mark) claim to provide context
495 to the vector.
497 For example, the body of an ID token claiming "pseudonymous, proof of
498 shared key, signed back-channel verified token, and no claim made
499 toward credential management" could look like this JSON object
500 payload of the ID token.
502 {
503 "iss": "https://idp.example.com/",
504 "sub": "jondoe1234",
505 "vot": "P1.Cc.Ac",
506 "vtm": "https://trustmark.example.org/trustmark/idp.example.com"
507 }
509 The body of the ID token is signed and optionally encrypted using
510 JOSE, as per the OpenID Connect specification. By putting the "vot"
511 and "vtm" values inside the ID token, the vector and its context are
512 strongly bound to the federated credential represented by the ID
513 token.
515 4.3. In SAML
517 In SAML, a vector is communicated as an AuthenticationContextDeclRef.
518 A vector is represented by prefixing it with the urn
519 urn:ietf:param:[TBD] to form a full URN. The
520 AuthenticationContextDeclaration corresponding to a given vector is a
521 AuthenticationContextDeclaration element containing an Extension
522 element with components of the vector represented by the following
523 XML schema:
525
526
530
531 This represents a set of vector components.
532
533
534
535
536
537
538
539
541 For instance the vector P1.Cc.Ac is represented by the
542 AuthenticationContextDeclRef URN urn:ietf:param:[TBD]:P1.Cc.Ac (or
543 urn:ietf:param:[TBD]:Cc.P1.Ac or ...) which corresponds to the
544 following AuthenticationContextDeclaration:
546
547
548
549 P1.Cc.Ac
550
551
553 5. Requesting Vector Values
555 In some identity protocols, the RP can request that particular vector
556 components be applied to a given identity transaction. Using the
557 same syntax as defined in Section 4.1, an RP can indicate that it
558 desires particular aspects be present in the authentication.
559 Processing and fulfillment of these requests are in the purview of
560 the IdP and details are outside the scope of this specification.
562 5.1. In OpenID Connect
564 In OpenID Connect [OpenID], the client MAY request a set of
565 acceptable VoT values with the "vtr" (vector of trust request) claim
566 request as part of the Request Object. The value of this field is an
567 array of JSON strings, each string identifying an acceptable set of
568 vector components. The component values within each vector are ANDed
569 together while the separate vectors are ORed together. For example,
570 a list of vectors in the form "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating
571 that either the full set of "P1 AND Cb AND Cc AND Ab" simultaneously
572 OR the set of "Ce AND Ab" simultaneously are acceptable to this RP
573 for this transaction.
575 Vector request values MAY omit components, indicating that any value
576 is acceptable for that component category, including omission of that
577 component in the response vector.
579 The mechanism by which the IdP processes the "vtr" and maps that to
580 the authentication transaction are out of scope of this
581 specification.
583 5.2. In SAML
585 In SAML (Section 4.3) the client can request a set of acceptable VoT
586 values by including the corresponding AuthenticationContextDeclRef
587 URIs together with an AuthenticationContextClassRef corresponding to
588 the trust mark (cf below). The processing rules in Section 4.3
589 apply.
591 6. Trustmark
593 When an RP receives a specific vector from an IdP, it needs to make a
594 decision to trust the vector within a specific context. A trust
595 framework can provide such a context, allowing legal and business
596 rules to give weight to an IdP's claims. A trustmark is a verifiable
597 claim to conform to a specific component of a trust framework, such
598 as a verified identity provider. The trustmark conveys the root of
599 trustworthiness about the claims and assertions made by the IdP,
600 including the vector itself.
602 The trustmark MUST be available from an HTTPS URL served by the trust
603 framework provider. The contents of this URL are a JSON [RFC7159]
604 document with the following fields:
606 idp The issuer URL of the identity provider that this trustmark
607 pertains to. This MUST match the corresponding issuer claim in
608 the identity token, such as the OpenID Connect "iss" field. This
609 MUST be an HTTPS URL.
611 trustmark_provider The issuer URL of the trustmark provider that
612 issues this trustmark. The URL that a trustmark is fetched from
613 MUST start with the "iss" URL in this field. This MUST be an
614 HTTPS URL.
616 Vector component values offered by this IdP are be listed in a using
617 their demarcator. For the four component categories defined in this
618 specification:
620 P Array of strings containing identity proofing values for which the
621 identity provider has been assessed and approved.
623 C Array of strings containing primary credential usage values for
624 which the identity provider has been assessed and approved.
626 M Array of strings containing primary credential management values
627 for which the identity provider has been assessed and approved.
629 A Array of strings containing assertion strength values for which
630 the identity provider has been assessed and approved.
632 For example, the following trustmark provided by the
633 trustmark.example.org organization applies to the idp.example.org
634 identity provider:
636 {
637 "idp": "https://idp.example.org/",
638 "trustmark_provider": "https://trustmark.example.org/",
639 "P": ["P0", "P1"],
640 "C": ["C0", "Ca", "Cb"],
641 "M": ["Mb"],
642 "A": ["Ab", "Ac"]
643 }
645 An RP wishing to check the claims made by an IdP can fetch the
646 information from the trustmark provider about what claims the IdP is
647 allowed to make in the first place and process them accordingly. The
648 RP MAY cache the information returned from the trustmark URL.
650 The operational aspects of the IdP MAY be included in the trustmark
651 definition. For example, if a trustmark can indicate that an IdP
652 uses multiple redundant hosts, encrypts all data at rest, or other
653 operational security mechanisms that affect the trustworthiness of
654 assertions made by the IdP. The definition of these additional
655 aspects is outside the scope of this specfication.
657 The means by which the RP decides which trustmark providers it trusts
658 is out of scope for this specification and is generally configured
659 out of band.
661 Though most trust frameworks will provide a third-party independent
662 verification service for components, an IdP MAY host its own
663 trustmark. For example, a self-hosted trustmark would look like:
665 {
666 "idp": "https://idp.example.org/",
667 "trustmark_provider": "https://idp.example.org/",
668 "P": ["P0", "P1"],
669 "C": ["C0", "Ca", "Cb"],
670 "M": ["Mb"],
671 "A": ["Ab", "Ac"]
672 }
674 7. Discovery
676 The IdP MAY list all of its available trustmarks as part of its
677 discovery document, such as the OpenID Connect Discovery server
678 configuration document. In this context, trustmarks are listed in
679 the "trustmarks" element which contains a single JSON [RFC7159]
680 object. The keys of this JSON object are trustmark provider issuer
681 URLs and the values of this object are the corresponding trustmark
682 URLs for this IdP.
684 {
685 "iss": "https://idp.example.org/",
686 "trustmark": {
687 "https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/"
688 }
689 }
691 8. Acknowledgements
693 The authors would like to thank the members of the Vectors of Trust
694 mailing list in the IETF for discussion and feedback on the concept
695 and document, and the members of the ISOC Trust and Identity team for
696 their support.
698 9. IANA Considerations
700 This specification creates one registry and registers several values
701 into existing registries.
703 9.1. Vector Of Trust Components Registry
705 This specification establishes the Vectors of Trust Components
706 Registry.
708 Component demarcators are registered by Specification Required
709 [RFC5226] after a two-week review period on the vot@ietf.org mailing
710 list, on the advice of one or more Designated Experts.
712 Criteria that should be applied by the Designated Experts includes
713 determining whether the proposed registration duplicates existing
714 functionality, whether it is likely to be of general applicability or
715 whether it is useful only for a single application, and whether the
716 registration description is clear.
718 Registration requests sent to the mailing list for review should use
719 an appropriate subject (e.g., "Request to register Vector of Trust
720 Component name: example"). Within the review period, the Designated
721 Expert(s) will either approve or deny the registration request,
722 communicating this decision to the review list and IANA. Denials
723 should include an explanation and, if applicable, suggestions as to
724 how to make the request successful. IANA must only accept registry
725 updates from the Designated Expert(s) and should direct all requests
726 for registration to the review mailing list.
728 9.1.1. Registration Template
730 Demarcator Symbol
731 An uppercase ASCII letter in the range [A-Z] representing this
732 component (e.g., "X").
734 Description:
735 Brief description of the component (e.g., "Example description").
737 Change controller:
738 For Standards Track RFCs, state "IESG". For other documents, give
739 the name of the responsible party. Other details (e.g., postal
740 address, email address, home page URI) may also be included.
742 Specification document(s):
743 Reference to the document(s) that specify the token endpoint
744 authorization method, preferably including a URI that can be used
745 to retrieve a copy of the document(s). An indication of the
746 relevant sections may also be included but is not required.
748 9.1.2. Initial Registry Contents
750 The Vector of Trust Components Registry contains the definitions of
751 vector components and their associated demarcators.
753 o Demarcator Symbol: P
755 o Description: Identity proofing
757 o Change Controller: IESG
759 o Specification document(s):: [[ this document ]]
760 o Demarcator Symbol: C
762 o Description: Primary credential usage
764 o Change Controller: IESG
766 o Specification document(s):: [[ this document ]]
768 o Demarcator Symbol: M
770 o Description: Primary credential management
772 o Change Controller: IESG
774 o Specification document(s):: [[ this document ]]
776 o Demarcator Symbol: A
778 o Description: Assertion presentation
780 o Change Controller: IESG
782 o Specification document(s):: [[ this document ]]
784 9.1.3. Additions to JWT Claims Registry
786 This specification adds the following values to the JSON Web Token
787 Claims Registry established by [RFC7519].
789 o Claim name: vot
791 o Description: Vector of Trust value
793 o Change Controller: IESG
795 o Document: [[ this document ]]
797 o Demarcator Symbol: vtm
799 o Description: Vector of Trust trustmark
801 o Change Controller: IESG
803 o Document: [[ this document ]]
805 9.1.4. Additions to the OAuth
807 This specification adds the following values to the OAuth Parameters
808 Registry established by [RFC6749].
810 o Demarcator Symbol: vtr
812 o Description: Vector of Trust request
814 o Change Controller: IESG
816 o Document: [[ this document ]]
818 10. Security Considerations
820 The vector of trust value MUST be cryptographically protected in
821 transit, using TLS as described in [BCP195]. The vector of trust
822 value must be associated with a trustmark marker, and the two must be
823 carried together in a cryptographically bound mechanism such as a
824 signed identity assertion. A signed OpenID Connect ID Token and a
825 signed SAML assertion both fulfil this requirement.
827 The VoT framework provides a mechanism for describing and conveying
828 trust information. It does not define any policies for asserting the
829 values of the vector, nor does it define any policies for applying
830 the values of a vector to an RP's security decision process. These
831 policies must be agreed upon by the IdP and RP, and they should be
832 expressed in detail in an associated human-readable trust framework
833 document.
835 11. Privacy Considerations
837 By design, vector of trust values contain information about the
838 user's authentication and associations that can be made thereto.
839 Therefore, all aspects of a vector of trust contain potentially
840 privacy-sensitive information and must be guarded as such. Even in
841 the absence of specific attributes about a user, knowledge that the
842 user has been highly proofed or issued a strong token could provide
843 more information about the user than was intended. It is recommended
844 that systems in general use the minimum vectors applicable to their
845 use case in order to prevent inadvertent information disclosure.
847 12. References
848 12.1. Normative References
850 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
851 Core 1.0", November 2014.
853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
854 Requirement Levels", BCP 14, RFC 2119,
855 DOI 10.17487/RFC2119, March 1997,
856 .
858 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
859 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
860 DOI 10.17487/RFC5226, May 2008,
861 .
863 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
864 RFC 6749, DOI 10.17487/RFC6749, October 2012,
865 .
867 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
868 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
869 2014, .
871 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
872 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
873 .
875 12.2. Informative References
877 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
878 "Recommendations for Secure Use of Transport Layer
879 Security (TLS) and Datagram Transport Layer Security
880 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
881 2015, .
883 [SP-800-63-2]
884 , , , , , , and , "Electronic Authentication Guideline",
885 August 2013.
887 Appendix A. Document History
889 -05
891 o Updated IANA considerations section to include instructions.
893 o Made security and privacy considerations non-normative.
895 -04
896 o Updated SAML example to be consistent.
898 -03
900 o Clarified language of LoA's in introduction.
902 o Added note on operational security in trustmarks.
904 o Removed empty sections and references.
906 -02
908 o Converted C, M, and A values to use letters instead of numbers in
909 examples.
911 o Updated SAML to a structured example pending future updates.
913 o Defined guidance for when to use letters vs. numbers in category
914 values.
916 o Restricted category demarcators to uppercase and values to
917 lowercase and digits.
919 o Applied clarifying editorial changes from list comments.
921 - 01
923 o Added IANA registry for components.
925 o Added preliminary security considerations and privacy
926 considerations.
928 o Split "credential binding" into "primary credential usage" and
929 "primary credential management".
931 - 00
933 o Created initial IETF drafted based on strawman proposal discussed
934 on VoT list.
936 o Split vector component definitions into their own section to allow
937 extension and override.
939 o Solidified trustmark document definition.
941 Authors' Addresses
943 Justin Richer (editor)
944 Bespoke Engineering
946 Email: ietf@justin.richer.org
948 Leif Johansson
949 Swedish University Network
950 Thulegatan 11
951 Stockholm
952 Sweden
954 Email: leifj@sunet.se
955 URI: http://www.sunet.se