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

[Gurshabad Grover]

On 13/02/19 8:22 PM, Gould, James wrote:
> 
> Can you provide your latest proposed section(s) on the list for consideration 
> by the WG?  
> 

James, thanks for bumping the thread.

Everyone, thanks for the discussion. I have revised the text based on
the discussion, which you can find below. I realise there are still some
differences in opinion, but I am hopeful we can arrive at agreeable
considerations for the draft. Would appreciate your feedback.

Privacy Considerations
--
The working of this extension depends on the sharing of data of (or
generated by) registrants with the VSP. For example, a verification code
with the "type" attribute set to "registrant" or "domain-registrant" (as
described in the examples in Section 2.1.1) depends on registrants'
personal information, such as contained in the contact mapping object,
being shared with the VSP.

To mitigate the possible negative impact on registrants' privacy,
clients using this extension are encouraged to inform registrants about
the information shared with the VSP.


Human Rights Considerations
---
The extension may contribute to a domain name filtering and
pre-censorship mechanism. This can negatively impact registrants'
freedom of expression, and may further impede their freedom of assembly
and association, and social and economic rights.

Additionally, this extension may support a paradigm where the VSP's
policies negatively impact registrants' human rights. For example,
depending on the information shared with the VSP (and data sources
already available to it), the VSP may discriminate against registrants
based on registrants' personal characteristics. Even when such
restrictions are not applied, knowledge of the information being shared
with the VSP could create chilling effects on registrants' freedom of
expression, association and assembly.

Clients should consider these possible human rights implications when
offering the use of this extension and advertising support for it in EPP.

/

Thank you.
Gurshabad



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

Gurshabad,

Can you provide your latest proposed section(s) on the list for consideration 
by the WG?  

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 1/2/19, 11:44 AM, "Gould, James"  wrote:

Gurshabad,

For the defined purpose of draft-ietf-regext-verificationcode, the VSP 
needs to be defined as an entity, but the VSP's verification process is not 
defined and is out-of-scope.  The use of examples in an IETF draft does not 
classify as guidance.  The only obligation of the VSP within 
draft-ietf-regext-verificationcode is to generate a technically compliant 
verification code and to store the proof of verification and the generated 
verification code.  There is no concrete definition defined within 
draft-ietf-regext-verificationcode of: 
- the forms of verifications performed by a VSP, 
- the data that must be passed for verification, 
- how the verification data is processed,
- the data sources that are used to perform the verification,
- the interface(s) or protocol(s) used by a VSP, and 
- other policies and technical details of a VSP.  

The majority of your considerations (Privacy and identified paragraphs from 
the HR) is focused on the policies and interfaces / protocols of the VSP that 
is by design out-of-scope from draft-ietf-regext-verificationcode.  

My recommendation is to strictly focus your proposed considerations text on 
the scope of draft-ietf-regext-verificationcode, that includes the definition 
of the verification code (e.g., digitally signed, typed identifier that 
provides proof of verification) and the passing of the verification code 
between the client (registrar) and the server (registry) over EPP. 

> 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]
  
Yes, it is my position that the proposed text included in your proposed 
sections as non-technical and focused on policy elements that the WG is not 
qualified to discuss and come to consensus on.  If you desire to have these 
sort of sections in WG drafts, it is best for it to be handled at the 
IETF-level and not at the WG-level.

Can you provide your latest proposed section(s) on the list for 
consideration by the WG?  

We also need to continue to hear from others in the working group.

Thanks,

—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 12/28/18, 5:49 AM, "Gurshabad Grover"  wrote:

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 consideratio

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

[John R Levine]

On Wed, 2 Jan 2019, Gould, James wrote:

To remove any concerns related to the inclusion of VSP policy in 
draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof of 
verification and the generated verification code; and MAY store the verified data." 
can be removed.  If there are no objections to the removal of this sentence, it will be 
removed in the next version of the draft.


That's OK with me.  I'm not totally opposed to it but without some hint 
about what an interoperating system would do with the object the token 
points to, I think it's confusing.  As you can see, it confused me.




—

JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

On 1/2/19, 3:56 PM, "regext on behalf of John R Levine"  wrote:

   On Wed, 2 Jan 2019, Adam Roach wrote:
   >>  I don't understand why.  The code is a signed token.  Imagine the 
registry
   >>  goes back to the signer asks about token 123-foo666 and the answer is
   >>  "We're the Ministry, we signed it, of course it's valid.  The details are
   >>  secret."
   >>
   >>  While that would not be my favorite way to work, and I can easily imagine
   >>  other scenarios with auditing and transparency business requirements, why
   >>  wouldn't that interoperate?
   >
   > If we're concerned merely with interoperation, the same is true of most --
   > if not all -- normative keywords used in "Security Considerations" 
