Re: [VoT] Vectors of Trust I-D

["Kelts, David" <[e-mail]>]

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:  [phone]
Mobile: [phone]
Fax:  [phone]
296 Concord Ave, Suite 300
Billerica, MA, 01821   USA
[e-mail]<mailto:[e-mail]>
www.MorphoTrust.com<http://www.morphotrust.com/>

[cid:image001.jpg@01D0B4E4.31052BB0]

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:[e-mail]] On Behalf Of Ira McDonald
Sent: Tuesday, June 30, 2015 1:38 PM
To: Scott Shorter; Ira McDonald
Cc: Josh Howlett; Justin Richer; [e-mail]
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: [e-mail]<mailto:[e-mail]>
Winter  579 Park Place  Saline, MI  48176  734-944-0094<tel:[phone]>
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<tel:[phone]>

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

On Jun 30, 2015, at 7:22 AM, Josh Howlett <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]> (Email);   http://www.electrosoft-inc.com<http://www.electrosoft-inc.com/> (Web)
==============================================================

_______________________________________________
vot mailing list
[e-mail]<mailto:[e-mail]>
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.