[VoT] Foundational questions of principle

swilson@lockstep.com.au Thu, 09 October 2014 20:18 UTC

Return-Path: <swilson@lockstep.com.au>
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 079AE1A7003 for <vot@ietfa.amsl.com>; Thu, 9 Oct 2014 13:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.401
X-Spam-Level: *
X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 tHub7UYMkZoK for <vot@ietfa.amsl.com>; Thu, 9 Oct 2014 13:18:56 -0700 (PDT)
Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6891A6EFC for <vot@ietf.org>; Thu, 9 Oct 2014 13:18:56 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BB62F18038D for <vot@ietf.org>; Thu, 9 Oct 2014 16:18:55 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app34.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A1B5F1802CE for <vot@ietf.org>; Thu, 9 Oct 2014 16:18:55 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app34.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.2.13); Thu, 09 Oct 2014 20:18:55 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app34.wa-webapps.iad3a (Postfix) with ESMTP id 9066518009F for <vot@ietf.org>; Thu, 9 Oct 2014 16:18:55 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au) with HTTP; Fri, 10 Oct 2014 07:18:55 +1100 (EST)
Date: Fri, 10 Oct 2014 07:18:55 +1100
From: swilson@lockstep.com.au
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20141010071855000000_21842"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1412885935.58929166@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_mTAbi3nEHfL7d6XrOAGjNzbBoQ
Subject: [VoT] Foundational questions of principle
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: <http://www.ietf.org/mail-archive/web/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: Thu, 09 Oct 2014 20:18:59 -0000

 
First, to introduce myself, I am an identity and privacy researcher, analyst and consultant.  I've been involved in this since 1995, when I cut my teeth in PKI and smartcards (with the early companies that became Baltimore Technologies). Since then I've worked on identity management frameworks, regulations and standards.  
 
I subscribe to the old Italian proverb: "it's nice to trust but better not to".  Words matter and I wonder if we shouldn't be using the word trust so much.  
 
More pragmatically, I note the very strong "Attributes" push of the past 18 months.  Andrew Nash, Anil John, myself and others have written about this.  The FIDO Alliance is all about authentication and attributes, and they purposefully leave "identity" as a matter for others to work out further up the stack. The OID Foundation is promoting an Attributes Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC pilot participant) talk about attributes and avoid "identity". 
 
I mention all of this as a prelude to suggest that "vector of trust" is synonymous with "attribute". I wonder if it would be clearer to use plain and current language rather than carry forward the fuzzy and I think overly ambitious idea of "trust"? 
 
Finally, I'd like to throw in my abiding concern that LOAs have foundered simply because it's difficult to pigeonhole risk. One party's idea of "medium" risk for instance will rarely map precisely to another's. I think people have been misled into thinking that an "LOA 3" identity should be be able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP. Risk management is not so simple. 
 
The LOA paradigm borrows from Risk Management standards like ISO 31000 which organisations use to plot their own risks internally typically on a five scale (eg Negligible / Low / Medium / High / Grave). But risk management standards require that each organisation calibrates risk in its own business context and according to its own risk appetite. The risk of a firewall breach for example at a startup social media company will be assessed differently by a big listed healthcare company. So organisation A can say the risk of event X is Low but B can say the risk of the same event is Medium.  As a result, LOAs do not inter-operate. They are based on standards meant for intra-organisation risk management, not inter-organisation communication of risk assessments. 
 
So far with VoT we are adding more dimensions to the RPs' generic risk management decision making, and that's great.  But we are still pigeonholing the dimensions.
 
I'm afraid the reality is that risk management will always be done locally.  And so it should be.  When an RP is making the decision to accept or reject a given subject, they will evaluate a range of attributes or signals.  The set of attributes that matters varies from one RP to the next.  I think it's a great idea indeed to create guidance for evaluating attributes, and to coach RPs to look at all sorts of dimensions.  I just don't think it helps anyone to pigeonhole the risk ratings, because across organisations, arguments about the boundaries between LOA 1/2/3/4 (that is, policy mapping) will undo any efficiencies gained from the categorization.  
 
Cheers, 
 
Steve.
 
 
Stephen Wilson
Managing Director
Lockstep Group
http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
new smart ID solutions that enhance privacy and prevent identity theft.