Re: [VoT] IPR disclosures

Justin Richer <> Sun, 26 November 2017 05:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB2F1127286 for <>; Sat, 25 Nov 2017 21:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.211
X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5xncI8996S8i for <>; Sat, 25 Nov 2017 21:00:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05C21124BAC for <>; Sat, 25 Nov 2017 21:00:52 -0800 (PST)
X-AuditID: 12074423-f87ff700000070d6-6d-5a1a4a804984
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 BC.2D.28886.18A4A1A5; Sun, 26 Nov 2017 00:00:49 -0500 (EST)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id vAQ50kJN005227; Sun, 26 Nov 2017 00:00:47 -0500
Received: from [IPv6:2607:fb90:e9c:e015:478:95ac:e651:54ac] ([]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id vAQ50hwC031992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Nov 2017 00:00:44 -0500
Message-Id: <>
Date: Sun, 26 Nov 2017 00:00:41 -0500
Importance: normal
From: Justin Richer <>
To: Chris Drake <>, Phil Hunt <>
Cc: John Bradley <>, "Paul A. Grassi" <>, Leif Johansson <>, "" <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFKsWRmVeSWpSXmKPExsUixCmqrNvoJRVlsOK8hcX5GVcZLRb0bmW2 WN4vZ7FgfiO7xeq7f9ksGn4+YHVg8+j9fIPNY8mSn0we107+ZfX4+PQWi8feTX3sHrdvb2QJ YIvisklJzcksSy3St0vgytj97DpzwbVvTBXre1ezNDB+eMPUxcjJISFgInH0/GfmLkYuDiGB xUwSp79NZYJwNjJKLFw2lR3COckkseXdIbAWXgEric0z3zCD2MIC8hItfSfAbBYBVYn5j/+y QMSVJB5OB1nBwcEpICTRtUsCJMwGVDJ9TQvYGBGBKIkZM26DlTMLzGKUOPa6GmK8oMTJmU+g 4rESU3+tZZvAyDcLSWoWkhSErS7xZ94lZghbUWJK90P2WUCbmQXUJJa1KiELL2BkW8Uom5Jb pZubmJlTnJqsW5ycmJeXWqRrppebWaKXmlK6iREUEewuyjsYX/Z5H2IU4GBU4uHdcUQySog1 say4MvcQoyQHk5Iob0e/eJQQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV4uEakoId6UxMqq1KJ8 mJQ0B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCV57T6BGwaLU9NSKtMycEoQ0EwcnyHAe oOE6IDW8xQWJucWZ6RD5U4zZHBtu3v3DxLEPTK47fQ9Itm27DyQ3fH8AJJ9cm/eXiePZzNcN zBzzjn9rYhZiycvPS5US513hATROAGRcRmke3EYlISEBNfbfE/jmPBBlqZi65llgyBpQEl1j IebyilEcGCjCvGtBDuEBJmC4O14BncgEdOLTk+IgJ5YkIqSkGhj5q9Y5ufzh+7rGy3pZ7oO2 fdqat91flp7k6dletOZlgM39XWV7Ltw7tON2yXNds8MKbvfnPrWKqKhp3tDX3XDsZfuF3sY3 oR38E+VX8me9Ewp8euzObEmO7kfPWwvX3nxUcbMsNOzeh4XJh/sq5D0LszovLFrvl90wc4vC v3hxvf+ru0wnpWxRYinOSDTUYi4qTgQAXe/jEn0DAAA=
Archived-At: <>
Subject: Re: [VoT] IPR disclosures
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: Sun, 26 Nov 2017 05:00:57 -0000

It's no mistake that both NIST and VoT have moved toward this model. VoT started as a conversation that Paul Grassi and I had years ago about how to improve on LoA, and at that same meeting Leif and others joined the conversation and we set down the roots of what would become VoT, including the chartering of this very mailing list. 
Furthermore, I'm a co author on the newest version of the NIST document in question, and my involvement in the rewrite was in part to develop this model further. They're commentary and in fact we are currently working on an additional volume that explicitly maps the NIST xAL model into the VoT expression syntax. You can see this work on NIST's public GitHub:
So to answer if VoT gives anything that xAL doesn't is pretty simple: VoT provides a syntax for communicating the xAL (and potentially other information) across the network between parties. The xAL definitions provide detailed guidance to how to reach each level in each category, VoT says how to send that info in an ID Token. 
I'm curious what you have in mind for pii as eliminating liability, but I have a feeling it's a bit more ocean boiling than we're after here. 
 Sent from my phone
-------- Original message --------From: Chris Drake <> Date: 11/25/17  11:17 PM  (GMT-05:00) To: Justin Richer <>du>, Phil Hunt <> Cc: John Bradley <>om>, "Paul A. Grassi" <>ov>, Leif Johansson <>se>, Subject: Re: [VoT] IPR disclosures 

Hi All,

NIST got rid of LoA for a reason - it seems disingenuous to express VoT in terms of something that's already been obsoleted - particularly the whistle-blower example, since that's exactly why NIST got rid of LoA in the 1st place.

If VoT brings anything that IAL/AAL/FAL does not, this needs to be spelled out.  If it does not bring anything, then it needs to be improved so it does - there's no need us building a VoT paring knife when everyone's already got the NIST paring knife .

In practical applications, I think NIST and VoT both have not properly considered commercial adoption risks - if improved addressing of PII protection and eradication of liability risks was incorporated, then VoT could be a standard that beats all others simply because it's commercially irresponsible to pick anything else.  This is radical innovation though, not mere improvement.

Kind Regards,

Chris Drake

Sunday, November 26, 2017, 1:01:58 PM, Justin Richer wrote:

From a technical standpoint, this is done by configuration. I get a vector and a trustmark URL. As an RP, I can look at the trustmark URL and do a simple string comparison against a list of trustmark URLs that I’ve been configured to trust — much the same way that RPs that talk to multiple IdPs do so today with issuer URLs (in both OIDC and SAML worlds). You’re absolutely right that deciding what goes on that list is a business decision, and more philosophical than technical. However, as a technical spec, VoT seeks to solve the technical problem of how to convey the information of what the IdP thinks about the current user and the current transaction. It does not seek to solve the question of how the RP determines if the IdP is allowed to make those claims or not, but instead gives the IdP a means of making these claims (a means that doesn’t exist otherwise). It’s not the end-goal that you are seeking, but it’s a major step forward. 

Per John’s request, here’s the introduction text that I’ve been working on this week as the draft goes forward:

Methods for measuring trust in digital identity transactions have historically fallen into two main categories: either all measurements are combined into a single scalar value, or trust decisions are calculated locally based on a highly detailed set  of attribute metadata. This document defines a method of conveying trust information that is more expressive than a single value but less complex than comprehensive attribute metadata. 

Prior to the third edition published in 2017, NIST Special Publication 800-63 used a single scalar measurement of trust called a Level of Assurance (LoA). An LoA can be used to compare different transactions within a system at a coarse level. For instance, an LoA4 transaction is generally considered more trusted (across all measured categories) than an LoA2 transaction. The LoA for a given transaction is computed by the identity provider (IdP) and is consumed by a relying party (RP). Since the trust measurement is a simple numeric value, it’s trivial for RPs to process and compare. However, since each LoA encompasses many different aspects of a transaction, it can’t express many real-world situations. For instance, an anonymous user account might have a very strong credential, such as would be common of a whistle-blower or political dissident. Despite the strong credential, the lack of identity proofing would make any transactions conducted by the account to fall into a low LoA. Furthermore, different use cases and domains require subtly different definitions for their LoA categories, and one group’s LoA2 is not equivalent or even comparable to another group’s LoA2. 

Attribute based access control (ABAC) systems used by RPs may need to know details about a user’s attributes, such as how recently the identity data was verified and by whom. Attribute metadata systems are capable of expressing a large and detailed amount of detail about the transaction. However, this approach requires the IdP to collect, store, and transmit all of this attribute data for the RP’s consumption. The RP must process this data, which may be prohibitive even for the most trivial security decisions. 

Vectors of Trust (VoT) seeks a balance between these two alternatives by allowing expression of multiple aspects of an identity transaction (including but not limited to identity proofing, credential strength, credential management, and assertion strength), without requiring full attribute metadata descriptions. This method of measurement gives more actionable data and expressiveness than an LoA, but is still relatively easy to process and calculate by the RP. It is anticipated that VoT can be used alongside more detailed attribute metadata systems. The RP can use the vector value for most basic decisions but be able to query the IdP for additional attribute metadata where needed. Furthermore, it is anticipated that some trust frameworks will provide a simple mapping between certain sets of vector values to LoAs, for RPs that do not have a need for the vector’s higher level of detail.

This document defines a data model for these vectors and an on-the-wire format for conveying them between parties, anchored in a trust definition. Additionally, this document defines a general-purpose component values and a mechanism for defining custom vector components which can be used by systems that need something more specific. 

Happy to hear feedback about the new intro and if it situates this work better. I still believe that you (Phil) want a different solution to a different problem than what VoT solves. Namely, I think you want the attribute metadata solution which would augment VoT, as described above. That’s great, and I look forward to seeing progress in that area as well. However, VoT shouldn’t be held up from solving the 90% use case that Paul mentions because the other 10% is going to take a lot more work. You want a surgical scalpel. We just need a good, sharp paring knife. Right now, everyone’s using a pointy stick and hoping for the best. VoT was never meant to solve what you’re asking it to solve, nor do I believe it should try to do so. Let other good work do that, and let this solve what it’s meant for. 

— Justin

On Nov 24, 2017, at 12:52 AM, Phil Hunt <> wrote:

What you described to me before required an RP to set up policy manually based on the reputation of the asserting party (eg its main business) in order to divine the meaning of its identity proofing. 

If that is the case, VoT as a standard does not improve interop, it causes more confusion because the spec does not define how a system may interpret the value other than in a philosophical sense. "Is John really John?" just isn't useful if it isn't the right John.


On Nov 23, 2017, at 7:27 PM, Grassi, Paul A. (Fed) <> wrote:

Fine. But as I have said you want a unicorn when we just want a car that can drive in the same Lane as SAML. Your unicorn is coming, as the phases of igov include international agreement on vot vectors/values and attribute metadata to assert 'assurance' of attributes that are unrelated to proofing.  

I happy for your contribution don't take unicorn comment poorly. Just a quick post turkey dinner way of making a point. Happy US Thanksgiving. 

Sent from my iPhone

On Nov 23, 2017, at 5:25 PM, Phil Hunt <> wrote:

The issue i am concerned about then is that by leaving out the issue of claims than the vot is incomplete and would require a separate statement. 

This leads to a lot of interop and complexity problems down the road.  Which value wins etc given they would overlap. 

The vot does not have to address it now but it should have the capability to do so (that may not be possible without a model). 

This is a lot like when we found loa was actually multi dimensional and it had to dramatically change.  IAL falls into the same problem. 


On Nov 23, 2017, at 2:08 PM, Leif Johansson <> wrote:

On 2017-11-23 21:23, John Bradley wrote:


As part of the write-up for the Vectors of trust document, we need an

IPR disclosure from all of you.

Are you aware of any IPR related to the following VOT document?

Please reply to the list.  


John B. 

I am not.


vot mailing list


vot mailing list


vot mailing list