With the increasing sharing of data over private or public networks, the possibility of global shared data space appears inevitable. Currently, intranets glue together the corporate shared data space within which information exchange takes place. In the global data space, the intranet concept has to be extended to the Internet. Before that can occur, there are two significant issues that have to be addressed:

• Speed at which data can be obtained in the current Internet and Intranet infrastructure
• Sharing the data space, whether files or managed objects, requires a strong framework of security in terms of authentication, confidentiality, data integrity, and policy-defined access control on the objects

However, where the shared data space is private and more controlled, i.e., the sources of data belong to the same organization, the connection media is owned and therefore limitations of economics are fewer. In that case, the bandwidth issue is not dictated by the width of the data pipe but by the ability of the infrastructure to efficiently move modest to large data objects at high data rates.

The second issue of sharing can be broken down into the issue of defining a global name space and the issue of creating a secure infrastructure for data access.

Global name spaces can be achieved in different ways, whether local data repositories or file system decide on a unique location independent naming system (somewhat similar to an URL naming scheme), or any scheme that maps a local file (assuming the shared object is a file) name into a global one.

We do not consider this to be a difficult problem since a mapping of a local file name to a global name can always be defined once the global naming scheme is agreed upon.

This brings us to the second important issue of secure data access. For sharing to occur:

• Every user must be authenticated by a data or file manager, a proxy owner that may be different from the creator of the data,
• Data should be stored encrypted. Authentication, key storage and authorization need to do accomplished using a public key system. This is necessary for this approach to be scalable to many users that may request the same data object.
• The data producer, the data consumer, and the manager are possibly distinct entities. This allows small to large systems to be the data producer, since the data manager has to provide real-time access control at line rates.
• If data is cached locally at a site close to the requestor or consumer (for performance reasons, as done today by most Web servers) then the access to the data must also be governed by the same access control defined by the data manager of the original data
• The encryption has to be done at the source (the producer) and the decryption at the destination (where it is consumed), e.g., the server that provides the original data and the server that receives it on behalf of the requestor, respectively. This implies no insecurity of the data while stored or inefficiency in encrypting-decrypting once for the storage, and then again for the network [see position paper in http://www.pdl.cs.cmu.edu/NASD/HICSS.html]
• The encryption and decryption must be possible at the line rate of the media [see for example: http://www.network.com/CorporateArea/ProductLiterature/ATLAS/ATLASbro.htm]. This assumes for importance as the backbone network infrastructure move beyond gigabit/sec capacities. This implies that line-encryption with hardware must be deployed using techniques that are not chain blocking schemes. These are possible using pipeline-able and parallelizable encryption algorithms such as counter mode.

In summary, besides evolving data rate issues, fundamental aspects of a secure distributed data infrastructure has to be realized for a truly global information network to be feasible.