[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: comments re sstc-saml-holder-of-key-browser-sso-draft-06
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]