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

Document ID: sstc-saml-holder-of-key-browser-sso-draft-05

Comments:

- Changes to this draft, especially sections 2.4.1 and 2.4.2, seem to
indicate that the initial request to the SP does *not* require SSL/TLS
client authentication.  I agree that's the way it should be, I'm just
double-checking my reading of the manuscript.  Should this fact be
highlighted, perhaps by noting that the initial request by the UA to
the SP MAY be mutually authenticated SSL/TLS?

- In section 2.4.3, please refer to the new section 2.6.  In fact, the
first paragraph in section 2.4.3 needs to be rewritten in light of
this new section.

- The paragraph at lines 330--332 is ambiguous.  The word "MUST"
should not be used here.

- In section 2.4.5, please refer to the new section 2.6.

- In lines 377--379, I'm concerned that the assertion "MAY be signed
if the HTTP Artifact binding is used," especially in light of the note
on lines 389--390.  I believe a HoK assertion MUST be signed,
regardless of how it is obtained.

- The requirement on lines 423--425 is incorrect.  The IdP is not in
the business of confirming the subject, its job is to produce
confirmable HoK <saml:SubjectConfirmation> elements.  The two are not
the same.

- On line 450, how does "the service provider indicates its ability to
process such keying information?"

- Thank you for editing the sentence on lines 472--473, but
unfortunately I still don't understand this requirement.  If that
sentence were omitted, what negative consequences would ensue?

- The type of the Protocol XML attribute should be a URI (since the
Binding XML attribute is a URI).

- Earlier, Nate asked me privately what I thought about possible
metadata requirements (section 2.6), and if I'd taken the time to
think about it then (sorry, Nate), I probably wouldn't be making the
following comments now.  Hijacking the Binding attribute like this is
a bit of a kludge.  Why not define new endpoints just for this
purpose?  Yes, I know you say (on line 494) that you'd rather not do
that, but why not?  That seems like the proper approach to me.

- In the same way an endpoint calls out its support for certain
NameIDs (with md:NameIDFormat), how does an endpoint call out its
support of various child elements of ds:KeyInfo? (This would require
new endpoint definitions, I think, as mentioned above.)

Tom Scavo
NCSA