[OpenID] Abusing Authentication Failure messages
David Nicol
davidnicol at gmail.com
Mon Aug 23 14:59:49 UTC 2010
I have noted this problem before. However, the freedom OpenID affords users
> also carries a burden of responsibility: if YOU are going to select your own
> provider, then YOU are going to need to decide which features YOU want, and
> YOU will have to evaluate OP's to find out whether they meet YOUR standards
> . . . then, if you can't find one, YOU get to create your own that does.
> Isn't self-agency fun?
>
> The catch is that your own standards can't be imposed upon others. This is
> also a feature (it's what keeps OP's from falling back to plaintext if a RP
> insists on not accepting encryption), but it keeps ethics out of the law -
> or specs, in this case. OpenID establishes a minimum to have the technical
> side work, and then leaves the rest optional - if you want your OP to decide
> between authenticating you or not authenticating you by having one thousand
> monkeys flip a coin, and then checking the parity bit, you can do that. No
> one else can stop you. RP's can decide to reject responses from your OP, but
> they can't force RP's who are fine with it to stop anyway. Users can send
> their personal information over plaintext channels, if they like it that
> way, and OpenID won't tell them "Around here we don't let you do this: find
> a different protocol."
>
>
> As an end-user, I would trust a site that claimed OpenID support to guard
>> my safety and privacy more if I knew the specification required it to be
>> stringent in the above matters.
>>
>
> The spec offers one way to do so; insisting that all redirects be targeted
> to SSL is another. Making it COMPULSORY in the spec would harm interop.
>
> What you have here is a legal issue: does your contract with the site
> *require* it to guard your safety and privacy? If it doesn't clearly tell
> you what steps it is taking to do so, perhaps you should investigate. If
> they are unable or unwilling to answer your questions, perhaps your trust
> would have been misplaced anyway.
>
I disagree. What you have here is a branding issue. Billemont seems to have
access to, if he would take time to write it down, the specification for an
improved but incompatible (due to refusal to engage in insecure thisandthat)
subset of the openID protocol which could be claimed -- with something like
a TrustE banner -- and certified and so on. Jobs for certifiers, and
bueraucrats. Full employment. Win!
--
"Elevator Inspection Certificate is on file in the Maintenance Office"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100823/2ffc7c2f/attachment.html>
More information about the general
mailing list