VOSpace-2.1 prototype

[Patrick Dowler]

Our vospace implementation now supports the 2.1 transfer document 
format, which allows one to include a securityMethod in the requested 
protocol and get URLs back that support/require that method. The term 
securityMethod was lifted from VOResource, where it is used in 
VOSI-capabilities to describe the exact same concept: authentication 
required to call an interface.

The usage for vospace transfers is as follows:

- client submits a transfer document with all the 
protocol+securityMethod combinations they can perform in addition to the 
node URI and direction of the transfer

- the service picks the ones that it supports, adds endpoint URLs and 
returns the result

Some interesting things I realised while writing the tests:

1. client should specify all the things they can do because for various 
implementation detail reasons some combinations may not be available. 
This includes always asking for protocol(s) with no securityMethod!

Example: in our service, users can call /vospace/transfers (or sync 
equivalent) anonymously or authenticate using x509, username/password, 
cookie, or a special token scheme. Because of the way our web server is 
configured, all https requests currently require an x509 certificate so 
we don't really support the other methods over https. However, the URLs 
to actually get or put data to vospace only support two combinations:

- https + x509
- http + anon

In the latter case, we have distributed storage and external sites 
cannot perform authentication and authorization so we generate a unique 
URL that they can validate instead. So, while it is http+anon it can 
correctly deliver private data to authorised users. The additions in 
WD-VOSpace-2.1 are fine as is: they correctly allow the client to say 
what they can do and the service to provide URLs that match.


One nice aside: since transfer negotiation sends documents both ways, 
the service can tell which version of vospace the client is using and 
respond in kind. For our service, if he client sends a 2.0 doc they get 
a 2.0 doc back and if they send a 2.1 doc (with extra goodies) they get 
a 2.1 doc back. We updated our java client but not our python client and 
so far all is well (including users of the old java client).
So: backwards compatible implementation is quite easy to do.

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)