[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Errata in "SAML 2.0 profile of XACML"
Eve Maler and I compared the Committee Specifications for - SAML 2.0 Core, - SAML 2.0 Profiles (XACML section), and - SAML protocol and assertion schemas with the - XACML 2.0 Core, and - SAML 2.0 profile of XACML, and associated schemas We found no errors in the XACML section of SAML 2.0 Profiles, XACML 2.0 core, or in any of the schemas. Eve found minor errors in the SAML 2.0 Core, which she has reported to the SSTC. We found a few errors in the "SAML 2.0 profile of XACML": 1. Line 378: "When a <saml:AttributeAssertion> is used to construct an XACML Attribute, the string value of the <saml:Issuer> element SHALL be used as the value of the XACML issuer XML attribute, so the SAML value SHOULD be specified with this in mind." Change "SHALL" to "will". This sentence is merely describing behavior specified in Section 2.1 that has implications for the SAML value, and is not imposing a requirement here. 3. Line 414: "6 Element <samlp:Request> (normative)" Change "<samlp:Request>" to "<samlp:RequestAbstractType>" 4. Line 416: "...SHALL be encapsulated in a <sampl:Request> element, which MAY be signed." Change "<samlp:Request>" to "<samlp:RequestAbstractType> 5. Line 417: "Most components of a <samlp:Request> are fully specified in the SAML 2.0 specification..." Change "<samlp:Request>" to "<samlp:RequestAbstractType>" 6. Line 420: "Except as specified here, this Profile imposes no requirements or restrictions on information in the the <samlp:Request> element Change "<samlp:Request>" to "<samlp:RequestAbstractType>" 7. There is no section addressing how to use <EncryptedData> (described in Section 6 of SAML Core specification) with SAML <Attribute> or <Assertion> elements used as part of the XACML Profile. Should we add a section for this? The XACML Profile imposes no restrictions or requirements on the SAML Core except where XACML requires different or specific handling of SAML elements. Encryption does not affect XACML's use of SAML in any way that is different from the general way encryption affects any use of SAML elements, so perhaps this is not needed. My recommendation is that no new section or other material be added for SAML encryption considerations. I noticed two typographical errors: 8. Line 392-393: typo "The subject of the statement (s) in the assertion" Change to "statement(s)". 9. Line 426: font "SHALL be" Is currently in the font used for schema elements; change to normal text font. There were other mentions of "SAML Request" shown below. These did not refer to a specific schema element, but were referring to the general SAML Request and Response mechanisms, and so Eve and I recommend not changing these. I am including them here in case others have a different opinion. 10. Line 93: definition of "AttributeQuery" "A standard SAML Request used for requesting one or more..." 11. Line 98: definition of "XACMLPolicyQuery" "A SAML Request extension, defined in this profile." 12. Line 103: definition of "XACMLAuthzDecisionQuery" "A SAML Request extension, defined in this profile." 13. Line 252: "In order to allow a PEP to use the SAML Request and Response syntax..." 14. Line 256: "It allows a PEP to submit an XACML Request in a SAML Request along with other information." 15. Line 267: "It allows a SAML Request to convey an XACML Request Context instance." 16. Line 330: "The <XACMLPolicyQuery> element is used by a PDP to request one or more XACML Policy or PolicySet instances from an on-line Policy Administration Point as part of a SAML Request." 17. Line 347: "...in a SAML Response to an <XACMLPolicyQuery> SAML Request." Anne Anderson -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]