Subject: Re: [VoT] Vectors of Trust I-D

From: "Kelts, David" <[email-masked]>
Date: Thu, 2 Jul 2015 20:29:03 +0000

Also expressing my thanks for this strawman and the discussion…

I’ve enclosed, for your consideration, a snippet of 800-63 feedback where I’d attempted to diagram and lexicon 4 components of Trust.   Some of my comments and terminology may spring from that model.

Since “Trust” is a two way experience, the addition of a vector for Level Of Control by the consumer over the interaction would enhance this VOT model.  The establishment of consent is necessary for many use cases, has value to RPs, and facilitates privacy.  For example (following the strawman): 0=no consent, 1=prior blanket consent, 2=specific, 3=specific purpose, etc.  This LoC value could be extracted from OIDC flows since Consent follows AuthN.

One possibility that might emerge from the 4-component model is that consumers could choose services that operate on their behalf and the IDP or TFP aggregates on behalf of consumer choice.  AuthN Services (like Fido) could create a scoring system while Consent Services create one also.  As a consumer, I can choose my Fido MFA widget to maximize my LoA(authentication) and take control over logins by expressing my consent preferences.  All can become aggregated.

The comment by Debbie Bucci on creating a container that enables differing content is interesting, and along the lines of Justin’s comment that the values within a vector are very tied to a trust framework.   I wonder, would the notation (or some mathematically accurate version) of { “P1:4.C2:5.A3:3.N5:5” } allow for the expression of the range of values within the vector?  This would allow frameworks to set their vector ranges and allow for RPs to calculate across TFTMs.  It might also make it just messy.  :)  Normalizing range on 100% is also possible.

If we do go down the “content of the vectors” path…
In the strawman’s list of component definitions (4), I would *strongly* suggest a P4 = “The IDP has legal authority to perform identity proofing of the subject and has satisfied proofing for this subject to its published standard”.  P3 as described would describe the sponsored employee paradigm of 800-63 but fall short of a proofing requirement for legal transactions.  For instance, we’re unlikely to allow online voting based on a P3 as described, but a credential from a legal authority could enable it.  National ID programs in countries that have them would be P4 when enabled online.

From that same section 4, I commend the subtle difference between C4 and C5 that would enable PKI to insert an equivalence to the PIV card in LOA4.  At the same time, you may want to alter C2 to “Known second-factor…” and possibly C3 to include the concept of multi-factor authN as equivalent to cryptographic proof.

I had other comments and potential edits on the spec, but can see how conversation evolves.  Hard to be brief when there’s real content, which is an excellent thing.

David

David Kelts
Director of Product Architecture

Phone:  978-215-2573
Mobile: 508-633-1133
Fax:  978-215-2500
296 Concord Ave, Suite 300
Billerica, MA, 01821   USA
[email-masked]<mailto:[email-masked]>
www.MorphoTrust.com<http://www.morphotrust.com/>

Follow @IdentoGO<https://twitter.com/identogo> on Twitter and IdentoGO<http://www.linkedin.com/company/identogo> on LinkedIn. Like IdentoGO<https://www.facebook.com/identogo> on Facebook.

From: vot [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Tuesday, June 30, 2015 1:38 PM
To: Scott Shorter; Ira McDonald
Cc: Josh Howlett; Justin Richer; [email-masked]
Subject: Re: [VoT] Vectors of Trust I-D

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]<mailto:[email-masked]>
Winter  579 Park Place  Saline, MI  48176  734-944-0094<tel:734-944-0094>
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<tel:906-494-2434>

On Tue, Jun 30, 2015 at 12:25 PM, Scott Shorter <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Josh, thanks for the great comments. Responses inline:

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

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]] On Behalf Of Justin Richer
Sent: 27 June 2015 04:15
To: [email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]> (Email);   http://www.electrosoft-inc.com<http://www.electrosoft-inc.com/> (Web)
==============================================================

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

________________________________

This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 30 Jul 2015 13:15:44 -0700

I made another pass through the document and have some more comments.
I'll leave out the grammatical nits, although I'm happy to pass them
along to the authors if they want them.

1.1 Terminology

Credential - I understand that "token" has conflicting usage, but
credential does too. At a minimum, a definition stating what this
document means by credential is needed.

Identity Provider - Manages "identity information".  What's that?  Seems
a bit circular. In many circumstances, assertions of attributes might
come from different parties than the one that authenticates the user. I
hope we can accommodate separation of authentication and attributes here.

Relying Party - "logging users in".  Additional attributes might also be
consumed for authorizing further access beyond the initial login.  I'd
prefer "authenticating users and authorizing their actions".

Trustmark - "has proved". My mind immediately went to some sort of
cryptographic proof. You seem to mean "is expected", "is deemed", or
something like that.

2. Background and Motivation

"attributes about an identity transaction": Attributes has a conflicting
meaning. How about "aspects of an identity transaction"?

Paragraph 2, last sentence.  I don't really understand what this is
saying, but identity proofing should be able to be done after token
issuance, and perhaps by a different party than the issuer.

2.1 last paragraph: I don't understand what point this is trying to
make, but binding of credential and the user is a "representation of the
identity proofing process" doesn't quite make sense.

3.2 Credential Management should be titled Credential Binding to be
consistent with earlier text.

use the "credential" to denote the credential: circular definition

3.3 Assertion Presentation: Doesn't the RP have direct visibility on how
the assertion is presented? For example, it shouldn't be necessary to
say something like "Token encrypted to the relying party's key" because
the relying party already knows that. There is perhaps some need for a
way for the RP to specify how the assertion is to be delivered, however.

4. Component Definitions

C5 is an example that is particularly troubling: equating a sealed
hardware token with a trusted biometric or TPM-backed keys. If the C
specification is an enumerated list, perhaps each of them should have a
C number. But if the components are that fine-grained, a requesting
vector (section 6) might be quite long and complex to represent all the
combinations of components that are acceptable. I personally prefer an
ordered set of value within each vector component that would be
necessarily more coarse-grained than this. In that case, the requesting
vector could be something like "P2.C2" which would mean P >= 2 AND C >= 2.

Eventually, the syntax will need to be nailed down further, probably
using ABNF.  For example, can P2.C2 be used as well as C2.P2?

The initial C values don't say anything about multifactor authentication.

5. Communicating vector values to RPs: I wonder if these values should
always be encrypted on the wire to protect against attackers looking for
high-value targets.

7.1 Trustmark

Trustmarks have enough usefulness independent of VoT that we should
consider whether they should be an independent specification.

Trustmarks are needed for attribute providers as well as IdPs. And
probably for attribute providers and brokers (like connect.gov) as well.

As specified, anyone who has a valid TLS certificate for the trust
framework can assert the trustmark, including rogue CAs. This might not
be good enough where substantial liability exposure is involved. Perhaps
the trustmark should be signed as well, maybe using keys verified with DANE.

-Jim

On 6/30/15 6:23 AM, Jim Fenton 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