OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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
As I said in that message, if there's better language for any of this, speak

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

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

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