sections.
   > Your position might (or might not) be correct, but the logic of "2119
   > language is only used for interoperabilty reasons" simply isn't true.

   I think there's a difference -- in security sections the goal is usually
   to prevent leakage or spoofing or something else that would allow a
   malicious party to interoperate with a victim.  One part of good interop
   is not to interoperate with attackers.  But that's not what's going on
   here.  The signature shows that the token is valid, and unless I'm missing
   something, whatever you might learn from the thing the token represents is
   outside the scope of EPP.

   Regards,
   John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
   Please consider the environment before reading this e-mail. https://jl.ly




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

John,

To remove any concerns related to the inclusion of VSP policy in 
draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof 
of verification and the generated verification code; and MAY store the verified 
data." can be removed.  If there are no objections to the removal of this 
sentence, it will be removed in the next version of the draft.  
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 1/2/19, 3:56 PM, "regext on behalf of John R Levine" 
 wrote:

On Wed, 2 Jan 2019, Adam Roach wrote:
>>  I don't understand why.  The code is a signed token.  Imagine the 
registry
>>  goes back to the signer asks about token 123-foo666 and the answer is
>>  "We're the Ministry, we signed it, of course it's valid.  The details 
are
>>  secret."
>>
>>  While that would not be my favorite way to work, and I can easily 
imagine
>>  other scenarios with auditing and transparency business requirements, 
why
>>  wouldn't that interoperate?
>
> If we're concerned merely with interoperation, the same is true of most 
-- 
> if not all -- normative keywords used in "Security Considerations" 
sections. 
> Your position might (or might not) be correct, but the logic of "2119 
> language is only used for interoperabilty reasons" simply isn't true.

I think there's a difference -- in security sections the goal is usually 
to prevent leakage or spoofing or something else that would allow a 
malicious party to interoperate with a victim.  One part of good interop 
is not to interoperate with attackers.  But that's not what's going on 
here.  The signature shows that the token is valid, and unless I'm missing 
something, whatever you might learn from the thing the token represents is 
outside the scope of EPP.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[John R Levine]

On Wed, 2 Jan 2019, Adam Roach wrote:

 I don't understand why.  The code is a signed token.  Imagine the registry
 goes back to the signer asks about token 123-foo666 and the answer is
 "We're the Ministry, we signed it, of course it's valid.  The details are
 secret."

 While that would not be my favorite way to work, and I can easily imagine
 other scenarios with auditing and transparency business requirements, why
 wouldn't that interoperate?


If we're concerned merely with interoperation, the same is true of most -- 
if not all -- normative keywords used in "Security Considerations" sections. 
Your position might (or might not) be correct, but the logic of "2119 
language is only used for interoperabilty reasons" simply isn't true.


I think there's a difference -- in security sections the goal is usually 
to prevent leakage or spoofing or something else that would allow a 
malicious party to interoperate with a victim.  One part of good interop 
is not to interoperate with attackers.  But that's not what's going on 
here.  The signature shows that the token is valid, and unless I'm missing 
something, whatever you might learn from the thing the token represents is 
outside the scope of EPP.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Adam Roach]

[as an individual]

On 1/2/19 12:10 PM, John R Levine wrote:
The 2119 words MUST and MAY are used to signify requirements; 
although that does imply interoperability as well.  This statement is 
associated with making the verification code functional, since the 
verification code represents a signed and typed verification pointer, 
it must point to something.


I don't understand why.  The code is a signed token.  Imagine the 
registry goes back to the signer asks about token 123-foo666 and the 
answer is "We're the Ministry, we signed it, of course it's valid.  
The details are secret."


While that would not be my favorite way to work, and I can easily 
imagine other scenarios with auditing and transparency business 
requirements, why wouldn't that interoperate?



If we're concerned merely with interoperation, the same is true of most 
-- if not all -- normative keywords used in "Security Considerations" 
sections. Your position might (or might not) be correct, but the logic 
of "2119 language is only used for interoperabilty reasons" simply isn't 
true.


/a

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

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

[John R Levine]

The 2119 words MUST and MAY are used to signify requirements; although 
that does imply interoperability as well.  This statement is associated 
with making the verification code functional, since the verification 
code represents a signed and typed verification pointer, it must point 
to something.


I don't understand why.  The code is a signed token.  Imagine the registry 
goes back to the signer asks about token 123-foo666 and the answer is 
"We're the Ministry, we signed it, of course it's valid.  The details are 
secret."


While that would not be my favorite way to work, and I can easily imagine 
other scenarios with auditing and transparency business requirements, why 
wouldn't that interoperate?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Gould, James]

John,

