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

From: Gurshabad Grover <[email-masked]>
Date: Fri, 14 Dec 2018 21:07:28 +0530

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

---

From: "John Levine" <[email-masked]>
Date: 14 Dec 2018 13:26:53 -0500

Having reviewed the proposed text, I would encourage the WG to ignore it.

It is unhelpful, tendentious and a distraction from the WG's purpose.
In the interest of not wasting any more time, this is my last message
on the topic.

R's,
John

In article <[email-masked]> you write:
>starting point for consensus. ...

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Dec 2018 14:42:16 -0600

[as an individual]

While I might quibble about some of the specifics of the proposed text, 
I disagree with the characterization of "unhelpful." Both proposed 
sections, in fact, make an attempt to be actionable.

In terms of tendentiousness, one could easily say the same of pretty 
much any "Security Considerations" or "Privacy Considerations" section 
we've ever published. But that's okay: a bias towards security and 
privacy are characteristics we've chosen to take on in our documents.

The same applies to the assertion regarding "a distraction from the WG's 
purpose": most protocols would "work" from a technical perspective 
without guidance regarding security and privacy; and so one could 
equally assert that such sections are also a "distraction" from the core 
work of those protocols. A key reason people come to the IETF to do work 
is the fact that it is a multi-stakeholder environment, designed to take 
these kinds of secondary effects into account.

And so I would encourage people to engage on the substance of the 
proposal rather than dismissing it out of hand.

/a

On 12/14/18 12:26 PM, John Levine wrote:
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Dec 2018 16:04:17 -0500

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 18 Dec 2018 21:20:21 +0000

Andy,

>    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
[email-masked]

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" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    -andy

---

From: Andrew Newton <[email-masked]>
Date: Tue, 18 Dec 2018 16:59:14 -0500

> 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 o…

Thanks for the _verification_, James. :)

I think this means the premise for the privacy considerations is
nonexistent, and therefore the text given is not applicable.

-andy

---

From: Gurshabad Grover <[email-masked]>
Date: Wed, 19 Dec 2018 15:51:58 +0530

> verification occurred before the transaction.

Thanks for pointing that out. A better way to phrase my concern would
have been that the extension's functioning is dependent on data being
shared with the VSP. The draft does describe some (not all of the
necessary) aspects of that data sharing.

Agree that the text could have been more accurate in reflecting that.
Changes are incorporated below (will review the HRC section again in
this light as well); for now, hope this reads better:

Privacy Considerations
----------------------
The working of the described extension depends on the sharing of data of
(or generated by) registrants with the Verification Service Provider
(VSP), which is a third party. The specification leaves the scope of
information shared with and stored by the VSP up to the policies of the
locality. There may be no mechanisms for registrants to express
preference for what information should shared with the VSP, in which
case, registrants' sensitive personal information directly linked to the
identities of the individual, such as contained in the contact mapping
object, may be exposed to the VSP without user control. This personal
information may be further correlated with other data sources available
to the VSP.

If a client seeks to implement or offer this extension, it MUST inform
the registrant about about the exact information to be shared with the VSP.

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 19 Dec 2018 12:47:02 +0100

I think the unclarity here is about the nature of causation, and more specifically about the priority of events. Because the exchange of private data between a registrar and a VSP on the one hand, and the use of the verification code on the other hand, is of a necessary deterministic nature, I do think the considerations are applicable.  

(more about the nature of causation in the chapter Causation, in: "Gerring, John. 2011, 'Social Science Methodology: A Unified Framework', Cambridge University Press, UK" - I can share the chapter with you if you contact me off-list)

Best,

Niels

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Dec 2018 10:19:33 -0500

> Privacy Considerations

I disagree with the MUST. What the registrant is informed of or not is
entirely a policy matter and not up to the IETF. At best, this should
be a lowercase "should".

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Dec 2018 10:27:56 -0500

> I think the unclarity here is about the nature of causation, and more specifically about the priority of events. Because the exchange of private data between a registrar and a VSP on the one hand,…

