[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Stateless Conformity To SAML
So if we refer to the "implementation" as the vendor product, and the "deployment" as what I do with the product, then...if I chose not to allow my SAML environment to write to my internal enterprise data stores, will I then be in a position of having a non-conformant deployment? I think we would like to be in the position of claiming a conformant deployment. If the vendors are required to implement Name Identifier management and companies are not willing to allow the internal write interaction (a very possible scenario) then the vendors must design for this restriction. Last, I took the term "statefulness" in this thread to mean the ability to write to a persistent information store. Probably not the correct use of the term, but that was how I connected it to Name Identifier management. Mike -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Thursday, July 29, 2004 2:59 PM To: 'Dana Kaufman'; security-services@lists.oasis-open.org Subject: RE: [security-services] Stateless Conformity To SAML > I have to agree with what Prateek mentioned. I think it important to > allow stateless components to claim conformity to SAML 2.0. I agree too, but I still don't see what "supporting" Name Identifier management messages has to do with the statefulness or lack thereof of a SAML implementation. I can't see any reasonable approach to consuming those messages that doesn't pass most of the non-transitory state off to something else. For conformance testing, that "something else" might well be a dummy implementation, but in real life it's probably something totally distinct. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]