idnits 2.17.1
draft-richer-vectors-of-trust-01.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 is 1 instance of too long lines in the document, the longest one
being 28 characters in excess of 72.
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 4, 2015) is 3150 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-Za-z' is mentioned on line 239, but not defined
== Missing Reference: '0-9A-Za-z' is mentioned on line 241, but not defined
-- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID'
** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
Summary: 2 errors (**), 0 flaws (~~), 4 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: Standards Track L. Johansson
5 Expires: March 7, 2016 Swedish University Network
6 September 4, 2015
8 Vectors of Trust
9 draft-richer-vectors-of-trust-01
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", "MAY", and "OPTIONAL" in this
21 document are to be interpreted as described in RFC 2119 [RFC2119].
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at http://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on March 7, 2016.
40 Copyright Notice
42 Copyright (c) 2015 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 4
60 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5
61 2. Core Components . . . . . . . . . . . . . . . . . . . . . . . 5
62 2.1. Identity Proofing . . . . . . . . . . . . . . . . . . . . 6
63 2.2. Primary Credential Usage . . . . . . . . . . . . . . . . 6
64 2.3. Primary Credential Management . . . . . . . . . . . . . . 6
65 2.4. Assertion Presentation . . . . . . . . . . . . . . . . . 6
66 3. Vectors of Trust Inititial Component Definitions . . . . . . 7
67 4. Communicating Vector Values to RPs . . . . . . . . . . . . . 8
68 4.1. On the Wire Representation . . . . . . . . . . . . . . . 8
69 4.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 9
70 4.3. In SAML . . . . . . . . . . . . . . . . . . . . . . . . . 9
71 5. Requesting Vector Values . . . . . . . . . . . . . . . . . . 10
72 5.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 10
73 6. Discovery and Verification . . . . . . . . . . . . . . . . . 10
74 6.1. Trustmark . . . . . . . . . . . . . . . . . . . . . . . . 10
75 6.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12
76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
78 8.1. Vector Of Trust Components Registry . . . . . . . . . . . 12
79 8.2. Additions to JWT Claims Registry . . . . . . . . . . . . 13
80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
81 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
83 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
84 11.2. Informative References . . . . . . . . . . . . . . . . . 14
85 Appendix A. Document History . . . . . . . . . . . . . . . . . . 14
86 Appendix B. Example Extension . . . . . . . . . . . . . . . . . 15
87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
89 1. Introduction
91 This document defines a mechanism for describing and signaling
92 several aspects of digital identity transactions that are used to
93 determine a level of trust in that transaction. In the past, there
94 have been two extremes of communicating authentication transaction
95 information. On one end, all attributes are communicated with full
96 provenance and associated trust markings. This approach seeks to
97 create a fully distributed attribute system that can be used for
98 things like attribute based access control (ABAC). These attributes
99 can be used to describe the end user, the identity provider, the
100 relying party, or even the transaction itself. While the information
101 that can be expressed in this model is incredible, the complexity of
102 such a system is often prohibitive to align across security domains,
103 especially to relying parties needing to process the sea of disparate
104 attributes.
106 At the other extreme there are systems that collapse all of the
107 attributes and aspects into a single scalar value that communicates,
108 in sum, how much a transaction can be trusted. The NIST special
109 publication 800-63 [SP-800-63] defines a linear scale Level of
110 Assurance (LoA) measure that combines multiple attributes about an
111 identity transaction into a single measure of the level of trust a
112 relying party should place on an identity transaction. Even though
113 this definition was originally made for a specific government use
114 cases, the LoA scale appeared to be applicable with a wide variety of
115 authentication use cases. This has led to a proliferation of
116 incompatible interpretations of the same scale in different trust
117 frameworks, preventing interoperability between these frameworks in
118 spite of their common measurement. Since identity proofing strength
119 increases linearly along with credential strength in the LoA scale,
120 this scale is too limited for describing many valid and useful forms
121 of an identity transaction. For example, an anonymously assigned
122 hardware token can be used in cases where the real world identity of
123 the subject cannot be known, for privacy reasons, but the credential
124 itself can be highly trusted.
126 This work seeks to find a balance between these two extremes by
127 creating a data model that combines attributes of the user and
128 aspects of the authenticaiton context into several values that can be
129 communicated together. This approach is both coarser grained than
130 the distributed attributes model and finer grained than the single
131 value model, with the hope that it is a viable balance of
132 expressivity and processability. Importantly, these three levels of
133 granularity can be mapped to each other. The information of several
134 attributes can be folded into a vector component, while the vector
135 itself can be folded into an assurance category. As such, the
136 vectors of trust seeks to complement, not replace, these other
137 identity and trust mechanisms.
139 1.1. Terminology
141 Identity Provider (IdP) A system that manages identity information
142 and is able to assert this information across the network through
143 an identity API.
145 Identity Subject The person (user) engaging in the identity
146 transaction, being identified by the identity provider and
147 identified to the relying party.
149 Primary Credential The credential used by the identity subject to
150 authenticate to the identity provider.
152 Federated Credential The assertion presented by the IdP to the RP
153 across the network to authenticate the user.
155 Relying Party (RP) A system that consumes identity information from
156 an IdP for the purposes of authenticating the user.
158 Trust Framework A document containing business rules and legal
159 clauses that defines how different parties in an identity
160 transaction may act.
162 Trustmark A verifiable attestation that a party has proved to follow
163 the constraints of a trust framework.
165 Trustmark Provider A system that issues and provides verification
166 for trustmarks.
168 Vector A multi-part data structure, used here for conveying
169 information about an authentication transaction.
171 Vector Component One of several constituent parts that make up a
172 vector.
174 1.2. An Identity Model
176 This document assumes the following (incomplete) model for identity.
178 The identity subject (aka user) is associated with an identity
179 provider which acts as a trusted 3rd party on behalf of the user with
180 regard to a relying party by making identity assertions about the
181 user to the relying party.
183 The real-world person represented by the identity subject is in
184 possession of a primary credential bound to the identity subject by
185 identity provider (or an agent thereof) in such a way that the
186 binding between the credential and the real-world user is a
187 representation of the identity proofing process performed by the the
188 identity provider (or an agent thereof) to verify the identity of the
189 real-world person.
191 1.3. Component Architecture
193 The term Vectors of Trust is based on the mathematical construct of a
194 Vector, which is defined as an item composed of multiple independent
195 scalar values. A vector is a set of coordinates that specifies a
196 point in a (multi-dimensional) Cartesian coordinate space. The
197 reader is encouraged to think of a vector of trust as a point in a
198 coordinate system, in the simples form (described below) a 3
199 dimensional space that is intended to be a recognizable, if somewhat
200 elided, model of identity subject trust.
202 An important goal for this work is to balance the need for simplicity
203 (particularly on the part of the relying party) with the need for
204 expressiveness. As such, this vector construct is designed to be
205 composable and extensible.
207 All components of the vector construct MUST be orthogonal in the
208 sense that no aspect of a component overlap an aspect of another
209 component.
211 The values assigned to each component of a vector is sometimes
212 written as an ordinal number (e.g. an integer) but MUST NOT be
213 assumed as having inherent ordinal properties when compared to the
214 same or other components in the vector space. In other words, 1 is
215 different from 2, but it is dangerous to assume that 2 is always
216 "more" (better) than 1.
218 2. Core Components
220 This specification defines four orthogonal components: identity
221 proofing, primary credential usge, primary credential management, and
222 assertion presentation. These dimensions MUST be evaluated in the
223 context of a trust framework and SHOULD be combined with other
224 information when making a trust and authorization decision.
226 This specification also defines values for each component to be used
227 in the absence of a more specific trust framework. It is expected
228 that trust frameworks will provide context, semantics, and mapping to
229 legal statutes and business rules for each value in each component.
230 Consequently, a particular vector value can only be compared with
231 vectors defined in the same context. The RP MUST understand and take
232 into account the trust framework context in which a vector is being
233 expressed in order for it to be processed securely.
235 It is anticipated that trust frameworks will also define additional
236 components using the component registry established in Section 8.
238 Each component is identified by a demarcator consisting of a single
239 case-sensitive ASCII character in the range [A-Za-z]. A value for a
240 given component is defined by its demarcator character followed by a
241 single case-sensitive ASCII character in the range [0-9A-Za-z].
243 2.1. Identity Proofing
245 The Identity Proofing dimension defines, overall, how strongly the
246 set of identity attributes have been verified and vetted, and how
247 strongly they are tied to a particular credential set. In other
248 words, this dimension describes how likely it is that a given digital
249 identity corresponds to a particular (real-world) identity subject.
251 This dimension SHALL be represented by the "P" demarcator and a
252 single-character level value, such as "P1", "P2", etc.
254 2.2. Primary Credential Usage
256 The primary credential usage dimension defines how strongly the
257 primary credential can be verified by the IdP. In other words, and
258 how easily that credential could be spoofed or stolen.
260 This dimension SHALL be represented by the "C" demarcator and a
261 single-character level value, such as "C1", "C2", etc. Multiple
262 credential usage factors MAY be communicated simultaneously, such as
263 when Multi-Factor Authentication is used.
265 2.3. Primary Credential Management
267 The primary credential management dimension conveys information about
268 the expected lifecycle of the primary credential in use, including
269 its binding, rotation, and revocation. This component defines how
270 strongly the primary credential can be trusted to be presented by the
271 party represented by the credential based on knowledge of the
272 management of the credentials at the IdP. In other words, this
273 dimension describes how likely it is that the right person is
274 presenting the credential to the identity provider.
276 This dimension SHALL be represented by the "M" demarcator and a
277 single-character level value, such as "M1", "M2", etc.
279 2.4. Assertion Presentation
281 The Assertion Presentation dimension defines how well the given
282 digital identity can be communicated across the network without
283 information leaking to unintended parties, and without spoofing. In
284 other words, this dimension describes how likely it is that a given
285 digital identity asserted was actually asserted by a given identity
286 provider for a given transaction. While this information is largely
287 already known by the RP by the nature of processing an identity
288 assertion, this dimension is still useful when the RP requests a
289 login (Section 5) and when describing the capabilities of an IdP
290 (Section 6.2).
292 This dimension SHALL be represented by the "A" demarcator and a level
293 value, such as "A1", "A2", etc.
295 3. Vectors of Trust Inititial Component Definitions
297 This specification defines the following general-purpose component
298 definitions, which MAY be used when a more specific set is
299 unavailable. These component values are referenced in a trustmark
300 definition defined by [[ this document URL ]].
302 P0 No proofing is done, data is not guaranteed to be persistent
303 across sessions
305 P1 Attributes are self-asserted but consistent over time, potentially
306 pseudonymous
308 P2 Identity has been proofed either in person or remotely using
309 trusted mechanisms (such as social proofing)
311 P3 There is a binding relationship between the identity provider and
312 the identified party (such as signed/notarized documents,
313 employment records)
315 C0 No credential is used / anonymous public service / simple session
316 cookies (with nothing else)
318 C1 Known device
320 C2 Shared secret such as a username and password combination
322 C3 Cryptographic proof of key possession using shared key
324 C4 Cryptographic proof of key possession using asymmetric key
326 C5 Sealed hardware token / trusted biometric / TPM-backed keys
328 M0 Self-asserted credentials
330 M1 Remote issuance and rotation / use of backup recover credentials
331 (such as email verification) / deletion on user request
333 M2 Full proofing required for each issuance and rotation / revocation
334 on suspicious activity
336 A0 No protection / unsigned bearer identifier (such as a session
337 cookie)
339 A1 Signed and verifiable token, passed through the browser
341 A2 Signed and verifiable token, passed through a back channel
343 A3 Token encrypted to the relying parties key and audience protected
345 4. Communicating Vector Values to RPs
347 All four of these dimensions (and others, as they are defined in
348 extension work) MUST be combined into a single vector that can be
349 communicated across the wire unbroken. All vector components MUST be
350 individually available, MUST NOT be "collapsed" into a single value
351 without also presenting the constituent dimensions as well.
353 When communicating the vectors across the wire, they MUST be
354 protected in transit and MUST signed by the asserting authority (such
355 as the IdP).
357 4.1. On the Wire Representation
359 The vector MUST be represented as a period-separated ('.') list of
360 vector components, with no specific order. A vector component type
361 MAY occur multiple times within a single vector, with each component
362 separated by periods. Multiple values for a component are considered
363 an AND of the values. A single value of a vector component MUST NOT
364 occur more than once in a single vector. In order to simplify
365 processing by RPs, it is RECOMMENDED that trust framework definitions
366 carefully define component values such that they are mutually
367 exclusive or subsumptive in order to avoid repeated vector components
368 where possible.
370 Vector components MAY be omitted from a vector. No holding space is
371 left for an omitted vector component. If a vector component is
372 omitted, the IdP is making no claim for that category.
374 For example, the vector value "P1.C3.A2" translates to pseudonymous,
375 proof of shared key, signed back-channel verified token in the
376 context of this specification's definitions (Section 3).
378 Vector values MUST be communicated along side of a trustmark
379 definition to give the components context. A vector value without
380 context is unprocessable.
382 4.2. In OpenID Connect
384 In OpenID Connect [OpenID], the IdP MUST send the vector value as a
385 string with the "vot" (vector of trust) claim in the ID token. The
386 trustmark (Section 6.1) that applies to this vector MUST be sent as
387 an HTTPS URL in the "vtm" (vector trust mark) claim to provide
388 context to the vector.
390 For example:
392 {
393 "iss": "https://idp.example.com/",
394 "sub": "jondoe1234",
395 "vot": "P1.C3.A2",
396 "vtm": "https://trustmark.example.org/trustmark/idp.example.com"
397 }
399 4.3. In SAML
401 In SAML a VoT vector is communicated as an
402 AuthenticationContextClassRef, a sample definition of which might
403 look something like this:
405
406
413
415
416 VoT vector P1.C3.A2
417
418
419
420
421
425
426
427
428
429
431 5. Requesting Vector Values
433 In some identity protocols, the RP can request that particular
434 attributes be applied to a given identity transaction.
436 5.1. In OpenID Connect
438 In OpenID Connect [OpenID], the client can request a set of
439 acceptable VoT values with the "vtr" (vector of trust request) claim
440 request as part of the Request Object. The value of this field is an
441 array of JSON strings, each string identifying an acceptable set of
442 vector components. The components within each vector are ANDed
443 together while the individual vector strings are ORed together.
444 Vector request values MAY omit components, indicating that any value
445 is acceptable.
447 {
448 "vtr": ["P1.C2.C3.A2", "C5.A2"]
449 }
451 6. Discovery and Verification
453 6.1. Trustmark
455 When an RP receives a specific vector from an IdP, it needs to make a
456 decision to trust the vector within a specific context. A trust
457 framework can provide such a context, allowing legal and business
458 rules to give weight to an IdP's claims. A trustmark is a verifiable
459 claim to conform to a specific component of a trust framework, such
460 as a verified identity provider. The trustmark conveys the root of
461 trustworthiness about the claims and assertions made by the IdP.
463 The trustmark MUST be available from an HTTPS URL served by the trust
464 framework provider. The contents of this URL are a JSON [RFC7159]
465 document with the following fields:
467 idp The issuer URL of the identity provider that this trustmark
468 pertains to. This MUST match the corresponding issuer claim in
469 the identity token, such as the OpenID Connect "iss" field. This
470 MUST be an HTTPS URL.
472 trustmark_provider The issuer URL of the trustmark provider that
473 issues this trustmark. The URL that a trustmark is fetched from
474 MUST start with the "iss" URL in this field. This MUST be an
475 HTTPS URL.
477 P Array of strings containing identity proofing values for which the
478 identity provider has been assessed and approved
480 C Array of strings containing primary credential usage values for
481 which the identity provider has been assessed and approved
483 M Array of strings containing primary credential management values
484 for which the identitity provider has been assessed and approved
486 A Array of strings containing assertion strength values for which
487 the identity provider has been assessed and approved
489 Additional vector component values MUST be listed in a similar
490 fashion using their demarcator.
492 For example, the following trustmark provided by the
493 trustmark.example.org organization applies to the idp.example.org
494 identity provider:
496 {
497 "idp": "https://idp.example.org/",
498 "trustmark_provider": "https://trustmark.example.org/",
499 "P": ["P0", "P1"],
500 "C": ["C1", "C2", "C3"],
501 "M": ["M2"],
502 "A": ["C2", "C3"]
503 }
505 A client wishing to check the claims made by an IdP can fetch the
506 information from the trustmark provider about what claims the IdP is
507 allowed to make in the first place and process them accordingly.
509 The means by which the RP decides which trustmark providers it trusts
510 is out of scope for this specification and is generally configured
511 out of band.
513 Though most trust frameworks will provide a third-party independent
514 verification service for components, an IdP MAY host its own
515 trustmark. For example, a self-hosted trustmark would look like:
517 {
518 "idp": "https://idp.example.org/",
519 "trustmark_provider": "https://idp.example.org/",
520 "P": ["C0", "C1"],
521 "C": ["C1", "C2", "C3"],
522 "M": ["M2"],
523 "A": ["C2", "C3"]
524 }
526 6.2. Discovery
528 The IdP MAY list all of its available trustmarks as part of its
529 discovery document, such as the OpenID Connect Discovery server
530 configuration document. Trustmarks are listed in the trustmarks
531 element which contains a single JSON [RFC7159] object. The keys of
532 this JSON object are trustmark provider issuer URLs and the values of
533 this object are the corresponding trustmarks for this IdP.
535 {
536 "trustmark": {
537 "https://trustmark.example.org/": "https://trustmark.example.org/trustmark/idp.example.org/
538 }
539 }
541 7. Acknowledgements
543 The authors would like to thank the members of the Vectors of Trust
544 mailing list in the IETF for discussion and feedback on the concept
545 and document.
547 8. IANA Considerations
549 This specification creates one registry and registers several values
550 into an existing registry.
552 8.1. Vector Of Trust Components Registry
554 The Vector of Trust Components Registry contains the definitions of
555 vector components and their associated demarcators.
557 o Demarcator Symbol: P
559 o Description: Identity proofing
561 o Document: [[ this document ]]
563 o Demarcator Symbol: C
565 o Description: Primary credential usage
567 o Document: [[ this document ]]
569 o Demarcator Symbol: M
571 o Description: Primary credential management
573 o Document: [[ this document ]]
574 o Demarcator Symbol: A
576 o Description: Assertion presentation
578 o Document: [[ this document ]]
580 8.2. Additions to JWT Claims Registry
582 This specification adds the following values to the JWT Claims
583 Registry.
585 o Claim name: vot
587 o Description: Vector of Trust value
589 o Document: [[ this document ]]
591 o Demarcator Symbol: vtm
593 o Description: Vector of Trust Trustmark
595 o Document: [[ this document ]]
597 o Demarcator Symbol: vtr
599 o Description: Vector of Trust Request
601 o Document: [[ this document ]]
603 9. Security Considerations
605 The vector of trust value MUST be cryptographically protected in
606 transit, using TLS. The vector of trust value MUST be associated
607 with a trustmark marker, and the two MUST be carried together in a
608 cryptographically bound mechanism such as a signed identity
609 assertion.
611 10. Privacy Considerations
613 By design, vector of trust values contain information about a user's
614 identity and assications that can be made thereto. Therefore, all
615 aspects of a vector of trust contain potentially privacy-sensitive
616 information and MUST be guarded as such.
618 11. References
620 11.1. Normative References
622 [OpenID] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect
623 Core 1.0", November 2014.
625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
626 Requirement Levels", BCP 14, RFC 2119,
627 DOI 10.17487/RFC2119, March 1997,
628 .
630 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
631 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
632 2014, .
634 11.2. Informative References
636 [SP-800-63]
637 , , , , , , and , "Electronic Authentication Guideline",
638 August 2013.
640 Appendix A. Document History
642 - 01
644 o Added IANA registry for components.
646 o Added preliminary security considerations and privacy
647 considerations.
649 o Split "credential binding" into "primary credential usage" and
650 "primary credential management".
652 - 00
654 o Created initial IETF drafted based on strawman proposal discussed
655 on VoT list.
657 o Split vector component definitions into their own section to allow
658 extension and override.
660 o Solidified trustmark document definition.
662 Appendix B. Example Extension
664 To extend the vector component definitions, a specification MUST
665 register its contents in the
667 Authors' Addresses
669 Justin Richer (editor)
670 Bespoke Engineering
672 Email: ietf@justin.richer.org
674 Leif Johansson
675 Swedish University Network
676 Thulegatan 11
677 Stockholm
678 Sweden
680 Email: leifj@sunet.se
681 URI: http://www.sunet.se