Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
On 13/02/19 8:22 PM, Gould, James wrote: > > 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 signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search
On 23/01/19 6:25 PM, Niels ten Oever wrote: > [...] > In this draft, there are no privacy considerations, and the report that is > being cited to legitimize this approach has not been adopted by ICANN the > organization or the community and was very controversial at the time of > publication. The report is being miscited as being produced by ICANN itself, > which was not the case. > [...] I agree with Niels: * Since the document starts with outlining privacy concerns as being of primary import and relevance to the discussion around reverse search, the document would naturally benefit from adding privacy considerations. * The reference to a ICANN WG's recommendations as "... ICANN itself, in its report about Next-Gen Registration Directory Service (RDS) ..." is also problematic. Thank you. Gurshabad signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
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 signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
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 signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
On 19/12/18 2:34 AM, Andrew Newton wrote: > > 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. > 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. signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-verificationcode Feedback by Gurshabad Grover at REGEXT Meeting
On 07/11/18 11:30 AM, Gould, James wrote: > 1. Clarifying that it’s up to server policy to define the server action > taken when the verification code grace period expires > Thanks, JG; I see that -05 incorporates this change. > 2. Ensure that the VSP does not modify the data verified after the > verification code is generated > This does not seem to be a concern since the VSP is transmitting only the verification code. Sorry for the confusion, we can ignore this. > 3. Include a HRPC section in draft-ietf-regext-verificationcode > This is being discussed actively on the list, but at present I > believe that we can address the feedback without adding a new > section to the document. > The primary concerns (as highlighted in the review) relate to how implementing this extension in a locality impacts registrants' privacy, freedom of expression, and allows the VSP to discriminate based on registrants' personal information. These minor changes I proposed, unfortunately, cannot address these primary concerns. That is why it may be useful to add a section with human rights considerations. I have shared the text that I think will be useful to include in the draft in another thread. Hope we can use that as a starting point for consensus. Thank you. Gurshabad signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Privacy and HR considerations for draft-ietf-regext-verificationcode
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 signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-verificationcode Feedback by Gurshabad Grover at REGEXT Meeting
On 16/11/18 8:48 PM, James Galvin wrote: > The co-Chairs would like to remind the working group that if anyone > believes there should be an HRPC section then the action is for that > person to propose the text that would go in an HRPC section. The > working group will then consider that addition as it would the > addition of any other contribution to the document. > Thank you, Antoin and Jim. As one of the persons who believes there should be an HRC section, I will propose some text on this list soon. Gurshabad signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] edit for Section 7
On 07/11/18 4:47 PM, Wilhelm, Richard wrote: > > Jim, > > > > A suggestion for Section 7 (Security Considerations) to delete the > sentence: > > > > The Verification Service Provider (VSP) MUST store the verification > > data in compliance with the applicable privacy laws and regulations. > > > > The rationale for this is that IETF RFCs (and I-Ds) are always > subordinate to laws/regulations. Therefore, it’s not necessary to > state or call out that compliance is required. And doing so would be > unusual for an RFC. > > > > Credit for pointing this out goes to Amelia Andersdotter from > Article19, who, in a helpful conversation we had today, also pointed > out that this sentence, which was added recently after receipt of the > human rights review, was not directly tied to a particular point of > feedback point. > > > > Rick > > > I brought this up at the regext meeting, thanks for mentioning it on the list. I completely agree. Thank you. Gurshabad signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] "Considerations" Sections
On 06/11/18 11:49 PM, Andrew Newton wrote: > 2. In my opinion, I do not believe a human rights considerations > section would negatively impact the readability of this draft if > written properly. That said, the text put forward in the other thread > is certainly not acceptable as it has the tone of "only people who > crush cute puppies under their boots would do this". The text should > be neutral in its advice and merely note the issues, as we see with > most security considerations in the IETF. The text I read said a lot > of things "will" happen instead of "may" happen. > Thanks. Just wanted to clarify here to avoid any confusion: the HR review is NOT the proposed text for the human rights considerations section for the draft. I will be drafting a paragraph or two as my proposition for the HRC section, and will be sharing it on this list. Thanks for your feedback, I will take it into account when I draft it. Thank you. Gurshabad signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Human Rights Review of draft-ietf-regext-verificationcode
On Friday 05 October 2018 04:44 PM, Hollenbeck, Scott wrote: >> If there is only one instance in which this MAY be useful, perhaps there >> is no need for standardization of this extension? > If there is at least one example, there is a demonstration of existence of > utility. > > Scott Thank you, Niels, Scott, Eliot, Adam, Andrew and Peter for bringing this up and discussing this issue. In this particular case, in addition to RFC 2026, we should also look at RFC 3735, 'Guidelines for Extending the Extensible Provisioning Protocol (EPP)', authored by Scott. It briefly discusses some criteria for which track to choose for different EPP extensions. Most pertinently, it notes that: "the intended maturity level (informational, proposed standard, etc.) largely depends on what is being extended and the amount of general interest in the extension." [1] Additionally, it says: “Extensions need not be published as Internet-Draft or RFC documents if they are intended for operation in a closed environment or are otherwise intended for a limited audience. In such cases extensions MAY be documented in a file and structural format that is appropriate for the intended audience.”[1] So, demonstration of utility and interest is an important aspect here (first for whether it should be an I-D/RFC; and if yes, with what status: informational/standard). Thank you. Gurshabad [1] https://tools.ietf.org/html/rfc3735#section-2.1 signature.asc Description: OpenPGP digital signature ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Human Rights Review of draft-ietf-regext-verificationcode
Hi all, Firstly, thanks to James Gould and the regext working group for developing draft-ietf-regext-verificationcode. As part of efforts in the Human Rights Protocol Considerations (HRPC) group, I have reviewed the human rights considerations (using RFC 8280 as a framework) in draft-ietf-regext-verificationcode-03. Please find the review below. Hope that some of these concerns can be addressed moving forward. HR Review: Verification Code Extension for the EPP == An assessment of human rights considerations in draft-ietf-regext-verificationcode-03. Introduction The ‘Verification Code Extension for the Extensible Provisioning Protocol (EPP)’ ([VCEPP], hereinafter also referred to as the “draft”) describes an extension in the EPP object mappings which supports adding a verification code provided by a third-party known as the Verification Service Provider (VSP). If the registrant’s data is not “verified” by the VSP, it may be prohibited from requesting the execution of EPP transform commands. This is a review of the human rights considerations in the the draft. (See [RFC 8280], ‘Research Into Human Rights Protocol Considerations’). We believe that the draft does not make adequate considerations for human rights: The implementation of the proposed extension will impact domain registrants’ right to freedom of expression, right to freedom of assembly and association, and right to privacy. Human Rights Considerations --- # Privacy ([RFC8280], section 6.2.2) From [RFC8280]: “Could your protocol improve data minimization?” and “Does your document identify potentially sensitive data logged [...] and/or for how long that data needs to be retained for technical reasons?” The draft leaves the precise data shared with the VSP “up to the policies of the locality” and outside the scope of the draft. In the 'domain-registrant' type of verification, both the registrant contact information and domain name are sent to the VSP. The registrant contact information is sensitive personal information, including name, address, telephone number and email address. [RFC5733] The draft notes that, “the data verified by the VSP MUST be stored by the VSP along with the generated verification code to address any compliance issues.” The information is retained and “may be accessed at a later time.” Registrants whose personal information will be shared in this way have no control over these aspects, which negatively impacts their privacy. # Content Agnosticism ([RFC8280], section 6.2.3) From [RFC8280]: “Does your protocol make decisions based on the payload [...]? Does your protocol prioritize certain content or services over others [...]?” Section 1 of the draft states that the “Verification Service Provider (VSP) is a certified party to verify that data is in compliance with the policies of a locality.” Therefore, the extension facilitates the prioritization of certain individuals based on how the VSP judges whether the registrants’ data is compliant. Registrants’ data which is not in “compliance” with the local regulations will not receive a verification code from the VSP, which gives the VSP the power to restrict individuals from registering/modifying a domain name, and limits their right to freedom of expression. # Censorship Resistance ([RFC8280], section 6.2.6) From [RFC8280]: “Can your protocol contribute to filtering in such a way that it could be implemented to censor data or services? [...]” By design, the extension facilitates filtering: the VSP will receive the power to “verify” data on arbitrary grounds when determining whether registrant data is in “compliance” with local regulations. The draft also identifies examples of these scenarios: the VSP will check whether “the domain name is not prohibited”, or whether the “registrant is a valid individual, organization, or business in the locality.” On these grounds, the VSP can accept or reject attempts to register domain names. Thus, the extension explicitly provides filtering and censorship abilities to the VSP, which are inimical to the registrants’ freedom of expression. # Open Standards ([RFC8280], section 6.2.7) From [RFC8280], “Are you aware of any patents that would prevent your standard from being fully implemented [RFC6701] [RFC8179]?” There is an IPR declaration filed by Verisign Inc. for an older version of the draft mentioning the relevant [PATENT]. The declaration facilitates mostly open development, giving minimal assertion rights over the license for Verisign Inc. From [RFC8280]: “Is your protocol fully documented in such a way that it could be easily implemented, improved, built upon, and/or further developed?” Several key details that will form the complete mechanism for the verification code are not included in the draft (as it only describes the extension), but have been offered in the [PATENT]. This includes a description of the grace period within whic