The 2119 words MUST and MAY are used to signify requirements; although that 
does imply interoperability as well.  This statement is associated with making 
the verification code functional, since the verification code represents a 
signed and typed verification pointer, it must point to something.  The VSP is 
required, by the normative MUST, to store the proof of verification and the 
generated verification code, and can optionally, by the normative MAY, store 
the verified data.  The "; and MAY store the verified data" can be removed, 
since the proof of verification is the only requirement for the verification 
code to be a functional pointer.  

Do you agree that the "; and MAY store the verified data" text should be 
removed?The statement would then read:

"The VSP MUST store the proof of verification and the generated verification 
code."

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 12/28/18, 2:45 PM, "regext on behalf of John Levine" 
 wrote:

In article <41f72627-faf2-1fd4-b356-065b3cb98...@cis-india.org> you write:
>"The VSP MUST store the proof of verification and the generated
>verification code; and MAY store the verified data."

The 2119 words MUST and MAY are about interoperation.

Now that you point it out, this has nothing to do with interoperation
unless compliance somehow affects interop.

I would suggest removing that part, or at least making it
non-normative since business practices are generally way out of scope
for IETF specs.

R's,
John

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


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

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

[Gould, James]

Gurshabad,

For the defined purpose of draft-ietf-regext-verificationcode, the VSP needs to 
be defined as an entity, but the VSP's verification process is not defined and 
is out-of-scope.  The use of examples in an IETF draft does not classify as 
guidance.  The only obligation of the VSP within 
draft-ietf-regext-verificationcode is to generate a technically compliant 
verification code and to store the proof of verification and the generated 
verification code.  There is no concrete definition defined within 
draft-ietf-regext-verificationcode of: 
- the forms of verifications performed by a VSP, 
- the data that must be passed for verification, 
- how the verification data is processed,
- the data sources that are used to perform the verification,
- the interface(s) or protocol(s) used by a VSP, and 
- other policies and technical details of a VSP.  

The majority of your considerations (Privacy and identified paragraphs from the 
HR) is focused on the policies and interfaces / protocols of the VSP that is by 
design out-of-scope from draft-ietf-regext-verificationcode.  

My recommendation is to strictly focus your proposed considerations text on the 
scope of draft-ietf-regext-verificationcode, that includes the definition of 
the verification code (e.g., digitally signed, typed identifier that provides 
proof of verification) and the passing of the verification code between the 
client (registrar) and the server (registry) over EPP. 

> 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]
  
Yes, it is my position that the proposed text included in your proposed 
sections as non-technical and focused on policy elements that the WG is not 
qualified to discuss and come to consensus on.  If you desire to have these 
sort of sections in WG drafts, it is best for it to be handled at the 
IETF-level and not at the WG-level.

Can you provide your latest proposed section(s) on the list for consideration 
by the WG?  

We also need to continue to hear from others in the working group.

Thanks,

—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 12/28/18, 5:49 AM, "Gurshabad Grover"  wrote:

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 person

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

[Niels ten Oever]

Hi all,

I strongly support the inclusion of text in the draft. 

I think the differentiations that are being made here between 'technical' and 
'policy', and 'technical' and 'judicial' here are merely rhetorical. No clear 
definition of the either terms and/or the difference have been offered thus 
far. Thus the argument to not include the text seems unfounded.

Next to that, I have not been able to locate the limitation for the use of MUST 
and MAY, as defined by John Levine, in RFC2119.

Best,

Niels

  

On 1/2/19 12:07 PM, Thomas Corte wrote:
> Hello,
> 
> On 12/26/18 15:32, Gould, James wrote:
> 
>> Do others in the working group believe that either the verification process 
>> of the VSP is in scope based on the current wording of the draft or that a 
>> consideration section can cover something that is outside the defined scope 
>> of the draft?
> 
> No, I agree that it's way out of scope. Gurshabad's proposed additions
> are in my point of view an attempt to address *judicial* issues (ensuring
> people's right to privacy, non-discrimination etc.) by adding wording to
> a *technical* specification. Lawyers and politicians exist to deal with
> such issues; engineers should not be required to waste their time with them.
> 
> Plus, even *if* such wording should end up in the draft, it would be
> utterly pointless. Looking at the various implementations of EPP and EPP
> extensions which are out in the open (especially for country code TLDs),
> it's obvious that even the most basic technical requirements (such as
> strict XML schema compliance) and MUST regulations are often ignored or
> violated by many operators. I'd therefore be surprised if anyone who's
> determined to "abuse" the extension for human rights violations would
> care much about the proposed additions anyway.
> 
> Best regards,
> 
> Thomas
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Thomas Corte]

Hello,

On 12/26/18 15:32, Gould, James wrote:

> Do others in the working group believe that either the verification process 
> of the VSP is in scope based on the current wording of the draft or that a 
> consideration section can cover something that is outside the defined scope 
> of the draft?

