<?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: How to rest assured</title>
	<atom:link href="http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/</link>
	<description>Tangled musings on identity, privacy, trust, and suchlike</description>
	<lastBuildDate>Sat, 08 Oct 2011 19:31:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Pushing String &#187; The Pushmi-pullyu problem of assurance</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-273059</link>
		<dc:creator>Pushing String &#187; The Pushmi-pullyu problem of assurance</dc:creator>
		<pubDate>Sat, 20 Mar 2010 23:30:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-273059</guid>
		<description>[...] by trusted issuers in some fashion. Attribute assurance is akin to identity assurance (as discussed previously here), except that it&#8217;s about the quality of specific types of information and their binding [...]</description>
		<content:encoded><![CDATA[<p>[...] by trusted issuers in some fashion. Attribute assurance is akin to identity assurance (as discussed previously here), except that it&#8217;s about the quality of specific types of information and their binding [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Data Without Borders Episode 12: It&#8217;s not my fault! :: Data Without Borders</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-268255</link>
		<dc:creator>Data Without Borders Episode 12: It&#8217;s not my fault! :: Data Without Borders</dc:creator>
		<pubDate>Wed, 03 Feb 2010 11:16:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-268255</guid>
		<description>[...] How the U.S. government&#8217;s need for assurance may or may not match commercial/social requirements for assurance: How to rest assured. [...]</description>
		<content:encoded><![CDATA[<p>[...] How the U.S. government&#8217;s need for assurance may or may not match commercial/social requirements for assurance: How to rest assured. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2010-01-19 &#8226; Bare Identity</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-266539</link>
		<dc:creator>links for 2010-01-19 &#8226; Bare Identity</dc:creator>
		<pubDate>Wed, 20 Jan 2010 00:03:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-266539</guid>
		<description>[...] Pushing String » How to rest assured (tags: evemaler identityassurance identity identityproofing) [...]</description>
		<content:encoded><![CDATA[<p>[...] Pushing String » How to rest assured (tags: evemaler identityassurance identity identityproofing) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eve</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-265225</link>
		<dc:creator>Eve</dc:creator>
		<pubDate>Fri, 08 Jan 2010 16:22:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-265225</guid>
		<description>(For ease of reference, Rich&#039;s post is &lt;a href=&quot;https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/entry/certco_exigesis25?lang=en&quot; rel=&quot;nofollow&quot;&gt;here&lt;/a&gt;.) Maybe you should take another run at it!

To be sure, the U.S. government and lots of other governments already have PKI-based systems in place to handle the single-axis space they&#039;ve developed in NIST SP 800-63. (Whether revocation is handled properly in those systems, I don&#039;t know...) But the richness of the types of confidence really needed in the wild -- that is, not just in government applications but others -- suggests that more is needed.  We&#039;re certainly finding that to be true in the &lt;a href=&quot;http://kantarainitiative.org/confluence/display/uma/Home&quot; rel=&quot;nofollow&quot;&gt;UMA&lt;/a&gt; work, where we&#039;re trying to do data-sharing terms negotiation through a freshened-up &quot;claims&quot; mechanism. (More on that very shortly. Hey, Rich, we could use you on the team!)

And in the meantime, many web developers push back on doing the tiniest bit of crypto, which makes it awfully hard to achieve even the sorts of security and confidence we know how to do pretty well. (See Ben Laurie&#039;s recent &lt;a href=&quot;http://www.links.org/?p=833&quot; rel=&quot;nofollow&quot;&gt;lament about WRAP&lt;/a&gt; on this score.)</description>
		<content:encoded><![CDATA[<p>(For ease of reference, Rich&#8217;s post is <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/entry/certco_exigesis25?lang=en" rel="nofollow">here</a>.) Maybe you should take another run at it!</p>
<p>To be sure, the U.S. government and lots of other governments already have PKI-based systems in place to handle the single-axis space they&#8217;ve developed in NIST SP 800-63. (Whether revocation is handled properly in those systems, I don&#8217;t know&#8230;) But the richness of the types of confidence really needed in the wild &#8212; that is, not just in government applications but others &#8212; suggests that more is needed.  We&#8217;re certainly finding that to be true in the <a href="http://kantarainitiative.org/confluence/display/uma/Home" rel="nofollow">UMA</a> work, where we&#8217;re trying to do data-sharing terms negotiation through a freshened-up &#8220;claims&#8221; mechanism. (More on that very shortly. Hey, Rich, we could use you on the team!)</p>
<p>And in the meantime, many web developers push back on doing the tiniest bit of crypto, which makes it awfully hard to achieve even the sorts of security and confidence we know how to do pretty well. (See Ben Laurie&#8217;s recent <a href="http://www.links.org/?p=833" rel="nofollow">lament about WRAP</a> on this score.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rich Salz</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-265199</link>
		<dc:creator>Rich Salz</dc:creator>
		<pubDate>Fri, 08 Jan 2010 05:00:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-265199</guid>
		<description>If only CertCo had succeeded; we were in this space 10 years ago.  See my blog on it.</description>
		<content:encoded><![CDATA[<p>If only CertCo had succeeded; we were in this space 10 years ago.  See my blog on it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Eve</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-264897</link>
		<dc:creator>Eve</dc:creator>
		<pubDate>Mon, 04 Jan 2010 21:13:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-264897</guid>
		<description>Gerry-- Your attribute assurance point is excellent. If you as an RP can specify who you&#039;ll accept as a source/data origin (including a trusted aggregator who deals only with trusted sources &quot;further back&quot;), the whole question of authority sort devolves into this. Regarding pseudonymity, I gather from John B. that the verified name stuff is largely a holdover from the PKI heritage of NIST SP 800-63, and it&#039;s arguable what is truly required in this area at a technical level. To the extent that it&#039;s possible to argue for more-minimal disclosure as a fair reading, that would be a good thing!

Paul-- My mouse did hover over the &quot;Venn&quot; category button for a moment, but it seemed too impure to get away with. ;-) By all means, have at it...</description>
		<content:encoded><![CDATA[<p>Gerry&#8211; Your attribute assurance point is excellent. If you as an RP can specify who you&#8217;ll accept as a source/data origin (including a trusted aggregator who deals only with trusted sources &#8220;further back&#8221;), the whole question of authority sort devolves into this. Regarding pseudonymity, I gather from John B. that the verified name stuff is largely a holdover from the PKI heritage of NIST SP 800-63, and it&#8217;s arguable what is truly required in this area at a technical level. To the extent that it&#8217;s possible to argue for more-minimal disclosure as a fair reading, that would be a good thing!</p>
<p>Paul&#8211; My mouse did hover over the &#8220;Venn&#8221; category button for a moment, but it seemed too impure to get away with. ;-) By all means, have at it&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gerald Beuchelt</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-264895</link>
		<dc:creator>Gerald Beuchelt</dc:creator>
		<pubDate>Mon, 04 Jan 2010 20:35:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-264895</guid>
		<description>Using pseudonyms is ok (and actually potentially preferred) in most cases, at least as long as they can be de-referenced into real-name at audit time. 

As far as attributes go: authoritativeness is really consumer dependent - in many cases the authority of a source may be perfectly acceptable for a given consumer, while not at all acceptable for another. A better concept here might be &quot;data originator&quot;, i.e. the original author of some data. If you use this concept, you can build on (context dependent) reputation schemes for the data originator (who might actually an aggregator or deriver of data). I find this overall easier than introducing yet another artificial concept such as &quot;authoritativeness&quot;.</description>
		<content:encoded><![CDATA[<p>Using pseudonyms is ok (and actually potentially preferred) in most cases, at least as long as they can be de-referenced into real-name at audit time. </p>
<p>As far as attributes go: authoritativeness is really consumer dependent &#8211; in many cases the authority of a source may be perfectly acceptable for a given consumer, while not at all acceptable for another. A better concept here might be &#8220;data originator&#8221;, i.e. the original author of some data. If you use this concept, you can build on (context dependent) reputation schemes for the data originator (who might actually an aggregator or deriver of data). I find this overall easier than introducing yet another artificial concept such as &#8220;authoritativeness&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Madsen</title>
		<link>http://www.xmlgrrl.com/blog/2009/12/31/how-to-rest-assured/comment-page-1/#comment-264894</link>
		<dc:creator>Paul Madsen</dc:creator>
		<pubDate>Mon, 04 Jan 2010 19:47:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.xmlgrrl.com/blog/?p=1937#comment-264894</guid>
		<description>There is a Venn in here, and I will not rest until I find it :-)

paul</description>
		<content:encoded><![CDATA[<p>There is a Venn in here, and I will not rest until I find it :-)</p>
<p>paul</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using apc (Feed is rejected)
Page Caching using apc
Database Caching using apc
Object Caching 406/464 objects using apc
Content Delivery Network via Amazon Web Services: CloudFront: cdn.xmlgrrl.com

Served from: www.xmlgrrl.com @ 2012-02-08 11:48:00 -->
