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: rphilpott@rsasecurity.com
I-name: =Rob.Philpott
|