Subject: A new URN namespace registration draft

From: Michael Mealling <[email-masked]>
Date: Thu, 18 May 2000 13:53:19 -0400

(Administrivia discussions on hold. Now for some real work for a change.)

Hi folx,
  I just submitted an Internet-Draft to the repository for requesting
a new URN NamespaceID called "PIN" which stands for "Personal Internet Name".
Since the [email-masked] list is only for approving the mechanics
of the registration mechanism it seemed appropriate that any discussions
of the actual draft should happen here. I've included the draft below.
It will be Informational only...

Network Working Group                                      M.M. Mealling
Internet-Draft                                   Network Solutions, Inc.
Expires: September 30, 2000                                   April 2000

  The Network Solutions Personal Internet Name (PIN): A URN Namespace
                      for People and Organizations
                     draft-mealling-pin-urn-00.txt

Status of this Memo

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026, and the author does not provide the IETF
   with any rights other than to publish as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 30, 2000.

Abstract

   This document describes a URN namespace that is engineered by
   Network Solutions, Inc for naming people and organizations.

1. Introduction

   In many cases, Network Solutions' directory applications require
   some unique and persistent way to talk about an individual or
   organization. For example, white pages services need to determine if
   one user is distinct from another even if some of the data happens
   to be the same. Also, e-commerce authentication mechanisms need to
   identify a user uniquely and possibly over large spans of time. In
   many cases a customer relationship can last several decades. Such
   long term customer relationships can outlast any specific email
   address, Internet service provider, surname, or possibly even the
   DNS itself.

   URNs are a uniquely suited solution for this due to the requirement
   that they also be unique and permanent. In addition, the

Mealling               Expires September 30, 2000               [Page 1]

Internet-Draft           NSI PIN URN Namespace                April 2000

   availability of a standardized resolution mechanism makes it
   possible for vastly different systems to utilize the PIN URN without
   needing to utilize an application or protocol specific element.

   This namespace specification is for a formal namespace.

2. Specification Template

   Namespace ID:

       "pin" requested.

   Registration Information:

       Registration Version Number: 1
       Registration Date: 2000-04-30

   Declared registrant of the namespace:

       Michael Mealling
       [email-masked]
       Network Solutions
       505 Huntmar Park Drive
       Herndon, VA 22070

   Declaration of structure:

       The structure of the NSS is a flat space of alphanumeric
         characters which have no knowable structure outside of the
         context of Network Solutions internal resolver.

   Relevant ancillary documentation:

       None

   Identifier uniqueness considerations:

       Identifiers are assigned by Network Solutions proprietary
         registration system in a way that guarantees uniqueness.

   Identifier persistence considerations:

       The assignment process guarantees that names are not reassigned
         and that the binding between the name and the entity named is
         permanent.

   Process of identifier assignment:

       Names are granted via Network Solutions proprietary registration
         procedures.

   Process of identifier resolution:

       PIN URNs are resolved via URN resolvers run by Network
         Solutions. The data and databases used by those resolvers is
         proprietary data and can only be accessed by the resolver.

   Rules for Lexical Equivalence:

       The entire URN is case-insensitive.

   Conformance with URN Syntax:

       There are no additional characters reserved.

   Validation mechanism:

       None additional to resolution specified

   Scope:

       Global

Mealling               Expires September 30, 2000               [Page 2]

Internet-Draft           NSI PIN URN Namespace                April 2000

3. Examples

   The following examples are not guaranteed to be real. They are
   listed for pedagogical reasons only.

      URN:pin:bs4321234
      URN:pin:324kj5hkj45
      URN:pin:mm2136

4. Security Considerations

   Since the URNs in this namespace are opaque there are no additional
   security considerations other than those normally associated with
   the use and resolution of URNs in general.

   It is noted however that attempting to resolve a PIN URN through a
   resolver other than the one provided by Network Solution is prone to
   error and is not considered authoritative.

References

   [1]  Moats, R., "URN Syntax", RFC 2141, May 1997.

Author's Address

   Michael Mealling
   Network Solutions, Inc.
   505 Huntmar Park Drive
   Herndon, VA  22070
   US

   Phone: +1 770 935 5492
   EMail: [email-masked]
   URI:   http://www.netsol.com

Mealling               Expires September 30, 2000               [Page 3]

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]

---

From: "Stephen D. Williams" <[email-masked]>
Date: Wed, 24 May 2000 09:20:44 -0400

Standardizing on a permanent ID system separate from email addresses, domain names,
and other identification is a valuable goal.  While I have had the same permanent
email address ([email-masked]) just as long as my Internic handle (sdw11), both in
1992, it is only because I run my own email server, a rare luxury these days.

Not only do people move between email addresses sometimes more often than they move
physical addresses due to ISP changes, job changes, and school changes, but they
may also be moving between registrars.

The principle problems with this draft is that it proposes an apparent neutral URN
space, URN:pin, but which is semi-private for read and private for write to Network
Solutions.  This is wholly unacceptable as an open standard.  Even taken in the
narrow application of domain registration it would be highly desirable for all
registrars to be able to identify an entity consistantly.  Similarly, registrants
are faced with the pervasive problem of tracking multiple ID's over potentially
several registrars' systems.

I would suggest first that URN:networksolutions-pin be used for the existing
'Internic handles' and that URN:pin be reserved for an open, free, accessable, and
comprehensively usable system of permanent identification of entities.

Some thoughts on OpenPin:

