GWS-WG plans and actions

[Guy Rixon]

Reagan,

we appreciate the chance to try VOSpace with SRB.  To facilitiate this we need
to make plain what we mean by "GSI security".

I understand GSI security to be defined by its API (the GSS one from IETF).
IIRC, the only extension of GSS in GSI is ability to do 'delegation by
approximation using proxy certificates.  I've never seen a definition of the
wire protocol for GSI, which leads me to suspect (a) that there may be
several, incompatible forms of GSI, and (b) that the wire protocols used in
GT3 web services (which follow OASIS standards) may not be GSI.

Do you have a better understanding of what GSI really means?  Can you tell us
what really happens when GSI is used to talk to SRB?

Cheers,
Guy

On Fri, 18 Jun 2004, Reagan Moore wrote:

> Guy:
> We will need to interoperate with at least two security environments:
>
> - GSI security for access to resources authenticated by grid technology
> - Shibboleth, for access to resources controlled by digital libraries (DSpace)
>
> For an early prototype for VOSpace we would like to volunteer the use
> of the Storage Resource Broker data grid.  The system supports GSI
> authentication, access controls, user defined metadata, collection
> hierarchies, data replication, access to archives, OAI interface,
> WSDL interface, and multiple APIs.  We would like to add IVOA access
> mechanisms as they are defined.
>
> Reagan Moore
>
>
> >Hi,
> >
> >Peter Quinn is asking for updated plans of this WG to go before the IVOA exec
> >next week. In particular, we need to explain how our work fits with the
> >demonstrations of January 2005 and with Peter's July-15th cut-off for input.
> >Appended below are my ideas of how it will go.  Please get back to me soonest
> >if you think this is wrong.  Objecttions received by tomorrow midnight will go
> >in my report to the exec; later ideas before Wednesday 23rd June can be fed in
> >verbally at the exec meeting.
> >
> >Cheers,
> >Guy
> >
> >VO Support Interfaces: concrete spec hoped for before 15th July 2004. Spec
> >should become a formal working draft by that date and should become a
> >recommendation before the Pune meeting. This standard is likely to be stable
> >well before January and would be fine for the demos.
> >
> >Async activities: some work needed.
> >
> >  - Clear up points of detail raised in Boston (Rixon, by end June 2004).
> >
> >  - Draft alternative proposal using WS-CAF for comparision (Rixon,
> >    by end of June 2004).
> >
> >  - Debate relative merits of WS-CAF and WS-RF following Matthew's comments
> >    (whole WG via mailing list; decision required by end of August 2004).
> >
> >  - Revise the proposal to use the selected technology
> >
> >  - Prototype to prove ideas in 4Q2004.
> >
> >Given that we haven't got working consensus about which plumbing to use
> >(consensus at Boston that WS-RF would work is not the same as consensus that
> >we prefer it to WS-CAF), this proposal won't be stable by July 15th.  This is
> >probably not one to showcase in January.
> >
> >
> >Single-sign-on proposal: some more work needed. If we accept the proposal as
> >presented at Boston, then it can go forward quickly.  However, Reagan raised
> >the problem of iteroperating with Shibboleth and that throws some doubt on the
> >whole thing. Shibboleth is based on SAML; our proposal doesn't use SAML, but
> >it could be changed to do so; might be better that way.  If we value
> >interoperating with Shib, then we should probably adapt our standard to suit.
> >Therefore, I (at least) need time to research SAML and Shib. I doubt that this
> >proposal will be stable by July 15th.  If we need security in the January
> >demos, then we may need to do something ad hoc, in which case the current
> >version of the proposal would be OK.
> >
> >Immediate actions:
> >
> >  - Break existing SSO proposal into three docs: wire-protocol spec, PKI spec
> >    and non-normative introduction (Rixon, by 7th July 2004).
> >
> >WS-I profile conformance: we accept that it's the right long-term goal, yes?
> >Therefore, we need to ppublish a short doc stating this formally. Andre: can
> >you draft something to go out before 15th July, please?  Longer term, we need
> >the collated conformance tests for the WS tool-kits. Can we have that for
> >Pune?  Iff we turn out to have some conforming toolkits (at least two of
> >them), then the WS-I facet of the January demos is to show that services from
> >these environments talk to each other without grief.
> >
> >VOSpace: no formal proposals yet, so I'm assuming that there won't be any
> >document drafts by 15th July.  Therefore, under Peter's rules, we don't expect
> >the VOSpace standard to appear in the January demos. However, I strongly
> >suspect that the demos will need some VOSpace facilities (e.g. we may be using
> >AstroGrid CEA services), so we'll need at least an ad-hoc VOSpace. Therefore,
> >I suggest that we try to make the demo solution look like the long-term
> >solution of choice even if the standard isn't ratified by January.
> >
> >  - Initial, written VOSpace proposal by end of July 2004, please?
> >
> >  - Discussion on mailing list plus informal, private prototypes
> >    (Morris and O'Mullane leading) by end of August?
> >
> >  - Discussion of finding at Pune
> >
> >  - Proposed recommendation by Christmas if consensus at Pune.
> >
> >Guy Rixon				        gtr at ast.cam.ac.uk
> >Institute of Astronomy  	                Tel: +44-1223-337542
> >Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523