comments re sstc-saml-holder-of-key-browser-sso-draft-06

["Tom Scavo" <trscavo@gmail.com>]

Document ID sstc-saml-holder-of-key-browser-sso-draft-06

General comments:

- Can you change the namespace URI and prefix as suggested here:
http://lists.oasis-open.org/archives/security-services/200808/msg00057.html

- Can you reference the "Holder-of-Key Assertion Profile" as suggested here:
http://lists.oasis-open.org/archives/security-services/200809/msg00000.html

- Use either "Single Sign-On Service" or "single sign-on service" throughout.

- Use either "Assertion Consumer Service" or "assertion consumer
service" throughout.

- In section 2.6, can you say something about the WantAssertionsSigned
attribute?  Is the IdP required to honor this attribute, if present?

- I don't believe the solution proposed in section 2.6 is general
enough.  Some other profile will likewise have to define a "Protocol"
attribute since basically this is a bug in SAML metadata.  Should the
"patch" be defined once and for all?

Specific comments:

[lines 145--146] I understand the intention of this sentence, but
elsewhere in the document you suggest that the certificate might be
used as an authentication token and/or IdP Discovery, so this sentence
appears to conflict with later suggestions.

[line 161] In the table, an URI is typeset in an inconsistent fixed-width font.

[lines 174--176] This reference is non-normative.

[lines 195--197] This reference is non-normative.

[line 202] AFAICT, the reference to section 2.4.3 belongs in section 1.3.2.

[lines 206--209] The content of the first bullet is called out later
in the document while the second bullet is covered by a reference to
the "Holder-of-Key Assertion Profile," so I believe these lines may be
removed.

[lines 220--223] See the comment re lines 206--209 above.

[lines 254--263] The sentence on lines 254--255 conflicts with the
paragraph on lines 259--263.  The X.509 certificate can not be used as
an authentication token without a "traditional PKI."

[page 9] Step 4 in the diagram should refer to the "X.509
certificate," not the "<samlp:AuthnRequest>" element.

[line 282] The first sentence in step 4 belongs in step 3.

[line 319] Some text on this line is typeset in an inconsistent
fixed-width font.

[lines 330--332] Although simplified from previous versions, this
sentence is still too complicated to be useful.  Can it be deleted
altogether?  The normative requirement on lines 411--412 more
elegantly address the signature issue, I think.

[lines 368--370] The phrase "MUST honor them if it can" is a
meaningless requirement.  Does the IdP return an error if it can't
honor these aspects the request?

[lines 419--421] These lines seem to contradict lines 366--370.

[lines 422--424] Do you mean to say if TLS client authentication fails?

[line 434] What is "it"?

[lines 441--450] These lines can be replaced by a reference to the
"Holder-of-Key Assertion Profile".

[lines 469--471] I believe this is an inappropriate use of the term
"strongly matches" but maybe I'm missing something.

[section 2.5.4.2]  This section is redundant (see lines 375--377).

[lines 501--502] Is it necessary that these endpoints be used
"exclusively" with this profile?  I don't see why this should be so.

[line 509] Why is this attribute called "Protocol"?  Isn't "Binding" a
more appropriate name for this attribute?  After all, it's value is a
binding URI.

[section 4] Combine the first and fourth bullets since they address
the same issue.

[lines 542--547] This isn't true (or at least it's misleading).  It
depends on whether or not the X.509 certificate is used as an
authentication token.  If it is, then what you say is true.  If it's
not, then most of these "limitations" can be avoided.

[lines 556--562] The first three sentences of this bullet should be
moved to section 2.6.  The last sentence should remain where it is.

Suggested edits:

[line 2] s/Holder-of-Key/SAML V2.0 Holder-of-Key/

[line 135, 237] s/4.1/section 4.1/

[line 136] s/identity provider/its preferred identity provider/

[lines 180--181] Join these lines.

[line 192] s/S. Cantor/J. Hughes/

[line 196] s/OASIS SSTC/OASIS Standard/

[lines 197--198] Join these lines.

[lines 255--256] Join these lines.

[line 259] Expand "PKI."

[line 273] s/proper identity provider/appropriate identity provider/

[line 310] s/request/HTTP request/

[line 380] s/TLS session/front-channel TLS session/

[line 396] s/message/<samlp:AuthnRequest> message/

[line 508] s/protocol/Protocol/

Tom Scavo
NCSA