No, I agree that it's way out of scope. Gurshabad's proposed additions
are in my point of view an attempt to address *judicial* issues (ensuring
people's right to privacy, non-discrimination etc.) by adding wording to
a *technical* specification. Lawyers and politicians exist to deal with
such issues; engineers should not be required to waste their time with them.

Plus, even *if* such wording should end up in the draft, it would be
utterly pointless. Looking at the various implementations of EPP and EPP
extensions which are out in the open (especially for country code TLDs),
it's obvious that even the most basic technical requirements (such as
strict XML schema compliance) and MUST regulations are often ignored or
violated by many operators. I'd therefore be surprised if anyone who's
determined to "abuse" the extension for human rights violations would
care much about the proposed additions anyway.

Best regards,

Thomas

-- 

 |   |
 | knipp |Knipp  Medien und Kommunikation GmbH
  ---Technologiepark
 Martin-Schmeißer-Weg 9
 44227 Dortmund
 Deutschland

 Dipl.-Informatiker  Tel:+49 231 9703-0
 Thomas CorteFax:+49 231 9703-200
 Stellvertretender LeiterSIP:thomas.co...@knipp.de
 Software-EntwicklungE-Mail: thomas.co...@knipp.de

 Registereintrag:
 Amtsgericht Dortmund, HRB 13728

 Geschäftsführer:
 Dietmar Knipp, Elmar Knipp

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

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

[John Levine]

In article <41f72627-faf2-1fd4-b356-065b3cb98...@cis-india.org> you write:
>"The VSP MUST store the proof of verification and the generated
>verification code; and MAY store the verified data."

The 2119 words MUST and MAY are about interoperation.

Now that you point it out, this has nothing to do with interoperation
unless compliance somehow affects interop.

I would suggest removing that part, or at least making it
non-normative since business practices are generally way out of scope
for IETF specs.

R's,
John

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

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

[Gurshabad Grover]

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

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

[John Levine]

In article  you write:
>Do others in the working group believe that either the verification process of 
>the VSP is in scope
>based on the current wording of the draft or that a consideration section can 
>cover something that
>is outside the defined scope of the draft?

Heck, no.  They have nothing to do with ensuring interoperability, and
nothing I can see to do with any plausible use of this extension.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[Gould, James]

Gurshabad,
 
I first need to be clear that I oppose adding both sections that you've 
provided to draft-ietf-regext-verificationcode.  The sections that you've 
provided are non-technical and are associated with policy elements.  The REGEXT 
working group has dealt with technical aspects of drafts.  I don't believe the 
REGEXT working group is qualified to effectively discuss and come to consensus 
on policy elements.  I recommend that inclusion of these sort of elements be 
brought up to the IETF-level.
 
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.  
 
* Depending on the information shared with the VSP and data sources
already available to it, the extension may also allow the VSP to
discriminate against registrants based on registrants' personal
characteristics, beliefs, or opinions. Even when such restrictions are
not applied, knowledge of the information being shared with the VSP
could create chilling effects on registrants' freedom of expression, and
freedom of association and assembly.
   
* The VSP may be a third party entrusted to carry out sensitive legal
decisions. Due to the lack of mechanisms in this extension that can
facilitate appeal and redressal of a rejection, the registrants' right
to legal transparency and remedy will also be impacted in such a situation. 
  
 
The scope of draft-ietf-regext-verificationcode does not include the 
verification process of the VSP by design.   Any considerations section, 
including the HR or the Privacy Considerations, need to be within the defined 
scope of the draft.
 
Do others in the working group believe that either the verification process of 
the VSP is in scope based on the current wording of the draft or that a 
consideration section can cover something that is outside 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  

On 12/21/18, 5:14 AM, "Gurshabad Grover"  wrote:

On 20/12/18 1:01 AM, Gould, James wrote:
> 
> 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.  
>  

I think the previous thread with Andrew Newton clarifies why the Privacy
Considerations are applicable. Could you be specific as to which HR
consideration is out of scope?

As you have already noted, the role of the VSP is defined and (therefore
presumably) in the scope of the document. Since most HR considerations
relate to the VSP's role, they are also in the scope of
draft-ietf-regext-verificationcode.

Thank you.
Gurshabad



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

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

[Gurshabad Grover]

On 20/12/18 1:01 AM, Gould, James wrote:
> 
> 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.  
>  

I think the previous thread with Andrew Newton clarifies why the Privacy
Considerations are applicable. Could you be specific as to which HR
consideration is out of scope?

As you have already noted, the role of the VSP is defined and (therefore
presumably) in the scope of the document. Since most HR considerations
relate to the VSP's role, they are also in the scope of
draft-ietf-regext-verificationcode.

Thank you.
Gurshabad



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

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
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 12/19/18, 4:01 PM, "regext on behalf of Niels ten Oever" 
 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
