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

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

SAML V2.0 Holder-of-Key Web Browser SSO Profile
Document ID sstc-saml-holder-of-key-browser-sso-draft-08 (ODT version)

General comments:

- Draft-08 seems to be missing from the archive.  The link in the SAML
wiki still works but the linked document is not exactly the same as
the one I've reviewed (the two are off by a few lines).  I don't know
what happened to that document.

- Section 1.5 needs to be replaced with an inline revision history as
suggested in this comment:

http://lists.oasis-open.org/archives/security-services/200811/msg00030.html

- A section entitled "TLS Usage" seems to be required.  The text in
this new section should reference the steps in section 2.3 and
emphasize where TLS is required and where it is optional.  Where it is
optional (step 1), the possible uses of client TLS should be outlined.
 (Possible uses of client TLS at step 1 include: 1) to construct a
specific <saml:SubjectConfirmation> element, 2) to use the TLS session
in lieu of a cookie-based session, and 3) to use information in the
certificate for the purposes of IdP Discovery.)

- Step 2 in section 2.3 needs to be rewritten.  (In particular, the
last phrase in the last sentence is not clear.)  Also, I think the
Identity Provider Discovery Profile should be mentioned (as long as
you're mentioning other approaches to discovery).

- I think much of section 2.5.2 has been rewritten in draft-09.
That's good since this section needs a lot of work.

- Bullets 3 and 8 in section 2.5.3 should be combined.  Bullets 9 and
10 can be combined.

- After combining the requirements of sections 2.6 and 3, I think I
know how to configure endpoints used exclusively with Web Browser SSO
or HoK Web Browser SSO, but I'm not clear how to configure an endpoint
that permits both.  Please describe.

- I'm still waiting for an opportunity to edit this document :-)


Specific comments:

- [lines 32--39]  Here is a revised abstract:

This profile allows for transport of holder-of-key assertions by
standard HTTP user agents with no modification of client software and
maximum compatibility with existing deployments.  Most of the flows
are as in standard Web Browser SSO [SAML2Prof], but an X.509
certificate presented by the user agent through client TLS
authentication supplies a key that results in a holder-of-key
assertion. Proof of possession of the private key corresponding to the
public key in the certificate resulting from TLS authentication
strengthens the assurance of the resulting authentication context and
protects against credential theft.  Neither the IdP nor the SP are
required to validate the certificate.

- [lines 329--330] I think a reference to [SAML2HoKAP] is appropriate here.

- Add the following paragraph at the end of section 2.4.4:

If the principal is unable to prove possession of the private key
corresponding to the public key bound to the certificate (via TLS), or
the identity provider is unable to retrieve the X.509 certificate
resulting from the TLS exchange, the identity provider MUST return an
error.  Otherwise the identity provider follows the rules specified in
section 2.5.2.

- [lines 343--345] The first part of this sentence should be moved to
section 2.4.1 as a requirement for the SP.  Then rewrite the sentence
as an "if-then" requirement.

- [lines 347--350] Break this one-sentence paragraph into at least two
sentences.

- [lines 360--361] I don't think there's any question that the SP will
establish a security context.  Can you give a use case where a
security context is not established?

- [lines 361--362] Can you reword this sentence for clarity?

- [lines 376--380]  I think these requirements have been reworded in
draft-09.  If not, this needs work.

- [lines 435--437] This requirement makes no sense, I think it should
be removed or at least reworded.

- [lines 461--462] Use profile names rather than URIs here.

- [lines 466--472] Is exclusivity required here?  Are there really two
sets of requirements, one for endpoints to be used exclusively with
this profile and one for shared endpoints?  I think this needs to be
made clear.  (See comments re section 3 as well.)

- [lines 490--491] This statement is true in general, not just for this profile.

- [lines 495--496] What are the "security precautions appropriate for
standard bearer assertions"?  A reference is required here.

- [lines 497--499] Here's the requirement I was looking for in section
2.6.  I think this requirement needs to be moved to section 2.6 for
clarity and precision.


Suggested edits::

- [line 27, 130] s/Profile/Profile described/

- [line 132] s/user agent needs to acquire/user agent acquires/

- [line 285] s/unsigned and//

- [line 300] s/X.509 subject/X.509 subject distinguished name/

- [line 307] s/user agent/user agent in section 2.4.1/

- [line 316] s/message using, for example,/message, using for example/

- [line 320] s/or referenced/in whole or in part/

- [line 335] s/[SAML2Bind]/the chosen binding [SAML2Bind]:/

- [line 336] s/to the/to the assertion consumer service at the/

- [line 347] s/message resulting from section 2.4.5 to the service
provider/response message to the service provider resulting from
section 2.4.5/

- [line 359] s/[SAML2Core]/[SAML2Core] and section 2.5.4/

- [line 411] s/metadata or/metadata or a <saml:SubjectConfirmation> element in/

- [line 439] s/which is not valid/that is not valid/

- [line 471] s/hoksso:ProtocolBinding attribute/attribute called
hoksso:ProtocolBinding/

- [line 472] s/original/desired/

- [line 491] s/<saml:SubjectConfirmation>/<saml:SubjectConfirmation> element/

- [line 494] s/subject confirmations/subject confirmation elements/

- [line 501] s/assertions and protocols supporting their issuance and
confirmation have/Web Browser SSO has/

- [line 526] s/must ensure/ensure/

Tom Scavo
NCSA