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

Niels,

By design, draft-ietf-regext-verificationcode does not define the verification process or data, which maximizes its usefulness to a wide variety of situations.  In this manner, it is in keeping with other REGEXT-originated RFCs (e.g. EPP, RDAP, etc).

The scope of draft-ietf-regext-verificationcode is very clear and relatively limited -- the structure of the verification code and the passing of the verification code -- and Considerations sections are not where the scope of the draft would be broadened.

I am not making a declaration, but I'm expressing my position that the Considerations should focus strictly on the scope of the draft.  It's up to the working group to decide, but if we start considering the verification process, we are (inappropriately, I’d offer) focusing on elements not defined within draft-ietf-regext-verificationcode.    

Thanks,

—

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, 4:01 PM, "regext on behalf of Niels ten Oever" <regext-bounces@ietf.org on behalf of lists@digitaldissidents.org> wrote:

    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

    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext