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:rphilpott@rsasecurity.com
|