Agenda for GWS-WG sessions 1 & 2, Monday 14th May 2006

Topics

• SSO security
  • Issues with TLS (listed in methods document)
  • Issues with digital signature (listed in methods document)
  • Issues with certificate chains (listed in methods document)
  • Any other changes to methods document before v1.0 WD?
  • Log-in/community services
  • Registering secures services
  • Delegation: details of delegation service interface
  • Arrangements for interop tests
• Universal worker service
  • New spec: 4 possible application contracts
  • Which contract(s) shall we develop?
• Experiences with grid
• Experiences with CEA
• VO Support Interfaces
  • Where are the implementations?
  • Log harvesting - VOSpace or not?
  • Any changes needed before v1.0 WD?

Presentations

• NVO log-in service (RayPlante): PDF
• AstroGrid SSO demonstration (GuyRixon)
• UWS v0.2 (GuyRixon)
• NVO Extensible Secure Scalable Service Infrastructure (NESSSI) (RoyWilliams)
• VisIVO: Interoperability Towards Grid (AlessandroCosta)
• Harvesting logs (KevinBenson)

Objectives

• SSO methods document -> v1.0 WD
• Plan SSO interop tests and assign volunteers
• VOSI document -> v1.0 WD, OR
• Define improvements to VOSI needed for v1.0 WD
• Plan VOSI interop tests and assign volunteers
• Decide which UWS contract(s) to implement

Documents

• VO Support Interfaces v0.24
• Universal Worker Service v0.2
• SSO authentication methods v0.2
• Registry metadata for security

Notes from the sessions

SSO

• NVO's prototype UAS was demonstrated.
• 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.
• Volunteers for SSO interop-trials:
  • NVO - RayPlante, MatthewGraham
  • ESO - Paul Harrison
  • AG - GuyRixon, DaveMorris

UWS

• NESSI was demonstrated.
• 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

Presentations

• Change from VOStore to VOSpace (MatthewGraham)
• VOStore operations and their semantics (DaveMorris)
• VOStore WSDL (PaulHarrison)
• Road-map (speaker TBD)

Objectives

• V1.0 WD of spec.
• Plan for interop. tests

Notes from sessions

• VOSpace-1 spec accepted with reservations:
  • Necessity of vos:// URIs (RoyWilliams not convinced)
  • Feasibility of data-objects that are not file-like (Roy thinks they won't work)
  • Usefulness of VOSpace-1 without directories (DougTody prefers a space with directories but not links; maybe an early form of VOSpace-2).
• However, agreed:
  • We will do VOSpace-1
  • We will have vos:// URIs (didn't find an alternative)
  • Caltech, ESO, AstroGrid to produce prototypes
• Not ready for v1.0 WD yet, but hope to get there during May
• VOSpace-2 to be eveloved while VOSpace-1 is in process.
• Relationship to AstroGrid MySpace
  • VOSpace-1 coexists with MySpace; does not replace it.
  • VOSpace-2 replaces MySpace.
• Participation of client authors encouraged.
• Noted that Astro Runtime will be a reusable client of VOSpace eventually (no release data available yet).

• : Ray Plante's presentation