Then the text should say that. As it stands, the current text makes it
sound like the IETF is enabling some new method for human rights abuse
that otherwise would not be available to an abusive authority, and
that is absolutely not true. In fact, the text should be clearer on
the point that this mechanism does not give an abusive authority any
more leverage to violate human rights than they already posses.

-andy

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 19 Dec 2018 16:38:43 +0100

On 12/19/18 4:27 PM, Andrew Newton wrote:
> that is absolutely not true. 

Everything is possible without the IETF: the Internet has open standards. So IETF is never solely responsible for anything. But IETF is setting a norm and thus normalizing and enabling this behavior. I think this is made clear in the text, and even clearer in the new text proposed by Gurshabad. 

Best,

Niels

> In fact, the text should be clearer on

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 19 Dec 2018 16:40:13 +0100

> entirely a policy matter and not up to the IETF. At best, this should

The distinction between policy and technology seems superficial here. The creation of the possibility of using a VSP in EPP can also be seen as a policy decision.

Unless you could provide a clear definition for the distinction of course.

Best,

Niels

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Dec 2018 10:45:23 -0500

> Everything is possible without the IETF: the Internet has open standards. So IETF is never solely responsible for anything. But IETF is setting a norm and thus normalizing and enabling this behavio…

Except that is not true. The IETF is not setting a norm. The norm
already exists. Any abusive authority that can force a registry to
obey verification codes already has the power to force a registry to
remove domain names.

-andy

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 19 Dec 2018 18:26:44 +0100

> obey verification codes already has the power to force a registry to

I am not quite sure I understand, are you saying an Internet standard is not a norm?

The verification code normalizes and facilitates the behavior that is potentially violating the human and privacy rights of registrants. 

Similar behavior might exists, but not in this way. This status code makes it easier and standardizes it, and thus facilitates and enables it. 

Therefore I think it should not be standardized, but if we do, we should at least say something about these inherent risks in implementation.

Best,

Niels

---

From: Andrew Newton <[email-masked]>
Date: Wed, 19 Dec 2018 12:57:16 -0500

> I am not quite sure I understand, are you saying an Internet standard is not a norm?

No, it's a technical specification.

>From an ethical point of view, I am not opposed to privacy or human
rights considerations in IETF documents. But practically speaking, if
discussions are to break down into meta-conversations on the
philosophical differences between what is or is not a specification or
what is or is not policy, I conclude that such efforts are futile and
a waste of time.

-andy

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 19 Dec 2018 19:12:27 +0100

> No, it's a technical specification.

Open technical standards are de facto norms. That something is a technical specification does not mean it is not a norm and vice versa.

> what is or is not policy, I conclude that such efforts are futile and

I think the discussion is very concrete, with a concrete text proposal. 

I agree that discussing the distinction between policies and technical specifications is a waste of time because these are overlapping concepts. 

Best,

Niels

---

From: Adam Roach <[email-masked]>
Date: Wed, 19 Dec 2018 12:24:00 -0600

[as an individual]

> The distinction between policy and technology seems superficial here. The creation of the possibility of using a VSP in EPP can also be seen as a policy decision.

No, Andrew is correct here. This is not a place for normative language. 
The guidance seems reasonable, but the formulation is overreaching. I 
would propose: "Clients are encouraged to inform registrants about the 
exact information to be shared with the VSP."

/a

---

From: "Gould, James" <[email-masked]>
Date: Wed, 19 Dec 2018 19:31:12 +0000

Gurshabad,

Your proposed Privacy Considerations section and much of your proposed Human Rights Considerations section focuses on the interface of the VSP, which is out-of-scope for draft-ietf-regext-verificationcode.  The scope of draft-ietf-regext-verificationcode is on the structure of the digitally signed verification code, that represents proof of verification, and the interface between the client (registrar) and the server (registry) to pass the verification code.  The role of the VSP is defined, but the VSP interface and the concrete verifications is by design left out of draft-ietf-regext-verificationcode, and therefore is out-of-scope.  Niels support for inclusion based on “causation, and more specifically the priority events” is beyond the scope of draft-ietf-regext-verificationcode and is not applicable.  We need to ensure to keep the technical and considerations text strictly focused on the defined scope of the draft.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 12/19/18, 5:22 AM, "regext on behalf of Gurshabad Grover" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Privacy Considerations
    ----------------------

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 19 Dec 2018 22:01:19 +0100

