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

Andrew Newton <andy@hxr.us> Tue, 18 December 2018 21:05 UTC

Return-Path: <andy@hxr.us>
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 B8E3E130F29 for <regext@ietfa.amsl.com>; Tue, 18 Dec 2018 13:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.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 oy0WMuMh7bcT for <regext@ietfa.amsl.com>; Tue, 18 Dec 2018 13:05:13 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9B713116F for <regext@ietf.org>; Tue, 18 Dec 2018 13:05:13 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id s22so13889671ioc.8 for <regext@ietf.org>; Tue, 18 Dec 2018 13:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ko8kGHiGV/Bt/dT4DGyZ/IwOOjwVo+P3B+myEfDIAok=; b=OKnUwlttra4iDpgFYLef7N0vDbclkYlQJpusniIwVw7OLahFTuR1eOHpP0AA66Txzr b76cJOAe/L5DMd3MxFFOcAZm7m418ZJcDOHvHGj0xVmwWB4WCI2CG3RRVXss2TY9ViW+ hn3zB7hO30EOUCPEHOmMllNeZZd06v7wzw6jVCGWv8ANkLOvoSFD/tGP8aqUuMUrFDV7 /4u/UWZyj4DsA94TVsOfFyGXsqu22ZufWmp6BoCiA+sbZQygXT/7O3eHHdtPqRPnZ0nh 5q0kYnj+BhXQUDwH6muSgmm2PCktYEY89kXmR8Kg1yaD3cyy+r6cr07g1ucXhKSMSEE7 3Tsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ko8kGHiGV/Bt/dT4DGyZ/IwOOjwVo+P3B+myEfDIAok=; b=DLhanMaAbfSROOTpz0rZBpShiJ0AJGBEqpHykzX77mXUDoj/IYWD4YR3oZv3KDXvzX qfh0zKJvgB9PJmSNBy5c1d0as44+PKvqfthz/TcGZ1dyIh673EjZStEHzJAkn1T1I0uW b1Ox+3o7PlhmlFlSa+W1tlrYzsxs8N9n41DbkwdfUwlBBnJlaweip/KYDQkGNB01Q/t2 uepQwz423UlTT1JyFE5TnISes7VPa+TYBiR7FyRQ9YkPxHgHp+DykuBLO4xrMcwmfUnJ YlqJEB+rtfzRlJB/DOXAyT2UoNDzNyRKcCgDexB+a3pwzO6YbKUhOGPU8/6ZSityj1m8 znwA==
X-Gm-Message-State: AA+aEWYRsYJDWQ8mEWuwjc1+xc2ll4PjaIhKO+bvxB49UIrlE41UZW+o RhsrJYVVfxAnefb+V7jQTm6t2BL2nhCUJSyDJvs6DQ==
X-Google-Smtp-Source: AFSGD/URNejmBlzlO4gq69UltiDWtpE/GaEShdXcXOCOCU1sTsEMtuuO9h697AI9cE53OGHkNI9z18PEzdbZ199/6W0=
X-Received: by 2002:a6b:7402:: with SMTP id s2mr15044943iog.219.1545167112932; Tue, 18 Dec 2018 13:05:12 -0800 (PST)
MIME-Version: 1.0
References: <5f7d0b3e-c844-1700-c369-90bb41e8241e@cis-india.org>
In-Reply-To: <5f7d0b3e-c844-1700-c369-90bb41e8241e@cis-india.org>
From: Andrew Newton <andy@hxr.us>
Date: Tue, 18 Dec 2018 16:04:17 -0500
Message-ID: <CAAQiQReVnuwFBCA2vOwnwaUw8k+1TCK-5DO+KLsd=CWF3Lh8Cg@mail.gmail.com>
To: gurshabad@cis-india.org
Cc: Registration Protocols Extensions <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/d6o8eI9K_pQRGslxdtVdlYwIWTA>
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:05:17 -0000

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