The Senior VP of Development from AOL, Larry Masinter (if I remember correctly),
myself, and many others have voiced the obvious need for a long-term stable ID
system that could be relied upon by various applications.  These applications could
include authentication (but not authorization) for applications including DNS
registrars, email forwarding, directory links, presence, etc.  Note that this
namespace is intended for legal or quasi-legal entities (including individuals,
distinct groups and clubs, corporations and companies) and not for arbitrary object
or concept ids.  Something like the unique field in White Pages, not an Internet
keyword.

Special consideration would have to be given to spam prevention, authentication
security methods, updates, and distributed replication/access.  An effort should be
made to allow easy mapping of existing IDs, especially email IDs, into the space in
a way that is resistant to time decay.  A simple example would be: [email-masked] ->
92esdw_lig_net.  The year could really be a base-36 month or quarter time-based
'salt' which would allow for ID reuse for entities like AOL which have a 6 month or
less reuse gap.  a1esdw_aol_com would be a different entity from a2esdw_aol_com.
'e' was a suggestion for denoting 'email' mapping.  'h' could denote 'Internic
Handle' mapping.  'a' could be AOL mapping, but that might be a bit too
preferential.  The goal of the name space should be to avoid overly random IDs when
possible by limiting name space and temporal collisions.

Of course it would be helpful in some contexts for this to have email address form
in which case a standard pseudo-domain could be used, such as:
[email-masked].  In other contexts, the [email-masked]' would be
implied.

With modern load balancing technology, resolution of these ID's and to a large
extent authorization when  needed could easily be distributed over vast numbers of
servers.  Each ISP and large entity could run a local, secure, ID translation
server.  Man-in-the-middle and other attacks could be minimized by strategies like
frequenhtly distributing PK private keys to authorized servers or IP validation in
reverse DNS periodically.

Updates should be propagated via flood (a la Usenet).  Collisions should be handled
by time stamp comparison or crypto-time sequence comparison (i.e., if NTP cheating
in servers is suspected, an encrypted NTP sequence could be used).

Both direct and delegated authentication should be supported.

Entities can be 'terminal', indicating that the entity does not exist, 'inherited'
which means it doesn't exist but has become 'owned' by a new entity, or
'delegated'.

OpenPin's should have privacy preferences determining what use is allowed and the
system should keep a history of changes to this.  Use of the Pins by both listed
and using parties should require agreement with a terms of use which can be used to
exclude certain conduct.  Alternately this can be handled by appropriate laws in
the future.

This might be going to far, but it makes sense for this ID directory to allow
certification information provided by certification authorities.

Although I haven't been tracking progress of PKI projects lately, it would seem
useful for an omni-PIN directory to contain public keys also.

Arbitrary capabilities and preferences are another recurrent problem.  For example,
who prefers HTML email?

It is debatable which of these services and information categories should be
retained within the OpenPIN records and which should be delegated to other servers,
but it's clear that there should be a permanent ID with which to find such
information or services for a particular entity.  An example heuristic might be:
anything that changes more often than X (a day, week, month) on a normal basis must
be delegated.

sdw

--
Insta.com - Revolutionary E-Business Communication
[email-masked] Stephen D. Williams  Senior Consultant/Architect   http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax  Jan2000

---

From: Michael Mealling <[email-masked]>
Date: Wed, 24 May 2000 11:35:13 -0400

On Wed, May 24, 2000 at 09:20:44AM -0400, Stephen D. Williams wrote:
> The principle problems with this draft is that it proposes an apparent
> neutral URN space, URN:pin, but which is semi-private for read and
> private for write to Network Solutions.  This is wholly unacceptable as
> an open standard.

This is not meant as an open standard. In the same sense that
ISBN is a semi-private for read and private for write, are you
going to deny ISBN, ISSN, et al their NID as well? Every
single one of them is run by a private organization who claim
proprietary ownership of the namespace.

> Even taken in the narrow application of domain
> registration it would be highly desirable for all registrars to be
> able to identify an entity consistantly.  Similarly, registrants
> are faced with the pervasive problem of tracking multiple ID's over
> potentially several registrars' systems.

This URN namespace will probably have nothing at all to do with
the domain-name registration process....

> 'Internic handles' and that URN:pin be reserved for an open, free,
> accessable, and comprehensively usable system of permanent identification
> of entities.

This is not and has never been the policy of the IETF to make these
social/political determinations. It is specifically not mentioned anywhere
in RFC2611 process for NID registration....

Nothing in the process says that a new URN namespace has to be
an open IETF standard. RFC 2611 specifically states that the required
RFC can be Information or even Experimental.

From RFC2611:

   "The development of an identifier structure, and thereby a collection
   of identifiers, is a process that is inherently dependent on the
   requirements of the community defining the identifier, how they will
   be assigned, and the uses to which they will be put.  All of these
   issues are specific to the individual community seeking to define a
   namespace (e.g., publishing community, association of booksellers,
   protocol developers, etc); they are beyond the scope of the IETF URN
   work."

-MM

---

From: "Stephen D. Williams" <[email-masked]>
Date: Wed, 24 May 2000 12:37:14 -0400

I don't dispute your points.  Let me summarize my comments more clearly:

A) With regard to your URN:pin draft:
URN:pin seems like an inappropriately generic namespace ID for a very narrow and
closed use.  I, personally, would prefer a more specific namespace.  I have not
studied the IETF politics and rules in detail regarding selection and registration
of URN namespace ID's and cannot make a more specific complaint.  It's not an
overly important issue in any case.

Why not use: URN:nichandle or URN:nshandle?

B) The need for a generic and open URN:pin (or URN:personalid, or whatever) has
come up before.
I go on, in my previous message, to describe my requirements for such a namespace
and postulated service informally but in some detail.

sdw