> jgo...@verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com  
> 
> On 12/19/18, 5:22 AM, "regext on behalf of Gurshabad Grover" 
 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
   

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

[Niels ten Oever]

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  
> 
> On 12/19/18, 5:22 AM, "regext on behalf of Gurshabad Grover" 
>  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 fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Gould, James]

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  

On 12/19/18, 5:22 AM, "regext on behalf of Gurshabad Grover" 
 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

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

[Adam Roach]

[as an individual]

On 12/19/18 9:40 AM, Niels ten Oever wrote:


On 12/19/18 4:19 PM, Andrew Newton wrote:

On Wed, Dec 19, 2018 at 5:22 AM Gurshabad Grover
 wrote:


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.


I disagree with the MUST. What the registrant is informed of or not is
entirely a policy matter and not up to the IETF. At best, this should
be a lowercase "should".


The distinction between policy and technology seems superficial here. The 
creation of the possibility of using a VSP in EPP can also be seen as a policy 
decision.



No, Andrew is correct here. This is not a place for normative language. 
The guidance seems reasonable, but the formulation is overreaching. I 
would propose: "Clients are encouraged to inform registrants about the 
exact information to be shared with the VSP."


/a

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

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

[Niels ten Oever]

On 12/19/18 6:57 PM, Andrew Newton wrote:
> On Wed, Dec 19, 2018 at 12:26 PM Niels ten Oever
>  wrote:
>>
>>
>> I am not quite sure I understand, are you saying an Internet standard is not 
>> a norm?
> 
> No, it's a technical specification.
> 

Open technical standards are de facto norms. That something is a technical 
specification does not mean it is not a norm and vice versa.

> From an ethical point of view, I am not opposed to privacy or human
> rights considerations in IETF documents. But practically speaking, if
> discussions are to break down into meta-conversations on the
> philosophical differences between what is or is not a specification or
> what is or is not policy, I conclude that such efforts are futile and
> a waste of time.

I think the discussion is very concrete, with a concrete text proposal. 

I agree that discussing the distinction between policies and technical 
specifications is a waste of time because these are overlapping concepts. 

Best,

Niels

> 
> -andy
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Andrew Newton]

On Wed, Dec 19, 2018 at 12:26 PM Niels ten Oever
 wrote:
>
>
> I am not quite sure I understand, are you saying an Internet standard is not 
> a norm?

No, it's a technical specification.

>From an ethical point of view, I am not opposed to privacy or human
rights considerations in IETF documents. But practically speaking, if
discussions are to break down into meta-conversations on the
philosophical differences between what is or is not a specification or
what is or is not policy, I conclude that such efforts are futile and
a waste of time.

-andy

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

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

[Niels ten Oever]

On 12/19/18 4:45 PM, Andrew Newton wrote:
> On Wed, Dec 19, 2018 at 10:38 AM Niels ten Oever
>  wrote:
>>
>>
>> Everything is possible without the IETF: the Internet has open standards. So 
>> IETF is never solely responsible for anything. But IETF is setting a norm 
>> and thus normalizing and enabling this behavior. I think this is made clear 
>> in the text, and even clearer in the new text proposed by Gurshabad.
> 
> Except that is not true. The IETF is not setting a norm. The norm
> already exists. Any abusive authority that can force a registry to
> obey verification codes already has the power to force a registry to
> remove domain names.
> 
> -andy
> 

I am not quite sure I understand, are you saying an Internet standard is not a 
norm?

The verification code normalizes and facilitates the behavior that is 
potentially violating the human and privacy rights of registrants. 

Similar behavior might exists, but not in this way. This status code makes it 
easier and standardizes it, and thus facilitates and enables it. 

Therefore I think it should not be standardized, but if we do, we should at 
least say something about these inherent risks in implementation.

Best,

Niels


-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Andrew Newton]

On Wed, Dec 19, 2018 at 10:38 AM Niels ten Oever
 wrote:
>
>
> Everything is possible without the IETF: the Internet has open standards. So 
> IETF is never solely responsible for anything. But IETF is setting a norm and 
> thus normalizing and enabling this behavior. I think this is made clear in 
> the text, and even clearer in the new text proposed by Gurshabad.

Except that is not true. The IETF is not setting a norm. The norm
already exists. Any abusive authority that can force a registry to
obey verification codes already has the power to force a registry to
remove domain names.

-andy

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

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

[Niels ten Oever]

On 12/19/18 4:19 PM, Andrew Newton wrote:
> On Wed, Dec 19, 2018 at 5:22 AM Gurshabad Grover
>  wrote:
>>
>>
>> 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.
>>
> 
> I disagree with the MUST. What the registrant is informed of or not is
> entirely a policy matter and not up to the IETF. At best, this should
> be a lowercase "should".
> 

