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 jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/19/18, 5:22 AM, "regext on behalf of Gurshabad Grover" <regext-boun...@ietf.org on behalf of gursha...@cis-india.org> wrote: 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. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
