ICANN/GNSO GNSO Email List Archives

[dow3tf]


<<< Chronological Index >>>    <<< Thread Index >>>

[dow3tf] Preliminary ideas for exploring WHOIS accuracy - Sarah Deutsch

  • To: "3DOW3tf" <dow3tf@xxxxxxxxxxxxxx>
  • Subject: [dow3tf] Preliminary ideas for exploring WHOIS accuracy - Sarah Deutsch
  • From: "GNSO SECRETARIAT" <gnso.secretariat@xxxxxxxxxxxxxx>
  • Date: Wed, 7 Jan 2004 17:39:35 +0100
  • Importance: Normal
  • Reply-to: <gnso.secretariat@xxxxxxxxxxxxxx>
  • Sender: owner-dow3tf@xxxxxxxxxxxxxx

Posted on behalf of Brain Darville Chair, WHOIS tf 3.

>>> <sarah.b.deutsch@xxxxxxxxxxx> 12/17/03 05:53PM >>>


Here it is again -- would you mind posting this for me -- I'm not sure why
it didn't work.

Sarah

***********************************************

All,

As promised, here are some preliminary ideas for exploring WHOIS accuracy
best practices models.  As you can see from both the length of this list
and the scope of material to be covered, as mentioned on today's call, our
WG clearly needs additional staffing help from ICANN.  The list below, is
only the beginning and I would hope our entire task force could use this a
first step in brainstorming and adding more thoughts to the list.


Sarah

1.  Explore the IETF standards.  One new IETF Working Group has a
requirement that  for ISPs, "initial contact may involve the consumer and
the provider mutually validating the other's identity."

Description of Working Group:
There are many cases where a service consumer needs to contact a
service provider to get credentials that the consumer can use when
accessing the service; part of this initial contact may involve
the consumer and the provider mutually validating the other's
identity.
This working group will look at some of the cases where cryptography
is used to provide authentication.

When doing enrollment of a service consumer against a service
provider, three pieces of information need to be provided or created in
order to support authentication of the service consumer to the service
provider (and visa versa) and to allow for additional security services
to be provided any information exchanged. These pieces of data are:

1. An identifier, within a namespace controlled by the service
  provider, for the service consumer.
2. Keying information to be used for identity confirmation.
3. A set of service consumer permissions. These permissions
  describe to the provider the services that the consumer
  wants to access, and they describe to the consumer what
  services offered by the provider will be accessable.

Each of these data items could be created by either the consumer or
provider at any point during the enrollment process.

This group will create a model to be used in describing enrollment
procedures and create a document for a framework how this is to be
done. The group will then produce three documents profiling the use of
the framework for the following types of keying material:

      1. A shared secret key.
      2. A bare asymmetric key.
      3. A bound asymmetric key (such as an X.509 certificate).

As part of the validation of the framework, the group will examine how
other real world enrollment procedures could be profiled. For example,
credit card information might be part of the input to the enrollment
process.

2. ENUM Verification Process.  Attached is the "ENUM Forum Specifications
for US Implementation of ENUM."  Section 12, Authentication and
Authorization, is the relevant section.

(See attached file: Enum Verification.pdf)

3.  There is some excellent information for verification of customer
identity by exploring practices of e-commerce providers, financial
companies and especially the online auction sites.  Auction sites are a
good market analogy because like domain name registrars, the entry costs
for participating is low and auctions, like domain name registrations,
occur on a global scale.  In both markets, fraudsters can be attracted
because of the low cost, global nature and impression that there are no
legal consequences to fraud.    Auction sites have tools to stop fraud
before it happens, including requiring a credit card when registering and
requiring a certain code be entered along with the card number and
expiration date, which both confirms identity and protects against the use
of stolen cards.
See Bidder Beware: Towards a Fraud-Free Marketplace - Best Practices for
the Online Auction Industry Joint Report, Washington Attorney General's
Office and the Shidler Center for Law, Commerce and Technology at the Univ.
of Washington Law School (2001, 2002)
http://www.atg.wa.gov/consumer/auctions/home.htm

See also: Visa Corporate on U-Commerce (Universal Commerce)
http://corporate.visa.com/av/ucomm/main.shtml

Ebay User Agreement
1995-2003
http://pages.ebay.com/help/community/png-user.html


4. Ironically, Verisign is apparently an expert in this area, at least when
it comes to authentication of data.   Some helpful advice can come from
Verisign itself in its other operations.  Preventing Payment Fraud on
Enterprise Web Sites
VeriSign, Inc. (white paper, 2003)
http://www.cio.com/sponsors/100903_17-WP-Fraud.pdf


5. Best practices also come from the consumer and educational sector.  See
Best practices for preventing fraud losses and protecting customers from
identity theft
Experian (white paper, 2003)
http://www.informativeresearch.com/PDFLibrary/White_Paper_Best_Practices.pdf

Identifiers, Authentication and Directories: Best Practices for Higher
Education
Internet2 Middleware Initiative report (May 2000)
http://middleware.internet2.edu/internet2-mi-best-practices-00.html

International Consumer Protection and Enforcement Network
(sweeps internet for fraudulent schemes; for electronic fraud complaints,
visit subsidiary econsumer.gov)
http://www.imsnricc.org/


6.  The UN has at least one agency dedicated to collecting and
standardizing business and geographic information to faciliate
international trade.  United Nations Centre for Trade Facilitation and
Electronic Business
http://www.unece.org/cefact/

