[VoT] Feedback on new Draft

Joanne Knight <Joanne.Knight@dia.govt.nz> Wed, 09 September 2015 04:39 UTC

Return-Path: <Joanne.Knight@dia.govt.nz>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654E71B34D9 for <vot@ietfa.amsl.com>; Tue, 8 Sep 2015 21:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.582
X-Spam-Level:
X-Spam-Status: No, score=0.582 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HELO_EQ_BIZ=0.288, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXtCiVAEXiRp for <vot@ietfa.amsl.com>; Tue, 8 Sep 2015 21:39:37 -0700 (PDT)
Received: from mx1.securemx.biz (mx1.securemx.biz [203.84.134.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F21E1B3320 for <vot@ietf.org>; Tue, 8 Sep 2015 21:39:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=nz.smxemail.com; s=alpha; c=relaxed/relaxed; q=dns/txt; i=@nz.smxemail.com; t=1441773575; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc; bh=NFXTWyT7/vdf+z7Aj4sV4747kTfCHojr9qCWZGhgmv8=; b=yG28l358UuHQeiovzRNeXqjJiWIh7MojuKH3SsjM5xvEdm7Sg4yoFa+7a82hAXsb a6RIQBhGF5t0YkreOzeU0YPLUa6JbFtFLRbv0ZHbCEmk3tWfgp0ecseK9mW2JvwK jevbe7KxaBYHzQ9vArGkScZ6w4uynAfHEeCksKRsxKw=;
Received: from s111-0006-lnv01 ([131.203.48.73]) by omr.nz.smxemail.com with ESMTP (using TLSv1 with cipher AES256-SHA (256/256 bits)) id 55EFB806-DDF31641@mta1102.omr; Wed, 09 Sep 2015 04:39:35 +0000
MIME-Version: 1.0
Message-ID: <569AD906E45DB44A8AFF11D61F5DA791014AE15D02@WLGPRDMBX02.dia.govt.nz>
X-MessageIsInfected: false
Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([161.65.142.21]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 1934838579; Wed, 09 Sep 2015 16:39:32 +1200 (NZST)
Received: from WLGPRDCAS01.dia.govt.nz (Not Verified[172.29.0.93]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id <B55efb7db0001>; Wed, 09 Sep 2015 16:38:51 +1200
Received: from WLGPRDMBX02.dia.govt.nz ([fe80::d51f:14cf:8162:8a0b]) by WLGPRDCAS01.dia.govt.nz ([172.29.0.93]) with mapi id 14.03.0235.001; Wed, 9 Sep 2015 16:39:31 +1200
From: Joanne Knight <Joanne.Knight@dia.govt.nz>
To: 'Justin Richer' <jricher@MIT.EDU>, "vot@ietf.org" <vot@ietf.org>
Thread-Topic: Feedback on new Draft
Thread-Index: AdDqs6Ih7NamluqxQNiuu+LHfQxsIQ==
Date: Wed, 9 Sep 2015 04:38:50 +0000
Accept-Language: en-NZ, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailadviser: Confirmation not required
x-originating-ip: [172.29.0.162]
Content-Type: multipart/alternative; boundary="_000_569AD906E45DB44A8AFF11D61F5DA791014AE15D02WLGPRDMBX02di_"
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/VawWUjWOadGHhzxSMFvUiX4_aUE>
Subject: [VoT] Feedback on new Draft
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2015 04:39:40 -0000

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.

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.

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.

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 ;-)

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 ;-)

Cheers

Joanne

From: Justin Richer [mailto:jricher@MIT.EDU]
Sent: Saturday, 5 September 2015 12:50 p.m.
To: vot@ietf.org
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:

https://tools.ietf.org/html/draft-richer-vectors-of-trust-01

 — Justin