Bill,
Excuse me for butting in here, but I want to add to what you wrote as
potential overview under the heading of security:
> Security
>
> When a digital object is accessed over a network, there are many occasions
> when a supplier wishes to make only part of the metadata accessible to
> specific users. For example, an organization may need to have access to
> technical metadata in order to store and transmit information, but, to
> avoid potential liability, may explicitly desire not to have access to
> metadata that describes content. A commercial organization may wish to
> provide some metadata openly, but require authorization before giving
> access to other metadata.
>
> These objectives can be achieved by providing each metadata package with
> its own security. Access controls on each package can be different.
I don't see that this last paragraph can stand on its own. Whether
metadata packages are delivered is an issue for the server, so the only
way that selective access can be maintained at the package level is by
multikey encryption of packages.
So one has a choice between:
1. Enforcing access controls in the _service_ that delivers the
metadata objects/packages, in which case security is an infrastructure
issue and _not_ part of the metadata framework, or
2. Building sophisticated key management mechanisms into the metadata
framework. Astoundingly sophisticated key management mechanisms.
I don't believe the second is a viable approach unless metadata is
built in an environment with self-aware objects.
Also, proving issues such as liability will require (a) certification
authorit(y|ies) as a minimal backbone for a nonrepudiation mechanism.
Without those in place, there's no need for a defence against liability
claims.
This is not to say that security is not important for metadata - it is
_very_ important - but rather that it's important to impose security at
the right layer of the infrastructure, architecturally speaking.
Sorry to be critical, but we need to start by solving simple issues
before tackling the hard ones.
Mark
--
Mark Madsen <[log in to unmask]> Telephone: +44-1223-568934
APM Ltd Poseidon House Castle Park Cambridge CB3 0RD UK
<URL:http://www.ansa.co.uk/><URL:mailto:[log in to unmask]>
Reception: +44-1223-515010; Facsimile: +44-1223-359779
|