Vectors of Trust (VoT) Bar BoF
22-July-2015, 8:00 pm CEST

Attending:
Leif Johansson, Steve Olshansky, Justin Richer, Robin Wilton, Karen 
OÕDonoghue, Nat Sakimura, Wendy Seltzer, Stephanie Gedes, and 
Steve Moore
Remote: Jim Fenton and Colin Wallis 

The main purpose of the Bar BoF was to talk about the current state 
of the document and to discuss potential next steps. 

Document Discussion:
==================
Justin Richer provided a quick overview of the current draft (draft-
richer-vectors-of-trust-00) and a high level summary of the comments 
received to date including: 

-	Default values have led to some objections, but they are simply 
a starting point
-	Orthogonality Ð the vectors should not overlap, but should be 
conceptually as different from each other as possible
-	VoT should be an expression construct for these types of 
semantics
-	We need guidance language re what orthogonality means in 
this context Ð these things are not completely orthogonal

There was discussion on several aspects of the current draft 
including: 

(Nat) (ITU-T) X.1254 and (ISO/IEC) 29115 tackle the issue of 
common trust frameworks and defined policies across different 
jurisdictions already, and that work is more accommodating than 
NIST 800-63. We should look at those to see if there is anything we 
can use or refer to. 

Vectors need to be evaluated by a relying party (RP) in a context. 
How simple can we make this work, without it being too simple?

Unbundling attributes leads to expressing them as vectors and not as 
levels of assurance (LoA). 

Liability: (Nat) In P3, a legal contractual relationship is not quite 
identity proofing. (Justin) Feedback from Kantara in other contexts 
was related to a legally binding relationship with a person, e.g. for 
payroll. (Leif) We could add another category / vector for degree of 
liability protection. Does this merit inclusion in the core or as an 
extension?

Attestation of proofing is contextual to authn, otherwise you are 
leaking private info. 

Keep in mind that the goal here is targeted to provide context for user 
authn Ð how certain am I that this person is identified correctly, and 
how certain can you be in my assertion about this?

(Robin) Extensions can lead to breaking down into pairwise 
agreements between stakeholders, and for liability this would be a 
good thing.

If a user is presenting the same credential, do we want the system to 
assert different VoT?
Justin: OpenID Connect has a notion of pairwise identifiers for a high 
assurance anonymous transaction. Regardless of assurances that 
the IdP has about me binding to an account, it will not convey that 
information because I told it not to. 

(Robin) How reliable is the credential lifecycle, verification and 
enrollment. Can the credential be forged or tampered with in 
presentation?

C = primary credential
A = derived federated credential

Trustmarks will provide ultimate definitions of the vectors. 

We need a way to handle:
-	account chooser
-	liability expressions
-	(+what else?)

(Nat) Why not just use existing documents like 29115 for definitions?
(Justin) This is what we want people to use in the real world. Doc has 
general case examples. We could use these other definitions, but 
making them up forces people to think about them. Ultimately we 
could certainly do that if that makes more sense. eIDAS is referencing 
29115.

(Colin) Perhaps we should add a cookbook or appendix referencing 
definitions from other sources. 

Where should the syntax pieces live? IANA registry? 

There are 2 dimensions to this work at a high level:
	- what are the categories?
	- what should be in them, are they ordered, does order matter?

Solution could be to Òlead by exampleÓ in the document and expect 
people to adapt to their own needs

Do we want to have one trustmark definition across entire vector, or 
should that be separable as well into components? (Justin) Yes, just 
one, send a URI for each vector. 

(Robin) In IoT we will have a number of things talking to each other, 
each with its own baggage. So expecting RP to look each one up is 
not realistic. 

The point about (not) using the labels ÒsubÓ and ÒissÓ for vectors and 
trustmarks needs to be investigated further. 

Next Steps:
=========

To wrap up the meeting, we discussed next steps for this work. They 
include the following: 

1. Justin will produce the next edition of the document. Comments 
can be sent either via pull requests on GitHub or to the mailing list 
(vot@ietf.org). General discussion should take place on the mailing 
list. 

2. We need to ensure that we are tracking and properly addressing all 
issues raised. We need to ensure that we are clear and transparent in 
this effort especially as we try to coordinate with groups and 
individuals who are not as familiar with the IETF process and 
shorthand. We will use the existing GitHub issue tracker:
https://github.com/vectorsoftrust/strawman/issues
We need to ensure all existing issues get added to the tracker. 

3. We need to ensure coordination with other SDOs working in this 
space. A recurring question was where this work should take place. 
The IETF does not seem to have quite the right expertise, but it is not 
clear there is a better forum. In order to be successful, this work will 
require close coordination with a number of other SDOs engaged in 
related work. We need to ensure that there is coordination with those 
SDOs (like ISO and ITU-T) so that we can leverage their expertise in 
this work. If we end up establishing an IETF working group, there will 
probably be official liaisons established with these SDOs. Until then, it 
will be up to us to coordinate leveraging on our existing connections 
and relationships.