I will enter this into
the errata document with disposition TBD. Some of these are fairly trivial and
we should be able to knock them out quickly. Some others will undoubtedly
generate more discussion.
Thanks,
Jahan
---------------- Jahan Moreh Chief Security
Architect 310.286.3070
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
|