Why do OPs have to use passwords? Someone using <a href="http://myvidoop.com">myvidoop.com</a> or InfoCards for example would have a harder time sharing their credential with someone else.<br clear="all">--<br>Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 12:20 AM, Ben Laurie <span dir="ltr"><<a href="mailto:benl@google.com">benl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Dec 10, 2009 at 2:44 AM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:<br>
> PS,<br>
> If you use your email account for account recovery your email provider can<br>
> get access to all of your other accounts. That is one of the largest<br>
> security problems.<br>
<br>
</div>Surely the problem is not that the provider can do it (yes, they can,<br>
but how often do they?), but that anyone you give your password away<br>
to can do it.<br>
<div><div></div><div class="h5"><br>
> John B.<br>
> On 2009-12-09, at 8:53 PM, Shearer, Charles Dylan wrote:<br>
><br>
> John & Andrew,<br>
><br>
> That you both for your interesting responses and pointers.<br>
><br>
> Andrew, you said:<br>
><br>
> your question moves past the security issues associated with the protocol<br>
> and addresses trust issues in the ecosystem. As John indicated, at the<br>
> current assurance levels and resulting appropriate usage scenarios, OpenID<br>
> deployment and the trust levels associated with OP's are probably<br>
> sufficient.<br>
><br>
><br>
> And John said:<br>
><br>
> Given that openID is only secure enough as a protocol for ICAM LoA 1<br>
> (pseudonymous protecting no PII) the most practical path is to provide more<br>
> trustable OP/IdP.<br>
><br>
> I think you both are saying that, for what OpenID is intended to do, it<br>
> works. In other words, OpenID can be used if we can assume that the<br>
> supported identity providers are honest. I cannot understand why we should<br>
> have to make that assumption at all. There are well-supported technologies<br>
> like PKI that provide identification, authentication, and even<br>
> nonrepudiation without forcing us to put a very large amount of trust in a<br>
> 3rd party.<br>
><br>
> Indeed, my point is that OpenID forces us to put a lot of trust in the<br>
> identity provider: we trust them with the ability to access our RP accounts,<br>
> and we trust them with the knowledge of the fact that we use these RP<br>
> services. Just like most attacks, the probability that a provider (or<br>
> employee thereof) will behave dishonestly is low (but certainly not<br>
> negligible) --- but I should not have to take that chance.<br>
><br>
> You might counter that we already put a lot of trust in organizations (that<br>
> is, potential RPs) --- for example, banks --- so why shouldn’t we also trust<br>
> an identity provider? That is true, but there is a difference. When I<br>
> trust bank A, my trust is limited to the cash I give it and the credit<br>
> accounts I have open with it. When I trust bank B, my trust covers only the<br>
> accounts I have with that bank. When I trust Amazon.com, I trust it only<br>
> with the information of one credit card. When I trust my email provider, I<br>
> trust them only with the email associated with that account. The risk is<br>
> limited in each case. Now, imagine that I use OpenID to log into all four<br>
> of those services: I am now trusting my identity provider with all four<br>
> aspects of my life.<br>
><br>
> Charles<br>
><br>
><br>
> On 12/9/09 8:18 AM, "Nash, Andrew" <<a href="mailto:annash@paypal.com">annash@paypal.com</a>> wrote:<br>
><br>
> Charles,<br>
><br>
> your question moves past the security issues associated with the protocol<br>
> and addresses trust issues in the ecosystem. As John indicated, at the<br>
> current assurance levels and resulting appropriate usage scenarios, OpenID<br>
> deployment and the trust levels associated with OP's are probably<br>
> sufficient.<br>
><br>
> The operating principals, policies controlling activities and personnel,<br>
> audit trails and verifiable operation by third parties are all aspects to<br>
> resolving the question you address. IFF you are dealing with low assurance<br>
> credentials and low value transactions, then as David identifies it probably<br>
> matters less and their are many alternative problems you could face from<br>
> your ISP. However, for higher assurance levels, higher value transactions,<br>
> more sensitive information or whatever, then you need to establish a trusted<br>
> Identity Services Provider - hopefully using transparent mechanisms rather<br>
> than just marketing spin, but heh.<br>
><br>
> However, you should be aware that in the area you seem to be addressing,<br>
> there are corresponding requirements and issues about how a relying party<br>
> will treat the information that is provided to it and a need to verify (at<br>
> higher assurance levels) that correct usage and protection of that<br>
> information takes place. This is an issue that I raised several times in the<br>
> context of the Federal Govt that Mary Rundle has taken up in the open trust<br>
> frameworks discussion. For large scale operation this relying party<br>
> assurance equivalent will not likely consist of audits, but probably will<br>
> need to rely on relying party agreements (no pun intended :) ).<br>
><br>
> The Kantara Initiative have done some good starting work on Identity<br>
> Assurance models (based on earlier work by NIST et al). It needs lot more<br>
> work and does not address a range of deployment challenges, but is worth<br>
> taking a look at.<br>
> --Andrew<br>
><br>
><br>
><br>
> ________________________________<br>
> From: <a href="mailto:openid-security-bounces@lists.openid.net">openid-security-bounces@lists.openid.net</a><br>
> [mailto:<a href="mailto:openid-security-bounces@lists.openid.net">openid-security-bounces@lists.openid.net</a>] On Behalf Of John Bradley<br>
> Sent: Tuesday, December 08, 2009 3:34 AM<br>
> To: Shearer, Charles Dylan<br>
> Cc: OpenID Security Mailing List<br>
> Subject: Re: [security] Nonrepudiation, and Trusting OpenID Providers<br>
><br>
> Charles,<br>
><br>
> It is true that almost all assertion based protocols require that a RP and<br>
> user have some trust in the OP/IdP. This is equally the case for SAML and<br>
> managed Info-Cards.<br>
><br>
> Some thing like PKI and personal info-cards allow the user to have complete<br>
> control over the authenticator.<br>
><br>
> There are two basic options:<br>
> 1 increase the trustability of the OP/IdP<br>
> 2 Use multiple IdP simultaneously and prey.<br>
><br>
> I don't personally believe that option 2 is all that practical or gives much<br>
> more security for the average user.<br>
><br>
> Given that openID is only secure enough as a protocol for ICAM LoA 1<br>
> (pseudonymous protecting no PII) the most practical path is to provide more<br>
> trustable OP/IdP.<br>
><br>
> That said, with some of the v.Next changes openID will become appropriate<br>
> for higher LoA.<br>
><br>
> I don't think Gov or Banks are going to be comfortable with multi Auth<br>
> solutions. They are going to insist on trusted OP/IdP.<br>
><br>
> You can have a look at the ICAM site to see where the US Gov is going.<br>
> <a href="http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV" target="_blank">http://www.idmanagement.gov/drilldown.cfm?action=openID_openGOV</a><br>
><br>
> I can see binding more than one openID to a RP to allow for recovery,<br>
> however that needs to be balanced against doubling the attack surface.<br>
><br>
> Regards<br>
> John Bradley<br>
><br>
> On 2009-12-07, at 9:47 PM, Shearer, Charles Dylan wrote:<br>
><br>
><br>
> I have some concerns about OpenID, and I would like to see what those<br>
> involved think about them.<br>
><br>
> It seems to me that, regardless of how OpenID is deployed, it is always<br>
> possible for an OpenID provider itself to authenticate with a relying party<br>
> as any user by forging a request to authenticate using the user’s<br>
> identifier. This is because a relying party cannot tell the difference<br>
> between a user attempting to log in using his or her identifier, and the<br>
> user’s OpenID provider spoofing that user to gain access to whatever<br>
> services the relying party provides to that user. This seems to require<br>
> that both users and relying parties put a lot of trust in OpenID providers:<br>
> for example, if I used my OpenID identifier for online banking and email,<br>
> 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<br>
> users’ accounts, I still cannot see how OpenID could provide nonrepudiation<br>
> regarding messages sent to a relying party by an authenticated user: for<br>
> example, if I authenticate with my bank using my OpenID identifier and then<br>
> use the bank’s “bill pay” service to pay a bill, there’s no way the bank<br>
> can prove that I ordered that payment because it is possible that someone<br>
> working for my OpenID provider logged in as me and ordered it.<br>
><br>
> Does anyone disagree with my analysis?<br>
><br>
> Dylan<br>
> _______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
><br>
><br>
_______________________________________________<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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-security</a><br>
</div></div></blockquote></div><br>