Subject: Re: [provreg] contact:disclose clarifications / best practices

From: Keith Gaughan <[email-masked]>
Date: Wed, 23 Jan 2013 12:20:49 +0000

On Wed, Jan 23, 2013 at 11:26:31AM +0100, Bernhard Reutner-Fischer wrote:

> I have questions about contact:disclose.
> 
> 1) How do i correctly handle non-disclosure of all fields of a contact:info
> command from a third party via EPP, especially name, email, addr (city, cc
> therein) etc?

Are you talking about a <contact:info> request being made against a contact by a
registrar other than the owning registrar, and is a <authInfo> element being
provided?

> 2) what dummy values should i use for the required fields, what is best/common
> practice?

If you omit them, the default registry policy is applied [SS2.9]:

   A server operator announces a default disclosure policy when establishing a
   session with a client. [...] When an object is created or updated, the client
   can specify contact attributes that require exceptional disclosure handling
   using an OPTIONAL <contact:disclose> element.

[SS2.9] http://tools.ietf.org/html/rfc5733#section-2.9

Thus, a good default is to comit the <contact:disclose> block entirely unless
there are specific fields you wish not to be disclosed.

> 3) is it ok to disclose the contact:disclose itself to third-parties?
> I guess it is, also to alleviate determining what fields contain real
> data instead of workaround fill junk?

I can't see any harm in doing so. It's not disallowed. Again, we need to know if
this command is being issued with or without a <contact:authInfo> element.

> Long story:
> Ideally i would have expected to be able to return:
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <contact:infData xmlns="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
>         <contact:id>dnd018360624626</contact:id>
>         <contact:roid>C0000000704-BOX</contact:roid>
>         <contact:status s="ok"/>
>         <contact:postalInfo type="int">
>           <contact:addr/>
>         </contact:postalInfo>
>         <contact:clID>primary</contact:clID>
>         <contact:crID>primary</contact:crID>
>         <contact:crDate>2013-01-22T18:50:12.160307Z</contact:crDate>
>         <contact:disclose flag="0">
>           <contact:name type="int"/>
>           <contact:org type="int"/>
>           <contact:addr type="int"/>
>           <contact:voice/>
>           <contact:fax/>
>           <contact:email/>
>         </contact:disclose>
>       </contact:infData>
>     </resData>
>     <trID>
>       <clTRID>8DE21C7A-64C4-11E2-BE5E-5148DCA3D1ED</clTRID>
>       <svTRID>20130122195013136028C3-secondary-box</svTRID>
>     </trID>
>   </response>
> </epp>
> 
> But that complains about
> Element '{urn:ietf:params:xml:ns:contact-1.0}clID': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:contact-1.0}voice, {urn:ietf:params:xml:ns:contact-1.0}fax, {urn:ietf:params:xml:ns:contact-1.0}email
> 
> The "best" i can come up with would be something like
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>   <response>
>     <result code="1000">
>       <msg>Command completed successfully</msg>
>     </result>
>     <resData>
>       <contact:infData xmlns="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
>         <contact:id>ost005598875483</contact:id>
>         <contact:roid>C0000000724-BOX</contact:roid>
>         <contact:status s="ok"/>
>         <contact:postalInfo type="int">
>           <contact:name>n/a</contact:name>
>           <contact:addr>
>             <contact:city>n/a</contact:city>
>             <contact:cc>n/</contact:cc>
>           </contact:addr>
>         </contact:postalInfo>
>         <contact:email>n/a</contact:email>
>         <contact:clID>primary</contact:clID>
>         <contact:crID>primary</contact:crID>
>         <contact:crDate>2013-01-23T10:00:09.394220Z</contact:crDate>
>         <contact:disclose flag="0">
>           <contact:name type="int"/>
>           <contact:org type="int"/>
>           <contact:addr type="int"/>
>           <contact:voice/>
>           <contact:fax/>
>           <contact:email/>
>         </contact:disclose>
>       </contact:infData>
>     </resData>
>     <trID>
>       <clTRID>ABE135BA-6543-11E2-A06D-7716DCA3D1ED</clTRID>
>       <svTRID>20130123110009545038BB-secondary-box</svTRID>
>     </trID>
>   </response>
> </epp>

