Prateek,
> I am not sure I agree with the assessment that such components or
> applications "will find only specialized use". IMHO, this is
> not a matter of intuition but of awareness of current practice
> in the field.
>
> I invite you to view the large and growing field of security
> appliances including some that generate and consume SAML today.
> Further, speaking as representative of a vendor with a
> considerable history in federation, our products are often
> delivered as "enforcement points" on various touchpoints
> that are quite capable of consuming SAML but cannot write
> back to persistent
> store.
>
Perhaps you could briefly explain how your federation products
would work as "enforcement points" that would consume (or
produce) SAMLv2.0 name id mgt without the ability to "cause to be
stored" updates to that federation (or alternately, identity
network failure modes as route-arounds)? Take, for example, the
cases that Greg raised and to which I was responding in this
message.
--Nick
