On 12/19/18 8:31 PM, Gould, James wrote: > 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. > 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 > — > > 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 > -- 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