I assume the it's a client parser that's giving these errors. If a contact is
being queried with an <authInfo> block, I don't think that disclosure flags
actually apply: if you've got a domain's authorisation code, that implies full
access to linked objects for the purpose of issuing <info> commands.

While this is an assumption on my part, there's good reason for it: transfer.
Say you have the email field set for nondisclosure and somebody was transferring
the domain away from you. The gaining registrar needs to be able to get at the
email so that they can contact the registrant for confirmation, so if the the
email field was set for nondisclosure, they wouldn't be able to deal with the
transfer.

> i.e. fill in name, city, email with an arbitrary token (which one?!)
> and fill in cc with an arbitrary, invalid ccType.

I think the disclosure fields deal more with the likes of what's published in
WHOIS and the likes.

-- 
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 23 Jan 2013 12:28:13 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Keith Gaughan
> Sent: Wednesday, January 23, 2013 7:21 AM
> To: Bernhard Reutner-Fischer
> Cc: [email-masked]
> Subject: Re: [provreg] contact:disclose clarifications / best practices
> 

[snip]

> I think the disclosure fields deal more with the likes of what's
> published in WHOIS and the likes.

Yes, that use case certainly applies. I've always thought of it as an indication of registrant disclosure preference in the context of registry operator policy. There is thus no single answer to what gets returned because privacy policies will vary from operator to operator.

Scott

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 23 Jan 2013 13:57:57 +0100

> this command is being issued with or without a <contact:authInfo> element.

Ideally, a third-party person should not be able to distinguish between a field 
that is not present and a field that is not disclosed. But this is impossible 
for fields which are considered mandatory by the protocol.

Regards,

Klaus

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Wed, 23 Jan 2013 15:21:48 +0100

> Yes, that use case certainly applies. I've always thought of it as an indication of registrant disclosure preference in the context of registry operator policy. There is thus no single answer to wh…

So you consider any registrar that is not sponsor of that contact to
not be third party, is that right?
In other words: The disclose flag is completely ignored for every
contact:info command from any registrar. It is solely used to
determine if the affected contact-data is handed out to entities
outside of the registry, like public whois-service.

thanks,

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Wed, 23 Jan 2013 15:28:28 +0100

On 23 January 2013 13:57, Klaus Malorny <[email-masked]> wrote:

> Ideally, a third-party person should not be able to distinguish between a
> field that is not present and a field that is not disclosed. But this is
> impossible for fields which are considered mandatory by the protocol.

exactly.
Iff you regard all non-sponsoring registrars of a contact as "third
party" you would have to fill in dummy data in those fields that are
mandatory in the protocol (name, addr/cc, addr/city, email).

Scotts reply seems to indicate that this is not the case, though; in
this case one can always hand out all contact-data to everybody via
EPP and as such the issue is moot.

thanks,

---

From: Keith Gaughan <[email-masked]>
Date: Wed, 23 Jan 2013 14:34:41 +0000

On Wed, Jan 23, 2013 at 03:21:48PM +0100, Bernhard Reutner-Fischer wrote:

> >> I think the disclosure fields deal more with the likes of what's published
> >> in WHOIS and the likes.
> >
> > Yes, that use case certainly applies. I've always thought of it as an
> > indication of registrant disclosure preference in the context of registry
> > operator policy. There is thus no single answer to what gets returned
> > because privacy policies will vary from operator to operator.
> 
> So you consider any registrar that is not sponsor of that contact to not be
> third party, is that right?

If they have the authorisation code for a linked domain, they implicitly have
authorisation for querying the contact in question, so while they might be a
third party, they're a third party who's authorised to access the information in
question.

> outside of the registry, like public whois-service.

