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

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

This is a very valuable document, with important consequences beyond
web browser SSO.  (I'll have more to say about this in a separate
message.)

I proofread most of this document, but I realized about halfway
through that there are bigger fish to fry here, so I'll refrain from
nit picking details except for these two:

- The word "section", as used in the phrase "section 2.4.3" for
example, should not be capitalized (except at the beginning of
sentences of course).

- Specific references to XML elements should be of the form
"<ElementName> element," not simply "<ElementName>".  For example,
refer to "the <samlp:Response> element," which is easier to digest,
especially for novices.

Comments:

- The note re SSL3 is hidden on line 153.  Can this note be more
prominently displayed?  Also, at least two cross-references are needed
in this paragraph (which is now only a single sentence).

- [SAML2Bind] on page 6 refers to the wrong spec.

- Is client TLS required initially at the SP?  (Section 2.4.2 seems to
indicate that this is so.)  If so, this should be called out
explicitly in section 2.4.1.  However, I don't see why the initial
request should require client TLS?  Am I missing something?

- On line 294, I don't know what a "primary identity provider" is.  Do
you mean "preferred identity provider"?

- On lines 301--303, it says the endpoint location is determined by
the binding and that SAML metadata may be used for this purpose.  I
don't think binding determines the endpoint since this profile, for
example, may require a separate endpoint location (but read on).
Along these lines, how would one configure metadata for this purpose
(if, in fact, one were using SAML metadata)?

- The sentence on lines 308--310 is ambiguous.  Is a signature required or not?

- On lines 311--312, a signature would preclude HTTP Redirect as well,
correct? (I think you mention this elsewhere, but this is where it
belongs, I think.)

- The requirement on lines 328--330 is crucial and should be elevated
to an earlier section.

- The remark on lines 333--335 belongs in section 4, I think.

- On lines 346--347, it says the endpoint location of the assertion
consumer service at the SP may be obtained from SAML metadata.  Why
can't SP metadata indicate that the SP wants holder-of-key SSO
assertions (something like 'wantsHolderOfKey' for instance)?

- On line 364, it says the SP "grants or denies access to the
resource."  I don't think this is correct.  Should it say instead that
the SP "creates a security context for the user?"

- On line 367, it says the SP "MAY establish a security context with
the user agent."  I'm not sure I buy this.  When would the SP NOT
establish a security context (if only a short-lived one)?  This is, in
fact, what the SP does (see previous comment).

- The introduction to section 2.5 is crucial, portions of which should
perhaps be elevated to an earlier section.  For example, the fact that
the SP is the requester precludes the principal as requester.  More
importantly, this section is clearly not about the use of the
AuthnRequest protocol since the latter has nothing to say about the
SP.  The AuthnRequest protocol is between the presenter and the IdP.

- The bulleted item starting on line 381 seems to imply that the
initial request to the SP need not be over client TLS.  If so, this
seems to contradict earlier requirements implicit in section 2.4.1 and
explicit in section 2.4.2.

- On lines 381--384, I see no reason why the SP would want to include
KeyInfo in the request.  What would be the purpose of doing so?  On
the other hand, I could imagine the SP might include a holder-of-key
SubjectConfirmation element (with no KeyInfo) to signal its desire for
a h-o-k SSO assertion.  Why not include this in this specification?

- On line 391, it says "authentication of the parties is OPTIONAL" in
the case of HTTP Artifact, but authentication is optional in any
event, is it not?

- The bulleted item on lines 421--429 should be split into at least
two separate items.  First, more detail about the KeyInfo element is
needed (right here, not in some other section).  Second, a
cross-reference to section 3 would be helpful.  Finally, I don't think
you should reference the conformance section here (or anywhere) since
this leads to circular reasoning!

- I'm not sure what you're worried about on lines 447--448.  In fact,
the certificate may very well contain other information the SP may
wish to add to the user's security context.  Would it be better to say
that anything else the SP does with the certificate is out of scope
with respect to this profile?  I don't believe this profile has any
business telling the SP that it can not process the certificate
further if it wishes.

- I don't understand the requirement on lines 462--463.  Isn't it
sufficient to sign the Response?

- On line 465, I think it would be better to say "this profile is
related to the Web Browser SSO Profile."

- Can you provide an example of what you're referring to on lines 467--469?

- The introductory sentence to section 4 doesn't make any sense to me,
I'm afraid.

- Self-signed certificates can circumvent the privacy issues alluded
to in the bulleted item on lines 480--485 except for the last
sentence, which is the only significant point as far as I can tell.

- I don't see what section 2.5.2 has to do with the bulleted item on
lines 486--488.

- I see you removed lines 489--492 from draft-04 (due to a comment
from Scott, I presume).  In doing so, an important point was thrown
away, namely, this profile guarantees that a replay attempt is
virtually guaranteed to be from the requested subject.  In other
words, replay attempts from rogue third parties are eliminated.

- The sentence on line 493 is accurate, but the rest of that bulleted
item is confusing and seems to have nothing to do with h-o-k SSO
assertions.  Am I missing something?  What exactly are you trying to
say in this bullet?

- I don't understand the requirement on line 501.  If the SP says it's
going to sign requests, the IdP doesn't have to do anything but verify
the signature (which it would have to do in any event).  The fact that
the SP calls this out in metadata seems like one of those metadata
items that carries little if any significance whatsoever.

- In general, you need to describe the metadata requirements of this
profile (if, in fact, SAML metadata is used).

- The SP should be able to call out its desire for holder-of-key SSO
assertions, either via metadata or by including a SubjectConfirmation
element (but no KeyInfo) in the request.  For IdP-first scenarios,
metadata is the only option that will work.  For SP-first flows, a
SubjectConfirmation element should be sufficient.  In either case, I
don't see why the IdP should need a separate endpoint location for
this profile.

Tom Scavo
NCSA