• This proposal to be developed further.
• Use of WS-RF is acceptable.
• WS-BaseNotification should be optional.

Issues:

• Does WS-BaseNotification do reliable messaging? Does it need to?
• Need some WS-RF prototypes.

Actions:

• Find out if WS-BaseNotification has reliable-messaging semantics (GuyRixon).

• Renamed from "standard interfaces" to "VObs support interfaces".
• All three port-types to be specified.
• getRegistration (was getMetadata, now renamed) to be optional.
• getAvailability (a.k.a. "heartbeat") to be mandatory.
• harvestLog to be optional.
• Progress to concrete design (WSDL, XSD, prototypes) ASAP.

• Revise document to v0.2 with detail changes (WilliamOMullane)

• May need to apply access control to harvestLog
• Unclear if registries will actually use getRegistration.

• A SSO system based on digital signature and WS-Security is basically suitable for the IVO.

• Use of community services (run by real-world, astronomical communities) is a good way to manage users.
• Split the current proposal into two IVOA documents: (1) wire protocol; (2) Public Key Infrastructure/community services.
• Only community services for authentication should be tackled now. Community authorization is separate and might not be required.
• We need to understand the technology better before deploying it.

• Is WS-Security compatible with "Shibboleth"?
• Is WS-Security compatible with grid services/portals?
• Will service providers acccept our SSO arrangements?
• Can we handle 100+ communities? Do we expect that many?
• How do we prevent spoofing of community services (allows stealing of passwords)?
• How do we delegate work from one service to another?

Actions:

• Check compatibility of WS-Security with other systems (GuyRixon)