Lets say that the registry allowed <contact:info> for any contact object,
regardless of whether they owned it or not. If it was queried by a registrar who
didn't own it without the authorisation code or the authorisation code of a
linked object, the disclosure policy would apply.

Registrars need to get this periodic raised access to deal with transfers.

K.

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Wed, 23 Jan 2013 16:06:31 +0100

> registrar other than the owning registrar, and is a <authInfo> element being

In my example i do not have an authinfo set in the contact, no.

> there are specific fields you wish not to be disclosed.

right, but that was not my question.
I was assuming that a contact:info sent in from a non-sponsoring
registrar for a contact that wants not to disclose it's name, email,
addr is considered to be from a third party so i would have had to
omit those affected fields from the reponse. Since the schema neither
allows to omit e.g. the email nor to have it empty, i would have had
to fill in some dummy data (see "n/a" in the second response in my
initial mail).

> access to linked objects for the purpose of issuing <info> commands.

yes, agree.

> I think the disclosure fields deal more with the likes of what's published in

That is one way to see it, agree.

thanks,

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 23 Jan 2013 15:38:06 +0000

> Sent: Wednesday, January 23, 2013 9:35 AM
> > > Yes, that use case certainly applies. I've always thought of it as
> > > an indication of registrant disclosure preference in the context of
> > > registry operator policy. There is thus no single answer to what
> > > gets returned because privacy policies will vary from operator to
> operator.
> >
> If they have the authorisation code for a linked domain, they
> implicitly have authorisation for querying the contact in question, so
> while they might be a third party, they're a third party who's
> authorised to access the information in question.
> 
> Lets say that the registry allowed <contact:info> for any contact
> object, regardless of whether they owned it or not. If it was queried
> by a registrar who didn't own it without the authorisation code or the
> authorisation code of a linked object, the disclosure policy would
> apply.
> 

Right. This is a different use case. The registrant makes an informed decision to provide the authInfo to a new registrar so that they can act as their agent to implement a transfer.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 23 Jan 2013 15:45:47 +0000

> Behalf Of Bernhard Reutner-Fischer
> Sent: Wednesday, January 23, 2013 10:07 AM
> To: Keith Gaughan
> Cc: [email-masked]
> >> 1) How do i correctly handle non-disclosure of all fields of a
> >> contact:info command from a third party via EPP, especially name,
> >> email, addr (city, cc
> >> therein) etc?
> >
> > Are you talking about a <contact:info> request being made against a
> > contact by a registrar other than the owning registrar, and is a
> > <authInfo> element being provided?
> 
> >> 2) what dummy values should i use for the required fields, what is
> >> best/common practice?
> >
> > Thus, a good default is to comit the <contact:disclose> block
> entirely
> > unless there are specific fields you wish not to be disclosed.
> 
> addr is considered to be from a third party so i would have had to omit
> those affected fields from the reponse. Since the schema neither allows
> to omit e.g. the email nor to have it empty, i would have had to fill
> in some dummy data (see "n/a" in the second response in my initial
> mail).

If the client lacks the appropriate privileges to view the information you can return a 2201 authorization error in response to the query.

Scott

---

From: Keith Gaughan <[email-masked]>
Date: Wed, 23 Jan 2013 15:54:47 +0000

> In my example i do not have an authinfo set in the contact, no.

Ok, the clarification that it's about a <contact:info> request issued without an
<authInfo> element clears things up a lot.

> right, but that was not my question.

Thats because I wasn't entirely clear on whether your were talking about its use
in <contact:create>/<contact:update> or <contact:info>. The above cleared it up.

Behaviour on this varies from registry to registry. Some omit the elements
entirely and assume that clients are not validating their responses against the
EPP schemata. Others provide empty elements (such as '<contact:voice/>'). Most
simply claim that the client has no authorisation to perform the operation and
issue a 2201 response (though the actual response code used can vary). From the
point of view of a registrar, I can say that I prefer this last option.

K.