RE: [security-services] Stateless Conformity To SAML

["Beach, Michael C" <michael.c.beach@boeing.com>]

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