Subject: RE: XACML extensions to SAML. Forwarded message from Scott Cantor.
Comments from SSTC member on XACML Profile for SAML on how we would handle the SAML Status and Conditions elements. 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. 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. 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. Here are the current SAML Response and Status schema fragments. <element name="Response" type="samlp:ResponseType"/> <complexType name="ResponseType"> <complexContent> <extension base="samlp:StatusResponseType"> <choice minOccurs="0" maxOccurs="unbounded"> <element ref="saml:Assertion"/> <element ref="saml:EncryptedAssertion"/> </choice> </extension> </complexContent> </complexType> <complexType name="StatusResponseType"> <sequence> <element ref="saml:Issuer" minOccurs="0"/> <element ref="ds:Signature" minOccurs="0"/> <element ref="samlp:Extensions" minOccurs="0"/> <element ref="samlp:Status"/> </sequence> <attribute name="ID" type="ID" use="required"/> <attribute name="InResponseTo" type="NCName" use="optional"/> <attribute name="MajorVersion" type="integer" use="required"/> <attribute name="MinorVersion" type="integer" use="required"/> <attribute name="IssueInstant" type="dateTime" use="required"/> <attribute name="Recipient" type="anyURI" use="optional"/> </complexType> <element name="Status" type="samlp:StatusType"/> <complexType name="StatusType"> <sequence> <element ref="samlp:StatusCode"/> <element ref="samlp:StatusMessage" minOccurs="0"/> <element ref="samlp:StatusDetail" minOccurs="0"/> </sequence> </complexType> <element name="StatusCode" type="samlp:StatusCodeType"/> <complexType name="StatusCodeType"> <sequence> <element ref="samlp:StatusCode" minOccurs="0"/> </sequence> <attribute name="Value" type="anyURI" use="required"/> </complexType> <element name="StatusMessage" type="string"/> <element name="StatusDetail" type="samlp:StatusDetailType"/> <complexType name="StatusDetailType"> <sequence> <any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType>
--- Begin Message ---
- From: Scott Cantor <firstname.lastname@example.org>
- To: Anne.Anderson@Sun.COM, 'Eve Maler' <Eve.Maler@Sun.COM>
- Date: Tue, 27 Jul 2004 23:54:18 -0400> It seemed very straightforward with the current SAML 2.0 Request > and Statement types. If you want to look them over (as a proof > of concept for SAML 2.0 extensibility), they are attached. > Comments are VERY welcome. Seems to be reasonable based on my memory of what the requirements were. IIRC, the main issue I had was with the duplication of protocol-related data in the XACML Response element, like a status code, but I think that's been made optional for 2.0? Does the XACML SAML profile for carrying this inside a SAML protocol exchange specify to use the SAML Response for handling the status, or is it like an "XACML processing status" that's distinct from the protocol? I guess terminology-wise, it's still potentially confusing: samlp:Response samlp:Status saml:Assertion xacml:XACMLAuthzDecisionStatement xacml:Response xacml:Status Is it reasonable to consider just putting the xacml:Decision and xacml:Obligations elements directly in the new statement type? That seems like it aligns more directly to the SAML authz statement type, just with more functionality. -- 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