RE: [security-services] Stateless Conformity To SAML

["Scott Cantor" <cantor.2@osu.edu>]

> I like your approach of thinking from the other view. I think,
> however, it's a bad idea to conceive of a 'general' SP that claims 
> support for name id mgt but that cannot/doesn't actually store 
> (or cause to be stored) persistent records. 

But "store" and "cause to be stored" are two fundamentally different
implementation strategies that are (as I understood it) exactly what's at
issue here.

I can implement a largely stateless system that implements the protocol by
"causing to be stored" the result of the messages. It's not up to me to make
it happen, and I can't be blamed if the deployer refuses to implement the
necessary write-back because he doesn't want to. Nor is that non-conformant,
but rather a deployment choice (as long as I return an error when I'm asked
to process the change and the write fails).

> > Where we would run into trouble, I think, is if an implementation  
> > stores persistent records of user federations but doesn't 
> > support Name ID Management (federation termination in particular).
> 
> Well put. This is one specific way in which the 'stateless'
> implementation is problematic, and for which its designers would
> probably have to rely on failure modes ... which would seem to
> shorten the life of two important utilities of such a "device" 
> (speed and independence).

But an implementation may well "support" persistent records of user
identities (I prefer that to the term federations) without "storing" them.

Does conformance need to distinguish such a case? From your previous note,
it sounds like this was handled by making qualified statements of
conformance, but that seems to underline what conformance is supposed to
mean, and I didn't see any guidance in the SCR for how that works.

-- Scott