Re: [VoT] Vectors of Trust I-D

[Ira McDonald <[e-mail]>]

Hi,

Thanks Justin and Leif for a really thought-provoking document.

Thanks Scott for a compact equation for trust.

About terminology:

Coming from the mobile device and automotive perspectives, the use
of *anonymized* identity for privacy protection is a major requirement.

In biometrics especially, devices should send anonymized user identity
authentication info as a "token".  But the common English definition of
"credential" precludes any such anonymization.

I suggest shifting to "token" and stressing the need for anonymous (but
highly reliable through Trusted Third Parties) device and user identities.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [e-mail]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Tue, Jun 30, 2015 at 12:25 PM, Scott Shorter <
[e-mail]> wrote:

> Great discussion all.  I don't know if I've said it here before, but my
> equation for trust goes like this:
>
>      trust = 1 / risk
>
> If we are trying to measure risk, what if this were considered a "risk
> score" that is calculated from "risk metrics"?  Identity risk score, if we
> want to get crazy.
>
> I get the notion from the Common Vulnerability Scoring System (CVSS,
> version 3 draft is available here
> <https://www.first.org/_assets/downloads/cvss/cvss-v30-preview2-metricvectorstring-december-2014.pdf>).
> I think that there's a lot of similarities between vulnerability management
> and credential management.  Vulnerabilities represent potential risks to
> systems, and CVSS provides a way of expressing those risks.  Similarly
> every credential issued represents a marginal increased risk, and our
> strawperson document currently looks a lot like CVSS.
>
> I don't know whether more harm is done by unmanaged credentials or
> unmitigated vulnerabilities, but each of those should be captured in an
> organization's risk registry.
>
> My 0.02USD,
> Scott
>
> On Tue, Jun 30, 2015 at 12:01 PM, Justin Richer <[e-mail]> wrote:
>
>> 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] <[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
>>
>>
>>
>> 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.
>>
>>
>>
>> _______________________________________________
>> vot mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>
>
> --
> ==============================================================
> *Scott Shorter, Principal Security Engineer*
> Electrosoft *–* Fueling Customer Success Through Outstanding Value and
> Trust!
> *Woman-Owned, Minority-Owned Small Business | ISO 9001 | CMMI Level 2 *
> 1893 Metro Center Drive; Ste 228; Reston, VA 20190
> [e-mail] (Email);   http://www.electrosoft-inc.com
>  (Web)
> ==============================================================
>
> _______________________________________________
> vot mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vot
>
>