The distinction between policy and technology seems superficial here. The 
creation of the possibility of using a VSP in EPP can also be seen as a policy 
decision.

Unless you could provide a clear definition for the distinction of course.

Best,

Niels

> -andy
> 
> ___
> 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 fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Niels ten Oever]

On 12/19/18 4:27 PM, Andrew Newton wrote:
> On Wed, Dec 19, 2018 at 6:47 AM Niels ten Oever
>  wrote:
>>
>> I think the unclarity here is about the nature of causation, and more 
>> specifically about the priority of events. Because the exchange of private 
>> data between a registrar and a VSP on the one hand, and the use of the 
>> verification code on the other hand, is of a necessary deterministic nature, 
>> I do think the considerations are applicable.
> 
> Then the text should say that. As it stands, the current text makes it
> sound like the IETF is enabling some new method for human rights abuse
> that otherwise would not be available to an abusive authority, and
> that is absolutely not true. 

Everything is possible without the IETF: the Internet has open standards. So 
IETF is never solely responsible for anything. But IETF is setting a norm and 
thus normalizing and enabling this behavior. I think this is made clear in the 
text, and even clearer in the new text proposed by Gurshabad. 

Best,

Niels

> In fact, the text should be clearer on
> the point that this mechanism does not give an abusive authority any
> more leverage to violate human rights than they already posses.



> 
> -andy
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Andrew Newton]

On Wed, Dec 19, 2018 at 6:47 AM Niels ten Oever
 wrote:
>
> I think the unclarity here is about the nature of causation, and more 
> specifically about the priority of events. Because the exchange of private 
> data between a registrar and a VSP on the one hand, and the use of the 
> verification code on the other hand, is of a necessary deterministic nature, 
> I do think the considerations are applicable.

Then the text should say that. As it stands, the current text makes it
sound like the IETF is enabling some new method for human rights abuse
that otherwise would not be available to an abusive authority, and
that is absolutely not true. In fact, the text should be clearer on
the point that this mechanism does not give an abusive authority any
more leverage to violate human rights than they already posses.

-andy

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

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

[Andrew Newton]

On Wed, Dec 19, 2018 at 5:22 AM Gurshabad Grover
 wrote:
>
>
> 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.
>

I disagree with the MUST. What the registrant is informed of or not is
entirely a policy matter and not up to the IETF. At best, this should
be a lowercase "should".

-andy

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

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

[Niels ten Oever]

I think the unclarity here is about the nature of causation, and more 
specifically about the priority of events. Because the exchange of private data 
between a registrar and a VSP on the one hand, and the use of the verification 
code on the other hand, is of a necessary deterministic nature, I do think the 
considerations are applicable.  

(more about the nature of causation in the chapter Causation, in: "Gerring, 
John. 2011, 'Social Science Methodology: A Unified Framework', Cambridge 
University Press, UK" - I can share the chapter with you if you contact me 
off-list)

Best,

Niels

On 12/18/18 10:59 PM, Andrew Newton wrote:
> On Tue, Dec 18, 2018 at 4:20 PM Gould, James  wrote:
>>
>> Yes, draft-ietf-regext-verificationcode defines the structure of the 
>> verification code that is passed between the EPP client (registrar) to the 
>> EPP server (registry) to show that the verification occurred before the EPP 
>> transaction.
>>
> 
> Thanks for the _verification_, James. :)
> 
> I think this means the premise for the privacy considerations is
> nonexistent, and therefore the text given is not applicable.
> 
> -andy
> 
> ___
> 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 fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

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

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

[Gurshabad Grover]

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.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Andrew Newton]

On Tue, Dec 18, 2018 at 4:20 PM Gould, James  wrote:
>
> Yes, draft-ietf-regext-verificationcode defines the structure of the 
> verification code that is passed between the EPP client (registrar) to the 
> EPP server (registry) to show that the verification occurred before the EPP 
> transaction.
>

Thanks for the _verification_, James. :)

I think this means the premise for the privacy considerations is
nonexistent, and therefore the text given is not applicable.

-andy

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

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

[Gould, James]

Andy,

>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.

Yes, draft-ietf-regext-verificationcode defines the structure of the 
verification code that is passed between the EPP client (registrar) to the EPP 
server (registry) to show that the verification occurred before the EPP 
transaction.   
 
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  

On 12/18/18, 4:05 PM, "regext on behalf of Andrew Newton" 
 wrote:

I am admittedly not as versed on EPP as others in the wg, but is this
true? From your privacy text:

"This document describes an extension designed to share the data of (or
generated by) a registrant with the Verification Service Provider (VSP),
which is a third party."

The intro section of the draft states:

