Vectors of Trust
draft-richer-vectors-of-trust-15

Thanks for the work everyone did on this document. I have one substantive
comment and some very minor editorial suggestions.

---------------------------------------------------------------------------

§8.1 establishes a registry for vector of trust components. Ordinarily, IANA
ensures that duplicate values are not registered in a table; however, it would
appear that the intention with these demarcators is that duplicate letters with
different meanings is *discouraged*, it is not outright prohibited. e.g., §2:

>  Different trust frameworks SHOULD use
>  the same component for similar information, but since the processing
>  for all vector values is contextual to a trust framework, the exact
>  semantics of interpreting a component will vary based on the trust
>  framework in use.

Since this is somewhat different than IANA's normal mode of operation, this
section really needs to call out the fact that duplicate entries are explicitly
allowed, and that it is the role of the expert(s) to help make informed
decisions about when including duplicates would be acceptable.

---------------------------------------------------------------------------

All of my remaining comments are minor editorial nits.

§1:

>  It is anticipated that
>  VoT can be used alongside more detailed attribute metadata systems as
>  has that proposed by NISITIR 8112 [NISTIR-8112].

This sentence doesn't parse. Perhaps "...systems, such as the one proposed
by..."

---------------------------------------------------------------------------

§3.2:

>  For example, assume that for the given trustmark, the body of an ID
>  token claiming "pseudonymous, proof of shared key, signed back-
>  channel verified token, and no claim made toward credential
>  management" could look like this JSON object payload of the ID token.

Please cite RFC 8259 (which is already in the reference section) here.

---------------------------------------------------------------------------

§4.1:

>  In OpenID Connect [OpenID], the client MAY request a partial set of
>  acceptable VoT values with the "vtr" (vector of trust request) claim
>  request as part of the Request Object.  The value of this field is an
>  array of JSON strings, each string identifying an acceptable set of

Please cite RFC 8259 here.

---------------------------------------------------------------------------

§6:

>  Trust frameworks that implement specification SHOULD choose either a

Nit: "...that implement this specification..."


---------------------------------------------------------------------------

§9:

>  fulfil this requirement by carrying both the vector value and the

Nit: "...fulfill..." (see RFC 7322 §3.1)

Interesting idea!

I am clearing my DISCUSS since the authors have indicated they still see value in the IANA registry as specified. But since my opinion has not changed, I am keeping the point (but demoting it to a comment:

<old-discuss>
I am concerned that the IANA considerations may be inappropriate for the purpose of the document, and possibly harmful. I'd like to see some discussion of this; if afterwards people still think it's a good idea, I will clear.

If I understand correctly, the interpretation of a component name is entirely contextual to the trust framework. While trust frameworks are encouraged to reuse existing components for similar purposes, there's no real way to enforce that. And given that even if trust frameworks share a component, they may assign entirely different value types, I don't see the value of registering components. Furthermore, since the instructions to the experts asks them to look at things like general applicability vs limited application, I can see registration requests creating a fair amount of discussion (meaning work for people).

So, why register components at all? Why not leave them up to trust frameworks to define as they please? Is harm done if different frameworks use the same component name for completely different things? (I could see registering the frameworks themselves, but I leave that to the WG to decide.)
</old-discuss>




This is an interesting document, and I hope it progresses in some form. But I share Ekr's question about whether is is appropriate as a PS when defined in a non-wg document. The shepherd writeup mentions discussion on a non-wg mail list, and existing implementations, so maybe it's okay (this this is a non-blocking comment, not a DISCUSS point). But it seems like the sort of thing we should consider treating as experimental at first.

§1.3: "All components of the vector construct MUST be orthogonal such that
   no aspect of a component overlaps an aspect of another component, as
   much as is possible."
Who does that requirement apply to? Implementers? Writers of trust frameworks? The authors of _this_ document?

§6: Does "implementations" in this section refer to software implementations? Trust frameworks? Something else?

Appendix A contains normative text. If you want everyone to actually read that, please consider promoting to the body.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4378


Question for the AD. Should this really be a PS RFC? It doesn't seem
like there was much feedback in IETF LC (there wasn't a WG) and so the
evidence of consensus/support is pretty weak. I'm not going to DISCUSS
here, but I thought it was worth raising.

IMPORTANT
S 1.3.
>      expressiveness.  As such, this vector construct is designed to be
>      composable and extensible.
>   
>      All components of the vector construct MUST be orthogonal such that
>      no aspect of a component overlaps an aspect of another component, as
>      much as is possible.

"MUST" and "as much as is possible" don't really work together.


S 5.
>      values represent within the trust framework.  The contents of the
>      trustmark URL MUST be reachable by the operators or implementors of
>      the RP.  The URL SHOULD be stable over time for a given trust
>      framework to allow RPs to process incoming vectors in a consistent
>      fashion.  New versions of a trust framework that require different
>      processing rules SHOULD use a different trustmark URL.

don't these both need to be a MUST? Otherwise you have a serious
interop problem.


S 9.
>      transit between parties, such as by using TLS as described in
>      [BCP195].  The vector of trust value must be associated with a
>      trustmark by the RP processing the vector.  A signed OpenID Connect
>      ID Token or a similarly signed assertion from another protocol would
>      fulfil this requirement by carrying both the vector value and the
>      trustmark URL as claims.

You should require that the Trustmark URL be HTTPS.

COMMENTS
S 1.1.
>   
>      Trust Framework  A document containing business rules and legal
>         clauses that defines how different parties in an identity
>         transaction may act.
>   
>      Trustmark  A URL referencing a specific Trust Framework and its

Are you aware that "Trustmark" is a large US company
(https://en.wikipedia.org/wiki/Trustmark)?


S 11.2.
>      category MAY be used in a single transaction.
>   
>      C0 No credential is used / anonymous public service
>      Ca Simple session HTTP cookies (with nothing else)
>   
>      Cb Known device

What is "known device"?


S 11.2.
>   
>      Ce Cryptographic proof of key possession using asymmetric key
>   
>      Cf Sealed hardware token / keys stored in a trusted platform module
>   
>      Cg Locally verified biometric

This seems like it might want to include token binding.

It's probably not ideal that there is normative language in appendix A. Maybe move the intro part of the appendix to the body of the document...?