NVO prototype operates a "weak" CA - only valid e-mail required to register.
Strong validation of registrations is being investigated. This may add extra elements to the SSO profile.
The pubcookie system is used to maintain SSO between web portals. This mechanism may become part of the SSO profile.
The UAS/community log-in process uses MyProxy and doesn't specifically need a web-browser. Use of MyProxy (as opposed to WS-Trust) was reaffirmed for the v1.0 standard.
AstroGrid's prototype was demonstrated: community login + digital-signature of request to a service.
There is an open issue of what names for users are presented to services. Currently only X.500 from certificates. Is this enough? Do we need to correlate different X.500 DNs for the same scientist?
Authenticate-methods spec. got four clarifictions and can now go to v1.0WD immediately.
Decision: services using TLS are expected to support RFC3820 proxy-certificates. This may rule out regular TLS implemenations.
Decision: no IETF extensions to TLS (other than RFC3820) need be supported.
Decision: doesn't matter which version of WS-Security is used, support them both (later resarch showed that it the wire protocol is the same for both versions if only digital signature is used).
Decision: certificate-chain checking must respect limits on chain length stated inside certificates.
NESSI looks quite like a CEA installation in terms of its use of application libraries. RoyWilliams agreed that NESSI and CEA might be made to converge.
Two means of running modelling codes were demonstrated: via AstroGrid CEA, on a private computer-cluster and via a big-iron grid.
CEA (or its successor, UWS-PA) needs to distinguish better the states of a job running on a cluster or grid. It needs a QUEUED state.
We really need a specialized kind of CEA service (or UWS-PA service) that talks directly to clusters and grids without the service provider needing to write glue code. The grid broker in Porstmouth is one of these.
The UWS spec has been rewritten for clarity. It now describes four possible applications that may be worked up in detail as companion standards.
The group opted to work up the UWS for Parameterized Applications sped as a full IVOA standard. This one gives us a standardized CEA and also an asynchronous ADQL service. The intention is to have a mature spec and working prototype by the autumn interop.
VOSI
The getAvailability and getRegistration interfaces are basically agreed, but the exact use of the log harvesting is still under debate.
Log harvesting is no longer considered an interface to be added to every service; more a specialized service with one on each site.
Log harvesting will be moved to a speparate spec-document, laeving the other VOSI parts to go forward immediately to v1.0 WD.
Agenda for GWS-WG sessions 3 & 4, Friday 18th May 2006
Topics:
VOSpace
Reprise: what happened to VOStore?
Finalize the operation names
Finalize the identifier scheme
Finalize the operation semantics
WSDL: how to represent different kinds/levels of service?
Road-map: features held over to later versions of VOSpace