Re: [VoT] Vectors of Trust I-D

Leif and I went back and forth on this one and decided to put a stake in the ground to start at. One of the biggest challenges in LoA-style systems has always been the overloading of the linear scale model. I’ve seen passionate arguments about the ordering of otherwise similar components, with people willing to die for the cause on both sides. I think that we can side step that with the technology expression while still keeping the “common sense semantics” of ordinals. In that “2 is probably better than 1 for most values of better but mostly they’re just different”.

I’m also afraid of the growth of the space for each component, but hopefully by having a few definitions set good examples (like the spec itself) we can encourage people to summarize the categories appropriately, as Josh talks about in his response.

While I agree that naming things is hard, and I’m open to new names, I’m very strongly against the use of “token” here. It’s already far too overloaded a term. OAuth issues tokens, FIDO calls their devices tokens, the IETF’s “token binding” is calling something (that I’m not even sure what it is) tokens, even the WS-* folks have started to re-cast all the WS-* stuff as “tokens”. I think the more precise term is “primary credential” or “primary user credential”. Neither of these have anything to do with the attributes, but they do speak to how strongly bound the credential is to the account. Still, I’m open to better names.

Thanks for the feedback,
 — Justin

> On Jun 30, 2015, at 9:23 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
> 
> Justin and Leif, thanks for getting things moving with this draft.
> 
> The biggest surprise to me is that (section 2.2, last paragraph) the components of the vector do not have ordinal properties; i.e., they are just an enumerated list. Aside from confusing people that are expecting a vector to be a set of scalars, it also requires Relying Parties, for example, to enumerate all of the types of credential management they will accept rather than "C2 or better". This isn't a huge problem at the current scale, but I'm concerned that the number of choices might grow.
> 
> I also have some problem with the use of the term "credential" because it encompasses management of attributes as well as tokens, which then overlaps with the identity proofing dimension which is, more generally, the question of how strongly the relying party can depend on attribute values.  I'd rather that we use the term "token" rather than "credential" to keep these separate.
> 
> -Jim
> 
> On 6/26/15 8:15 PM, Justin Richer wrote:
>> Hi Everyone,
>> 
>> I have taken the initial strawman proposal along with a substantial number of edits and inputs from several folks and have created an initial I-D of the document:
>> 
>> https://tools.ietf.org/id/draft-richer-vectors-of-trust-00 <https://tools.ietf.org/id/draft-richer-vectors-of-trust-00>
>> 
>> It’s still a very drafty draft, but hopefully it’s starting to make this a concrete thing. Please read it over and discuss it here on the list.
>> 
>> I would like to propose a bar-BoF in Prague for VoT for anyone who would like to discuss this. If you’re interested (and will be there in person), let me know!
>> 
>>  — Justin
>> 
>> 
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org <mailto:vot@ietf.org>
>> https://www.ietf.org/mailman/listinfo/vot <https://www.ietf.org/mailman/listinfo/vot>
> 