Comments inserted.... 2009/3/17 weizhong qiang weizhongqiang@gmail.com
If we are talking about attributes carried inside SAML assetion, getting the attributes from attribute authority is not a challenge, for instance we can use the VOMS SAML service (client gets back SAML assertion that including attributes through SSL authentication with VOMS SAML service) as a candidate.
I propose that the "aquisition of tokens" in a push-style model is orthogonal to action-item (1). If we want to consider it, we should address it as a separate concern (in the same vein that aquisition-of-delegation-tokens has been broken out into a seperate issue). Action-item (1) should be about nothing more complicated than profiling a simple request-response message exchange between two endpoints in which all parties already possess the necessary credentials.
But how to push the SAML assertion from client side to service side could be a challenge (for which voms has not provided solution, IMO). I can see two ways: one ways is put the SAML assertion into X.509 proxy certificate's extension, by which you can gurantee that the attributes information is binded with SSL authentication;
I believe that the use-case for attribute-bound SSL authentication involves X.509 attribute certs (ACs) as per the original VOMS implementation rather than SAML attributes.
the other way is to put SAML assertion in the SOAP header, which furtherly cause two branches: First brach, using the SAML assertion for message (SOAP) level authentication + attribute carraying (in this case the VOMS SAML service should probably be improved to creat SAML response containing a holder-of-key authentication assertion, then this assertion can be used for message level authentication according to WS-Security SAML Token profile 1.1); Second branch, using SAML assetion only for attribute carraying (in this case, the transport level securiry should be configured).
The second branch you describe ("bearer" style) is not viable: you need a "holder-of-key" approach in which the caller demonstrates possession of a private key corresponding to the public one signed into the attribute by the attribute authority. (You could potentially demonstrate this via an SSL signature, but I consider that to be an ugly hack and explicitly discouraged it in the Strawman document.) Thus we arrive at two scenarios: ACs-via-SSL-authn and SAML-via-SOAP-authn. Confidentiality and integrity provided in both cases by SSL/TLS, of course.
(2) Agreement on Definition/Semantics/Structure of Attributes
Yes. The Strawman doc makes an initial stab at this by profiling a FQAN-style syntax/semantics for both X.509 ACs and SAML assertions. (VOMS already does that for the former, and the SAML examples in Morris' doc in GridForge resemble the latter.) That way both assertion-styles would be capable of conveying identical information. Cheers, Duane