Re: [VoT] Foundational questions of principle

Ken Dagg <kendaggtbs@gmail.com> Fri, 10 October 2014 01:41 UTC

Return-Path: <kendaggtbs@gmail.com>
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 F414B1AD051 for <vot@ietfa.amsl.com>; Thu, 9 Oct 2014 18:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_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 GJ6scC7cqwMl for <vot@ietfa.amsl.com>; Thu, 9 Oct 2014 18:41:49 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8286F1AD048 for <vot@ietf.org>; Thu, 9 Oct 2014 18:41:49 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id id10so1926724vcb.6 for <vot@ietf.org>; Thu, 09 Oct 2014 18:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vAoCcB6FvtiLx0cyHiUekfrGlJJwUAv/eFVNT63uAiw=; b=MD7JbfkFumFRe89pnTrkmmuYE3Y2euRqEKYIq9LpkHR2+/+QOYhrHNCXC2h8F7gfoY fZJTALFwH8T+lYch5GobV5ZkBkZ7cljyj8J0cwHqqf+KwD1kHPyZTGxUviDH6yBTq6ZZ NmCpm9cnmoT/VUmaEqrBRm6ROARJVdKYsihp7/pKf3ijrfFuEVpubo0rNj3Za88RsW4L rV7bwWkMGNMpnk1WR19JJZEuzhezuyj25wuR5xojqgzu132/KZXps3WGYvuCgNVupqdA We3C4SKlpqyCZ9kfQw2RCuLjns9FAnGSEu9fK8lTaIOs5otYkNAFNwJ7NEfrGCmpxEmJ dAvA==
MIME-Version: 1.0
X-Received: by 10.220.185.72 with SMTP id cn8mr1976372vcb.26.1412905308715; Thu, 09 Oct 2014 18:41:48 -0700 (PDT)
Received: by 10.220.88.199 with HTTP; Thu, 9 Oct 2014 18:41:48 -0700 (PDT)
In-Reply-To: <1412885935.58929166@apps.rackspace.com>
References: <1412885935.58929166@apps.rackspace.com>
Date: Thu, 09 Oct 2014 21:41:48 -0400
Message-ID: <CAKSgTGTjdeC=54RAUZUbQKCDfQ2COJC9DZ9+jNyCdDsnLy5XDQ@mail.gmail.com>
From: Ken Dagg <kendaggtbs@gmail.com>
To: "swilson@lockstep.com.au" <swilson@lockstep.com.au>
Content-Type: multipart/alternative; boundary="001a11c2c44a070a6d050507a7d3"
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_M9xOFpnJZqsn3nx9OoMxFdds4U
Cc: "vot@ietf.org" <vot@ietf.org>
Subject: Re: [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: Fri, 10 Oct 2014 01:41:52 -0000

Steve,

As we have communicated in the past, I am a strong believer the an LOA
designation is an indication of the processes/mechanisms that an IdP has
undertaken. In other words, it is a communication tool. The choice is the
RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of the
mechanisms a RP should use to offset the authentication risk it has
identified for the service it wants to deliver. In other words, it is the
risk of the RP that is paramount not the claims of
an identity/credential/attribute/token provider.

Like you, I am a strong believer that the determination of whether or not
an identity is good enough is the responsibility of the RP. In my
experience, they make that determination based upon a set of attributes
they believe are necessary. If they trust that an IdP's assertion of
identity covers the attributes they believe are required them they can
accept the assertion. If it doesn't then that have to implement additional
mechanisms to offset the residual risk.

With respect to vectors of trust, I am interested in exploring what they
are and how they can be applied.

Ken

On Thursday, October 9, 2014, <swilson@lockstep.com.au> wrote:

>
>
> 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.
>
>
>
>
>
>
>