[security-services] Comments on bindings-model-07

["Eve L. Maler" <eve.maler@sun.com>]

I've been making some editorial comments privately to Prateek, but here are 
some substantive/"deep editorial" comments:

- The MUST in the "guidelines" section should be a SHOULD.  (This is more 
consonant with the SHOULD that appears in bullet #3 of the process 
framework section, and we can't make people do anything in their private 
bindings/profiles.)

- I find the SOAP-over-HTTP wording somewhat schizophrenic.  I think that 
what we want to say is that it's a *vendor conformance criterion* whether 
SOAP is being used over HTTP and that we are providing normative rules for 
how to do this if you want to do it, but that *SAML users* can use whatever 
the heck substrate they want.  If this is correct, then we need to have 
some coordination between what the bindings document says and what the 
conformance document says; the bindings document shouldn't get into 
conformance criteria (but it can make a cross-reference to the other doc).

- I have already given Prateek this comment, and he seems okay with it, but 
I thought others would want to get some exposure to it.  There isn't one 
web browser profile, there are two.  In some places they're referred to in 
the singular, and in some places it's acknowledged (sort of) that the 
artifact approach and the form POST approach are really different.  I think 
we should just admit that these are two profiles, even if they have the 
same overall purpose in life, and give them separate names.  I have 
proposed "browser/artifact profile for SAML" and "browser/POST profile for 
SAML".  If we want, we can further qualify the names by sticking "SSO" 
somewhere in there.

- There are some very important security considerations provided in this 
document, and I think they're best suited to being here (and not pulled out 
into the "real" security considerations document).  At the very least, the 
"real" document should make sure to make a cross-reference here.

- The random stuff in Appendix A is not ready for prime time.  Exactly why 
is it here, and can it be turned into specification language?

- Is the point of Appendix B to be a non-normative hint about using form 
POST?  If so, I think it would be much more effective if it were inline, 
and its non-normative status indicated (e.g. by putting it in a "note").

	Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com