Re: [VoT] VoT Identity Proofing and individual claims

Justin Richer <> Wed, 13 September 2017 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 958A0132EC4 for <>; Wed, 13 Sep 2017 10:57:55 -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_H3=-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 sImuI1RFyW9n for <>; Wed, 13 Sep 2017 10:57:53 -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 86A96133035 for <>; Wed, 13 Sep 2017 10:57:53 -0700 (PDT)
X-AuditID: 1209190e-b33ff700000005aa-87-59b9719f3a66
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 70.BD.01450.F9179B95; Wed, 13 Sep 2017 13:57:52 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v8DHvoN4023280; Wed, 13 Sep 2017 13:57:51 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v8DHvmEJ013392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 13:57:50 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7431D66D-CA6B-4AD1-8415-D2AF9C514EE2"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 13 Sep 2017 13:57:48 -0400
In-Reply-To: <>
To: Phil Hunt <>
References: <>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrLugcGekQc9rJosF8xvZLRp+PmB1 YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDLW7JzEWnCrsmJl70zGBsYVGV2MnBwSAiYS f88tYuxi5OIQEljMJNF/ZiM7SEJIYCOjxP5XWRD2NSaJu81FIDabgKrE9DUtTCA2r4CVRHPL YWYQm1kgSaJ7zSvWLkYOoLi+RO9zRpCwsICdxME5f8BsFqDWX7cXg5VzAsXPPD7PAtEqIDH3 0DSwkSICKhLfrl5nhFhrK/Hl7XMmiDtlJW7NvsQ8gZF/FpJtsxC2QYS1JZYtfM0MYWtK7O9e zoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBIS3Jt4Nx UoP3IUYBDkYlHt4HljsjhVgTy4orcw8xSnIwKYny7tUFCvEl5adUZiQWZ8QXleakFh9ilOBg VhLhTcwAyvGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKEryzC4AaBYtS 01Mr0jJzShDSTBycIMN5gIZbgtTwFhck5hZnpkPkTzFacnTcvPuHiWMDmNwHIoVY8vLzUqXE eQ/mAzUIgDRklObBzQSlKPd1dhavGMWBXhTmXQcylgeY3uCmvgJayAS08MzpHSALSxIRUlIN jDekJ83Tbbx3IrGMNfbv+pfGepzVFV2vRT3ee6bNT99ar3dNdO2NsIszVA/P/n6ZaY7MahnO O3ISL14d6J01/5lJ2mtBoQiNggu/FQXWNHSs4uEVWqc4t7h4rdfOKeq8k2dfUpq+YEvNkYYt e2/wKH+5PJmzcLuQ2q15Vy7z29o960o7au9/IVCJpTgj0VCLuag4EQA51qIuLAMAAA==
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 17:57:56 -0000

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