Re: [VoT] Vectors of Trust I-D

[Scott Shorter <[e-mail]>]

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)
==============================================================