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

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
> jgould@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-bounces@ietf.org on behalf of gurshabad@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