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

From: Steve Olshansky <[email-masked]>
Date: Tue, 4 Aug 2015 12:46:19 +0000

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

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 4 Aug 2015 13:51:15 +0000

Steve,

My apologies… I was editing the draft notes, and our emails crossed in the ether… 

The big changes I made were correcting the actual attendance…
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 

And specifying the next steps at the end. The action items you specified below were 
not in the draft minutes and are not quite accurate. The issue tracker item is quite important,
and we were not pursuing formal liaison relationships until there was a working group to
liaise with (if it should come to that). 

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 
([email-masked]). 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. 

I have attached my edited notes for reference. My apologies for the delay, but I
was on vacation and just didn’t get to it. 

Regards,
Karen

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 5 Aug 2015 03:13:56 +0900

Indeed, and it was one of the reason why we wanted to become a formal WG.
For a formal liaison arrangement, we need to be a formal body.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en