" The Verification Service Provider (VSP) is a certified party to
   verify that data is in compliance with the policies of a locality.  A
   locality MAY require the client to have data verified in accordance
   with local regulations or laws utilizing data sources not available
   to the server.  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.  The data verified, and the objects and operations that
   require the verification code to be passed to the server, is up to
   the policies of the locality.  The verification code represents a
   marker that the verification was completed."

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.

-andy

On Fri, Dec 14, 2018 at 10:37 AM Gurshabad Grover
 wrote:
>
> Hi,
>
> Thank you for your comments on the proposed Human Rights Considerations
> section. Please find the draft text below (with an accompanying Privacy
> Considerations section which will also be useful); hope it is a good
> starting point for consensus.
>
> Privacy Considerations
> --
> This document describes an extension designed to share the data of (or
> generated by) a registrant with the Verification Service Provider (VSP),
> which is a third party. The scope of information shared with and stored
> by the VSP is dependent on the policies and regulations of the locality
> and the VSP. The extension has no built-in mechanisms for registrants to
> express preference for what information should shared with the VSP. In
> certain cases, this will lead to the exposure of registrants' sensitive
> personal information directly linked to the identities of the
> individual, such as contained in the contact mapping object, without
> user control. This may impact users' expectation of confidentiality of
> their information. This personal information may be further correlated
> with other data sources available to the VSP.
>
> If a service provider seeks to implement or offer this extension, it
> MUST inform the registrant about about the exact information to be
> shared with the VSP.
>
> Human Rights Considerations
> ---
> The use of this extension may have negative implications for the human
> rights of potential or actual registrants, depending on the
> implementation and policies used by the registrar and the VSP.
>
> * In particular, the extension might be employed as, or contribute to, a
> domain name filtering and censorship mechanism. This can negatively
> impact registrants' freedom of expression, and may further impede their
> freedom of assembly and association, and social and economic rights.
>
> * Depending on the information shared with the VSP and data sources
> already available to it, the extension may also allow the VSP to
> discriminate against registrants based on registrants' personal
> characteristics, beliefs, or opinions. Even when such restrictions are
> not applied, knowledge of the information being shared with the VSP
> could create chilling effects on registrants' freedom of expression, and
> freedom of association and assembly.
>
> * The VSP may be a third party entrusted to carry out sensitive legal
> decisions. Due to the lack of mechanisms in this extension that can
> facilitate appeal and redressal of a rejection, the registrants' right
> to legal transparency and remedy will also be impacted in such a 
situation.

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

[Andrew Newton]

I am admittedly not as versed on EPP as others in the wg, but is this
true? From your privacy text:

"This document describes an extension designed to share the data of (or
generated by) a registrant with the Verification Service Provider (VSP),
which is a third party."

The intro section of the draft states:

" The Verification Service Provider (VSP) is a certified party to
   verify that data is in compliance with the policies of a locality.  A
   locality MAY require the client to have data verified in accordance
   with local regulations or laws utilizing data sources not available
   to the server.  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.  The data verified, and the objects and operations that
   require the verification code to be passed to the server, is up to
   the policies of the locality.  The verification code represents a
   marker that the verification was completed."

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.

-andy

On Fri, Dec 14, 2018 at 10:37 AM Gurshabad Grover
 wrote:
>
> Hi,
>
> Thank you for your comments on the proposed Human Rights Considerations
> section. Please find the draft text below (with an accompanying Privacy
> Considerations section which will also be useful); hope it is a good
> starting point for consensus.
>
> Privacy Considerations
> --
> This document describes an extension designed to share the data of (or
> generated by) a registrant with the Verification Service Provider (VSP),
> which is a third party. The scope of information shared with and stored
> by the VSP is dependent on the policies and regulations of the locality
> and the VSP. The extension has no built-in mechanisms for registrants to
> express preference for what information should shared with the VSP. In
> certain cases, this will lead to the exposure of registrants' sensitive
> personal information directly linked to the identities of the
> individual, such as contained in the contact mapping object, without
> user control. This may impact users' expectation of confidentiality of
> their information. This personal information may be further correlated
> with other data sources available to the VSP.
>
> If a service provider seeks to implement or offer this extension, it
> MUST inform the registrant about about the exact information to be
> shared with the VSP.
>
> Human Rights Considerations
> ---
> The use of this extension may have negative implications for the human
> rights of potential or actual registrants, depending on the
> implementation and policies used by the registrar and the VSP.
>
> * In particular, the extension might be employed as, or contribute to, a
> domain name filtering and censorship mechanism. This can negatively
> impact registrants' freedom of expression, and may further impede their
> freedom of assembly and association, and social and economic rights.
>
> * Depending on the information shared with the VSP and data sources
> already available to it, the extension may also allow the VSP to
> discriminate against registrants based on registrants' personal
> characteristics, beliefs, or opinions. Even when such restrictions are
> not applied, knowledge of the information being shared with the VSP
> could create chilling effects on registrants' freedom of expression, and
> freedom of association and assembly.
>
> * The VSP may be a third party entrusted to carry out sensitive legal
> decisions. Due to the lack of mechanisms in this extension that can
> facilitate appeal and redressal of a rejection, the registrants' right
> to legal transparency and remedy will also be impacted in such a situation.
>
> Implementers should consider the potential human rights impacts of
> offering and normalising this extension when advertising support for it
> in EPP.
>
> /.
>
> Thanks to Mallory, Niels and Adam for their feedback off-list. The text
> above may not reflect their opinion.
>
> Thank you.
> Gurshabad
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

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

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

