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

Eric Goodman <Eric.Goodman@ucop.edu> Thu, 10 March 2016 19:27 UTC

Return-Path: <Eric.Goodman@ucop.edu>
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 D34B712DC02 for <vot@ietfa.amsl.com>; Thu, 10 Mar 2016 11:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 FfqOcf1Dfner for <vot@ietfa.amsl.com>; Thu, 10 Mar 2016 11:27:41 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0057.outbound.protection.outlook.com [65.55.169.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9914E12DBFD for <vot@ietf.org>; Thu, 10 Mar 2016 11:27:41 -0800 (PST)
Received: from BN3PR0601MB1956.namprd06.prod.outlook.com (10.165.119.146) by BN3PR0601MB1955.namprd06.prod.outlook.com (10.165.119.145) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 10 Mar 2016 19:27:39 +0000
Received: from BN3PR0601MB1956.namprd06.prod.outlook.com ([10.165.119.146]) by BN3PR0601MB1956.namprd06.prod.outlook.com ([10.165.119.146]) with mapi id 15.01.0434.016; Thu, 10 Mar 2016 19:27:39 +0000
From: Eric Goodman <Eric.Goodman@ucop.edu>
To: "vot@ietf.org" <vot@ietf.org>
Thread-Topic: [VoT] How to express duplicate checks with VoT?
Thread-Index: AQHRev7BCw/Ruv/PkE24C055dh5VIJ9TDuLQ
Date: Thu, 10 Mar 2016 19:27:39 +0000
Message-ID: <BN3PR0601MB195623087B6C3142F341E059FBB40@BN3PR0601MB1956.namprd06.prod.outlook.com>
References: <56E1A5F8.3090201@switch.ch> <D8C2F321-13E0-4705-903A-79656151F468@mit.edu>
In-Reply-To: <D8C2F321-13E0-4705-903A-79656151F468@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ucop.edu;
x-originating-ip: [128.48.44.96]
x-ms-office365-filtering-correlation-id: c1dd3b52-3b9b-4a14-00e5-08d3491a0b4e
x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1955; 5:HlcyWV8cNY9cYc2epmOAjAH4o7g22Hx/FvzUaFZiGImQnH/ddwOagNba0YyaAWw8aDSRq+4ewaX3dQ2Whakn/LxnLYbgyQ6GksJL9DxEbMiyKO5q7x65BABHcbHKdFcVn0GtEzSE0eNVOY0IFT7Mkw==; 24:I5rhkXFmUu51BwXG52fMNsCiFPo9XOJ6cP4+fpe2yz00MH932B1WG0rlnmjxTyxjts2bgK2PjwzfdM48PMiggYJj9pOjiosfXsM4Ai5L/Lc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1955;
x-microsoft-antispam-prvs: <BN3PR0601MB1955ACEDD01BACB4ADA064F2FBB40@BN3PR0601MB1955.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0601MB1955; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1955;
x-forefront-prvs: 08770259B4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(24454002)(13464003)(377454003)(5004730100002)(50986999)(3280700002)(89122001)(2351001)(110136002)(107886002)(87936001)(450100001)(189998001)(2906002)(74316001)(1096002)(1220700001)(3660700001)(76576001)(86362001)(2501003)(33656002)(81166005)(122556002)(5640700001)(66066001)(5002640100001)(6116002)(54356999)(1730700002)(102836003)(3846002)(586003)(90282001)(76176999)(2900100001)(106116001)(77096005)(5003600100002)(75432002)(10400500002)(5008740100001)(92566002)(19580395003)(2950100001)(15975445007)(11100500001)(19580405001)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1955; H:BN3PR0601MB1956.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ucop.edu
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2016 19:27:39.5604 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6737ae8b-7f79-4cda-90a2-1861f16fa830
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1955
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/jc2gk1wLiN79SMxowz9oTKysOls>
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, 10 Mar 2016 19:27:44 -0000

This seems like it would be really hard to specify, unless you scope it pretty clearly.

"Proofed unique among accounts with identity vetting level (moderate or higher)" seems like it might be achievable (and maybe is what you have in mind). "Proofed unique" literally seems nearly impossible. How would you prove someone didn't get a low-value account on the same IdP? 

The challenge to me would be defining the scope in a way that is understandable and agreeable.

--- Eric

-----Original Message-----
From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 10, 2016 10:58 AM
To: Rolf Brugger
Cc: vot@ietf.org
Subject: Re: [VoT] How to express duplicate checks with VoT?

This would probably be another category/dimension, I think. Unless you wanted to wrap it into your own definitions of the “P” dimension, where there’d be a “Pu” for “proofed unique” that could be added to that category. 

 — Justin

> On Mar 10, 2016, at 11:51 AM, Rolf Brugger <rolf.brugger@switch.ch> wrote:
> 
> 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

_______________________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/listinfo/vot