<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Federated De-provisioning</title>
	<atom:link href="http://eternallyoptimistic.com/2009/02/05/federated-de-provisioning/feed/" rel="self" type="application/rss+xml" />
	<link>http://eternallyoptimistic.com/2009/02/05/federated-de-provisioning/</link>
	<description></description>
	<lastBuildDate>Wed, 10 Aug 2011 17:44:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Ian Clark</title>
		<link>http://eternallyoptimistic.com/2009/02/05/federated-de-provisioning/comment-page-1/#comment-502</link>
		<dc:creator>Ian Clark</dc:creator>
		<pubDate>Thu, 12 Feb 2009 23:48:57 +0000</pubDate>
		<guid isPermaLink="false">http://eternallyoptimistic.com/?p=876#comment-502</guid>
		<description>Federated provisioning?

Consider a company providing and charging for a service (SP) based on the number of connections.

Say the number of connections is a function of those people at the identity provider (IdP) who wish to (say) view their pay information. Not all will use the functionality, so the chargeable connections will be less than the total number employed.

The responsibility and interest of employee separation processing will be on the part of the IdP administrator, whereas creation of account mapping would be on an as required basis whenever an existing employee choses to register.

Separation of users at the SP is an administrative funtion of the IdP administrator as those users are separated from the IdP domain. SPML is merely the conveyance.</description>
		<content:encoded><![CDATA[<p>Federated provisioning?</p>
<p>Consider a company providing and charging for a service (SP) based on the number of connections.</p>
<p>Say the number of connections is a function of those people at the identity provider (IdP) who wish to (say) view their pay information. Not all will use the functionality, so the chargeable connections will be less than the total number employed.</p>
<p>The responsibility and interest of employee separation processing will be on the part of the IdP administrator, whereas creation of account mapping would be on an as required basis whenever an existing employee choses to register.</p>
<p>Separation of users at the SP is an administrative funtion of the IdP administrator as those users are separated from the IdP domain. SPML is merely the conveyance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Janus versus Vulcan in Federated Provisioning &#171; Identity Blogger</title>
		<link>http://eternallyoptimistic.com/2009/02/05/federated-de-provisioning/comment-page-1/#comment-499</link>
		<dc:creator>Janus versus Vulcan in Federated Provisioning &#171; Identity Blogger</dc:creator>
		<pubDate>Sat, 07 Feb 2009 03:00:50 +0000</pubDate>
		<guid isPermaLink="false">http://eternallyoptimistic.com/?p=876#comment-499</guid>
		<description>[...] flurry of posts about Federated Provisioning. You can go here to read the latest from Dave Kearns, Pamela Dingle, Ian Glazer, and Nishant Kaushik. These are some really smart people who make some good points, but [...]</description>
		<content:encoded><![CDATA[<p>[...] flurry of posts about Federated Provisioning. You can go here to read the latest from Dave Kearns, Pamela Dingle, Ian Glazer, and Nishant Kaushik. These are some really smart people who make some good points, but [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pbryan</title>
		<link>http://eternallyoptimistic.com/2009/02/05/federated-de-provisioning/comment-page-1/#comment-498</link>
		<dc:creator>pbryan</dc:creator>
		<pubDate>Fri, 06 Feb 2009 19:22:51 +0000</pubDate>
		<guid isPermaLink="false">http://eternallyoptimistic.com/?p=876#comment-498</guid>
		<description>I think a common reason for deferral of any deprovisioning is that personalization and/or profile data not present in any supplied claims are easily captured and persisted within the SP/RP for that user.</description>
		<content:encoded><![CDATA[<p>I think a common reason for deferral of any deprovisioning is that personalization and/or profile data not present in any supplied claims are easily captured and persisted within the SP/RP for that user.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

