<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18828"></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2
face=Arial>Charles,</FONT></SPAN></DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2 face=Arial>your
question moves past the security issues associated with the protocol and
addresses trust issues in the ecosystem. As John indicated, at the current
assurance levels and resulting appropriate usage scenarios,
OpenID deployment and the trust levels associated with OP's are probably
sufficient.</FONT></SPAN></DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2 face=Arial>The
operating principals, policies controlling activities and personnel, audit
trails and verifiable operation by third parties are all aspects to resolving
the question you address. IFF you are dealing with low assurance credentials and
low value transactions, then as David identifies it probably matters less and
their are many alternative problems you could face from your ISP. However, for
higher assurance levels, higher value transactions, more sensitive information
or whatever, then you need to establish a trusted Identity Services Provider -
hopefully using transparent mechanisms rather than just marketing spin, but
heh.</FONT></SPAN></DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2
face=Arial>However, you should be aware that in the area you seem to be
addressing, there are corresponding requirements and issues about how a relying
party will treat the information that is provided to it and a need to verify (at
higher assurance levels) that correct usage and protection of that information
takes place. This is an issue that I raised several times in the context of the
Federal Govt that Mary Rundle has taken up in the open trust frameworks
discussion. For large scale operation this relying party assurance equivalent
will not likely consist of audits, but probably will need to rely on
relying party agreements (no pun intended :) ). </FONT></SPAN></DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2
face=Arial></FONT></SPAN> </DIV>
<DIV><SPAN class=225335915-09122009><FONT color=#0000ff size=2 face=Arial>The
Kantara Initiative have done some good starting work on Identity Assurance
models (based on earlier work by NIST et al). It needs lot more work and does
not address a range of deployment challenges, but is worth taking a look
at.</FONT></SPAN></DIV><!-- Converted from text/rtf format -->
<P><SPAN lang=en-us><FONT size=2 face=Arial>--Andrew</FONT></SPAN> </P>
<DIV> </DIV><BR>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> openid-security-bounces@lists.openid.net
[mailto:openid-security-bounces@lists.openid.net] <B>On Behalf Of </B>John
Bradley<BR><B>Sent:</B> Tuesday, December 08, 2009 3:34 AM<BR><B>To:</B>
Shearer, Charles Dylan<BR><B>Cc:</B> OpenID Security Mailing
List<BR><B>Subject:</B> Re: [security] Nonrepudiation, and Trusting OpenID
Providers<BR></FONT><BR></DIV>
<DIV></DIV>Charles,
<DIV><BR></DIV>
<DIV>It is true that almost all assertion based protocols require that a RP and
user have some trust in the OP/IdP. This is equally the case for SAML and
managed Info-Cards.</DIV>
<DIV><BR></DIV>
<DIV>Some thing like PKI and personal info-cards allow the user to have complete
control over the authenticator. </DIV>
<DIV><BR></DIV>
<DIV>There are two basic options:</DIV>
<DIV>1 increase the trustability of the OP/IdP</DIV>
<DIV>2 Use multiple IdP simultaneously and prey.</DIV>
<DIV><BR></DIV>
<DIV>I don't personally believe that option 2 is all that practical or gives
much more security for the average user.</DIV>
<DIV><BR></DIV>
<DIV>Given that openID is only secure enough as a protocol for ICAM LoA 1
(pseudonymous protecting no PII) the most practical path is to provide more
trustable OP/IdP.</DIV>
<DIV><BR></DIV>
<DIV>That said, with some of the v.Next changes openID will become appropriate
for higher LoA.</DIV>
<DIV><BR></DIV>
<DIV>I don't think Gov or Banks are going to be comfortable with multi Auth
solutions. They are going to insist on trusted OP/IdP.</DIV>
<DIV><BR></DIV>
<DIV>You can have a look at the ICAM site to see where the US Gov is
going.</DIV>
<DIV><A
href="http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV">http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV</A></DIV>
<DIV><BR></DIV>
<DIV>I can see binding more than one openID to a RP to allow for recovery,
however that needs to be balanced against doubling the attack
surface.</DIV>
<DIV><BR></DIV>
<DIV>Regards</DIV>
<DIV>John Bradley</DIV>
<DIV><BR></DIV>
<DIV>
<DIV>
<DIV>On 2009-12-07, at 9:47 PM, Shearer, Charles Dylan wrote:</DIV><BR
class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<DIV><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt">I have some concerns about OpenID, and I would like to
see what those involved think about them.<BR><BR>It seems to me that,
regardless of how OpenID is deployed, it is always possible for an OpenID
provider itself to authenticate with a relying party as any user by forging a
request to authenticate using the user’s identifier. This is because a
relying party cannot tell the difference between a user attempting to log in
using his or her identifier, and the user’s OpenID provider spoofing that user
to gain access to whatever services the relying party provides to that user.
This seems to require that both users and relying parties put a lot of
trust in OpenID providers: for example, if I used my OpenID identifier for
online banking and email, my OpenID provider could easily access my email and
bank account. <BR><BR>Additionally, even if we assume that OpenID
providers will not log into users’ accounts, I still cannot see how OpenID
could provide nonrepudiation regarding messages sent to a relying party by an
authenticated user: for example, if I authenticate with my bank using my
OpenID identifier and then use the bank’s “bill pay” service to pay a bill,
there’s no way the bank can prove that I ordered that payment because it is
possible that someone working for my OpenID provider logged in as me and
ordered it.<BR><BR>Does anyone disagree with my
analysis?<BR><BR>Dylan</SPAN></FONT>
</DIV>_______________________________________________<BR>security mailing
list<BR><A
href="mailto:security@lists.openid.net">security@lists.openid.net</A><BR><A
href="http://lists.openid.net/mailman/listinfo/openid-security">http://lists.openid.net/mailman/listinfo/openid-security</A><BR></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>