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

[Ballot comment]
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:


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.)





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.

[Ballot discuss]
Is it really appropriate for this document to put normative requirements on OpenID Connect? The reverse would typically not be true, which is why I wanted to check.

[Ballot 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.)

[Ballot comment]
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.

[Ballot comment]
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)

[Ballot comment]
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.

[Ballot comment]
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...?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-richer-vectors-of-trust-11. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, a new registry is to be created called the Vectors of Trust Components Registry. The new registry will be managed via Specification required as defined by RFC 8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

We understand that there are initial registrations in this new registry as follows:

Demarcator Description Change
Symbol Controller Reference
+-----------------------------------+-----------+------------
P Identity proofing IESG [ RFC-to-be ]
C Primary credential usage IESG [ RFC-to-be ]
M Primary credential IESG [ RFC-to-be ]
management
A Assertion presentation IESG [ RFC-to-be ]

Second, in the OAuth Parameters registry on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

a single, new registration will be added to the registry as follows:

Name: vtr
Description: Vector of Trust request
Parameter usage location: authorization request, token request
Change Controller: IESG
Document: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the JSON Web Token Claims Registry on the JSON Web Token regsitry page located at:

https://www.iana.org/assignments/jwt/

two new registrations are to be made as follows:

Claim name: vot
Claim Description: Vector of Trust value
Change Controller: IESG
Document: [ RFC-to-be ]

Claim name: vtm
Claim Description: Vector of Trust trustmark URI
Change Controller: IESG
Document: [ RFC-to-be ]

As this section also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JSON Web Token Claims have asked that you send a review request to the mailing list jwt-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the OAuth Token Introspection Response registry also on the OAuth Parameters registry page located at:

https://www.iana.org/assignments/oauth-parameters/

two new registrations are to be made as follows:

Metadata Name: vot
Metadata Description: Vector of Trust value
Change Controller: IESG
Document: [ RFC-to-be ]

Metadata Name: vtm
Metadata Description: Vector of Trust trustmark URI
Change Controller: IESG
Document: [ RFC-to-be ]

As this section also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-26):

From: The IESG
To: IETF-Announce
CC: draft-richer-vectors-of-trust@ietf.org, kaduk@mit.edu, sean@sn3rd.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Vectors of Trust) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'Vectors of Trust'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-06-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a mechanism for describing and signaling
  several aspects of a digital identity transaction and its
  participants.  These aspects are used to determine the amount of
  trust to be placed in that transaction.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-richer-vectors-of-trust/ballot/


No IPR declarations have been submitted directly on this I-D.

Notification list changed to "Karen O'Donoghue" <odonoghue@isoc.org>, John Bradley <ietf@ve7jtb.com>, Sean Turner <sean@sn3rd.com>,  from "Karen O'Donoghue" <odonoghue@isoc.org>, John Bradley <ietf@ve7jtb.com, Sean Turner <sean@sn3rd.com>

Notification list changed to "Karen O'Donoghue" <odonoghue@isoc.org>, John Bradley <ietf@ve7jtb.com, Sean Turner <sean@sn3rd.com> from "Karen O'Donoghue" <odonoghue@isoc.org>, John Bradley <ietf@ve7jtb.com