Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

"Gould, James" <jgould@verisign.com> Tue, 18 December 2018 21:20 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA95D1292F1 for <regext@ietfa.amsl.com>; Tue, 18 Dec 2018 13:20:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.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 GWH4SN3EPDcG for <regext@ietfa.amsl.com>; Tue, 18 Dec 2018 13:20:37 -0800 (PST)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 E60EB130F29 for <regext@ietf.org>; Tue, 18 Dec 2018 13:20:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8034; q=dns/txt; s=VRSN; t=1545168037; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=MBwjxDEykC0p6AoTTfUF7yWoD7tpOgi3QDR/vRqXvwg=; b=KH7fPGOrXUtzvVFBBbnAyrn/BVegIfIpI08nFPWYANsnTBy0t4xmZBIX yrWBg0u1/j8PZWNDXK0lmehvsJ+aC8jWMjBCwE5zAw/JRUuWe6JnuqWpE Ci6MI6MUFeLIcnKMbtPalleRBaBD1sl79wox7t/hZ+QkcdbAt7WNoep5D EarpUAFNUSu/Ua8RcfHY0dvIzoxvikjJ08m+jE3P8YPZmCz40nM/qh1cz Jr/e8iShTcKtdJxspaE+iNL8xiC0cyhItGy1AobBIDgeWX6dzdbFVJFsj eV/u6PFxy3w6kgxEVIbd8B8lmMPgIeTPArErh39hwuzMSn74/lQl9c9ha g==;
X-IronPort-AV: E=Sophos;i="5.56,370,1539648000"; d="scan'208";a="9092304"
IronPort-PHdr: 9a23:A7Sn5R91miVV3v9uRHKM819IXTAuvvDOBiVQ1KB+0+kXIJqq85mqBkHD//Il1AaPAd2Lraocw8Pt8InYEVQa5piAtH1QOLdtbDQizfssogo7HcSeAlf6JvO5JwYzHcBFSUM3tyrjaRsdF8nxfUDdrWOv5jAOBBr/KRB1JuPoEYLOksi7ze+/94HQbglSmDaxfa55IQmrownWqsQYm5ZpJLwryhvOrHtIeuBWyn1tKFmOgRvy5dq+8YB6/ShItP0v68BPUaPhf6QlVrNYFygpM3o05MLwqxbOSxaE62YGXWUXlhpIBBXF7A3/U5zsvCb2qvZx1S+HNsDwULs6Wymt771zRRHolikJKiI5/m/UhMx+jq1UrhOhqABwzYHbe4yVKOFxfqbBcd8GX2dMXMBcXDFBDIOmaIsPCvIMMehZoYn6ulsOqQaxCRGxD+3r0DBIg2H53bY03+88FgzG3gMgH9UTsHTQsdr4L7kSXv6vzKnJ1jXDbvxW2THn5IfUdRAhpOiBULRtesTfzkkvEhnKjlSWqYH9ITOayP4Ns2mA7+phWuKvjW8nqwdtrTS12sgsjYzJipoUyl/a6SV5zpw5JdqiSE50Z9OvDZhetzmCOodrXs8uWXxktSQ0x7EcpJK2fCYHxI4oyhPcc/CLbpSE7gj+WOuTPTt0nm9pdb28ihqo7EStyfXwVseq31tJsiZIl9zBuWoO2hHX8ceKT/Vw8lm81juO0g3c8eVJLEE2mKfeJZMszLw9mYcVvE/eBCH5gl/2g7WTdkg8/+io7Pnobav+q5+HMo90lhn+MqMzmsyjGeg4MhYBX2yc+emkybDt4VX3TKhKgfMunafWsYzWKdkBqq6nHwBV1Zwj6w6lAzi8zdsUh2cHLEheeBKBlYTmJ1bOIPXgAfe+hVSjjitryujbMrH9GJnBM3rOnbn7cbpg60NRxhA/wN9c6p5MD7EOOvPzWkv/tNzCCR85NhS5w+ToCNV6y4MeXX+AD7SHMKzMq1+I5/kvI+iDZI8TojryN/8l5/v2gX8jhVAdZbWp3YcQaH2gBPtmJViWYHr3j9cBHmYKpBAyTPHxiFeaSz5ce26yX74g5jE8EI+mAprDRpq2gLyBxii0BYdZaX1dB1+QEHfobJyIW/YKaC2PI89uiCYIVb+7S48uzRuurhP1y6J7LurI/S0VrYjj28Z65+LNmhAy6Sd5D8WD3GGRQWF4hGQIRyU53PM3nUsogF6F3blQg+xCU8FIrbsdWwE2JLbc3/Y8FsukHkqLccqTU1avSNyqKTowVZcwxdMPagB6AdroxkTMwjCxA7YfnrCjD50vt6Pa03n4YcFnxCCV+rMmigxsbcxSMWHizox28gXITcadkUqeiqKmXboRxi/W9WiFi2GJuRcLA0ZLTazZUCVHNQPtptPj6xaaQg==
X-IPAS-Result: A2EWAABAZBlc/zCZrQpgAxwBAQEEAQEHBAEBgVEHAQELAYFagQ+BKQqDc4gZjgiSXYR+gT8XHQgMARgLC4N4RgIXgmc0CQ0BAwEBAQEBAQIBAQKBBQyCNiISMRwvCQEFAQEBAQEBJwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQgCCAc1EgEBGAEBAQECAQEBIRE6CwULAgEIGAICJgICAiULFRACBAENBYJwMgGBeBenH4Evii2BC4tLgUE+gREnH4JMgx4BAYFLFgwLCiaCQTGCJgKJRoYMkVIDBgKHDYEKiV+BXU2EUopbiUSEcQaLEQIEAgQFAhSBRoIPcBU7KgGCQQmCR4M4hRSFP3INJI0XgR8BAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1531.3; Tue, 18 Dec 2018 16:20:21 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1531.003; Tue, 18 Dec 2018 16:20:21 -0500
From: "Gould, James" <jgould@verisign.com>
To: "andy@hxr.us" <andy@hxr.us>, "gurshabad@cis-india.org" <gurshabad@cis-india.org>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
Thread-Index: AQHUlxVqlYBPqhgCwUiJL3hXFpv+MKWFAMoA
Date: Tue, 18 Dec 2018 21:20:21 +0000
Message-ID: <FD1E789E-8B3B-41D3-8DA3-57056DBC437E@verisign.com>
References: <5f7d0b3e-c844-1700-c369-90bb41e8241e@cis-india.org> <CAAQiQReVnuwFBCA2vOwnwaUw8k+1TCK-5DO+KLsd=CWF3Lh8Cg@mail.gmail.com>
In-Reply-To: <CAAQiQReVnuwFBCA2vOwnwaUw8k+1TCK-5DO+KLsd=CWF3Lh8Cg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A8541756F141D64BB4ED85EB7811E561@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/3GY2lUyrVKzjfEN0oKPagpM8eN0>
Subject: Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Dec 2018 21:20:39 -0000

