Nothing requires that the Name ID Management service endpoints be
co-located with the SSO consumer endpoints, so I don't see that
deploying a read-only SAML consumer at an enforcement point on the edge
of the network precludes deploying a Name ID Management capability
somewhere else.
In any case, my only point was that it seems fair to require that
systems that ARE stateful (ie persistently record name identifiers
received via SSO assertions, aka record federations in-band) also
support Name ID Management. Systems that are stateless, or that require
name identifier mappings (aka federations) to be managed out-of-band,
need not support Name ID Management.
-Greg
On Jul 30, 2004, at 3:16 PM, Scott Cantor wrote:
>> 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.
>
> They wouldn't, but that's the point. Not everybody is pursuing the
> approach
> to managing identifiers in-band that Liberty (and now SAML) provides.
> As
> Prateek noted, transactional integrity and reliability are often pretty
> important, and neither SOAP nor the browser bindings provide it.
>
> Such enforcement points consume identifiers and may be reading data
> sources
> that are synchronized to these out of band mechanisms.
>
> Liberty *deployments* are free to do this (they don't have to use the
> profiles) but Liberty IdP/SP implementations are not free to do this
> exclusively.
>
> -- Scott
>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/security-services/
> members/leave_workgroup.php.