[Adam Roach]

[as an individual]

While I might quibble about some of the specifics of the proposed text, 
I disagree with the characterization of "unhelpful." Both proposed 
sections, in fact, make an attempt to be actionable.


In terms of tendentiousness, one could easily say the same of pretty 
much any "Security Considerations" or "Privacy Considerations" section 
we've ever published. But that's okay: a bias towards security and 
privacy are characteristics we've chosen to take on in our documents.


The same applies to the assertion regarding "a distraction from the WG's 
purpose": most protocols would "work" from a technical perspective 
without guidance regarding security and privacy; and so one could 
equally assert that such sections are also a "distraction" from the core 
work of those protocols. A key reason people come to the IETF to do work 
is the fact that it is a multi-stakeholder environment, designed to take 
these kinds of secondary effects into account.


And so I would encourage people to engage on the substance of the 
proposal rather than dismissing it out of hand.


/a

On 12/14/18 12:26 PM, John Levine wrote:

Having reviewed the proposed text, I would encourage the WG to ignore it.

It is unhelpful, tendentious and a distraction from the WG's purpose.
In the interest of not wasting any more time, this is my last message
on the topic.

R's,
John


In article <5f7d0b3e-c844-1700-c369-90bb41e82...@cis-india.org> you write:

Thank you for your comments on the proposed Human Rights Considerations
section. Please find the draft text below (with an accompanying Privacy
Considerations section which will also be useful); hope it is a good
starting point for consensus. ...

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



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

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

[John Levine]

Having reviewed the proposed text, I would encourage the WG to ignore it.

It is unhelpful, tendentious and a distraction from the WG's purpose.
In the interest of not wasting any more time, this is my last message
on the topic.

R's,
John


In article <5f7d0b3e-c844-1700-c369-90bb41e82...@cis-india.org> you write:
>Thank you for your comments on the proposed Human Rights Considerations
>section. Please find the draft text below (with an accompanying Privacy
>Considerations section which will also be useful); hope it is a good
>starting point for consensus. ...

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

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

[Gurshabad Grover]

Hi,

Thank you for your comments on the proposed Human Rights Considerations
section. Please find the draft text below (with an accompanying Privacy
Considerations section which will also be useful); hope it is a good
starting point for consensus.

Privacy Considerations
--
This document describes an extension designed to share the data of (or
generated by) a registrant with the Verification Service Provider (VSP),
which is a third party. The scope of information shared with and stored
by the VSP is dependent on the policies and regulations of the locality
and the VSP. The extension has no built-in mechanisms for registrants to
express preference for what information should shared with the VSP. In
certain cases, this will lead to the exposure of registrants' sensitive
personal information directly linked to the identities of the
individual, such as contained in the contact mapping object, without
user control. This may impact users' expectation of confidentiality of
their information. This personal information may be further correlated
with other data sources available to the VSP.

If a service provider seeks to implement or offer this extension, it
MUST inform the registrant about about the exact information to be
shared with the VSP.

Human Rights Considerations
---
The use of this extension may have negative implications for the human
rights of potential or actual registrants, depending on the
implementation and policies used by the registrar and the VSP.

* In particular, the extension might be employed as, or contribute to, a
domain name filtering and censorship mechanism. This can negatively
impact registrants' freedom of expression, and may further impede their
freedom of assembly and association, and social and economic rights.

* Depending on the information shared with the VSP and data sources
already available to it, the extension may also allow the VSP to
discriminate against registrants based on registrants' personal
characteristics, beliefs, or opinions. Even when such restrictions are
not applied, knowledge of the information being shared with the VSP
could create chilling effects on registrants' freedom of expression, and
freedom of association and assembly.

* The VSP may be a third party entrusted to carry out sensitive legal
decisions. Due to the lack of mechanisms in this extension that can
facilitate appeal and redressal of a rejection, the registrants' right
to legal transparency and remedy will also be impacted in such a situation.

Implementers should consider the potential human rights impacts of
offering and normalising this extension when advertising support for it
in EPP.

/.

Thanks to Mallory, Niels and Adam for their feedback off-list. The text
above may not reflect their opinion.

Thank you.
Gurshabad



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext