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


  1. Lines 722, 726: The font for the "Location" and "Binding" attributes is different from "AuthorityKind" on line 714.
  2. Line 887: s/interger/integer/
  3. Line 961: s/may/MAY/ ?
  4. Line 966: s/success would normally/"Success MUST"/
  5. Line 967: s/to be found therein/will be included/
  6. Lines 969-970: "exactly as for saml:AuthorityKind attribute; see Section" - 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.
  7. Line 971: s/must/MUST/ ?
  8. Section - 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).
  9. 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.
  10. 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.
  11. Section 3.3.4 AttributeQuery - Should also mention the subject-matching rules as described in section 3.3.3
  12. 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?
  13. Section 3.3.5 AuthorizationDecisionQuery - Should also mention the subject-matching rules as described in section 3.3.3
  14. Line 1219: s/request. top-most/request. The top-most/
  15. Line 1237: s/subcodes MAY be/subcodes may be/ (should not use normative "MAY")
  16. 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.
  17. Line 1417: s/REQUIRES/requires/
  18. 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


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

Powered by eList eXpress LLC