Re: [VoT] How to express duplicate checks with VoT?

Rolf Brugger <rolf.brugger@switch.ch> Thu, 17 March 2016 10:34 UTC

Return-Path: <rolf.brugger@switch.ch>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7F312D711 for <vot@ietfa.amsl.com>; Thu, 17 Mar 2016 03:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hDgemcG1qkt2 for <vot@ietfa.amsl.com>; Thu, 17 Mar 2016 03:34:50 -0700 (PDT)
Received: from iberico.switch.ch (iberico.switch.ch [IPv6:2001:620:0:1002::27]) (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 14D1112D636 for <vot@ietf.org>; Thu, 17 Mar 2016 03:34:49 -0700 (PDT)
Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by iberico.switch.ch (8.14.4/8.14.4/Debian-4) with ESMTP id u2HAYkXo014970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <vot@ietf.org>; Thu, 17 Mar 2016 11:34:47 +0100
Received: from macrb.switch.ch ([2001:620:0:44:426c:8fff:fe37:cd48]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <rolf.brugger@switch.ch>) id 1agVGP-0007Yf-U4 for vot@ietf.org; Thu, 17 Mar 2016 11:34:45 +0100
To: vot@ietf.org
References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz>
From: Rolf Brugger <rolf.brugger@switch.ch>
Message-ID: <56EA8845.3040503@switch.ch>
Date: Thu, 17 Mar 2016 11:34:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6
X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default)
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/ECer1u3zFA1hIQkRsGKEBxPDM_k>
Subject: Re: [VoT] How to express duplicate checks with VoT?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 17 Mar 2016 10:34:54 -0000

Hi all,

Thanks for all your responses and ideas. We have discussed your inputs 
in our project team (which is why it took me some time to respond)

I was wondering what actually the differences are between the three 
levels of uniqueness described by Joanne. In each of the three levels a 
set of attributes is used to determine if an identity is unique within a 
population of identities. The difference is 1) what exact set of 
attributes is used in each level and 2) the vetting level of the 
attributes. Right?

A concrete example might be

First level:
- attributes: Name, email, phone number
- vetting level: P1

Second level:
- attributes: Name, email, phone number, social security number
- vetting level: P2

Third level:
- attributes: finger print or retina scan
- vetting level: P3

The appropriate set of attributes to be used in each level is certainly 
context-specific. As Eric points out it will be difficult to define and 
agree on a generic definition of the scope.

Maybe it's time to describe our use cases here. In the IdM service we 
are planning individuals self-register their identities. With such an 
identity, individuals can register for studies at a university. But one 
individual may only register once at the same university. Another case 
is a user's library account that was blocked because of violations of 
the library's usage terms. Such a user should not be able to just create 
a new account to use the library services again.

With Justin's suggestion of a Pu category, the requirements in our use 
cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" 
would then be: Proofed unique based on an attribute set with the vetting 
level P2.

cheers

Rolf



On 11.03.16 02:56, Joanne Knight wrote:
> Hi All
>
> There are three aspect or levels when looking at uniqueness to be
> considered.
>
> First level is that the identity is unique - that is, within a
> context there is a set of attributes that are unique for each
> identity registered.
>
> Second level is sole claimant - this is a check that only one entity
> has claimed a particular set of attributes. At the higher levels of
> identity proofing where authoritative sources are used it may be
> possible to achieve this. This is sufficient in most RPs cases. At
> this level while it is possible for a single entity to claim more
> than one identity, they do so at the risk of causing a counter-fraud
> flag should the real owner (or any other party) also attempt to claim
> the identity.
>
> The final level is one and only one - This is a check - usually
> biometric - that an entity has only one claim in the context. This is
> usually only reserved for the highest level of identity and would
> also require equally high levels of credential and credential
> issuance processes.
>
> As to how this relates to VoT - The first should be innately built
> into all levels of P - it is the sole requirement of all levels
>
> The second could be built into P3 if the wording was amended
> slightly.
>
> The last item only is substantively missing and to date (in the
> conversations I have been having elsewhere) there has been
> insufficient appetite to add it as an explicit requirement.
>
> Should we have a PU? Maybe, but steer clear of the term 'unique' If
> we do, in my mind it would only have two values - P?0 - Claims per
> entity not checked, P?1 - Claims per entity restricted to one.
>
> Joanne
>
>
> -----Original Message----- From: Rolf Brugger
> [mailto:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:51
> a.m. To: vot@ietf.org Subject: [VoT] How to express duplicate checks
> with VoT?
>
> Hi all,
>
> I'm new to this list and I hope my question is not totally irrelevant
> here.
>
> We have plenty of use cases where RPs need to have confidence, that a
> person does not have multiple identities in one IdP. I don't see how
> this aspect of identity quality can be expressed, and I believe it is
> pretty orthogonal to the P, C, M and A dimensions that are currently
> specified in the VoT draft.
>
> We could imagine multiple ways to gradually prove that an identity
> has been checked against duplicates. The most straightforward
> approach would be to make sure that unique personal attributes are
> used only once within one IdP or an IdP federation, like - email
> address(es) - mobile phone number - home postal address - social
> security number - ID / passport number - the combination of name and
> birth date - etc.
>
> Would it make sense to express this in VoT?
>
> best regards
>
> Rolf
>
>
> -- SWITCH -------------------------- Rolf Brugger, project Swiss
> edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44
> 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch,
> http://www.switch.ch
>
>
> _______________________________________________ vot mailing list
> vot@ietf.org https://www.ietf.org/mailman/listinfo/vot
>

-- 
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 15 89
rolf.brugger@switch.ch, http://www.switch.ch