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
