[OpenID] Abusing Authentication Failure messages

[SitG Admin]

>>It sounds like you have multiple topics in your email now.
>
>I was clearly introducing the issue.

Not clearly enough, apparently.

Maybe we're just too stupid to have readily understood you.

>session management at the RP's side would definitely be helped by 
>this as well; being able to cache request discovery information for 
>matching against a response in a set hashed by ID.

Caching of OP discovery only speeds user access: the RP can perform 
discovery while the user's browser waits the RP to respond. No 
security is added, and [user] sessions would not help users who 
arrived at the site *from* the OP (initiating login from there).

>However, consider the fact that association is optional, signing 
>(even without association) is optional,

For assertions of success, the RP (by spec) MUST verify that the 
signature is valid (see sections 11 and 11.4 of v2.0 for more 
details). It is only for assertions of failure that the spec does not 
mandate checking signatures (although the Protocol Overview does give 
that impression).

>responses are allowed to be sent over clear-text transports 
>(revealing identity information to intermediate parties)

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.

-Shade