The question then becomes - how do you know you can trust a given OP?
Which, when compared to a traditional password situation, becomes "how
do you know you can trust a given user".
It's a bit more complicated than that, actually.
Or, if those assertion are *not* present, inform the user that their
OP has vouched for them but the level of security is not sufficient
to permit full services.
Or let them make that call.
I've had at least one bank
Banks are an excellent example of exactly why RP's *do* need to make
these calls. I haven't had time to write a reply properly addressing
these points, but Andrew has touched on most of them, so I'll simply
run a short scenario by you:
Your bank lets you transfer money by logging into their website. One
day, their system recognizes your password and logs you in, whereupon
you promptly transfer most of your money to another account. A few
days later, you walk into their physical building and raise hell
about it. What happens next?
1) They tell you that you can't have your cake and eat it too.
2) They acknowledge the possibility of fraud but tell you that YOU
were responsible for safeguarding your password, and the password was
obviously known, so it's YOUR fault the money is gone and THEY are
not liable for its loss.
That's what it's all about: liability. If *their* security is
compromised and someone steals all the user's passwords, it's THEIR
fault, and heads will roll (probably) . . . but when accusations of
theft *do* occur (and they will), are they going to keep the user
waiting while investigations are pursued, which may not even unearth
anything? No; banks provide security of mind, the knowledge that we
have money and that our losses are covered. They may try to recover
those losses (because our losses are their losses), but they may
write it off as more expenditure than it's worth. Spyware is
prevalent, the user may have had some. End of story.
Or was #1 the *real* story? Was the user really trying to have their
cake and eat it too, double their money by transferring it to another
account (for withdrawal) and then claiming that the money was stolen?
Introduce a 3rd party (the OP) and users have someone else to blame -
and fraud is suddenly looking much easier. That doesn't mean it will
*be* easier, but it *does* suggest that more people will be *trying*
- and losses go up.
And these are just *monetary* losses! Not all breaches are a simple
matter of budgeting for future compensation. Compromising a spy's
cover (revealing their mission/identity) could literally be life and
death. A company could go down if their (trade) secrets were to fall
into the wrong hands. We're basically looking at two or three
interested parties here:
1) the insurance company that provides coverage against fraud
2) the user who wants ready access to services
3) the RP that needs to keep some data out of unprivileged hands
Let the user make that call, unilaterally? Unacceptable.
And remember, this isn't some case where the user can say "You *must*
accept it, one of the tenets of OpenID is that you must permit me to
choose my own OP." - frankly, I don't give a flying *duck* what the
authentication system's philosophical ideals are, I'm not under an
external obligation to provide services to that user under any terms
the user dictates. We have a contract. It works both ways.
In fact, one might say that *because* my contract obliges me to
provide services *to that user and ONLY to that user*, I am
duty-bound to do my utmost, by any and all measures I see fit, to
ensure that noone else can pose as that user!
-Shade
_______________________________________________
security mailing list
[email protected]
http://openid.net/mailman/listinfo/security