> Your proposed Privacy Considerations section and much of your proposed Human Rights Considerations section focuses on the interface of the VSP, which is out-of-scope for draft-ietf-regext-verificat…
So if the verification code is a verification that X happened, your argument is that the verification code technically has nothing to do with X ? 

I am sorry but that is pretty far fetched imho. I am not sure whether the author can declare this out-of-scope.

Best,

Niels

---

From: "Gould, James" <[email-masked]>
Date: Wed, 19 Dec 2018 22:28:35 +0000

Niels,
 
By design, draft-ietf-regext-verificationcode does not define the verification process or data, which maximizes its usefulness to a wide variety of situations.  In this manner, it is in keeping with other REGEXT-originated RFCs (e.g. EPP, RDAP, etc).
 
The scope of draft-ietf-regext-verificationcode is very clear and relatively limited -- the structure of the verification code and the passing of the verification code -- and Considerations sections are not where the scope of the draft would be broadened.
 
I am not making a declaration, but I'm expressing my position that the Considerations should focus strictly on the scope of the draft.  It's up to the working group to decide, but if we start considering the verification process, we are (inappropriately, I’d offer) focusing on elements not defined within draft-ietf-regext-verificationcode.    
 
Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 12/19/18, 4:01 PM, "regext on behalf of Niels ten Oever" <[email-masked] on behalf of [email-masked]> wrote:

    
    Best,
    
    Niels

---

From: Gurshabad Grover <[email-masked]>
Date: Fri, 21 Dec 2018 15:44:26 +0530

On 20/12/18 1:01 AM, Gould, James wrote:
> 
> Your proposed Privacy Considerations section and much of your proposed Human Rights Considerations section focuses on the interface of the VSP, which is out-of-scope for draft-ietf-regext-verificationcode.  The scope of draft-ietf-regext-verificationcode is on the structure of the digitally signed verification code, that represents proof of verification, and the interface between the client (registrar) and the server (registry) to pass the verification code.  The role of the VSP is defined, but the VSP interface and the concrete verifications is by design left out of draft-ietf-regext-verificationcode, and therefore is out-of-scope.  
>  

I think the previous thread with Andrew Newton clarifies why the Privacy
Considerations are applicable. Could you be specific as to which HR
consideration is out of scope?

As you have already noted, the role of the VSP is defined and (therefore
presumably) in the scope of the document. Since most HR considerations
relate to the VSP's role, they are also in the scope of
draft-ietf-regext-verificationcode.

Thank you.
Gurshabad

---

From: "Gould, James" <[email-masked]>
Date: Wed, 26 Dec 2018 14:32:57 +0000

Gurshabad,
 
I first need to be clear that I oppose adding both sections that you've provided to draft-ietf-regext-verificationcode.  The sections that you've provided are non-technical and are associated with policy elements.  The REGEXT working group has dealt with technical aspects of drafts.  I don't believe the REGEXT working group is qualified to effectively discuss and come to consensus on policy elements.  I recommend that inclusion of these sort of elements be brought up to the IETF-level.
 
The thread with Andrew Newton did not clarify the applicability of the Privacy Considerations, but addressed two technical issues related to fixing the described relationship of the client with the server, and fixing the inappropriate inclusion of a normative policy statement.  The clearly out of scope elements of the HR Considerations section include the following bulleted items that are only associated with the VSP, and have nothing to do with draft-ietf-regext-verificationcode.      

 
The scope of draft-ietf-regext-verificationcode does not include the verification process of the VSP by design.   Any considerations section, including the HR or the Privacy Considerations, need to be within the defined scope of the draft.
 
