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.

 

Conformance:

 
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.

 
  
“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).

  
“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.

  
The list of attribute profiles
      is missing the “Basic Attribute Profile”.

  
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.

  
“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.

 
 
Table 2 (conformance Feature
     Matrix): 

 
  
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).

  
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.

 

 

Core:

 
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.

 

Bindings:

 
Line 511: “security at
     the SOAP message layer is recommended.” I believe we should
     capitalize “RECOMMENDED”.

 
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…”

 
Same comment on line 1022.

 
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?

 
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.”

 

Profiles:

 
Line 322: “Unlike the
     authentication context” seems to be a pretty obscure, confusing
     reference in this sentence.  Could someone please clarify what it
     means?

 
Section 4.3: This profile is
     missing a subsection for “Required Information” that we put in
     all other profiles.

 
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).

 

Metadata:

 
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?

 
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.

 
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”.

 
Line 809: the section 2.4.4.2
     should really be indented so that it is 2.4.4.1.1 since
     <RequestedAttribute> is part of the <AttributeConsumingService>
     defined in section 2.4.4.1.  [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

Email: 

I-name:  =Rob.Philpott