Subject: RE: XACML extensions to SAML. Forwarded message from Scott Cantor..Forwarded message from Scott Cantor.
--- Begin Message ---
- From: Scott Cantor <firstname.lastname@example.org>
- To: Anne.Anderson@Sun.COM
- Date: Wed, 28 Jul 2004 10:22:58 -0400(feel free to forward) > I see this as a protocol layering issue: the SAML Status and > Conditions should contain Status and Conditions associated with > the SAML envelopes, and not with the processing of their > payloads. The payloads are a different protocol layer and > contain self-contained XACML Request and Response elements. > Their Status and Obligations elements are associated with the > processing of the payload itself. You're mixing SAML layers here. The SAML Status addresses the result of processing the protocol request, which in this case is an XACML Query message containing an XACML Request. That is its purpose, there would be no other "status" to represent in SAML. Meanwhile, Conditions is something else entirely. It's part of the assertion you get back, so it's not a protocol element. It has some obvious sorts of parallels to Obligations. In the same vein, I'd argue that XACML's Status is the result of processing the XACML Request, and Obligations is part of the XACML "result", which I saw as a statement in an assertion. If all you wanted to do was reuse the SAML protocol binding work, you wouldn't even need an assertion. You could just define a new XACMLResponse that extends SAML's StatusResponseType and directly contains the Decision and Obligations. And again, having a second Status element would be confusing there. But I think the point is to wrap the XACML Decision and Obligations in an Assertion, in which case I don't see the XACML Response as the optimum payload for the statement. > Another alternative is that we require the XACML Status and > Obligations to be duplicated in the SAML Response/Status and > Assertion/Conditions. This has the problem that a single XACML > Response may have multiple <Result> elements, each with its own > Status and Obligations. I think we would have to require a > separate SAML Statement, Assertion, and Response for each > <Result> element if we take this approach. This is why I think this is messy, but it's much cleaner if you just place multiple Decision/Obligation elements directly in your new statement type and leave the Status processing to SAML. If you're doing a status, then you're embedding an application protocol inside SAML's application protocol, and that's why it's messy. > In the current XACML Profile for SAML, the XACML Response from > evaluating the payload of an XACMLAuthzDecisionQuery would be > part of an XACMLAuthzDecisionStatement, which would be put into a > SAML Assertion, and then into a SAML Response. Similarly for > XACMLPolicyQuery. The current Profile defines only the Statement > levels, but should probably add a description of the packaging > into an Assertion and a Response. That description can deal with > the SAML Status and Condition elements. That I would agree with, but Conditions is a different animal from Status and probably doesn't need any mention here. One way or the other it needs to be clear what the relationship is. -- Scott--- End Message ---
-- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692