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

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

To follow-up on the SubjectConfirmation issue, lines 441--450 seem to
contradict the strongly matches requirement from [SAML2Core].  If you
want to restrict the SubjectConfirmation in the assertion, you're
obliged to restrict the SubjectConfirmation in the request (due to the
strongly matches requirement in Core).  In draft-06, however, I can
find no requirements on the SubjectConfirmation in the request.

Actually, I don't think any restrictions on SubjectConfirmation are
needed.  You could specify the following, for instance:

- The requester MAY include a SubjectConfirmation element in the AuthnRequest.

- If there is a SubjectConfirmation element in the AuthnRequest, the
IdP MUST honor it or return an error.  (This may be a redundant
requirement because of the strongly matches requirement in Core.)

- If there is no SubjectConfirmation element in the AuthnRequest, the
IdP MUST include a ds:X509Certificate element in the response.

In the simplest case, the SP will omit the SubjectConfirmation element
in the AuthnRequest and the IdP will include a ds:X509Certificate
element in the response.

Tom

On Tue, Sep 2, 2008 at 10:33 AM, Tom Scavo <trscavo@gmail.com> wrote:
> 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
>