Do others in the working group believe that either the verification process of the VSP is in scope based on the current wording of the draft or that a consideration section can cover something that is outside the defined scope of the draft?
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 12/21/18, 5:14 AM, "Gurshabad Grover" <[email-masked]> wrote:

    
    
    Thank you.
    Gurshabad

---

From: "John Levine" <[email-masked]>
Date: 26 Dec 2018 21:58:50 -0500

In article <[email-masked]> you write:
>Do others in the working group believe that either the verification process of the VSP is in scope
>based on the current wording of the draft or that a consideration section can cover something that
>is outside the defined scope of the draft?

Heck, no.  They have nothing to do with ensuring interoperability, and
nothing I can see to do with any plausible use of this extension.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Gurshabad Grover <[email-masked]>
Date: Fri, 28 Dec 2018 16:19:47 +0530

On 26/12/18 8:02 PM, Gould, James wrote:
> [...] The thread with Andrew Newton did not clarify the applicability of the Privacy Considerations, but addressed two technical issues related to fixing the described relationship of the client with the server, and fixing the inappropriate inclusion of a normative policy statement.  The clearly out of scope elements of the HR Considerations section include the following bulleted items that are only associated with the VSP, and have nothing to do with draft-ietf-regext-verificationcode. [...]     
>  

For the context of the considerations, let's look at some text from the
draft:

"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."

"It is up to the VSP and the server to define the valid values for the
"type" attribute. Examples of possible "type" attribute values include
"domain" for verification of the domain name, "registrant" for
verification of the registrant contact, or "domain-registrant" for
verification of both the domain name and the registrant. The typed
signed code is used to indicate the verifications that are done by the VSP."

"The VSP MUST store the proof of verification and the generated
verification code; and MAY store the verified data."

So, the draft
(1) describes the role of the VSP;
(2) has guidance on what types of verification the VSP can perform; and
(3) places certain obligations on the VSP.

So, I think it's unfair to say that considerations that touch upon the
VSP's role "have nothing to do with draft-ietf-regext-verificationcode."

Re: text of the considerations...

The proposed privacy considerations rely entirely on the draft and the
guidance in RFC6973 (very commonly used across working groups to write
privacy considerations). Specifically, the excerpts above and the
following items in RFC6973:

* "Are there expected ways that information exposed by the protocol will
be combined or correlated with information obtained outside the
protocol?" [3]

* "Does the protocol provide ways for initiators to express individuals'
preferences to recipients or intermediaries with regard to the
collection, use, or disclosure of their personal data?" [4]

The proposed text addresses these, and in fact, uses terminology from
only the draft and RFC6973.

Similarly, most HR considerations directly follow from the privacy
considerations and rely on guidance in RFC8280. Specifically,

* "Can your protocol contribute to filtering in such a way that it could
be implemented to censor data or services?" [5]

* "What is the potential for discrimination against users of your
protocol?" [6]

Open to further discussing the rationale behind the proposed text. Would
also like to hear what others think.

Thank you.
Gurshabad

PS.

> I recommend that inclusion of these sort of elements be brought up to
> the IETF-level.

Not sure what you mean here. I think there is enough clarity from
the chairs and the IESG that it is entirely up to the WG about what to
include in the WG draft. [0][1][2]

[0] https://youtu.be/LYYehA0LNRc?t=8690
[1] https://www.ietf.org/mail-archive/web/regext/current/msg01991.html
[2] https://www.ietf.org/mail-archive/web/regext/current/msg01993.html
[3] https://tools.ietf.org/html/rfc6973#section-7.1
[4] https://tools.ietf.org/html/rfc6973#section-7.2
[5] https://tools.ietf.org/html/rfc8280#section-6.2.6
[6] https://tools.ietf.org/html/rfc8280#section-6.2.13

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2018 14:45:10 -0500

>verification code; and MAY store the verified data."

The 2119 words MUST and MAY are about interoperation.

Now that you point it out, this has nothing to do with interoperation
unless compliance somehow affects interop.

I would suggest removing that part, or at least making it
non-normative since business practices are generally way out of scope
for IETF specs.

R's,
John