Last Call Review of draft-richer-vectors-of-trust-11
review-richer-vectors-of-trust-11-genart-lc-worley-2018-06-10-01
Request | Review of | draft-richer-vectors-of-trust |
---|---|---|
Requested revision | No specific revision (document currently at 15) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2018-06-26 | |
Requested | 2018-05-29 | |
Authors | Justin Richer , Leif Johansson | |
I-D last updated | 2018-06-12 | |
Completed reviews |
Genart Last Call review of -11
by Dale R. Worley
(diff)
Genart Telechat review of -12 by Dale R. Worley (diff) Secdir Last Call review of -11 by Klaas Wierenga (diff) |
|
Assignment | Reviewer | Dale R. Worley |
State | Completed | |
Request | Last Call review on draft-richer-vectors-of-trust by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 11 (document currently at 15) | |
Result | Ready w/nits | |
Completed | 2018-06-12 |
review-richer-vectors-of-trust-11-genart-lc-worley-2018-06-10-01
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. Document: draft-richer-vectors-of-trust-11 Reviewer: Dale R. Worley Review Date: 2018-06-10 IETF LC End Date: 2018-06-26 IESG Telechat date: [not scheduled] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Generally -- there is use of both "individual" and "person". However, when we look at legal meanings, a "person" can be an organization that has legal personhood (i.e., can form contracts). This leads to the question of whether we are making assertions about the *individual* that is involved in the transaction, or the legal *person* on behalf of whom the individual is acting. And that leads to the question of whether the credential is being evaluated relative to the particular individual using it vs. the credential is being evaluated relative to the legal person on behalf of whom the individual is acting. E.g., when I am dealing with a bank, I'm less concerned with what individual I am dealing with than the fact that they are an authorized employee of the bank. I assume that these issues are well-understood within the security profession and can be adequately handled within this framework. 5. Trustmarks It seems that a trustmark must not just be a URI but a URL, which (by definition) describes how the document can be retrieved. 8.1. Vector Of Trust Components Registry Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear. This is interesting because it implies that in order to register a component, it must be "of general applicability". However, there is no constraint that all components in a particular trust framework must be of general applicability. If a trust framework has a narrow-purpose component, it is still necessary to register it (section 2), but it might be forbidden to register it (section 8.1). What is actually intended here? 1.1. Terminology Trustmark A URI referencing a specific Trust Framework and its definition of vector components and vector component values. Trustmark Provider A system that can verify that a given system (such as an identity provider) is both capable of asserting and allowed to assert the vector component values it is claiming. It seems to me that "Trustmark Provider" should contain some reference that it defines the Trust Framework of its Trustmark. 2. Component Definitions The RP MUST understand and take into account the trust framework context in which a vector is being expressed in order for to process a vector securely. s/order for to/order to/ But I think you want to change "securely" to "correctly". (Security is consequent to correctness here.) Each component is identified by a demarcator consisting of a single uppercase ASCII letter in the range "[A-Z]". The demarcator SHOULD reflect the category with which it is associated in a natural manner. Demarcators for components MUST be registered as described in Section 8. It is anticipated that trust framework definitions will use this registry to define specialized components, though it is RECOMMENDED that trust frameworks re-use existing components wherever possible. I think you want to explain more here: As you note in the previous paragraph, a particular vector can only be properly interpreted in the context of a particular trust framework. But a consequence of that is that the semantics of a component is only well-defined when the trust framework is specified. And the consequence of that is that the "same" components in two different frameworks do not have exactly the same semantics. The critical point is that, nonetheless, we want definers of vectors to re-use categories and demarcators for similar information in different frameworks. Demarcators for components MUST be registered as described in Section 8. While it is anticipated that trust framework definitions will use this registry to define specialized components, it is RECOMMENDED that trust frameworks re-use the designators of previously registered, similar components if possible, rather than defining new components/designators. -- Categories which have a natural ordering SHOULD use digits, with "0" as the lowest value. What does "lowest" mean? Perhaps: Categories which have a natural ordering SHOULD use digits, with larger digits indicating stronger assertions than smaller digits. If "0" is used, it SHOULD be the weakest assertion defined for the category. However, this concept is not entirely harmonized with the statement below, "the values assigned to each component of a vector MUST NOT be assumed always to have inherent ordinal properties when compared to the same or other components in the vector space". I think you want to emphasize that one is SHOULD and one is MUST. -- It's quite correct to place a SHOULD on the generator of information and a MUST on the consumer to not require that the generator conform to the SHOULD, but you want be quite explicit about that. Categories MAY use both letter style and number style value indicators simultaneously. s/letter style and number style/letter and digit/ And also through the document -- you don't need to say "letter style value" when what you mean is that the value *is* a letter. Also, "value indicator" is used in a few places where "value" seems to be sufficient. Each component MAY be repeated with multiple different values within a single vector (see Section 3.1 for details). I think you want to state explicitly here that two or more values presented for a component mean the logical AND of the assertions represented by each value individually. In other words, "1" is different from "2", but it is dangerous to assume that "2" is always better than "1." Rather, say "For example, [...] but the RP MUST NOT assume that the value "2" for a particular component within a particular trust framework is stronger than "1" without specific knowledge of that trust framework." 2.1. Identity Proofing (P) This dimension uses the "P" demarcator and a single-character level value, such as "P0", "P1", etc. These sections repeatedly use the term "level value" to describe component values, even though "level" is not defined, and it's not clear that it carries any additional information. 2.2. Primary Credential Usage (C) This dimension uses the "C" demarcator and a single-character level value, such as "Ca", "Cb", etc. Presumably you mean that *letter* values are RECOMMENDED? But that is also stated later in the paragraph. as there may be several equivalent classes described within a trust framework. It's not clear what "equivalent" means here -- I think you mean "non-comparable" or "non-orderable" classes. In such cases it is RECOMMENDED that a letter style value be used for this component and that multiple distinct credential usage factors be allowed to be communicated simultaneously, such as when Multi-Factor Authentication is used. Since the meaning of multiple values for a single component is generically defined, you don't need to allow them here. But I think you mean to say, "When multi-factor authentication is used, it should be communicated by multiple values, with one value describing each authentication factor". 2.4. Assertion Presentation (A) In other words, this dimension describes how likely it is that a given digital identity was actually asserted by a given identity provider for a given transaction. I suspect you mean "asserted by a given identity *subject*" here -- as written, it doesn't make much sense. 3.1. On the Wire Representation This probably should be "On-the-Wire Representation". Trust frameworks MAY define a distinct value for a component category to indicate that a category was not used at all. Instead of "a category was not used at all", better "no assertion is being made for that category". Perhaps recommend that "0" always be used for such a value? (A similar recommendation seems to be made in section 2.) but here the IdP is making no statement to that to the RP. Perhaps "but here the IdP is making no assertion to that effect to the RP". 4. Requesting Vector Values Using the same syntax as defined in Section 3.1, an RP can indicate that it desires particular aspects be present in the authentication. This isn't phrased quite correctly. Better: An RP can describe the particular vector component values that it desires the IdP to assert for a given identity transaction using the syntax defined in Section 3.1. 4.1. In OpenID Connect "["P1.Cb.Cc.Ab", "Ce.Ab"]" Either the outer or the inner quotations should be done using '...'. 5. Trustmarks The URI SHOULD be stable over time for a given trust framework. Does this mean that a trust framework should use the same URL over time, or that the document retrievable via the URL should be the same over time, or both? For example, [[this document URI]] is used as a trustmark to reference the values defined in Appendix A. In light of the previous paragraph, s/a trustmark/the trustmark/. 6. Defining New Vector Values However, the exact nature of the information needed is reliant on the parties requiring the information and the relationship between them. Probably s/reliant/depends/. Component categories such as those defined in Section 2 are intended to be general purpose and reusable in a variety of circumstances. s/circumstances/trust frameworks/ Implementations of this specification MUST specify whether s/Implementations of this specification/Trust frameworks/ 8.1. Vector Of Trust Components Registry s/Of/of/ Registration requests sent to the vot@ietf.org mailing list for review should use an appropriate subject This sentence doesn't assert what you want, viz., Registration requests should be sent to the vot@ietf.org mailing list for review using an appropriate subject 8.1.1. Registration Template An uppercase ASCII letter in the range [A-Z] representing this component (e.g., "X"). "in the range [A-Z]" is redundant. 8.1.2. Initial Registry Contents It would be helpful to group the lines that describe each category in some way. Appendix A. Vectors of Trust Default Component Value Definitions This trust framework referenced in a trustmark URI of [[ this document URL ]]. Better The trustmark URI of this trust framework is [[ this document URL ]]. A.1. Identity Proofing The identity proofing component of this vector definition represents increasing scrutiny during the proofing process. It seems like you should s/increasing scrutiny/the level of scrutiny/. A.2. Primary Credential Usage Cf Sealed hardware token / TPM-backed keys Is "TPM" well-understood in this context, or should it be expanded? A.4. Assertion Presentation Ad Assertion encrypted to the relying parties key and audience protected s/parties/party's/ Is "audience protected" used correctly here? [END]