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

["Mishra, Prateek" <pmishra@netegrity.com>]

>>
>>- 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 dont have a strong feeling about this. Here is one question though:
let us suppose a hacked up bindings draft is submitted to the SSTC
without any of the suggested structure
in the "Guidelines" section. Doesnt the "SHOULD"
help people argue around the need to follow the guidelines?


>>
>>- 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).
>>

Agreed, there has been some discussion around this point at F2F#5.

>>- 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.
>>

Agreed, these are two different profiles that accomplish the
same task (in very different ways). I am comfortable with the
proposed names.

>>- 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?
>>

Appendix A deals with the issue of limitation on URL size in
commercial browsers. There is no RFC that states this, so I felt
this was a piece of "folk wisdom" that needed documentation. The
Appendix reproduces the relevant documentation from MSFT and
Netscape. Perhaps it just needs to be titled 

"URL Size Limits of Commercial Browsers" ?

>>- 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").

Your characterization is correct. Adding it as a note
works for me (especially as it is relatively short).

>>
>>	Eve
>>--
>>Eve Maler                                    +1 781 442 3190
>>Sun Microsystems XML Technology Center   eve.maler @ sun.com
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>