7.  Finally, I'd suggest a quick look at the USA PATRIOT Act (Public Law
107-56, which has a section requiring improved identity authentication
measures for financial institutions (section 326).  The section is
mentioned throughout the web, and the text can be found on THOMAS (
http://thomas.loc.gov)





Sarah B. Deutsch
Vice President & Associate General Counsel
Verizon Communications
Phone: 703-351-3044
Fax:      703-351-3670
sarah.b.deutsch@xxxxxxxxxxx





                      "GNSO SECRETARIAT"
                      <gnso.secretariat@gnso        To:       3DOW3tf
<dow3tf@xxxxxxxxxxxxxx>
                      .icann.org>                   cc:
                      Sent by:                      Subject:  [dow3tf]
Inaccurate Whois data studies
                      owner-dow3tf@xxxxxxxxx
                      n.org


                      12/17/2003 10:05 AM
                      Please respond to
                      gnso.secretariat






Posted on behalf of Brain Darvile, task force 3 chair

I paste below some links to the various studies done by Ben Edelman, which
document the scale of the problem of inaccurate Whois data, and which also
contain some other valuable data which may be relevant to the Task Force's
work.

1. Survey of Domain Name Registration Services- Initial Results, available
at http://cyber.law.harvard.edu/people/edelman/registrarsurvey/

2. Large Scale Intentional Invalid Whois Data, available at
http://cyber.law.harvard.edu/people/edelman/invalid-whois/

3. Large-Scale Registration of Domains with Typographical Errors, available
at  http://cyber.law.harvard.edu/people/edelman/typo-domains/

4. Compliance with UDRP Decisions: A Case Study of Joker.com, available at
http://cyber.law.harvard.edu/people/edelman/udrp-compliance/.

Thank you.

Brian Darville
Oblon, Spivak
(703) 412-6426
bdarville@xxxxxxxxx

GNSO Secretariat







Sarah B. Deutsch
Vice President & Associate General Counsel
Verizon Communications
Phone: 703-351-3044
Fax:      703-351-3670
sarah.b.deutsch@xxxxxxxxxxx





                      "Brian Darville"
                      <BDARVILLE@oblon.        To:       Sarah B.
Deutsch/EMPL/VA/Verizon@VZNotes
                      com>                     cc:       tclark@xxxxxxx
                                               Subject:  Re: [dow3tf]
Proposed schedule for work on Whois TF 3:
                      12/17/2003 05:06
                      PM






Sarah:

I have copied Terry Clark, an IPC alternate, so that when you resend your
list, he will receive it directly.

Brian

>>> <sarah.b.deutsch@xxxxxxxxxxx> 12/17/03 04:53PM >>>

Did you see my email with the long list of suggestions?  I didn't see it
posted to the group and am not sure it went through.

Sarah


Sarah B. Deutsch
Vice President & Associate General Counsel
Verizon Communications
Phone: 703-351-3044
Fax:      703-351-3670
sarah.b.deutsch@xxxxxxxxxxx





                      "Brian Darville"
                      <BDARVILLE@oblon.        To:
                      dow3tf@xxxxxxxxxxxxxx,
                      gnso.secretariat@xxxxxxxxxxxxxx
                      com>                     cc:
                      Sent by:                 Subject:  Re: [dow3tf]
                      Proposed schedule for work on Whois TF 3:
                      owner-dow3tf@gnso
                      .icann.org


                      12/17/2003 04:46
                      PM






Barbara, Glen and All others:

I would suggest a slightly revised schedule for TF3:

December 24, 2003 ?  Dissemination by ICANN of all WHOIS Workshop materials
related to Task Force 3's milestones and tasks;

December 31, 2003 ? Prepare  list of contacts for data verification
practices

December 31, 2003 ? Prepare draft of questions for contacts

December 31, 2003 ? ICANN Staff to provide (available) data verification
data and protocols from ccTLDs

December 31, 2003 ? Prepare questions for Registrars regarding current
practices

January 5, 2003 ? Send questions to Registrars

January 5, 2003 ? Finalize list of contacts for data verification practices

January 5, 2003 ? Finalize questions for contacts and begin survey

January 12, 2003 ? Analyze responses from Registrars

January 26, 2003 ? Conclude survey of contacts

February 2, 2003 ? Prepare interim report on survey of Registrars and
outside sources

February 23, 2003 ? Constituency statements due

March 16, 2003 ? Prepare Preliminary Report including constituency
statements and policy recommendations

March 17, 2003 ? Open public comment period for 20 days

April 6, 2003 ? Public Comment Period Closes

April 20, 2003 ? Prepare Final report for GNSO Council

Regards,

Brian Darville
Chair, Task Force 3

>>> "GNSO SECRETARIAT" <gnso.secretariat@xxxxxxxxxxxxxx> 12/17/03 02:39PM
>>>
[To:dow3tf[at]gnso.icann.org]

Please find the Staff Manager's proposed schedule for work on Whois TF 3:

Prepare  list of contacts for data verification practices (due 31 Dec)
Prepare draft of questions for contacts (due 31 Dec)
Prepare questions for Registrars regarding current practices (due 31 Dec)

Send questions to Registrars (begin 7 Jan)

Finalize list of contacts for data verification practices (due 7 Jan)
Finalize questions for contacts and begin survey (due 7 Jan)

Analyze responses from Registrars (begin 14 Jan)

Conclude survey of contacts (due 30 Jan)

Prepare interim report on survey of Registrars and outside sources (due 6
Feb)

Constituency statements (due 28 Feb)

Prepare Preliminary Report including constituency statements and policy
recommendations (23 March)

Open public comment period for 20 days (concludes 12 Apr)

Prepare Final report for GNSO Council (due 30 Apr)


GNSO Secretariat






<<< Chronological Index >>>    <<< Thread Index >>>