<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Response to Mark Diodati&#8217;s &#8220;Nothing is Bulletproof&#8221; post</title>
	<link>http://eyedentityonline.com/archives/20</link>
	<description></description>
	<pubDate>Thu, 28 Aug 2008 19:20:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Mark Diodati</title>
		<link>http://eyedentityonline.com/archives/20#comment-224</link>
		<dc:creator>Mark Diodati</dc:creator>
		<pubDate>Thu, 25 Oct 2007 21:19:43 +0000</pubDate>
		<guid>http://eyedentityonline.com/archives/20#comment-224</guid>
		<description>Hi Tim,

Many thanks for your thoughtful, insightful, and articulate reply to my blog entry.  I agree that this is an important topic and the discourse we are having is a positive thing.  To that end, I am posting this comment on both the Burton Group Identity Blog and your blog.

The Javelin user acceptance study is encouraging.  The security of consumer authentication would be raised materially if a client were in play.  Clientless device identification â€“ while valuable â€“ is readily impersonated.  With a client, there can be some cryptographic â€˜meat on the boneâ€™ to provider a stronger device ID.  Obviously, the security quality of the consumerâ€™s primary authentication would be improved as well.  

While software acceptance by consumers is a good thing, I have residual concerns.  Will customers tolerate multiple client packages, with the potential for software conflicts or performance issues?  This issue is the software analogue of the OTP â€œtoken necklaceâ€ many of us like to talk about.  This is a different use case than deploying a single anti-virus package.  To be fair, the customer may get lucky because all of the customerâ€™s FIs may use the same client.  Also, as you point out, user acceptance is only one-half of the recipe.  FIs must be willing to deploy and support client software, and probably for multiple operating systems (not just Windows).

I agree that we should continue this discourse on the challenges of consumer authentication.  I am not sure of the best medium, but I commit to giving it some thought (and I am open to suggestions).  Additionally, the Burton Group IdPS team is in the process of defining our 2008 focus areas, and it will certainly include consumer authentication.  Weâ€™ll wrap-up our planning mid-November.  Perhaps we can take the roundtable idea to the next Burton Group Catalyst conference, which will enable a healthy percentage of customers to interactively collaborate with us on the topic.

For the record, I think that TriCipher has some interesting and unique technology in its portfolio, and I have called this out in our research work.  The split key technology and variable client footprint options provides good security and mobility features.  I like the way that TriCipher does mobile PKI in conjunction with one-time password devices.  The use of the private key is tightly coupled to the OTP authentication, more so than any other product I am aware of.  Itâ€™s also nice that the product transparently supports a mix of vendor OTPs; this capability introduces cost-saving OTP migration options.

As always, I look forward to reading your blog, and I look forward to additional discussions.

Sincerely,

Mark</description>
		<content:encoded><![CDATA[<p>Hi Tim,</p>
<p>Many thanks for your thoughtful, insightful, and articulate reply to my blog entry.  I agree that this is an important topic and the discourse we are having is a positive thing.  To that end, I am posting this comment on both the Burton Group Identity Blog and your blog.</p>
<p>The Javelin user acceptance study is encouraging.  The security of consumer authentication would be raised materially if a client were in play.  Clientless device identification â€“ while valuable â€“ is readily impersonated.  With a client, there can be some cryptographic â€˜meat on the boneâ€™ to provider a stronger device ID.  Obviously, the security quality of the consumerâ€™s primary authentication would be improved as well.  </p>
<p>While software acceptance by consumers is a good thing, I have residual concerns.  Will customers tolerate multiple client packages, with the potential for software conflicts or performance issues?  This issue is the software analogue of the OTP â€œtoken necklaceâ€ many of us like to talk about.  This is a different use case than deploying a single anti-virus package.  To be fair, the customer may get lucky because all of the customerâ€™s FIs may use the same client.  Also, as you point out, user acceptance is only one-half of the recipe.  FIs must be willing to deploy and support client software, and probably for multiple operating systems (not just Windows).</p>
<p>I agree that we should continue this discourse on the challenges of consumer authentication.  I am not sure of the best medium, but I commit to giving it some thought (and I am open to suggestions).  Additionally, the Burton Group IdPS team is in the process of defining our 2008 focus areas, and it will certainly include consumer authentication.  Weâ€™ll wrap-up our planning mid-November.  Perhaps we can take the roundtable idea to the next Burton Group Catalyst conference, which will enable a healthy percentage of customers to interactively collaborate with us on the topic.</p>
<p>For the record, I think that TriCipher has some interesting and unique technology in its portfolio, and I have called this out in our research work.  The split key technology and variable client footprint options provides good security and mobility features.  I like the way that TriCipher does mobile PKI in conjunction with one-time password devices.  The use of the private key is tightly coupled to the OTP authentication, more so than any other product I am aware of.  Itâ€™s also nice that the product transparently supports a mix of vendor OTPs; this capability introduces cost-saving OTP migration options.</p>
<p>As always, I look forward to reading your blog, and I look forward to additional discussions.</p>
<p>Sincerely,</p>
<p>Mark</p>
]]></content:encoded>
	</item>
</channel>
</rss>
