Re: [VoT] Feedback on new Draft

Joanne Knight <Joanne.Knight@dia.govt.nz> Wed, 09 September 2015 22:01 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 505191B48ED for <vot@ietfa.amsl.com>; Wed, 9 Sep 2015 15:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.207
X-Spam-Level:
X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=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, T_DKIM_INVALID=0.01] 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 KEwwb0o81bsx for <vot@ietfa.amsl.com>; Wed, 9 Sep 2015 15:01:04 -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 6606B1B48E8 for <vot@ietf.org>; Wed, 9 Sep 2015 15:01:03 -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=1441836061; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC; bh=1Ns7U4gdjOdK0pAk0vUEcd6yc8PVA2zAunDZ6g3GI/Q=; b=sDaCcHTjekah1TBRFSrU5lYu2fNzXmrwTQl8PRyTfRJKYVPvezEbEZ9xqL/v1WFe mhWTdr8KMf3cT6LPRN5d5vM73uxbaoxo6f/IULzBM+AT4Bu7Mo/eymQIU/5Hk4Cx sYVAeNPzKAkOs2g2EYwCsEpJsJZPkkqeWdcossJExKI=;
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 55F0AC1B-E24A087B@mta1101.omr; Wed, 09 Sep 2015 22:01:00 +0000
MIME-Version: 1.0
Message-ID: <569AD906E45DB44A8AFF11D61F5DA791014AE15DBC@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 823813785; Thu, 10 Sep 2015 10:00:57 +1200 (NZST)
Received: from WLGPRDCAS02.dia.govt.nz (Not Verified[172.29.0.70]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id <B55f0abee0001>; Thu, 10 Sep 2015 10:00:14 +1200
Received: from WLGPRDMBX02.dia.govt.nz ([fe80::d51f:14cf:8162:8a0b]) by WLGPRDCAS02.dia.govt.nz ([172.29.0.70]) with mapi id 14.03.0235.001; Thu, 10 Sep 2015 10:00:55 +1200
From: Joanne Knight <Joanne.Knight@dia.govt.nz>
To: 'Justin Richer' <jricher@mit.edu>
Thread-Topic: Feedback on new Draft
Thread-Index: AdDqs6Ih7NamluqxQNiuu+LHfQxsIQADmzeAAB+ovzA=
Date: Wed, 9 Sep 2015 22:00:13 +0000
References: <569AD906E45DB44A8AFF11D61F5DA791014AE15D02@WLGPRDMBX02.dia.govt.nz> <2AAA27A5-1522-4490-A87C-75583E0491AD@mit.edu>
In-Reply-To: <2AAA27A5-1522-4490-A87C-75583E0491AD@mit.edu>
Accept-Language: en-NZ, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailadviser: Confirmation provided by user
x-originating-ip: [172.29.0.162]
Content-Type: multipart/mixed; boundary="_005_569AD906E45DB44A8AFF11D61F5DA791014AE15DBCWLGPRDMBX02di_"
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/qN63hMNsMk__mh3VGXgzP3Z5myw>
Cc: "vot@ietf.org" <vot@ietf.org>
Subject: Re: [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 22:01:08 -0000

Some added comments, in line

From: Justin Richer [mailto:jricher@mit.edu]
Sent: Thursday, 10 September 2015 5:41 a.m.
To: Joanne Knight
Cc: vot@ietf.org
Subject: Re: Feedback on new Draft

Joanne, thanks for the comments. Replies inline.

On Sep 9, 2015, at 12:38 AM, Joanne Knight <Joanne.Knight@dia.govt.nz<mailto:Joanne.Knight@dia.govt.nz>> 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.

Could we word it so that it allows replacement rather than excluding it, as it does now.


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.

Yes we definitely need to separate the two. The fact that the term is not used means it has already been described elsewhere in the document as something different. In 2.4 the words ‘Assertion presentation’ and ‘digital identity’ are used.
I toyed with ‘Attribute credential’ but I think the key is the assertion and so ‘Attribute assertion’ or ‘Attribute presentation’ which you used is better. This moves away from any connotation that the ‘thing’ asserted is always the same.

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.

I use the attached diagram (Attributes) a lot. If we are working with the definition of identity being – the minimum set of attributes the uniquely separate one entity from another in a context, and a privacy centric stance where we only collect what we need, then all identity attributes collected also have a secondary purpose.
Identity becomes the just the cognisant understanding that there is a predetermined selection of attributes, otherwise required for the delivery of a service to a customer, that when combined provide a unique reference (ideally without the assigned administrative reference).
Persistent identity – the use of an identical attribute set (or bundle) across contexts is only needed when an RP has to get or verify authoritative attributes from multiple sources. Once RPs are able to access more Ubber Attribute Providers (Intermediaries that federate attributes) their reliance on persistent identity reduces. The Ubber AP is the only one who may need persistent identity). I have attached a table and flow that show this that I have found helpful in dampening the extremes issue. In saying that, for most of the people I am educating that is extreme. Probably preaching to the converted ;-)

Loving your work

Jo

 — Justin




Cheers

Joanne

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