Re: [VoT] VoT Identity Proofing and individual claims

Phil Hunt <> Wed, 13 September 2017 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8FA7132EDC for <>; Wed, 13 Sep 2017 12:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZfJD3R3BvXEb for <>; Wed, 13 Sep 2017 12:10:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD327132EBB for <>; Wed, 13 Sep 2017 12:10:04 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8DJA3mn005691 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 19:10:04 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id v8DJA3jM005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 19:10:03 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id v8DJA25b013287; Wed, 13 Sep 2017 19:10:03 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Sep 2017 19:10:02 +0000
From: Phil Hunt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_71E93C0C-A728-460C-8E90-4EEEF80FD69F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 13 Sep 2017 12:09:59 -0700
In-Reply-To: <>
To: Justin Richer <>
References: <> <>
X-Mailer: Apple Mail (2.3273)
X-Source-IP: []
Archived-At: <>
Subject: Re: [VoT] VoT Identity Proofing and individual claims
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Vectors of Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Sep 2017 19:10:08 -0000


I don’t believe making things arbitrarily out of scope helps simplify.  In this case, I believe it complicates matters.

Firstly, missing from the spec….a definition of Identity.

> 2.1 <>.  Identity Proofing
>    The Identity Proofing dimension defines, overall, how strongly the
>    set of identity attributes have been verified and vetted.  In other
>    words, this dimension describes how likely it is that a given digital
>    identity transaction corresponds to a particular (real-world)
>    identity subject.
>    This dimension SHALL be represented by the "P" demarcator and a
>    single-character level value, such as "P0", "P1", etc.  Most
>    definitions of identity proofing will have a natural ordering, as
>    more or less stringent proofing can be applied to an individual.  In
>    such cases it is RECOMMENDED that a digit style value be used for
>    this component.

What is meant by overall?  Is it an average?  The lowest value of all of the attributes (claims)?

What is meant by a real world identity subject?  Do you mean a legal person?  Do you mean a device/thing?

An overall level of confidence in how strongly a transaction corresponds to a particular identity subject sounds an awful lot like authentication confidence.

I can see how you might arrive at this definition looking an an internal data system like a payroll system. You can assess the procedures and establish an overall confidence level in the quality of data.  But as soon as you want to share that payroll data with other systems.  

I began my experience in Identity management building large scale meta-directories. We once assumed business systems like payroll systems were authoritative over things like employee addresses.  Turns out we were wrong.  Payroll doesn’t care about addresses, they care about bank account deposit numbers.  

Conclusion:  Just because the payroll department has a high level of confidence in the attributes they have *internally*, it does not mean there is high confidence for secondary uses.  If you ask payroll about sharing data, they might only share employee number, salary, and bank accounts as being accurate (assuming there was a valid reason to share).  Should an IDP based on payroll only assert high level data?  Can they assert low-level data for the purpose of correlation/confirmation?

Another case, look at Facebook and Twitter. They have variable assertions as well.  Some users are verified and some are not.  What does that mean? How would VoT help in this case?  Would it mean that the out of scope information in the name claim is deemed accurate?  Are we talking about the same Michael Douglas or are we talking about Michael Keaton (Michael Keaton’s real name is Michael Douglas).


Oracle Corporation, Identity Cloud Services Architect
@independentid <> <>
> On Sep 13, 2017, at 10:57 AM, Justin Richer <> wrote:
> It applies to the IdP’s judgement across the entire assertion. How that’s calculated when the trust in different attributes differs will vary depending on the IdP, and probably defined by rules within the trust framework that defines the vector values themselves. NIST 800-63-3 volume A, for example, is very clear about how to handle all the attributes collected at different levels. If you were using NIST’s encoding of VoT, specified in the upcoming volume D of that document, then you’d be bound by those rules as an IdP. A university group, like you’re talking about below, might have different rules under its own trust framework and vector component definitions.
> It looks like you might be asking if this is about per-attribute metadata. If you read the introduction, we explicitly state that we’re not trying to solve per-attribute metadata. If you’d like that kind of data, you’re looking for a different kind of solution, of which there have been numerous attempts over the years. Generally speaking, attribute metadata systems look great on paper but are incredibly complicated for RP’s to implement. When we wrote VoT, we directly decided to take a different approach, something between the granularity of attributes and the single-scale of LOA. 
> This level of granularity is very, very useful in the real world, otherwise we wouldn’t have dozens of international trust frameworks based around the concept of proofing an individual and tying that account to a set of proofed attributes. There isn’t an easy way to express something complex as “We’re sure this is Justin but aren’t sure about his medical degree” in any VoT implementation that I’ve seen to date, and especially not in the example values given in the spec itself. But if you really wanted to, you could have something like:
>  - P3: High level of confidence in individual’s name, address, phone, eye color, and shoe size
>  - Pm: In person verification of a medical degree by making the claimant perform surgery on the verifier.
> So if you wanted to express that, you could say “P3.Pm” or just “P3” if you weren’t so sure about that medical degree. However, like I described above, I don’t think this is a good solution for that as you’d need to get really specific with each attribute. If you really need that level of expressiveness, you’ll want a different solution and VoT doesn’t work for you. However, just because it doesn’t solve this use case doesn’t mean it’s not useful in many others. VoT is a tool fit for a purpose that we tried to express in the intro text, it fits in between attribute metadata and single scalar measurements. And in fact, you could use it side by side in the same system, and I see no conflict in this.
> Don’t deny the world a hammer just because you think you need a screwdriver.
>  — Justin
>> On Sep 13, 2017, at 1:01 PM, Phil Hunt < <>> wrote:
>> Section 3.1
>> Does 3.1 apply to the identifier issued, to the whole assertion? 
>> An Identity is usually an identifier and a set of claims.
>> So what about claims?   Some claims may be issued by a provider (and thus are P3) while others may be provided as self asserted by the subject.  Some, as in banking may have involved a physical documents or other mechanism and thus all claims are not equal.
>> I have trouble determining the affect of P0-P3 and worry that privilege escalation will occur since not all claims are equal.  There isn’t really a way to say “We’re confident this is Justin, we’re just not so sure about his medical degree”.
>> Consider a university knows student numbers and degrees and courses completed. Is it authoritative over nationality, residence, addresses?  Maybe. Maybe not.
>> Consider a social network. In many cases they can be considered authoritative over the social network identity (P3) but know nothing about most users.
>> I’m just not sure identity proofing as expressed is actually useful.
>> Phil
>> Oracle Corporation, Identity Cloud Services Architect
>> @independentid
>> <> <>
>> _______________________________________________
>> vot mailing list
>> <>