[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: THREDDS and lightly restricted datasets
- Subject: Re: THREDDS and lightly restricted datasets
- Date: Sat, 27 Mar 2004 09:23:13 -0700
Hi all,
I guess I was rushing to get out the door on a Friday afternoon. I
forgot to say a few things.
I think John's idea of a mustNotify is good but needs to be expanded.
And I would go for a seperate element from documentation. Maybe
something like
<rights policy="display">
The following data and products ...
</rights>
Where the value of the policy attribute can be "provide", "display",
"acknowledge", or "authenticate" and others that seem appropriate.
Also, I'm wondering if clients need to identify the policies that they
understand. Or would this need to be done outside of the catalog.
This is also strictly related to data restrictions. There can also be
cases where the metadata (or part of the metadata) is restricted. But
that seems even messier.
Ethan
Ethan Davis wrote:
Benno Blumenthal wrote:
John Caron wrote:
thats an interesting issue. i suppose we can add an optional
attribute to the documentation element, like mustNotify="true" which
means to clients that they should pop up the contents of the
documentation element and have the user press "Accept". Do you
think that would suffice?
This is a tough issue because THREDDS is more of an information
transmission protocol than a client.
I want to say yes, something like that would work, but that supposes,
1) all THREDDS clients would do the right thing, and
2) all DODS/OPenDAP/WCS/ADDE clients would display the restrictions
in the THREDDS catalog.
1) is possible at this stage of THREDDS, I think, but 2) seems pretty
unlikely. It would really take a communal commitment to this sort
of thing to make it work, and I am not sure the interest is really
there. The alternative is for me to set up user names and passwords
so that I (as the original server) can take care of challenging the
user using HTTP and then allowing the user to use the data. Not my
favorite solution, but at least it works.
Since the clients in 2) have to be THREDDS clients to access THREDDS
catalogs, seems this collapses into just 1). I agree that 1) might be
possible at this stage but it is not containable so could change at
any time without our knowledge.
We've certainly wrestled with this issue before and not really gotten
very far. To my mind, THREDDS can "provide" this information (if it is
in the catalog, the client will read it); however, it can't enforce
the acknowledgement of or even ensure that anything is done with the
information. If that is required then the clients and/or servers must
have some control mechanism and policy in place (whether highly
restrictive or lightly).
I think there are things THREDDS as a protocol can do to support
access controlled systems and THREDDS as a project can do to provide
or encourage access controlled systems. But I don't see how THREDDS
can enforce this kind of thing. It is up to the data providers to make
sure that their systems (and the clients that are accessing them)
adhere to the requied policies.
Ethan
Benno
I realize THREDDS is mostly about freely exchanged data, and
restricted data is OK too because the underlying data server is
responsible for restricting access to the data. But there is
another class of data which required display of some agreement as a
condition for use.
The classic example is WMO40, the key phrase being "must provide
this same notification" ,e.g.
*The following data and products may have conditions placed on their
international commercial use. They can be used within the U.S. or
for non-commercial international activities without restriction.
Re-distribution of these data by others must provide this same
notification. A log of IP addresses accessing these data and
products will be maintained and may be made available to data
providers. *
*For details, please consult: *
*http://www.wmo.ch/web/ddbs/jen/AdditionalData&Products/AdditionalData&Products.html
<http://www.wmo.ch/web/ddbs/jen/AdditionalData&Products/AdditionalData&Products.html>
*
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: address@hidden
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------