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] | [List Home]


Subject: comments: sstc-saml-x509-authn-attrib-profile-draft-11


Document identifier: sstc-saml-x509-authn-attrib-profile-draft-11

Errata:

[line 76] s/section /section 3/

[line 77] s/section /section 4/

[line 138] Delete this empty line.

[line 144] s/Based/In step 4, based/

[line 146] s/sequence steps/sequence of steps/

[line 146] s/Sections/sections/

[line 166, 168, 175, 178, 179, 229, 260] s/Section/section/

[lines 171--175] Decrease the indentation of these lines one level.

[line 174] s/isurn/is urn/

[line 178, 229] s/defined/specified/

[line 202] s/the Basic Mode/Basic Mode/

[line 245] s/Optionally, the/The/

[line 252, 277, 300] s/assertions and protocols/Assertions and Protocols/

[line 274] s/assertions/encrypted assertions/

[line 279] s/Encrypted mode/Encrypted Mode/

[line 287] s/Optionally, and if supported by the service provider, the/The/

[line 287] s/Optionally, and if supported by the service provider, and if/If/

[line 310] Replace the curved quotes with straight quotes.

[line 326] s^username/password^credential (most likely a username/password)^

[line 329] s/attribute requester/attribute requester (i.e., the
service provider)/

[line 332] s/service provider/attribute requester/

[line 342] s/situations/deployment scenarios/

[line 384] s/SAML Metadata Extension/Metadata Extension/

[line 385] s/OASIS/OASIS Draft/

[line 391] Remove the extraneous indentation.

[lines 399--402] Remove the bold text.

Specific Comments:

[line 113, 117, 129, 135, 137, 151, 172, 204] What precisely is meant
by the term "X.509v3 certificate"?  In section 1, the term "X.509
certificate" is defined, but "X.509v3 certificate" is used throughout.
 I would suggest either to use the term "X.509 certificate" throughout
or modify the definition in section 1.  If you choose to do the
latter, note that term "X.509 v3 certificate" is used in RFC3280, not
"X.509v3 certificate".

[lines 130--132] I would suggest deleting these lines and replacing
them with this sentence: "The details of this step are out of scope
for this profile."

[line 160, 214] Should the URNs contain the string "2.0"?  If not, how
do we distinguish between this profile and a similar profile bases on
SAML V1.1?

[lines 181--182] These lines are mostly redundant considering the
previous four lines.  Can you combine lines 177--182 into a single
paragraph?

[lines 184--193] Just a reminder that these lines were discussed in
detail on the mailing list.

[lines 188--189] This requirement assumes that the IdP is able to
authenticate the SP, but nowhere in this section is client
authentication required.

[section 3] Why did you delete section 3.3.2 (Error Processing) from
draft-10?  (Not a big deal, I guess---just curious.)

[section 3] What are the security requirements of Basic Mode?  This is
not clear from reading this section.

[line 218] Is Encrypted Mode more properly thought of as an extension
of Basic Mode?  Indeed, section 3 is referenced repeatedly in section
4, so this would seem to be the case.  I think this line should be
modified to reflect this.

[line 244, 286] I suggest you delete this line.  It can't be enforced
so I don't see the point of making such a vacuous requirement.

[lines 287--291] In effect, this key becomes a "previously established
symmetric key."  How long does this key remain a previously
established symmetric key?  In other words, should the IdP cache this
symmetric key, or should it be discarded immediately after use?

[lines 287--296] These two options are mutually exclusive.  This
should be indicated as such.

[lines 303--306] The <Assertion> signature is discussed, but what
about the <Response>?  Must it, too, satisfy FIPS 140-2 Security
Requirements?

[lines 338--339] I totally agree with this sentence, but this is not
mentioned in section 3.

[section 6] Much of the implementation guidance from draft-10 was
omitted from draft-11.  Although the material is only informative, and
therefore expendable, I'm curious why you chose to omit it?

[section 7] Note that much of the text in this section is blue.  Only
the URLs should be blue, I think.

[lines 369--370] This is reference is totally incorrect.  See draft-10
for a precise reference for RFC 3280.

General Comments:

Shouldn't this spec be cast as a "deployment profile"?  I may be
mistaken, but I thought it was agreed that this spec was to be
formulated as a deployment profile.

The diff is evidently against CD-02, but I believe it should be
against draft-10, right?

Can you include a detailed Revision History (from the old, deprecated draft-11)?

The default namespace prefix is ambiguous.  Unqualified elements from
namespaces urn:oasis:names:tc:SAML:2.0:assertion and
urn:oasis:names:tc:SAML:2.0:protocol are used throughout the document.

----------------------
Tom Scavo
NCSA/University of Illinois


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