Hi,
I think that most of what is VOStore and what is VOSpace is clear; however, the two grey areas are access control (authorization) and identifiers and this stems from the use case where the user wants direct access to a VOStore (e.g. a local store) and does not want to go through the VOSpace layer. Here are my suggestions for handling these areas:
Access control:
A VOStore can run in two modes: authorized and unauthorized. An unauthorized VOStore is semantically equivalent to an anonymous ftp site: any authenticated user (we still maintain security) can put something in, move/rename it, get it and delete it. An authorized VOStore will only allow the requested operation if a valid authentication token is included in the request - all the VOStore has to do here is validate the authentication token. The generation of the authentication token is handled by VOSpace: it makes sure that the authenticated user has permission to do what they are requesting and if so, places a valid token in the request down to the VOStore.
Identifiers:
The protocol identifier ivo:// identifies a resource that exists in the VO. It does not promise that you can completely resolve a URI beginning ivo:// in a registry, merely that some component of the URI will relate to a resource that has a registry entry, i.e. the bit before the first # can be resolved in a registry. So I can go to a registry and find out where ivo://nvo.caltech/vostores/vostore1 is but I need to go to VOStore interface for this store to resolve ivo://nvo.caltech/vostores/vostore1#halibut3. I do not see why we need to introduce a second protocol just for VOStore contents.
Now resolution of individual VOStore identifiers has to be done at the VOStore level; however, VOSpace gives you the ability to set up a single logical identifier for multiple copies of the same resource so here we might want a separate protocol: vos and resolution of this identifier has to be done at the VOSpace level since VOSpace manages multiple VOStores.
Cheers,
Matthew
Paul Harrison wrote:
> Reagan Moore wrote:
>
>> The differentiation between the VOStore and VOSpace interfaces is
>> becoming unclear. The latest draft implies that properties that were
>> originally associated with VOSpace would now be supported by VOStore.
>>
>
> I have to say that I agree that there seems to be some confusion in
> this area - with hindsight it was probably a mistake to defer the
> specification of VOSpace and work on VOStore alone as the "easier"
> problem - the specifications should be worked in tandem to see where
> it is most appropriate to place roles and responsibilities for
> particular use cases, so that a "global" solution is arrived at.
>
> I thought that the original separation into VOStore and VOSpace was
> done so that VOStore could be an essentially "dumb" BLOB repository
> that did what it was told by the VOStore layer when it comes to issues
> of file permissions and hierarchical file names. However, because no
> VOSpace specification was created, these more advanced features have
> crept into the VOStore layer.
>
>>
>> Let's look at the current VOStore and VOSpace proposal:
>>
>> VOStore VOSpace
>> Storage of objects management of virtual
>> file system
>> data stored under unspecified ID?
>> no user home directory User home directory
>> directory hierarchy Directory hierarchy
>> Unique file name within storage User-defined file names
>> Mapping VOSpace name to
>> VOStore name
>> List files for user
>> Restrict access by user identity?
>> Identify files with URIs
>> Access controls on local file name Access controls on
>> VOSPace name
>>
>> This characterization mixes name space, mixes access controls, does
>> not provide consistent identity, does not allow consistent
>> management. For instance, if a URI is being provided for file
>> identity within the VOStore interface, then there is no need for
>> user-specified names within VOSTore. A second issue is the
>> assumption that file access can be restricted by user identity. This
>> means that the VOStore must manage the owner for each file, access
>> controls for each file. File systems usually do this by creating
>> accounts for each user name and applying Unix permissions. Is this
>> capability to be provided now by both VOSpace and VOStore? We need a
>> cleaner separation of capabilities.
>
>
> This security aspect is crucial - it is clear that the owners of
> VOStores would not want to be managing user identity lists of all the
> VObs users at their stores - the fine grained access controls should
> be at the VOSpace level. If VOStores only respond to requests from
> trusted VOSpace services then this is possible, but I think that the
> perceived requirement for more detailed access control in the VOSpace
> layer has come about because prototype end-user applications have
> appeared that talk directly to the VOStore layer - of course, it is
> not surprising that this has happened because there was no VOSpace
> definition for the end user applications to talk to.
>
> How file/BLOB identity is managed is also crucial to producing a
> system that offers more than ftp. I thought that one of the
> fundamental driving use cases for a VOSpace was that the same BLOB
> could potentially live on serveral VOStores, and that when specifying
> a resource in VOSpace, in a workflow for instance, the resource could
> be retrieved from the VOStore that was "closest" on the network to
> where the resource would be consumed. This sort of use case does
> require some careful thought about the allocation and management of
> identifiers, and I think probably means that the VOStore will have to
> be aware of the VOSpace identifier.
>
> I also have an issue with reusing ivo: as the protocol part for the
> URI of an identifier in this system - ivo: is already well defined and
> used as the identifer for registry entries, and the "protocol" for
> accessing the entity associated with the identifier is defined in the
> registry interface standard. This means that given an identifier of
> the form ivo://authority.org/something#blah a software agent (or human
> for that matter) cannot tell by inspection whether the identifier
> refers to a file in VOSpace or is simply a reference to a registry
> entry (e.g. for a SkyNode) - this leads to software having to be more
> complex in order constantly to test for the different possibilities. I
> think that it would be better to have a URI with a different protocol
> part, vos: for instance, it would then be immediately apparent that
> the VOSpace protocol should be used to access the entity referred to
> by the identifier.
>
>>
>> Let's look at the Storage Resource Broker data grid separation of
>> local storage management from the virtual file system management:
>>
>> Local storage system SRB name space
>> Storage of objects management of virtual
>> file system
>> data stored under SRB ID
>> no user home directory User home directory
>> directory indirection structure Directory hierarchy
>> Unique file name within storage User-defined file names
>> Mapping SRB name to local
>> file name
>> List files for user
>> Access through SRB ID, controlled by SRB
>> Identify files by URIs
>> Access controls on SRB name
>>
>
> I think that as Regan points out the separation of responsibilities
> that SRB has with the local storage system is pretty much the right
> model for VOSpace and VOStore - though it means that SRB is pretty
> much at VOSpace level rather than a VOStore as is suggested in the
> current VOSpace definition document.
>
Received on 2005-08-03Z20:02:44