Andy,

>    I thought the token was passed by the EPP client (registrar) to the
>    EPP server (registry), the purpose of which is to show that the
>    verification occurred before the transaction.

Yes, draft-ietf-regext-verificationcode defines the structure of the verification code that is passed between the EPP client (registrar) to the EPP server (registry) to show that the verification occurred before the EPP transaction.   
 
—
 
JG



James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 12/18/18, 4:05 PM, "regext on behalf of Andrew Newton" <regext-bounces@ietf.org on behalf of andy@hxr.us> wrote:

    I am admittedly not as versed on EPP as others in the wg, but is this
    true? From your privacy text:
    
    "This document describes an extension designed to share the data of (or
    generated by) a registrant with the Verification Service Provider (VSP),
    which is a third party."
    
    The intro section of the draft states:
    
    " The Verification Service Provider (VSP) is a certified party to
       verify that data is in compliance with the policies of a locality.  A
       locality MAY require the client to have data verified in accordance
       with local regulations or laws utilizing data sources not available
       to the server.  The VSP has access to the local data sources and is
       authorized to verify the data.  Examples include verifying that the
       domain name is not prohibited and verifying that the domain name
       registrant is a valid individual, organization, or business in the
       locality.  The data verified, and the objects and operations that
       require the verification code to be passed to the server, is up to
       the policies of the locality.  The verification code represents a
       marker that the verification was completed."
    
    I thought the token was passed by the EPP client (registrar) to the
    EPP server (registry), the purpose of which is to show that the
    verification occurred before the transaction.
    
    -andy
    
    On Fri, Dec 14, 2018 at 10:37 AM Gurshabad Grover
    <gurshabad@cis-india.org> wrote:
    >
    > Hi,
    >
    > Thank you for your comments on the proposed Human Rights Considerations
    > section. Please find the draft text below (with an accompanying Privacy
    > Considerations section which will also be useful); hope it is a good
    > starting point for consensus.
    >
    > Privacy Considerations
    > ----------------------
    > This document describes an extension designed to share the data of (or
    > generated by) a registrant with the Verification Service Provider (VSP),
    > which is a third party. The scope of information shared with and stored
    > by the VSP is dependent on the policies and regulations of the locality
    > and the VSP. The extension has no built-in mechanisms for registrants to
    > express preference for what information should shared with the VSP. In
    > certain cases, this will lead to the exposure of registrants' sensitive
    > personal information directly linked to the identities of the
    > individual, such as contained in the contact mapping object, without
    > user control. This may impact users' expectation of confidentiality of
    > their information. This personal information may be further correlated
    > with other data sources available to the VSP.
    >
    > If a service provider seeks to implement or offer this extension, it
    > MUST inform the registrant about about the exact information to be
    > shared with the VSP.
    >
    > Human Rights Considerations
    > ---------------------------
    > The use of this extension may have negative implications for the human
    > rights of potential or actual registrants, depending on the
    > implementation and policies used by the registrar and the VSP.
    >
    > * In particular, the extension might be employed as, or contribute to, a
    > domain name filtering and censorship mechanism. This can negatively
    > impact registrants' freedom of expression, and may further impede their
    > freedom of assembly and association, and social and economic rights.
    >
    > * Depending on the information shared with the VSP and data sources
    > already available to it, the extension may also allow the VSP to
    > discriminate against registrants based on registrants' personal
    > characteristics, beliefs, or opinions. Even when such restrictions are
    > not applied, knowledge of the information being shared with the VSP
    > could create chilling effects on registrants' freedom of expression, and
    > freedom of association and assembly.
    >
    > * The VSP may be a third party entrusted to carry out sensitive legal
    > decisions. Due to the lack of mechanisms in this extension that can
    > facilitate appeal and redressal of a rejection, the registrants' right
    > to legal transparency and remedy will also be impacted in such a situation.
    >
    > Implementers should consider the potential human rights impacts of
    > offering and normalising this extension when advertising support for it
    > in EPP.
    >
    > /.
    >
    > Thanks to Mallory, Niels and Adam for their feedback off-list. The text
    > above may not reflect their opinion.
    >
    > Thank you.
    > Gurshabad
    >
    > _______________________________________________
    > regext mailing list
    > regext@ietf.org
    > https://www.ietf.org/mailman/listinfo/regext
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext