Last Call Review of draft-richer-vectors-of-trust-11
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]