Subject: [Ietf-not43] use case: selective access

From: [email-masked] (Leslie Daigle)
Date: Tue, 16 Apr 2002 15:29:17 -0400

This is a multi-part message in MIME format.
--------------53044F4E43EC406F7816A9AB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Howdy,

Here's another use case for discussion...

Leslie.

-- 

-------------------------------------------------------------------
"An essential element of a successful journey
    is recognizing when you have arrived."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------
--------------53044F4E43EC406F7816A9AB
Content-Type: text/plain; charset=us-ascii;
 name="041202-lld-use-case.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="041202-lld-use-case.txt"

Use case:  Registrar needs to provide selective access to
  collected data

Description: A domain registrar is required to collect specific
data from domain registrants. This may include contact or
other personal (social) data.  The registrar is also faced with
competing requirements to make data publicly available and
to provide adequate privacy for the registrants.  These policy
requirements vary from region to region. 

Problem Statement 1:
The registrar may be required to allow individual domain registrants
(holders) to "opt out" of allowing public presentation to ANY of
their data.  (E.g., open access to searches on the Internet).

  Possible Solution i:  The registrar chooses not to make any 
  of the collected domain holder data available publicly. [Achievable
  with whois today].

    Issue:  Public access to some domain holder data is required or
    desired for administrative purposes.

  Possible Solution ii:  The registrar maintains 2 databases, using
  network-level access controls to secure the private one (e.g.,
  it is only accessible on the registrar's internal network).
  [Achievable with whois today].

    Issue:  Requires maintaining and synchronizing 2 related databases.
    The databases would be "domain holders" and "opted out 
    domain holders".  Wreaks havoc with any kind of referral 
    mechanism (which database is the target?).

  Possible Solution iii:  The registrar provides one single service to
  access domain holder data, but enforces access control restrictions.
  [CANNOT be implemented with RFC954 whois today.]

Problem Statement 2:
The registrar may be required to allow individual domain registrants
(holders) to "opt out" of allowing public presentation to SOME of
their data.  (E.g., open access to searches on the Internet).

  Possible Solution i:  The registrar chooses not to make any 
  of the collected domain holder data available publicly. [Achievable
  with whois today].

    Issue:  Public access to some domain holder data is required or
    desired for administrative purposes.

  Possible Solution ii:  The registrar maintains 2 databases, using
  network-level access controls to secure the private one (e.g.,
  it is only accessible on the registrar's internal network).
  [Achievable with whois today].

    Issue:  Requires maintaining and synchronizing 2 related databases.
    The databases would be "public data for each domain
    holder" and "private data for each domain holder".  

  Possible Solution iii:  The registrar provides one single service to
  access domain holder data, but enforces access control restrictions.
  [CANNOT be implemented with RFC954 whois today.]

Problem Statement 3:
The registrar may be required to provide access to all domain holder
data to law enforcement agents.

  Possible Solution i:  The registrar chooses not to make any 
  of the collected domain holder data available publicly. [Achievable
  with whois today].

    Issue:  Public access to some domain holder data is required or
    desired for administrative purposes.  Law enforcement agents
    would have to obtain privileged access to internal databases.

  Possible Solution ii:  The registrar maintains 2 databases, using
  network-level access controls to secure the private one (e.g.,
  it is only accessible on the registrar's internal network).
  [Achievable with whois today].

    Issue:  Requires maintaining and synchronizing 2 related databases.
    Depending on the requirements, that might be "domain holders"
    and "opted out domain holders", or "public data for each domain
    holder" and "private data for each domain holder".  Wreaks havoc
    withtany kind of referral mechanism (which database is the 
    target?).  Again, requires special access and search tools
    for law enforcement agents.

    Issue:  Registrars may need to be able to provide both -- allowing
    individual domain holders to "opt out" of public access to data,
    while allowing access to that data for specific classes (e.g.,
    law enforcement).  The dual database model becomes complex to
    design and maintain.

  Possible Solution iii:  The registrar provides one single service to
  access domain holder data, but enforces access control restrictions.
  [CANNOT be implemented with RFC954 whois today.]

--------------53044F4E43EC406F7816A9AB--

---

From: [email-masked] (Eva Steng�rd - es)
Date: Wed, 17 Apr 2002 10:26:28 +0200

Hi,
whether or not data should be public/ private in an opt-out (or opt-in)=20
scheme is IMHO conditional as you normally opt-out certain specified=20
uses of the data. It's not just a decision on the data being public or =
not.
Therefore any data, though certain types of data such as e-mail=20
addresses probably more often, may need a battery of rules=20
associated with them. In some cases they may even need to follow=20
the data in exports.
For instance (say regarding admin contact e-mail):
opt-in : publishing in registrar web directory
opt-out : bulk export
opt-out : export to third party
opt-in : bulk e-mail from registrar trusted partners
opt-in : statistical use

Some of the rules may be non-optional from the domain holders=20
point of view and rather dictated by legal or technical requirements.
For any rule the interpretation of null must be specified.

Using two databases for public/ private data does not solve the=20
problem with conditional use however a model using a master from=20
which is generated a number of 'mirror facets' (databases) at=20
regular intervals may work. Each 'mirror facet' should have one=20
specific use that is clearly stated in a standardized way (so that=20
the collection of  'mirror facets' of the same kind may serve as a=20
distributed database). Access may then be set up for each facet=20
as a whole and not per data entry in them.

>=20
> requirements vary from region to region.=20
>=20
Just some thoughts, without any regard whatsoever on what's=20
possible or not today or what have been proposed so far :-),
Eva

Eva Steng=E5rd
MuseDoma

---

From: [email-masked] (Andrew Newton)
Date: 17 Apr 2002 10:25:02 -0400

Eva,

These are some excellent points.  My comments in-line...

> opt-in : bulk e-mail from registrar trusted partners

You have a valid idea here, however I think it is more relevant to the
provisioning side (PROVREG) that this information is collected.  I think
the thing for us to understand is that if a registry has such
information, the publication protocol must allow for these rules to be
followed.

> as a whole and not per data entry in them.

Excellent point.  I agree.

-andy

---

From: [email-masked] (Eva Stengård)
Date: Thu, 18 Apr 2002 08:41:36 +0200 (MEST)

Andy and all,

> > Therefore any data, though certain types of data such as e-mail
> > addresses probably more often, may need a battery of rules
> > associated with them. In some cases they may even need to follow
> > the data in exports.

I agree that most of it is applicable where the information is collected
but I also think that in any case where information collected also may end
up being available from another party the protocol need to support
transfer of such data as above between the parties. Let's use registrar -
registry as an exemple. If information collected by the registrar have
been subject to opt-in/ opt-out by the domain holder gets transferred
to the registry the rules needs to be included if data transferred
is accessible by any other party than the registrar. With the inclusion of
sponsored TLDs there's now three parties involved with somewhat
overlapping needs of the data collected by the registrars.
So, I believe the protocol has to support transfer of rules but are open
to arguments.

rgds,
Eva

---

From: [email-masked] (Eva Stengård)
Date: Thu, 18 Apr 2002 17:12:29 +0200 (MEST)

> information, the publication protocol must allow for these rules to be

Actually, anyone requesting information from a system that includes
information that is subject to conditional access needs to state the
purpose for which the request is made. To me, that suggests that the
protocol has to support this. 

What goes in or not in the reply will then be a matter of how the rules
are implemented in each system. For instance, using the same request, from
one database you can get all that has not chosen opt-out for bulk e-mail
and from another database you get those that have chosen opt-in for bulk
e-mail (perhaps subject to local legal concerns).

rgds,
Eva

---

From: [email-masked] (Andrew Newton)
Date: 18 Apr 2002 11:48:48 -0400

On Thu, 2002-04-18 at 11:12, Eva Steng=E5rd wrote:
> protocol has to support this.=20

I don't disagree with the requirement, I'm just thinking more about the
details.  I don't necessarily think the protocol needs to support the
tagging of the data explicitly but rather the ability for a service to
differentiate which users can read certain data (that was tagged perhaps
in EPP or something).  To me, this would be the ability to conduct
authentication for the purpose of applying access controls.

But we should definitely look at this to see how it is a requirement.

In reply to your earlier email in this thread, I think we need to scope
this so that we are talking about a service to publish information from
registry/registrar/registrant to end-users for the most part.  Bits that
flow from registry to registry or registry to registrar might be the
subject of PROVREG.

-andy

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 18 Apr 2002 10:59:22 -0500

> Here's another use case for discussion...

It seems to me that this discussion has illustrated that there need to be
two systems: a provisioning service which has all information, and a
publishing service which provides public information.

For delegated resources, the provisioning system is the read-write system,
where all updates are made. Updates can only be made on the provisioning
system, since that is where most of the flags are kept. The implication
from this is that the publishing service is read-only, or that the data
provided by the delegation authority MAY be read-only. On the other hand,
the nature of the delegated hierarchy is such that the leaf-node entities
MAY be read-write. I guess what I'm saying is that the resulting
publishing system needs to support multiple kinds of update capabilities,
ranging from NONE to FULL, with the specific level being determined by the
publishing party.

As for authenticated access to full data, I would think that the
provisioning system is the natural exposure point, since it is where ALL
of the data (including all of the flags) is kept. Even if a user has full
access to the publishing service, they will not see all of the falgs from
the provisioning service, so those systems are where law enforcement and
other actors with court orders would likely prefer to go anyway.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 18 Apr 2002 11:12:04 -0500

Andrew Newton wrote:

> I think we need to scope this so that we are talking about a service
> to publish information from registry/registrar/registrant to end-users
> for the most part.

CRISP should be a system to publish and retrieve a specific set of schema.
The source of the data under the schema should be somewhat irrelevant to
the operation of the schema.

I would think that it would be desirable to ensure that the provisioning
and publishing schema are capable of supporting a common database. This
means that the provisioning schema should effectively be a superset of the
publishing schema (or turn that around if you want, with the publishing
schema being a subset of the provisioning schema). ACLs and entry points
would determine which schema you worked with.

The protocol requirements between these two systems are also somewhat
different. An update doesn't require the tree-walks that a query does.

---

From: [email-masked] (Ted Hardie)
Date: Thu, 18 Apr 2002 09:21:40 -0700

> publishing service which provides public information.

Let's be clear here that "a provisioning service which has all
information" does not imply a global, monolithic service.  We've
stressed in the past that having one monolithic data store raises a
number of serious privacy and fate-sharing problems; I'd hate for
folks to believe that the need to provide publishing services drove
the need for that sort of thing.

I agree with your analysis that the provision system is the read-write
system and that CRISP relates to the publish & query interface
into that system.  I think we've agreed that we're trying to standardize
the publish and & query interface here, and that standardizing
those interfaces shouldn't force people to use a single (or even
a standard) read-write backend.  Similarly, I believe the provreg
effort means to provide a standard interface for provisioning.
without standardize the backend.
			regards,
				Ted Hardie

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 18 Apr 2002 11:23:58 -0500

"Eric A. Hall" wrote:

> and publishing schema are capable of supporting a common database.

> different. An update doesn't require the tree-walks that a query does.

Examples on this:

  central delegation authority (eg, ARIN)

    provisioning system to allocate resources
      has specific authorization and authentication requirements
      has large schema
      has few entry-points
   
    publishing system to advertise resources
      anonymous access to public data
      has smaller schema
      has multiple entry-points

  secondary delegation authority (eg, ISP)

    provisioning system to further allocate resources
      can be identical to top-level provisioning service
      similar auth requirements
      similar schema requirements
      small number of entry-points

    publishing system
      is identical to global publishing service
      local auth requirements
      identical schema requirements
      identical entry-points

  leaf-node resource consumer

    may need provisioning for internal resources
      can be identical to top-level provisioning service

    publishing system
      is identical to global publishing service

---

From: [email-masked] (Eric A. Hall)
Date: Thu, 18 Apr 2002 11:26:26 -0500

Absolutely agree with all of this.