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] | [List Home]

Subject: new SAML 2.0 errata/issues

I’ve been jotting notes and dog-earing pages in the spec for awhile now for some minor and some not-so-minor things that I think should be dealt with in the errata updates to the specs… Sorry for the big “batch”.  If folks wish to have thread discussions on any of the individual items, please create a separate message with a new subject line rather than replying to this specific thread.



  1. Table 1 (Possible Implmentations): The first column is labeled “Profile”, yet several of the entries are technically not “profiles”.  The same comment really applies to the section title and the paragraph above the table.
    1. “Authentication Query”, “Attribute Query”, “Authorization Decision Query”, and “Request for Assertion by Identifier” are not individual profiles; they are types of messages sent as part of the “Assertion Query/Request Profile”.  So I think that they should be collapsed into a single Profile row, with 4 separate sub-rows under the “Message Flows” column (refer to how it’s done for Web SSO and Single Logout profile rows).
    2. “SAML URI binding” is not a profile at all; it’s a binding.  This one particularly confused people since the third column of the table is for the supported bindings, for which this row lists “HTTP” as it’s binding.  But we do not define an HTTP binding (we do define HTTP Redirect, HTTP POST, and HTTP Artifact bindings, but none of these apply here).  IMO, the “right” solution for this would be, in the Bindings doc, to break the “Assertion Query/Request Profile” into separate “Assertion Query Profile” and “Assertion Request Profile” sections. The query profile would profile use of the authn, attr, and authz queries using the SOAP binding.  The request profile would profile the use of the assertion ID request using both the SOAP and SAML URI bindings.  I’ve had many people find it confusing that they were lumped together, BTW, because it didn’t include any discussion of the SAML URI Binding; I understood it, but folks reading it really were confused.  Anyway, if that split was done, Table 1 in the conformance doc would remove the row for SAML URI binding as a “profile”, and my suggestion in (a) above would result in 2 rows, one for each profile.  Unfortunately, breaking the profile into two profiles is a bit beyond errata, IMO, so at a minimum, I believe we need to remove this “binding” row from the current table.  It should perhaps be mentioned as a feature in a separate paragraph.
    3. The list of attribute profiles is missing the “Basic Attribute Profile”.
    4. Rather than leaving blank entries for the “Message Flows” and “Binding” columns, would it be preferable to list “N/A”.  Currently, the table looks like we forgot to finish filling it out.
    5. “Metadata” is not a profile; “Consumption” and “Exchange” are not message flows.  This particular item should probably be broken out of the table altogether and listed as a separate feature with info on consumption/processing of MD and info on the possible publication and resolution mechanisms.  Ideally, we could have someone actually write a metadata profile or two and then we could add them as profile rows.  But that’s really not errata.
  2. Table 2 (conformance Feature Matrix):
    1. We mandate support for the HTTP Artifact binding for a Web SSO <Response> in full and Lite versions of IDP’s and SP’s.  However, we do not indicate what mechanisms (HTTP Redirect or HTTP POST) are mandated for delivery of the artifact. This decision then dictates which encoding forms are required (URL-encoding for redirect and/or FORM-encoding for POST).  Were we assuming both delivery mechanisms MUST be supported? Just the redirect method?  The conformance doc should state what our assumption was here.  Or if we can’t agree on what our assumptions were, we should state that one or the other must exist, but it is not defined for conformance (I don’t like this option).
    2. The table is missing feature rows for performing a “Request for Assertion by Identifier” over SOAP and for “SAML URI Binding”.  These features are clearly permissible for IDP’s, since the IDPSSODescriptor includes an element for zero or more <AssertionIDRequestService> elements.  It’s okay with me to list them as OPTIONAL under IDP/IDPLite (and N/A for SP, SPLite, and ECP) if that’s what was intended, although I don’t recall what was intended.  But they are features and should be listed.



  1. Line 3110: “optionally one or more” sounds a little confusing.  May I suggest changing to simply “zero or more”?  The “zero”  gets the “optional” point across.



  1. Line 511: “security at the SOAP message layer is recommended.” I believe we should capitalize “RECOMMENDED”.
  2. Line 785: “If no such value is included with a SAML request message” – “value” is a little ambiguous.  It’s referring to the RelayState parameter, which itself is a name/value pair.  I suggest changing to “If no RelayState parameter is included…”
  3. Same comment on line 1022.
  4. Line 1136: “using a direct SAML binding”.  We have no definition for what a “direct” SAML binding is.  Elsewhere, we have referred to the SOAP binding as a “synchronous” binding.  Should we really use “synchronous” here?
  5. Line 1397: “Note that use of wildcards is not allowed on such ID queries”.  Does it make sense to normatively phrase this as “Note that wildcards MUST NOT be permitted on such ID queries.”



  1. Line 322: “Unlike the authentication context” seems to be a pretty obscure, confusing reference in this sentence.  Could someone please clarify what it means?
  2. Section 4.3: This profile is missing a subsection for “Required Information” that we put in all other profiles.
  3. Section 6: See my comments in Metadata re: breaking the Query/Request profile into separate profiles (although this probably can’t be considered as errata).



  1. Line 264: re: the “index” of an IndexedEndpointType: Do we need to specify a range for this item?  When an endpoint index is used in an artifact, it is limited to 2 bytes.  Thus, it should probably be restricted to integers from 0-65535.  Right?
  2. Line 392: The text is not actually clear which elements above and below the “OR” clause on line 392 are part of the clause.  You can figure it out from looking at the schema snippet, but perhaps it could be clearer through an alternative layout/text.
  3. Lines 700, 871, and 904: “profile of the Assertion Request protocol defined in [SAMLProf]”.  Both the protocol and the profile are named “Assertion Query/Request”, not “Assertion Request”.
  4. Line 809: the section should really be indented so that it is since <RequestedAttribute> is part of the <AttributeConsumingService> defined in section  [There is a precedence for going to header level 5 section numbers in core.]



Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
I-name:  =Rob.Philpott


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]