<?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"
	>
<channel>
	<title>Comments on: Selective Disclosure and Privacy</title>
	<atom:link href="http://wendy.seltzer.org/blog/archives/2007/05/02/selective_disclosure_and_privacy.html/feed" rel="self" type="application/rss+xml" />
	<link>http://wendy.seltzer.org/blog/archives/2007/05/02/selective_disclosure_and_privacy.html</link>
	<description>Musings of a techie lawyer</description>
	<pubDate>Fri, 10 Sep 2010 22:44:24 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7-bleeding</generator>
		<item>
		<title>By: Peter Murray</title>
		<link>http://wendy.seltzer.org/blog/archives/2007/05/02/selective_disclosure_and_privacy.html#comment-712</link>
		<dc:creator>Peter Murray</dc:creator>
		<pubDate>Thu, 03 May 2007 13:41:21 +0000</pubDate>
		<guid isPermaLink="false">http://wendy.seltzer.org/wordpress/?p=404#comment-712</guid>
		<description>This sounds a lot like the Internet2 Shibboleth project to me:

The Shibboleth software implements the OASIS SAML v1.1 specification, providing a federated Single-SignOn and attribute exchange framework. Shibboleth also provides extended privacy functionality allowing the browser user and their home site to control the Attribute information being released to each Service Provider. (&lt;a href="http://shibboleth.internet2.edu/)" rel="nofollow"&gt;http://shibboleth.internet2.edu/)&lt;/a&gt;

To briefly address the points you quoted:

Verifiable
Verification is based on a formal trust framework  -- either a bilateral trust between the identity provider and the service provider or as part of a trust federation of which both the identity provider and the service provider are members.

Minimal
Shibboleth excels in this area.  The user and/or the user's identity organization can decide what attributes about an individual (that I am over 21 years of age or that I am a resident of Ohio) are given to the service provider.

Unlinkable
If a unique id is required by the service provider (say, for instance, to provide some site customization) the identity provider can provide an opaque string, called a "targeted ID", that is unique for user/service-provider pairing yet in no way reveals the actual identity of the user and is meaningless outside of the user/service-provider pair.
</description>
		<content:encoded><![CDATA[<p>This sounds a lot like the Internet2 Shibboleth project to me:</p>
<p>The Shibboleth software implements the OASIS SAML v1.1 specification, providing a federated Single-SignOn and attribute exchange framework. Shibboleth also provides extended privacy functionality allowing the browser user and their home site to control the Attribute information being released to each Service Provider. (<a href="http://shibboleth.internet2.edu/)" rel="nofollow"></a><a href="http://shibboleth.internet2.edu/" rel="nofollow">http://shibboleth.internet2.edu/</a>)</p>
<p>To briefly address the points you quoted:</p>
<p>Verifiable<br />
Verification is based on a formal trust framework  &#8212; either a bilateral trust between the identity provider and the service provider or as part of a trust federation of which both the identity provider and the service provider are members.</p>
<p>Minimal<br />
Shibboleth excels in this area.  The user and/or the user&#8217;s identity organization can decide what attributes about an individual (that I am over 21 years of age or that I am a resident of Ohio) are given to the service provider.</p>
<p>Unlinkable<br />
If a unique id is required by the service provider (say, for instance, to provide some site customization) the identity provider can provide an opaque string, called a &#8220;targeted ID&#8221;, that is unique for user/service-provider pairing yet in no way reveals the actual identity of the user and is meaningless outside of the user/service-provider pair.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
