[OpenID] Widgets and other aggregation

[David Fuelling]

Ok, I see where you were going, and can understand your point.
I actually don't think my bank website needs to be *that* secure.  We can't
really *do* anything in our banking websites except look at our transaction
history, and maybe try to change a mailing address or add an external
account in order to transfer money in/out (if you have a good bank).  Even
here, though, banks have external controls to mitigate any risks to doing
"banking business" online.  In the first case, banks always send something
out to the previous postal address saying, "You changed your address to this
or that".  Outgoing transfers of anything substantial (> $10k) are usually
flagged and re-verified somehow.  From a banking/risk perspective, $5k or
$10k is small enough that banks can stomach the risk, and it would be pretty
difficult to get away with a fraudulent transfer nowadays -- it's not like I
can easily "ACH" money from my citibank account to a Swiss account.  There
are controls.
Security is a gradient -- MultiAuth gives me a lot more comfort when I sleep
at night, since it would be difficult for OP's to collude in the way you
suggest (though, to your point, not impossible).  However, with proper
external controls (e.g., banking websites), any gain for two OP operators to
collude in such a scheme as you laid out would not even come close to the
risk involved.  So, I don't really see it as a worry.

At the end of the day, I feel like you're making the arguement that says,
"Hey, MultiAuth is maybe 100% better than SingleAuth, but it's not perfect,
so let's not do it".  It's a bit like saying, "The door on the front of my
house stops most intruders, but since it's not perfect (intruders can still
break in through a window), then I shouldn't use a door because it's not
worth the effort".

david


On Wed, Jan 28, 2009 at 1:17 AM, SitG Admin <sysadmin at shadowsinthegarden.com
> wrote:

> Any other RP's (like the Bank RP) would require MultiAuth, preventing the
>>>> OP from getting bank info without the user's consent.
>>>>
>>>
>>> Making it more difficult; requiring collaboration, and (if it came to
>>> legal action) even conspiracy ;)
>>>
>>
>> Not sure I follow here, especially the part about conspiracy.
>>
>
> It would still technically be possible for the OP to get bank info without
> the user's consent, it would just be more difficult since they would need to
> enlist the aid of another OP (trusting that the OP wouldn't just turn them
> in for attempting it). I wouldn't be surprised if banks adopted OpenID as a
> gateway to other authentication measures, and then STILL required a password
> (outside of OpenID) from the user. It would reduce the SSO benefits (but not
> eliminate them entirely, if the user visited other sites that didn't require
> such security levels), pending of course any future updates to OpenID which
> might eventually remove this risk, thus permitting the banks to remove that
> requirement.
>
> When money is involved (especially LOTS of money), people can be crazy.
> We're not talking about a user feature, here - we're talking about an OP
> that thinks "Hey, lots of people are using me to vouch for their identity at
> the bank website, and this hasn't mattered to me before, but this fellow
> here is RICH, so it may be worth going to jail on the off chance that *one*
> of the employees at their other OP's can be bribed with a share of the
> spoils - which is still plenty, even after I give them all *their* cut -
> into making an exception to SOP this once."
>
> If it's just one person taking advantage of an opportunity afforded to them
> by their position, it's fraud. But if you have *multiple* people combining
> their influence to deliberately commit fraud, you may be looking at some
> conspiracy charges, there, too :(
>
> -Shade
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090128/62dc4eca/attachment-0002.htm>