> 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
