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

Rolf Brugger <> Thu, 17 March 2016 10:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D7F312D711 for <>; Thu, 17 Mar 2016 03:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hDgemcG1qkt2 for <>; Thu, 17 Mar 2016 03:34:50 -0700 (PDT)
Received: from ( [IPv6:2001:620:0:1002::27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14D1112D636 for <>; Thu, 17 Mar 2016 03:34:49 -0700 (PDT)
Received: from ( [IPv6:2001:620:0:1001::69]) by (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 <>; Thu, 17 Mar 2016 11:34:47 +0100
Received: from ([2001:620:0:44:426c:8fff:fe37:cd48]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) id 1agVGP-0007Yf-U4 for; Thu, 17 Mar 2016 11:34:45 +0100
References: <> <>
From: Rolf Brugger <>
Message-ID: <>
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: <>
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;,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: <>
Subject: Re: [VoT] How to express duplicate checks with VoT?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Vectors of Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



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
> [] Sent: Friday, 11 March 2016 5:51
> a.m. To: 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,
> _______________________________________________ vot mailing list

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,