[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]