idnits 2.17.1
draft-richer-vectors-of-trust-02.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 5 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 (November 12, 2015) is 3087 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
** 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 (~~), 1 warning (==), 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: May 15, 2016 Swedish University Network
6 November 12, 2015
8 Vectors of Trust
9 draft-richer-vectors-of-trust-02
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 May 15, 2016.
41 Copyright Notice
43 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . 13
77 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . 16
84 9.2. Additions to JWT Claims Registry . . . . . . . . . . . . 16
85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
86 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
88 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
89 12.2. Informative References . . . . . . . . . . . . . . . . . 17
90 Appendix A. Document History . . . . . . . . . . . . . . . . . . 18
91 Appendix B. Example Extension . . . . . . . . . . . . . . . . . 18
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
94 1. Introduction
96 This document defines a mechanism for measuring and signaling several
97 aspects of digital identity and authentication transactions that are
98 used to determine a level of trust in that transaction. In the past,
99 there have been two extremes of communicating authentication
100 transaction information.
102 At one extreme, all attributes can be communicated with full
103 provenance and associated trust markings. This approach seeks to
104 create a fully-distributed attribute system to support functions such
105 as attribute based access control (ABAC). These attributes can be
106 used to describe the end user, the identity provider, the relying
107 party, or even the transaction itself. While the information that
108 can be expressed in this model is incredibly detailed and robust, the
109 complexity of such a system is often prohibitive to realize,
110 especially across security domains. In particular, a large burden is
111 placed on relying parties needing to process the sea of disparate
112 attributes when making a security decision.
114 At the other extreme there are systems that collapse all of the
115 attributes and aspects into a single scalar value that communicates,
116 in sum, how much a transaction can be trusted. The NIST special
117 publication 800-63 [SP-800-63] defines a linear scale Level of
118 Assurance (LoA) measure that combines multiple attributes about an
119 identity transaction into such a single measure. While this
120 definition was originally narrowly targeted for a specific set of
121 government use cases, the LoA scale appeared to be applicable with a
122 wide variety of authentication scenarios in different domains. This
123 has led to a proliferation of incompatible interpretations of the
124 same scale in different contexts, preventing interoperability between
125 these contexts in spite of their common measurement. This system is
126 also artificially limited due to its original goals: since identity
127 proofing strength increases linearly along with credential strength
128 in the LoA scale, this scale is too limited for describing many valid
129 and useful forms of an identity transaction that do not fit the
130 government's original model. For example, an anonymously assigned
131 hardware token can be used in cases where the real world identity of
132 the subject cannot be known, for privacy reasons, but the credential
133 itself can be highly trusted. This is in contrast with a government
134 employee accessing a government system, where the identity of the
135 individual would need to be highly proofed and strongly credentialed
136 at the same time.
138 The Vectors of Trust (VoT) effort seeks to find a balance between
139 these two extremes by creating a data model that combines attributes
140 of the user and aspects of the authentication context into several
141 values that can be communicated separately but in parallel with each
142 other. This approach is both coarser grained than the distributed
143 attributes model and finer grained than the single scalar model, with
144 the hope that it is a viable balance of expressibility and
145 processability. Importantly, these three levels of granularity can
146 be mapped to each other. The information of several attributes can
147 be folded into a vector component, while the vector itself can be
148 folded into an assurance category. As such, the vectors of trust
149 seeks to complement, not replace, these other identity and trust
150 mechanisms in the larger identity ecosystem while providing a single
151 value for RPs to process.
153 1.1. Terminology
155 Identity Provider (IdP) A system that manages identity information
156 and is able to assert this information across the network through
157 an identity API.
159 Identity Subject The person (user) engaging in the identity
160 transaction, being identified by the identity provider and
161 identified to the relying party.
163 Primary Credential The means used by the identity subject to
164 authenticate to the identity provider.
166 Federated Credential The assertion presented by the IdP to the RP
167 across the network to authenticate the user.
169 Relying Party (RP) A system that consumes identity information from
170 an IdP for the purposes of authenticating the user.
172 Trust Framework A document containing business rules and legal
173 clauses that defines how different parties in an identity
174 transaction may act.
176 Trustmark A verifiable attestation that a party has proved to follow
177 the constraints of a trust framework.
179 Trustmark Provider A system that issues and provides verification
180 for trustmarks.
182 Vector A multi-part data structure, used here for conveying
183 information about an authentication transaction.
185 Vector Component One of several constituent parts that make up a
186 vector.
188 1.2. An Identity Model
190 This document assumes the following model for identity based on
191 identity federation technologies:
193 The identity subject (also known as the user) is associated with an
194 identity provider which acts as a trusted third party on behalf of
195 the user with regard to a relying party by making identity assertions
196 about the user to the relying party.
198 The real-world person represented by the identity subject is in
199 possession of a primary credential bound to the identity subject by
200 identity provider (or an agent thereof) in such a way that the
201 binding between the credential and the real-world user is a
202 representation of the identity proofing process performed by the
203 identity provider (or an agent thereof) to verify the identity of the
204 real-world person. This is all carried by an identity assertion
205 across the network to the relying party during the authentication
206 transaction.
208 1.3. Component Architecture
210 The term Vectors of Trust is based on the mathematical construct of a
211 vector, which is defined as an item composed of multiple independent
212 values.
214 An important goal for this work is to balance the need for simplicity
215 (particularly on the part of the relying party) with the need for
216 expressiveness. As such, this vector construct is designed to be
217 composable and extensible.
219 All components of the vector construct MUST be orthogonal in the
220 sense that no aspect of a component overlap an aspect of another
221 component, as much as is possible.
223 2. Component Definitions
225 This specification defines four orthogonal components: identity
226 proofing, primary credential usage, primary credential management,
227 and assertion presentation. These dimensions MUST be evaluated by
228 the RP in the context of a trust framework and SHOULD be combined
229 with other information when making a trust and authorization
230 decision.
232 This specification also defines values for each component to be used
233 in the absence of a more specific trust framework in Section 3. It
234 is expected that trust frameworks will provide context, semantics,
235 and mapping to legal statutes and business rules for each value in
236 each component. Consequently, a particular vector value can only be
237 compared with vectors defined in the same context. The RP MUST
238 understand and take into account the trust framework context in which
239 a vector is being expressed in order for it to be processed securely.
241 Each component is identified by a demarcator consisting of a single
242 uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD
243 reflect the category with which it is associated in a natural manner.
244 Demarcators for components MUST be registered as described in
245 Section 9. It is anticipated that trust framework definitions will
246 use this registry to define specialized components, though it is
247 RECOMMENDED that trust frameworks re-use existing components wherever
248 possible.
250 The value for a given component within a vector of trust is defined
251 by its demarcator character followed by a single digit or lowercase
252 ASCII letter in the range "[0-9a-z]". Categories which have a
253 natural ordering SHOULD use digits, with "0" as the lowest value.
254 Categories which do not have a natural ordering, or which can have an
255 ambiguous ordering, SHOULD use letters. Categories MAY use both
256 letter style and number style value indicators. For example,
257 defining "0" as a special "empty" value and using letters such as
258 "a", "b", "c" for normal values.
260 Regardless of the type of value indicator used, the values assigned
261 to each component of a vector MUST NOT be assumed as having inherent
262 ordinal properties when compared to the same or other components in
263 the vector space. In other words, "1" is different from "2", but it
264 is dangerous to assume that "2" is always better than "1" in a given
265 transaction.
267 2.1. Identity Proofing
269 The Identity Proofing dimension defines, overall, how strongly the
270 set of identity attributes have been verified and vetted. In other
271 words, this dimension describes how likely it is that a given digital
272 identity transaction corresponds to a particular (real-world)
273 identity subject.
275 This dimension SHALL be represented by the "P" demarcator and a
276 single-character level value, such as "P0", "P1", etc. Most
277 definitions of identity proofing will have a natural ordering, as
278 more or less stringent proofing can be applied to an individual. In
279 such cases it is RECOMMENDED that a digit style value be used for
280 this component.
282 2.2. Primary Credential Usage
284 The primary credential usage dimension defines how strongly the
285 primary credential can be verified by the IdP. In other words, and
286 how easily that credential could be spoofed or stolen.
288 This dimension SHALL be represented by the "C" demarcator and a
289 single-character level value, such as "Ca", "Cb", etc. Most
290 definitions of credential usage will not have an overall natural
291 ordering, as there may be several equivalent classes described within
292 a trust framework. In such cases it is RECOMMENDED that a letter
293 style value be used for this component. Multiple credential usage
294 factors MAY be communicated simultaneously, such as when Multi-Factor
295 Authentication is used.
297 2.3. Primary Credential Management
299 The primary credential management dimension conveys information about
300 the expected lifecycle of the primary credential in use, including
301 its binding, rotation, and revocation. This component defines how
302 strongly the primary credential can be trusted to be presented by the
303 party represented by the credential based on knowledge of the
304 management of the credentials at the IdP. In other words, this
305 dimension describes how likely it is that the right person is
306 presenting the credential to the identity provider.
308 This dimension SHALL be represented by the "M" demarcator and a
309 single-character level value, such as "Ma", "Mb", etc. Most
310 definitions of credential management will not have an overall natural
311 ordering, though there can be preference and comparison between
312 values in some circumstances. In such cases it is RECOMMENDED that a
313 letter style value be used for this component.
315 2.4. Assertion Presentation
317 The Assertion Presentation dimension defines how well the given
318 digital identity can be communicated across the network without
319 information leaking to unintended parties, and without spoofing. In
320 other words, this dimension describes how likely it is that a given
321 digital identity was actually asserted by a given identity provider
322 for a given transaction. While this information is largely already
323 known by the RP as a side effect of processing an identity assertion,
324 this dimension is still very useful when the RP requests a login
325 (Section 5) and when describing the capabilities of an IdP
326 (Section 7).
328 This dimension SHALL be represented by the "A" demarcator and a level
329 value, such as "Aa", "Ab", etc. Most definitions of assertion
330 presentation will not have an overall natural ordering. In such
331 cases, it is RECOMMENDED that a letter style value be used for this
332 component.
334 3. Vectors of Trust Initial Component Value Definitions
336 This specification defines the following general-purpose component
337 definitions, which MAY be used when a more specific set is
338 unavailable. These component values are referenced in a trustmark
339 definition defined by [[ this document URL ]].
341 It is anticipated that trust frameworks and specific applications of
342 this specification will define their own component values. In order
343 to simplify processing by RPs, it is RECOMMENDED that trust framework
344 definitions carefully define component values such that they are
345 mutually exclusive or subsumptive in order to avoid repeated vector
346 components where possible.
348 3.1. Identity Proofing
350 The identity proofing component of this vector definition represents
351 increasing scrutiny during the proofing process. Higher levels are
352 largely subsumptive of lower levels, such that "P2" fulfills
353 requirements for "P1", etc.
355 P0 No proofing is done, data is not guaranteed to be persistent
356 across sessions
358 P1 Attributes are self-asserted but consistent over time, potentially
359 pseudonymous
361 P2 Identity has been proofed either in person or remotely using
362 trusted mechanisms (such as social proofing)
364 P3 There is a binding relationship between the identity provider and
365 the identified party (such as signed/notarized documents,
366 employment records)
368 3.2. Primary Credential Usage
370 The primary credential usage component of this vector definition
371 represents distinct categories of primary credential that MAY be used
372 together in a single transaction.
374 C0 No credential is used / anonymous public service
376 Ca Simple session cookies (with nothing else)
377 Cb Known device
379 Cc Shared secret such as a username and password combination
381 Cd Cryptographic proof of key possession using shared key
383 Ce Cryptographic proof of key possession using asymmetric key
385 Cf Sealed hardware token / trusted biometric / TPM-backed keys
387 3.3. Primary Credential Management
389 The primary credential management component of this vector definition
390 represents distinct categories of management that MAY be considered
391 separately or together in a single transaction.
393 Ma Self-asserted primary credentials (user chooses their own
394 credentials and must rotate or revoke them manually) / no
395 additional verification for primary credential issuance or
396 rotation
398 Mb Remote issuance and rotation / use of backup recover credentials
399 (such as email verification) / deletion on user request
401 Mc Full proofing required for each issuance and rotation / revocation
402 on suspicious activity
404 3.4. Assertion Presentation
406 The assertion presentation component of this vector definition
407 represents distinct categories of assertion which are RECOMMENDED to
408 be used in a subsumptive manner but MAY be used together.
410 Aa No protection / unsigned bearer identifier (such as a session
411 cookie in a web browser)
413 Ab Signed and verifiable assertion, passed through the user agent
414 (web browser)
416 Ac Signed and verifiable assertion, passed through a back channel
418 Ad Assertion encrypted to the relying parties key and audience
419 protected
421 4. Communicating Vector Values to RPs
423 A vector of trust is designed to be used in the context of an
424 identity and authentication transaction, providing information about
425 the context of a federated credential. The vector therefore needs to
426 be able to be communicated in the context of the federated credential
427 in a way that is strongly bound to the assertion representing the
428 federated credential.
430 This vector has several requirements for use.
432 o All applicable vector components and values need to be combined
433 into a single vector.
435 o The vector can be communicated across the wire unbroken and
436 untransformed.
438 o All vector components need to remain individually available, not
439 "collapsed" into a single value.
441 o The vector needs to be protected in transit.
443 o The vector needs to be cryptographically bound to the assertion
444 which it is describing.
446 These requirements lead us to defining a simple string-based
447 representation of the vector that can be incorporated within a number
448 of different locations and protocols without further encoding.
450 4.1. On the Wire Representation
452 The vector MUST be represented as a period-separated ('.') list of
453 vector components, with no specific order. A vector component type
454 MAY occur multiple times within a single vector, with each component
455 separated by periods. Multiple values for a component are considered
456 a logical AND of the values. A specific value of a vector component
457 MUST NOT occur more than once in a single vector. That is, while
458 "Cc.Cd" is a valid vector, "Cc.Cc" is not.
460 Vector components MAY be omitted from a vector. No holding space is
461 left for an omitted vector component. If a vector component is
462 omitted, the vector is making no claim for that component. This MAY
463 be distinct from a specific component value stating that a component
464 was not used.
466 Vector values MUST be communicated along side of a trustmark
467 definition to give the components context. A vector value without
468 context is unprocessable, and vectors defined in different contexts
469 are not directly comparable as whole values. Different trustmarks
470 MAY re-use component definitions (including their values), allowing
471 comparison of individual components across contexts without requiring
472 complete understanding of all aspects of a context. The proper
473 processing of such cross-context values is outside the scope of this
474 specification.
476 For example, the vector value "P1.Cc.Ab" translates to "pseudonymous,
477 proof of shared key, signed browser-passed verified assertion, and no
478 claim made toward credential management" in the context of this
479 specification's definitions (Section 3). The vector value of
480 "Cb.Mc.Cd.Ac" translates to "known device, full proofing require for
481 issuance and rotation, cryptographic proof of possession of a shared
482 key, signed back-channel verified assertion, and no claim made toward
483 identity proofing" in the same context.
485 4.2. In OpenID Connect
487 In OpenID Connect [OpenID], the IdP MUST send the vector as a string
488 within the "vot" (vector of trust) claim in the ID token. The
489 trustmark (Section 6) that applies to this vector MUST be sent as an
490 HTTPS URL in the "vtm" (vector trust mark) claim to provide context
491 to the vector.
493 For example, the body of an ID token claiming "pseudonymous, proof of
494 shared key, signed back-channel verified token, and no claim made
495 toward credential management" could look like this JSON object
496 payload of the ID token.
498 {
499 "iss": "https://idp.example.com/",
500 "sub": "jondoe1234",
501 "vot": "P1.Cc.Ac",
502 "vtm": "https://trustmark.example.org/trustmark/idp.example.com"
503 }
505 The body of the ID token is signed and optionally encrypted using
506 JOSE, as per the OpenID Connect specification. By putting the "vot"
507 and "vtm" values inside the ID token, the vector and its context are
508 strongly bound to the federated credential represented by the ID
509 token.
511 4.3. In SAML
513 In SAML, a vector is communicated as an AuthenticationContextDeclRef.
514 A vector is represented by prefixing it with the urn
515 urn:ietf:param:[TBD] to form a full URN. The
516 AuthenticationContextDeclaration corresponding to a given vector is a
517 AuthenticationContextDeclaration element containing an Extension
518 element with components of the vector represented by the following
519 XML schema:
521
522
526
527 This represents a set of vector components.
528
529
530
531
532 This represents a vector component.
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
550 For instance the vector P1.Cc.Ac is represented by the
551 AuthenticationContextDeclRef URN urn:ietf:param:[TBD]:P1.Cc.Ac (or
552 urn:ietf:param:[TBD]:Cc.P1.Ac or ...) which corresponds to the
553 following AuthenticationContextDeclaration:
555
556
557
558
559
560
561
562
563
564
565 A VoT trustmark URI corresponds to an assurance certification URI
566 defined according to [[ TODO - assurance certification ]]. Each
567 trust mark should be registered according to [[ RFCXXXX ]].
569 5. Requesting Vector Values
571 In some identity protocols, the RP can request that particular vector
572 components be applied to a given identity transaction. Using the
573 same syntax as defined in Section 4.1, an RP can indicate that it
574 desires particular aspects be present in the authentication.
575 Processing and fulfillment of these requests are in the purview of
576 the IdP and details are outside the scope of this specification.
578 5.1. In OpenID Connect
580 In OpenID Connect [OpenID], the client MAY request a set of
581 acceptable VoT values with the "vtr" (vector of trust request) claim
582 request as part of the Request Object. The value of this field is an
583 array of JSON strings, each string identifying an acceptable set of
584 vector components. The component values within each vector are ANDed
585 together while the separate vectors are ORed together. For example,
586 a list of vectors in the form "["P1.Cb.Cc.Ab", "Ce.Ab"]" is stating
587 that either the full set of "P1 AND Cb AND Cc AND Ab" simultaneously
588 OR the set of "Ce AND Ab" simultaneously are acceptable to this RP
589 for this transaction.
591 Vector request values MAY omit components, indicating that any value
592 is acceptable for that component category.
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 to
603 the trust mark (cf below). The processing rules in [[ SAMLAuthnCtx
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 P Array of strings containing identity proofing values for which the
632 identity provider has been assessed and approved.
634 C Array of strings containing primary credential usage values for
635 which the identity provider has been assessed and approved.
637 M Array of strings containing primary credential management values
638 for which the identity provider has been assessed and approved.
640 A Array of strings containing assertion strength values for which
641 the identity provider has been assessed and approved.
643 Additional vector component values MUST be listed in a similar
644 fashion using their demarcator.
646 For example, the following trustmark provided by the
647 trustmark.example.org organization applies to the idp.example.org
648 identity provider:
650 {
651 "idp": "https://idp.example.org/",
652 "trustmark_provider": "https://trustmark.example.org/",
653 "P": ["P0", "P1"],
654 "C": ["C0", "Ca", "Cb"],
655 "M": ["Mb"],
656 "A": ["Ab", "Ac"]
657 }
659 An RP wishing to check the claims made by an IdP can fetch the
660 information from the trustmark provider about what claims the IdP is
661 allowed to make in the first place and process them accordingly. The
662 RP MAY cache the information returned from the trustmark URL.
664 The means by which the RP decides which trustmark providers it trusts
665 is out of scope for this specification and is generally configured
666 out of band.
668 Though most trust frameworks will provide a third-party independent
669 verification service for components, an IdP MAY host its own
670 trustmark. For example, a self-hosted trustmark would look like:
672 {
673 "idp": "https://idp.example.org/",
674 "trustmark_provider": "https://idp.example.org/",
675 "P": ["P0", "P1"],
676 "C": ["C0", "Ca", "Cb"],
677 "M": ["Mb"],
678 "A": ["Ab", "Ac"]
679 }
681 7. Discovery
683 The IdP MAY list all of its available trustmarks as part of its
684 discovery document, such as the OpenID Connect Discovery server
685 configuration document. In this context, trustmarks are listed in
686 the "trustmarks" element which contains a single JSON [RFC7159]
687 object. The keys of this JSON object are trustmark provider issuer
688 URLs and the values of this object are the corresponding trustmark
689 URLs for this IdP.
691 {
692 "trustmark": {
693 "https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/"
694 }
695 }
697 8. Acknowledgements
699 The authors would like to thank the members of the Vectors of Trust
700 mailing list in the IETF for discussion and feedback on the concept
701 and document, and the members of the ISOC Trust and Identity team for
702 their support.
704 9. IANA Considerations
706 This specification creates one registry and registers several values
707 into an existing registry.
709 9.1. Vector Of Trust Components Registry
711 The Vector of Trust Components Registry contains the definitions of
712 vector components and their associated demarcators.
714 o Demarcator Symbol: P
716 o Description: Identity proofing
718 o Document: [[ this document ]]
720 o Demarcator Symbol: C
722 o Description: Primary credential usage
724 o Document: [[ this document ]]
726 o Demarcator Symbol: M
728 o Description: Primary credential management
730 o Document: [[ this document ]]
732 o Demarcator Symbol: A
734 o Description: Assertion presentation
736 o Document: [[ this document ]]
738 9.2. Additions to JWT Claims Registry
740 This specification adds the following values to the JWT Claims
741 Registry.
743 o Claim name: vot
745 o Description: Vector of Trust value
747 o Document: [[ this document ]]
749 o Demarcator Symbol: vtm
751 o Description: Vector of Trust Trustmark
753 o Document: [[ this document ]]
755 o Demarcator Symbol: vtr
756 o Description: Vector of Trust Request
758 o Document: [[ this document ]]
760 10. Security Considerations
762 The vector of trust value MUST be cryptographically protected in
763 transit, using TLS as described in [BCP195]. The vector of trust
764 value MUST be associated with a trustmark marker, and the two MUST be
765 carried together in a cryptographically bound mechanism such as a
766 signed identity assertion. A signed OpenID Connect ID Token and a
767 signed SAML assertion both fulfil this requirement.
769 11. Privacy Considerations
771 By design, vector of trust values contain information about the
772 user's authentication and associations that can be made thereto.
773 Therefore, all aspects of a vector of trust contain potentially
774 privacy-sensitive information and MUST be guarded as such. Even in
775 the absence of specific attributes about a user, knowledge that the
776 user has been highly proofed or issued a strong token could provide
777 more information about the user than was intended. It is RECOMMENDED
778 that systems in general use the minimum vectors applicable to their
779 use case in order to prevent inadvertent information disclosure.
781 12. References
783 12.1. Normative References
785 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
786 Core 1.0", November 2014.
788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
789 Requirement Levels", BCP 14, RFC 2119,
790 DOI 10.17487/RFC2119, March 1997,
791 .
793 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
794 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
795 2014, .
797 12.2. Informative References
799 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
800 "Recommendations for Secure Use of Transport Layer
801 Security (TLS) and Datagram Transport Layer Security
802 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
803 2015, .
805 [SP-800-63]
806 , , , , , , and , "Electronic Authentication Guideline",
807 August 2013.
809 Appendix A. Document History
811 -02
813 o Converted C, M, and A values to use letters instead of numbers in
814 examples.
816 o Updated SAML to a structured example pending future updates.
818 o Defined guidance for when to use letters vs. numbers in category
819 values.
821 o Restricted category demarcators to uppercase and values to
822 lowercase and digits.
824 o Applied clarifying editorial changes from list comments.
826 - 01
828 o Added IANA registry for components.
830 o Added preliminary security considerations and privacy
831 considerations.
833 o Split "credential binding" into "primary credential usage" and
834 "primary credential management".
836 - 00
838 o Created initial IETF drafted based on strawman proposal discussed
839 on VoT list.
841 o Split vector component definitions into their own section to allow
842 extension and override.
844 o Solidified trustmark document definition.
846 Appendix B. Example Extension
848 To extend the vector component definitions, a specification MUST
849 register its contents in the
851 Authors' Addresses
853 Justin Richer (editor)
854 Bespoke Engineering
856 Email: ietf@justin.richer.org
858 Leif Johansson
859 Swedish University Network
860 Thulegatan 11
861 Stockholm
862 Sweden
864 Email: leifj@sunet.se
865 URI: http://www.sunet.se