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

Joanne Knight <Joanne.Knight@dia.govt.nz> Thu, 17 March 2016 21:49 UTC

Return-Path: <Joanne.Knight@dia.govt.nz>
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 E896712DAAB for <vot@ietfa.amsl.com>; Thu, 17 Mar 2016 14:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nz.smxemail.com
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 ePvZKiCW24G2 for <vot@ietfa.amsl.com>; Thu, 17 Mar 2016 14:49:28 -0700 (PDT)
Received: from out1102.nz.smxemail.com (out1102.nz.smxemail.com [203.84.134.33]) (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 C6D8812DCB0 for <vot@ietf.org>; Thu, 17 Mar 2016 14:49:27 -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=1458251365; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc; bh=i4gU4oMpgmANoxZklCWPgoBgHBIHnBmEx3GSwgwfn4M=; b=cQHfiem7rU+ulOrGNckfZby5Q4Qh8YtDbpae9OWqQyyXD13lLTxxRj81JYk5GZ3N wuFOwpd0xZjAEXdLXrWtn1+1llM3pbC1/R3VOioe3d+CbOCvsJlQlYYV+uKU6aQT swVBd5Vglza0MP+HGrfsA9ptbyLXCtPi7o8vynpQFg8=;
Received: from smtp.dia.govt.nz ([131.203.48.73]) by omr.nz.smxemail.com with ESMTP (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) id 56EB2664-E8A7229D@mta1103.omr; Thu, 17 Mar 2016 21:49:25 +0000
Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([161.65.142.21]) by s111-0006-lnv01 (Liverton Technology Group - SmartGate) with ESMTP ID 1526770832; Fri, 18 Mar 2016 10:49:22 +1300 (NZDT)
Received: from AklDrCas02.dia.govt.nz (Not Verified[10.104.240.112]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id <B56eb26620000>; Fri, 18 Mar 2016 10:49:22 +1300
Received: from AKLDRMBX03.dia.govt.nz ([fe80::d1c1:15a7:3e85:ac71]) by AklDrCas02.dia.govt.nz ([::1]) with mapi id 14.03.0279.002; Fri, 18 Mar 2016 10:49:21 +1300
From: Joanne Knight <Joanne.Knight@dia.govt.nz>
To: 'Rolf Brugger' <rolf.brugger@switch.ch>, "vot@ietf.org" <vot@ietf.org>
Thread-Topic: [VoT] How to express duplicate checks with VoT?
Thread-Index: AQHRewefr30T8sn2a0aikcEmelKPBJ9eF5ww
Date: Thu, 17 Mar 2016 21:49:20 +0000
Message-ID: <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz>
References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch>
In-Reply-To: <56EA8845.3040503@switch.ch>
Accept-Language: en-NZ, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailadviser: Confirmation not required
x-originating-ip: [10.220.229.74]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/evXwLVJ0CUffyFpeXRyqiCie8So>
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 21:49:31 -0000

The short answer to your question - No.

Your use case is silent on the level of vetting required (how real does the identity have to be). You can have any level of identity and still collect a biometric for the purposes of one and only one uniqueness. I would pose however that it is very unusual for one and only one assurance to be required without some other driver requiring an elevated level of realness. 

In your use case I would suggest that there is also a requirement that a qualification is issued to 
a) the person carrying out the study and 
b) an identity of such rigour that their (or the university's) eligibility for public funding can be established and 
c) an identity that is going to be tested by future employers.

Therefore you are probably looking at P2 or P3 depending on the level/type of qualification. (I might want P3 if the qualification is for brain surgeon or commercial pilot).

As one and only one is really only able to be achieved through the use of a biometric, we now have to consider 'acceptability'.
Does the collection of a biometric (and all that it entails - cost, privacy, security, user acceptance etc.) outweigh the impact caused by a duplicate entity in the system?
In other words, do you really need one and only one (the 3rd level of uniqueness) or could sufficient singularity be gained from leveraging the social security number's uniqueness and an equivalent level of validation and ownership test (the 2nd level of uniqueness) i.e. no Pu?

We must remember the mutual exclusivity between attributes collected, vetting under taken and level of uniqueness. 

Happy to discuss further if this makes no sense.

Cheers



-----Original Message-----
From: Rolf Brugger [mailto:rolf.brugger@switch.ch] 
Sent: Thursday, 17 March 2016 11:35 p.m.
To: vot@ietf.org
Subject: Re: [VoT] How to express duplicate checks with VoT?

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