[security-services] Core spec errata

Hi all - Some of these items
may really trigger new issues or re-open some old ones.  If so, we can
open separate email discussions on each one in question...

 

 
Lines 722, 726: The font for the "Location"
     and "Binding" attributes is different from "AuthorityKind"
     on line 714.

 
Line 887: s/interger/integer/

 
Line 961: s/may/MAY/ ?

 
Line 966: s/success would normally/"Success MUST"/

 
Line 967: s/to be found therein/will be included/

 
Lines 969-970: "exactly as for saml:AuthorityKind
     attribute; see Section 2.4.3.2" - The AuthorityKind section is
     referring to samlp:Query references not saml:Statement references. 
     Folks read the reference to AuthorityKind and sometime try to figure out a
     relationship between RespondWith and AuthorityKind, which of course does
     not exist.  The section reference is intended to highlight the use of
     saml and samlp QNames. Also, AuthorityKind is an attribute, while RespondWith
     is an element, so the methods for specifying the values are different. I
     recommend removing the section reference and simply insert similar text
     inline.

 
Line 971: s/must/MUST/ ?

 
Section 3.2.1.1 - I think we should provide
     better guidance on rationalizing use of RespondWith elements in a query
     and the associated Query type.  I know there's been some discussion
     on this topic on the list, but I don't think the current text here is
     very clear. For example, we should be explicit about what happens on an AuthenticationQuery
     that includes a RespondWith for a saml:AttributeStatement.  Another
     example is when an authority has an existing Web SSO assertion that
     contains both AuthenticationStatements and an AttributeStatement (e.g.
     what we used in the Interop).  Now if a later AuthenticationQuery
     arrives for the SAML Subject with a RespondWith of saml:AuthenticationStatement,
     this Web SSO assertion should NOT be returned according to lines 963-964.
     So we should be explicit that if an assertion contains multiple statement
     types, there must be a RespondWith in the query for every statement type
     in the assertion (assuming at least one RespondWith is specified).

 
Section 3.2 (Requests) - Section 3.3 (Queries)
     provides not only definitions of query elements, it also provides
     processing rules and interpretation info for the Queries.  But we don't
     do that for the <AssertionArtifact> or <AssertionIDReference>
     request types.  Section 3.2.3 defines the <AssertionArtifact>
     element but doesn't say how it is used (of course this is discussed
     in the Profiles).  There is no section describing the RequestType "saml:AssertionIDReference"
     here since the element is defined in section 2.3.1.  When someone
     asked me why AssertionIDReference wasn't described, I at first
     thought it was an omission since all of the other request and query types
     are discussed in 3.2 and 3.3.  Then I realized the saml/samlp
     distinction. But it might be clearer and avoid questions if there was a
     brief mention of processing rules for AssertionIDReference.

 
Lines 1061-1065: In addition to subject and authn
     method matching rules, we should indicate that the assertion processing
     rules are also impacted by the presence of RespondWith elements in the
     Query.

 
Section 3.3.4 AttributeQuery - Should also
     mention the subject-matching rules as described in section 3.3.3

 
Line 1085: "the start of the current document"
     - In a query, the samlp:Request is the **current** document, so what
     does it mean to use a Resource with an empty URI?

 
Section 3.3.5 AuthorizationDecisionQuery - Should
     also mention the subject-matching rules as described in section 3.3.3

 
Line 1219: s/request. top-most/request. The top-most/

 
Line 1237: s/subcodes MAY be/subcodes may be/ (should
     not use normative "MAY")

 
Section 3.4.4 (Responses to <AuthnQuery> and <AttrQuery>)
     - Don't the saml:Subject matching rules described in this
     section also apply to <AuthzQuery>?  In fact, I assume the
     rules should apply to all <SubjectQuery> requests, including and
     extensions.  So I think the section should be more general.

 
Line 1417: s/REQUIRES/requires/

 
Section 5.4.2 (C14n) - We should mention the
     preference for Exclusive C14N and refer to the external DSig Guidelines
     document.

 

Rob Philpott 

RSA Security Inc. 

The Most Trusted Name in e-Security 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: