Re: [VoT] Vectors of Trust I-D

[Jim Fenton <[e-mail]>]

I made another pass through the document and have some more comments.
I'll leave out the grammatical nits, although I'm happy to pass them
along to the authors if they want them.


1.1 Terminology

Credential - I understand that "token" has conflicting usage, but
credential does too. At a minimum, a definition stating what this
document means by credential is needed.

Identity Provider - Manages "identity information".  What's that?  Seems
a bit circular. In many circumstances, assertions of attributes might
come from different parties than the one that authenticates the user. I
hope we can accommodate separation of authentication and attributes here.

Relying Party - "logging users in".  Additional attributes might also be
consumed for authorizing further access beyond the initial login.  I'd
prefer "authenticating users and authorizing their actions".

Trustmark - "has proved". My mind immediately went to some sort of
cryptographic proof. You seem to mean "is expected", "is deemed", or
something like that.

2. Background and Motivation

"attributes about an identity transaction": Attributes has a conflicting
meaning. How about "aspects of an identity transaction"?

Paragraph 2, last sentence.  I don't really understand what this is
saying, but identity proofing should be able to be done after token
issuance, and perhaps by a different party than the issuer.

2.1 last paragraph: I don't understand what point this is trying to
make, but binding of credential and the user is a "representation of the
identity proofing process" doesn't quite make sense.

3.2 Credential Management should be titled Credential Binding to be
consistent with earlier text.

use the "credential" to denote the credential: circular definition

3.3 Assertion Presentation: Doesn't the RP have direct visibility on how
the assertion is presented? For example, it shouldn't be necessary to
say something like "Token encrypted to the relying party's key" because
the relying party already knows that. There is perhaps some need for a
way for the RP to specify how the assertion is to be delivered, however.

4. Component Definitions

C5 is an example that is particularly troubling: equating a sealed
hardware token with a trusted biometric or TPM-backed keys. If the C
specification is an enumerated list, perhaps each of them should have a
C number. But if the components are that fine-grained, a requesting
vector (section 6) might be quite long and complex to represent all the
combinations of components that are acceptable. I personally prefer an
ordered set of value within each vector component that would be
necessarily more coarse-grained than this. In that case, the requesting
vector could be something like "P2.C2" which would mean P >= 2 AND C >= 2.

Eventually, the syntax will need to be nailed down further, probably
using ABNF.  For example, can P2.C2 be used as well as C2.P2?

The initial C values don't say anything about multifactor authentication.

5. Communicating vector values to RPs: I wonder if these values should
always be encrypted on the wire to protect against attackers looking for
high-value targets.

7.1 Trustmark

Trustmarks have enough usefulness independent of VoT that we should
consider whether they should be an independent specification.

Trustmarks are needed for attribute providers as well as IdPs. And
probably for attribute providers and brokers (like connect.gov) as well.

As specified, anyone who has a valid TLS certificate for the trust
framework can assert the trustmark, including rogue CAs. This might not
be good enough where substantial liability exposure is involved. Perhaps
the trustmark should be signed as well, maybe using keys verified with DANE.

-Jim

On 6/30/15 6:23 AM, Jim Fenton wrote:
> Justin and Leif, thanks for getting things moving with this draft.
>
> The biggest surprise to me is that (section 2.2, last paragraph) the
> components of the vector do not have ordinal properties; i.e., they
> are just an enumerated list. Aside from confusing people that are
> expecting a vector to be a set of scalars, it also requires Relying
> Parties, for example, to enumerate all of the types of credential
> management they will accept rather than "C2 or better". This isn't a
> huge problem at the current scale, but I'm concerned that the number
> of choices might grow.
>
> I also have some problem with the use of the term "credential" because
> it encompasses management of attributes as well as tokens, which then
> overlaps with the identity proofing dimension which is, more
> generally, the question of how strongly the relying party can depend
> on attribute values.  I'd rather that we use the term "token" rather
> than "credential" to keep these separate.
>
> -Jim