[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] Proposed normative text for ISSUE:[DS-14-11:CompareElements]
This message expands on the text I originally posted in http://lists.oasis-open.org/archives/security-services/200201/msg00228.html. As I said in that message, if there's better language for any of this, speak up. For the purposes of this message, I'll assume that we're adding a section on value comparisons to the end of Section 1 of Core. I'll send another message with proposed comparison rules for some specific elements. 1.4 Comparing SAML values Unless otherwise noted, all elements in SAML documents that have the XMLSchema "string" type, or a type derived from that, MUST be compared using an exact binary comparison. In particular, SAML implementations and deployments MUST NOT depend on case-insensitive string comparisons, normalization or trimming of white space, or conversion of locale-specific formats such as numbers or currency. This requirement is intended to conform to the W3C Requirements for String Identity, Matching, and String Indexing (http://www.w3.org/TR/WD-charreq). If an implementation is comparing values that are represented using different character encodings, the implementation MUST use a comparison method that returns the same result as converting both values to the Unicode character encoding (http://www.unicode.org), Normalization Form C (as described in http://www.unicode.org/unicode/reports/tr15/tr15-21.html) and then performing an exact binary comparison. This requirement is intended to conform to the W3C Character Model for the World Wide Web (http://www.w3.org/TR/charmod/), and in particular the rules for Unicode-normalized Text (http://www.w3.org/TR/charmod/#sec-Unicode-normalized) Applications that compare data received in SAML documents to data from external sources MUST take into account the normalization rules specified for XML. Text contained within elements is normalized so that line endings are represented using linefeed characters (ASCII #x0A), as described in section 2.11 of the XML Recommendation (http://www.w3.org/TR/REC-xml#sec-line-ends). Attribute values defined as strings (or types derived from strings) are normalized as described in section 3.3.3 (http://www.w3.org/TR/REC-xml#AVNormalize); all white space characters are replaced with blanks (ASCII #x20). The SAML specification does not define collation or sorting order for attribute or element values. SAML implementations MUST NOT depend on specific sorting orders for values, because these may differ depending on the locale settings of the hosts involved. ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC