A SOAP interface was used for NDG Alpha but without WS-Security. For Beta delivery we want to have a fully WS-Security compliant interface to facilitate interoperability with Java toolkits and other languages as required. This was an aim for the related DEWS project.
WS-Security with DEWSFor DEWS it was partially successful: a problem arises in how to communicate the chain of trust from proxy certificate back to the CA certificate: CA Certificate <- user certificate <- proxy certificate. (Ref. http://www.globus.org/toolkit/docs/4.0/security/key-index.html#s-security-key-delegation).
In the WS-Security schema, the BinarySecurityToken element can be set with the X.509 certificate for the recipient to use to validate the signature but in the case of a proxy certificate you would need to pass both the proxy and the user certificate. For DEWS, proxy certificates were dispensed with because of this difficulty or also more importantly, the fact that the Java WebSphere and WSS4J toolkits that the Python code interfaced with use fixed certificate settings set at start up. Proxy certificates are generated at runtime so this is a non-starter.
Instead a server certificate was used for signing messages to an Attribute Authority passing the user ID as a separate element in the message.