Re: [VoT] Vectors of Trust I-D

[Justin Richer <[e-mail]>]

Josh, thanks for the great comments. Responses inline:

> On Jun 30, 2015, at 7:22 AM, Josh Howlett <[e-mail]> wrote:
> 
> Justin, Leif,
>  
> Thanks for this draft. I only have some general comments at this point. The first two concern the use of language; I might be hair-splitting: YMMV. The final comment is more substantive. <>
>  
> 1. Vectors have a very specific formal meaning in mathematics. Given that this is an engineering community, I think there’s a possibility of creating confusion from the use of this language. You correctly try to disambiguate this in 2.2, but the use of different language would make this unnecessary.

When we picked the name “vectors of trust” we knew that both “vector” and “trust” were terms that were going to confuse some people but could be explained fairly succinctly in this context and help get the point across. I’m honestly welcome to renaming the whole shebang but for now I’ve yet to hear a better set of terms.

>  
> 2. The draft talks of vectors of trust but actually describes types of evidence and attributes that can be associated with these. As you discuss in section 7.1, there is a specific trust context which confers semantics on these attributes ex post facto. Thus this evidence and their attributes can inform runtime outcomes, in the context of a given trust context, but do not define it. I think it might be helpful to reconsider the description of this work, so that its goal is clearer to the reader; and set out the fundamental role of the trust context within the introduction/background.

It was only in this latest draft that we really started to set out the importance of context for a given VoT value, so I think your comments here are valid. 

>  
> 3. The goal of the draft, as I understand it, is to enable RPs and IdPs to share a common vocabulary of evidence and their attributes. This avoids the “bundling” of different kinds of evidence by allowing for decomposability. This evidence, now unbundled, can be employed in different trust contexts, facilitating interoperability across trust framework. So far so good? However I’ll note that the evidences and attributes described in section 3 are often themselves bundles (“C5 Sealed hardware token / trusted biometric / TPM-backed keys). So, playing devil’s advocate, what is to stop actors from decomposing the core elements described in section 3? Indeed I think it’s actually a goal of this document to permit that through extensions. I wonder therefore whether an excess of decomposability will actually aggravate interoperability between trust contexts. Clearly this could be addressed by setting norms, but then you’ve reinvented NIST 800-63. Alternatively you could imagine a taxonomy of evidence, with classes and (through extensions) sub-classes allowing for greater specificity, while providing for a general interpretation if actors do not share the same vocabulary. I hesitate to describe this as fractal, but I hope you can see what I’m driving at.
>  
> 

It could definitely be fractal, but I think it’s important that we capture something at the right level. Aggregate a bunch of vector values together and you get a definition like 800-63, which is still useful but only in its intended consequences. Break apart the vector components and you get into the specifics of a full trust framework definition, like the high granularity in the GTRI work (or Steve’s “everything is an attribute” utopia). I think there’s value in each of those, but the value doesn’t really come at runtime when you need to make a contextual decision. That’s where I think that the VoT approach can really shine. It’s more granular than the broad sweeping definitions that authentication guidelines would have, but it’s less granular than a sea of attributes. We want something that an RP can hope to process and make sense of, and to do that we need to walk a fine line.

 — Justin

> Josh.
> From: vot [mailto:[e-mail]] On Behalf Of Justin Richer
> Sent: 27 June 2015 04:15
> To: [e-mail]
> Subject: [VoT] Vectors of Trust I-D
>  
> 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
> 
> Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
> 
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.