comments: sstc-saml-holder-of-key-browser-sso-draft-01

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

Hi Nate,

Here are some comments on the "Holder-of-Key Web Browser SSO Profile":

http://wiki.oasis-open.org/security/SamlHoKWebSSOProfile

This is an important piece of work.  I've reviewed this draft document
and have a large number of comments (which is good :).  Rather than
post all of these here (mostly due to laziness, but partly to avoid
being counter-productive), I'll provide some general comments below in
hopes that my (unreported) detailed comments will be addressed as a
matter of course in the next revision.

- This document needs a section entitled 'Security and Privacy
Considerations" (or something similar).  There's a lot of text in this
document, mentioned in passing, that would have more effect if it were
aggregated in a non-normative "Security" section.  Examples of such
text include much of section 2.2 (including lines 223--232) and any
reference to "issuer," "subject," "X.509 subject," "subjectAltName,"
and "X.509 subjectAltName" set in monospace font.  (By the way, why
are the latter set in monospace font?)

- IMO, section 2.3 (Profile Overview) should not use normative
language.  I realize [SAML2Prof] does this, but I don't recommend it,
especially since related requirements are spread throughout section 2.
 So I suggest you state all normative requirements in the body of
section 2, beginning with section 2.4.

- Is this profile meant to be a refinement of the Web Browser SSO
Profile in [SAML2Prof] or is it meant to be a complete replacement?
(Yes, I read lines 195--196 but I have to ask.)  I suspect it's meant
to be a refinement, otherwise there's more work to do to cover all the
bases touched by [SAML2Prof].  In that case, I recommend you remove
any redundant requirements (i.e., requirements already covered by
[SAML2Prof]) unless reiterating those requirements helps to prevent
misinterpretation.  Some requirements can be removed regardless of the
profile's relationship to [SAML2Prof]; for example, most (if not all)
of section 2.7 (Use of Metadata) can be eliminated, I think.

- Wherever encryption is mentioned, one gets the impression it is
required or assumed.  But encryption is not required as far as I know,
so any subsequent conclusions or requirements seem to be based on a
false assumption.  So what are the encryption requirements of this
profile?  I suspect there are none, so I suggest you go back and
rewrite any paragraph that has the word "encryption" in it.

- In section 1.3 (Conformance), try to specify what sections are
required for a conforming SP.  Similarly, specify what sections are
required for a conforming IdP.  I don't think you want to leave this
up to the reader.

- The body of section 2 (sections 2.4 and 2.5) is disorganized.  For
one thing, there is more than one incorrect cross-reference, which is
annoying.  Perhaps the next version of the document can reorganize the
subsections in section 2.  It would be helpful if there were a
one-to-one mapping between the subsections of sections 2.4 and 2.5,
respectively.  In the very least, cross-references should be used
freely, and they should be correct.

- I suggest you break out the authentication request/response sequence
into a separate profile.  This will, first of all, simplify an already
complicated section 2. Secondly, it's likely someone will want to
implement the authentication exchange outside of the normal browser
profile.  Indeed, the HTTP-based authentication request/response that
you've profiled here is much easier to implement than the SOAP-based
attribute self-query I profiled recently!  So having those
requirements in a separate section would be very helpful.

Thanks for this valuable contribution, Nate.

Tom Scavo
NCSA