[VoT] Notes: VoT BoF 22-July-2015 (@IETF93, Prague)

[Steve Olshansky <[e-mail]>]

VoT BoF: 22-July-2015 (@IETF93, Prague)

***NOTE on making changes to the ID***
=> While discussion about the ID on the list is interesting and useful for fleshing out the issues, ultimately the only things that will impact the draft are actual suggested text to add or change. We can use the existing GitHub tracker:
         https://github.com/vectorsoftrust/strawman/issues
And we will use the this mailing list as the side-channel at least for now, for those uncomfortable with using GitHub.
 
*Attending*
Remote: Jim Fenton, Colin Wallis, Nov Matake 
In the room: Leif Johansson, Steve Olshansky, Justin Richer, Robin Wilton, Karen O’Donoghue, Nat Sakimura 

*Action Items*
[AI_1] (Justin) rev the ID (at least) once more, including adding more explanatory text
[AI_2] (Steve) set up liaison relationships with other SDOs to encourage participation

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

Justin: NIST needs a mechanism for conveying the various categories separately

Vectors need to be evaluated by 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 LoA

COMMENTS - responses
-	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

Nat: in P3, legal contractual relationship is not quite identity proofing
Justin: feedback from Kantara in other contexts was related to legally binding relationship with a person, e.g. for payroll
Leif: we can tweak the language to reflect this. Another category / vector could be degree of liability protection. Does this merit inclusion in the core, v. 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 user is presenting same credential, do we want system to assert different VoT?
Justin: OpenID Connect (OIC) has notion of pairwise identifiers, and regardless of assurances that IdP has about me binding to an account it will not convey that because I told it not to – high assurance anonymous transaction

Robin: re: credential lifecycle, verification and enrollment, how reliable is this, and can the credential be forged or tampered with in presentation?

A typical ‘credential lifecycle’ model runs like this:
1.	Do identity proofing, verification and enrolment;
2.	Bind credential to user (e.g. through biometrics, shared secret, etc.)
3.	Issue credential (hopefully a nice robust one that is hard to forge/tamper with)
4.	Credential gets presented by the user
5.	Credential gets verified by RPs
6.	Credential may get modified/updated by issuer
7.	Credential may get revoked/reactivated
8.	Credential destruction

The VoT model specifies the attributes IDPs and RPs can exchange concerning steps 1, 2 and 4.
My question was about the reliability of step 5.

By analogy: when your bank issues you with a payment card, they can be reasonably confident that they are issuing it to the right account holder; they can assume that when you sign it, you sign it with your own signature, and that you make the same signature when you’re buying something (that’s steps 1, 2 and 4). But retail staff never do a good job of comparing your signature to what’s on the card… so the model breaks down at step 5.

Robin: In the current draft, the vector message and the trustmark message both use the same variable labels (iss and sub), even though the labels refer to different things in the two types of message. I think that’s likely to lead to confusion, and sooner of later to someone making a coding/verification error.

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 rather than lazily just using ours. Ultimately we could certainly do that if that makes more sense. eIDAS is referencing 29115.

Colin: suggest adding a cookbook or appendix referencing definitions from other sources

Q: where should the syntax pieces live? IANA registry? 

2 dimensions to this work at a high level:
	1. what are the categories?
	2. 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

Q: Do we want to have one trustmark definition across entire vector, or should that be separable as well into components?
J: 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 of T&Cs. So expecting RP to look each one up is not realistic

Notwithstanding the questions of where this work should take place, 
would it make sense to setup liaison relationships to other SDOs to encourage participation?

Q: Do we have right expertise within the IETF community?
The general sentiment in the room was “not quite.” Note that this work originated from discussion at an Internet Society workshop held last September. While the mailing list is hosted by IETF, and this work *may* at some point make its way toward becoming a chartered working group there, setting up an IETF non-working group mailing list for this work was a choice made as a matter of convenience at the beginning of this effort, and due to a friendly IPR framework. That being said, there is no reason that this work couldn’t or shouldn’t move to another forum at some point if that seems beneficial.

Thus, in order to mitigate the fact that the IETF community may not have the right expertise, and toward obtaining the best result from our work, we reached the conclusion that creating liaison relationship with other SDOs like ISO and ITU-T would be a good idea, so that we can leverage their knowledge and experience in this work 

[AI_2] (Steve) set up liaison relationships with other SDOs to encourage participation

 
--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org