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

From: "Gould, James" <[email-masked]>
Date: Wed, 13 Feb 2019 14:52:32 +0000

Gurshabad,

Can you provide your latest proposed section(s) on the list for consideration by the WG?  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 1/2/19, 11:44 AM, "Gould, James" <[email-masked]> wrote:

    Gurshabad,
    
    For the defined purpose of draft-ietf-regext-verificationcode, the VSP needs to be defined as an entity, but the VSP's verification process is not defined and is out-of-scope.  The use of examples in an IETF draft does not classify as guidance.  The only obligation of the VSP within draft-ietf-regext-verificationcode is to generate a technically compliant verification code and to store the proof of verification and the generated verification code.  There is no concrete definition defined within draft-ietf-regext-verificationcode of: 
    - the forms of verifications performed by a VSP, 
    - the data that must be passed for verification, 
    - how the verification data is processed,
    - the data sources that are used to perform the verification,
    - the interface(s) or protocol(s) used by a VSP, and 
    - other policies and technical details of a VSP.  
    
    The majority of your considerations (Privacy and identified paragraphs from the HR) is focused on the policies and interfaces / protocols of the VSP that is by design out-of-scope from draft-ietf-regext-verificationcode.  
    
    My recommendation is to strictly focus your proposed considerations text on the scope of draft-ietf-regext-verificationcode, that includes the definition of the verification code (e.g., digitally signed, typed identifier that provides proof of verification) and the passing of the verification code between the client (registrar) and the server (registry) over EPP. 
    
        > 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]
      
    Yes, it is my position that the proposed text included in your proposed sections as non-technical and focused on policy elements that the WG is not qualified to discuss and come to consensus on.  If you desire to have these sort of sections in WG drafts, it is best for it to be handled at the IETF-level and not at the WG-level.
    
    Can you provide your latest proposed section(s) on the list for consideration by the WG?  
    
    We also need to continue to hear from others in the working group.
    
    Thanks,
    
    —
     
    JG

    James Gould
    Distinguished Engineer
    [email-masked]
    
    703-948-3271
    12061 Bluemont Way
    Reston, VA 20190
    
    Verisign.com <http://verisigninc.com/> 
    
    On 12/28/18, 5:49 AM, "Gurshabad Grover" <[email-masked]> wrote:
    
        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: Gurshabad Grover <[email-masked]>
Date: Mon, 18 Feb 2019 22:52:23 +0530

> Can you provide your latest proposed section(s) on the list for consideration by the WG?  

James, thanks for bumping the thread.

Everyone, thanks for the discussion. I have revised the text based on
the discussion, which you can find below. I realise there are still some
differences in opinion, but I am hopeful we can arrive at agreeable
considerations for the draft. Would appreciate your feedback.

Privacy Considerations
----------------------
The working of this extension depends on the sharing of data of (or
generated by) registrants with the VSP. For example, a verification code
with the "type" attribute set to "registrant" or "domain-registrant" (as
described in the examples in Section 2.1.1) depends on registrants'
personal information, such as contained in the contact mapping object,
being shared with the VSP.

To mitigate the possible negative impact on registrants' privacy,
clients using this extension are encouraged to inform registrants about
the information shared with the VSP.

Human Rights Considerations
---------------------------
The extension may contribute to a domain name filtering and
pre-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.

Additionally, this extension may support a paradigm where the VSP's
policies negatively impact registrants' human rights. For example,
depending on the information shared with the VSP (and data sources
already available to it), the VSP may discriminate against registrants
based on registrants' personal characteristics. 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, association and assembly.

Clients should consider these possible human rights implications when
offering the use of this extension and advertising support for it in EPP.

/

Thank you.
Gurshabad