Re: [VoT] Feedback on new Draft

Justin Richer <> Wed, 09 September 2015 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E11A1B362C for <>; Wed, 9 Sep 2015 10:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hi9LJ4yZP_MO for <>; Wed, 9 Sep 2015 10:40:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FC351B35AC for <>; Wed, 9 Sep 2015 10:40:44 -0700 (PDT)
X-AuditID: 12074424-f79b46d000001e7f-14-55f06f1acde0
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 F0.E0.07807.A1F60F55; Wed, 9 Sep 2015 13:40:42 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t89HegrO029722; Wed, 9 Sep 2015 13:40:42 -0400
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t89HedbC030444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Sep 2015 13:40:41 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FBEBCB05-1D49-49CB-B9D6-5E8E078BC299"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <>
In-Reply-To: <>
Date: Wed, 9 Sep 2015 13:40:39 -0400
Message-Id: <>
References: <>
To: Joanne Knight <>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrSuV/yHUYOMVC4tVP8+wWjT8fMDq wORxZFKBx5IlP5kCmKK4bFJSczLLUov07RK4MnbMWsJYcKOXseLG5s9MDYy/q7oYOTkkBEwk Vn1fyQxhi0lcuLeerYuRi0NIYDGTxOyODiYIZwOjxIlHN1ggnAdMEiu3bWUFaWEWSJBYdvIB G4jNK6An8erWZbC4sICSRPvkt0wgNpuAqsT0NS1gNqdAoETLxelg9SwCKhKH+7ZAzVGUODft HCPEHCuJvgPfwE4SEgiQ+D5nB1hcREBX4s+y+6wQp8pK7P79iGkCo8AsJGfMQnIGRFxbYtnC 18wQtqbE/u7lLJjiGhKd3yayLmBkW8Uom5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6 iREU8uwuKjsYmw8pHWIU4GBU4uFtKHsfKsSaWFZcmXuIUZKDSUmUd3fuh1AhvqT8lMqMxOKM +KLSnNTiQ4wSHMxKIryBMUA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkO DiUJXtU8oEbBotT01Iq0zJwShDQTByfIcB6g4S4gNbzFBYm5xZnpEPlTjIpS4ryHQC4SAElk lObB9cJS0itGcaBXhHkbQdp5gOkMrvsV0GAmoMFnxd6DDC5JREhJNTCuNI4qfHBHSmhR7mTR njnnXso+sL2bEv0jwjvZwt1K+fgqwUW1Gtkn3vaLbHhX+8HMZmWxG//LzHfXWh9+kxZ8bLPl xv/bUSzPr0y10dq/qI+n+tZUvi+nYlfE/Sj7t1dZQ+Fef/LmgFnfFzKdZOK3K9Xwu87B7XFz 2mOJbTeO17ypnhDvyl+oxFKckWioxVxUnAgAGhGRyyQDAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [VoT] Feedback on new Draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2015 17:40:47 -0000

Joanne, thanks for the comments. Replies inline.

> On Sep 9, 2015, at 12:38 AM, Joanne Knight <> wrote:
> Hi Justin
> The document is looking great. I picked up some things that might be hiccups or just me needing more explanation.
> Last 2 sentences in introduction – ‘… while the vector itself can be folded into an assurance category. As such the vectors of trust seeks to complement, not replace, these other identity and trust mechanisms.’  Given the problems we are having with ISO/IEC29115 and the fact that I think this model solves many of them, I would like to see that a technology agnostic version of this does in fact replace LoA.

I agree that it might replace the way that LoA is getting used in many places, and that’s a good thing indeed. It won’t, however, replace every need for LoA, which does have use in some circumstances. 

> Federated Credential – as yet this is not used in the document. If it were I am unsure that based on the description that the credential is necessarily federated. I am thinking of a privacy centric system where the assertion is unique every instance. Colin may be able to clarify this better than I can. I am pretty sure in our product RealMe our Primary Credential is federatable but not the Assertion….but I may have  the wrong end of the stick.

The terminology does need to be better aligned, thanks for that. We’re trying to differentiate between the primary credential — what the user presents to the IdP — and the federated credential — the assertion carried across the network to the RP. 

> 2.1 Identity proofing – in 1.3 it is stated that no aspect of a component should overlap. Given the last sentence of the first para of 2.1 is from my view the correct statement, is the use of ‘..a particular credential set’ out of place? If this refers to a leveraged credential then this may need further explanation.

I think you’re right in that seems to have been subsumed by the new credential management (M) component. 

> 3 P0-P3 align nicely with thinking in ISO/IEC 29003, many thanks. The others C0-A3 have been written explicitly from the aspect of the Internet, which is understandable given the scope of this document – nicely stated up front. I am interested to see what impact lifting these up to a technology agnostic level will have on the number and description of the component descriptions. This would be a highly valuable exercise that I would dearly like to be involved in ;-)

Definitely interesting work! I think that VoT really does sit in the middle as something that’s technology-focused and sitting between higher descriptive frameworks and detailed attribute-set descriptions.

> You have nicely given me confidence that my FRAGGLE is not wingy and can be applied. Great read.
> On a totally random (or not) note, I have been playing with an idea I think someone in the VoT mailing group started. I can’t remember who it was but when I remember, I will be in touch. Anywho I replaced ‘identity’ throughout the document with ‘attribute’ and barring a few grammar issues everything still works. Makes me now question what I do for a living ;-)

The problem that I have with that is that it works best if the attributes are clearly bundled, and without that it tends to be extremely difficult to cross security domain boundaries. Basically, it’s not wrong but it can lead to the wrong extremes very quickly.

 — Justin

> Cheers
> Joanne
> From: Justin Richer [mailto:jricher@MIT.EDU] 
> Sent: Saturday, 5 September 2015 12:50 p.m.
> To:
> Subject: [VoT] New Draft
> Hi All,
> I’ve just published a new draft of VoT, incorporating many of the comments that have come in so far. The basic structure and premise is still there, but hopefully a bit clearer this time around. I’ve added the shell of an IANA registry for vector components. I’ve also added a “credential management” vector component, which is separated out from the “credential strength” component.
> The new draft is here:
> <>
>  — Justin