Subject: [VoT] Vectors of Trust I-D

From: Justin Richer <[email-masked]>
Date: Fri, 26 Jun 2015 23:15:11 -0400

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

---

From: Josh Howlett <[email-masked]>
Date: Tue, 30 Jun 2015 11:22:41 +0000

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.

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.

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.

Josh.
From: vot [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: 27 June 2015 04:15
To: [email-masked]
Subject: [VoT] Vectors of Trust I-D

Hi Everyone,

https://tools.ietf.org/id/draft-richer-vectors-of-trust-00

 — 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.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 30 Jun 2015 06:23:15 -0700

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:
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot

---

From: Justin Richer <[email-masked]>
Date: Tue, 30 Jun 2015 11:54:24 -0400

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 <[email-masked]> wrote:
> 
> 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
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/vot <https://www.ietf.org/mailman/listinfo/vot>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 30 Jun 2015 12:01:59 -0400

Josh, thanks for the great comments. Responses inline:

> On Jun 30, 2015, at 7:22 AM, Josh Howlett <[email-masked]> 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. <>
>  

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 wh…

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 a…

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

---

From: "Jones, Mark B" <[email-masked]>
Date: Tue, 30 Jun 2015 16:03:50 +0000

'Credential' is just as overloaded as 'token'.  I think you just need to
pick a term and make sure it is well defined in the document.

The External Identity working group decided to use the term 'authenticator'.

https://spaces.internet2.edu/display/EXTID/External+Identities+Working+Group
+Report

From: vot [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Tuesday, June 30, 2015 10:54 AM
To: Jim Fenton
Cc: [email-masked]
Subject: 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

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

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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draf
t-2Dricher-2Dvectors-2Dof-2Dtrust-2D00&d=BQMF-g&c=6vgNTiRn9_pqCD9hKx9JgXN1Va
pJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=D7k8gb4TAu
copdNmcdaifmXQtO1jWHH2uV_Cj6pmYHA&s=IwCJH7ghyIh0YTbpIPjpug1zmFhB0yPqQGbyYhqr
mRw&e=> 

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
[email-masked]
https://www.ietf.org/mailman/listinfo/vot
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_vot&d=BQMF-g&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DN
gV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=D7k8gb4TAucopdNmcdaifmXQtO1jWHH2uV_Cj
6pmYHA&s=X0ZbIaYx4wnBo5JKrUCwAlSMm0NP7vycKmcLkHZBw3I&e=>

---

From: Scott Shorter <[email-masked]>
Date: Tue, 30 Jun 2015 12:25:22 -0400

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 <[email-masked]> wrote:

> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Justin Richer
> *Sent:* 27 June 2015 04:15
> *To:* [email-masked]
> *Subject:* [VoT] Vectors of Trust I-D
>
>
>
> Hi Everyone,
>
>
>
> It’s still a very drafty draft, but hopefully it’s starting to make this a
> 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.
>
>
>

-- 
==============================================================
*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
[email-masked] (Email);   http://www.electrosoft-inc.com (Web)
==============================================================

---

From: Ira McDonald <[email-masked]>
Date: Tue, 30 Jun 2015 13:37:31 -0400

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: [email-masked]
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 <
[email-masked]> wrote:

>> 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”
>> number of edits and inputs from several folks and have created an initial
>> I-D of the document:
>>
>>
>>
>> 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.
>>
>>
>>