The OpenID spec does not prevent users from having separate passwords for separate services within one OpenID.

Yeah, that sounds fair.

But, I'm not aware of any providers offering this extra bit of security.

I've only seen "Allow Once" "Allow forever" after I authenticate my identity to my provider.

So, what is the advantage of OpenID in these situations?

There really isn't any advantages that I've seen yet until the spec is fully implemented by more identity providers.
Even when there is a full implementation, it still has most of the "holes" of normal security short of using key fobs, retina scans and thumb prints, and other features.

Retina scans have downsides too. My retinas have both changed drastically within my lifetime. I'd hate to get back from the retinologists and suddenly have lost access to my account.

On a side note, I love using my credit card at the retinologist's office, because it's the only place where they give me a retinal scan before accepting my card.

@Rachel, you still have interoperability and a globally unique identity across all your networks and services, which is IMHO the coolest thing about OpenID.

I'm not talking about showing your bank account number to other sites with OpenID; you still have to pick your service providers carefully, but your Flickr photos could work on facebook; your Amazon book ratings could follow you to netflix and thence to blockbuster; or your jyte reputation could give you clout on wonkette (for what that's worth).

interoperability between sites is close, but i dont think it will happen without a big push from users who have the skills to write the glue.

I don't see how it could follow you without being traceable back, such that someone on wonkette (whatever that is) will find your jyte account and know you use netflix.

It's going to work down to every person stores their own data, and settings, and shares this dataset with permissions, to shops, and online sites, etc, who take this shared data, and provide the user with a personalized experience.

How you authenticate to your OpenID provider is outside the scope of the OpenID spec. MyOpenID, for example, uses a password to initiate a session, and the session key is subsequently stored as a cookie that will only be transmitted over HTTPS.

However, an OpenID provider that required that you type in six digits of PI, continuing where you previously left off, for every authentication, would not be out of spec, just silly and insecure.

Back on track, you could have an OpenID provider that asked you for a different password for every site you logged into, sure. But that would also be pretty silly.

Rachel, in my example, I wanted those things to be public, but that's my preference and i would (hopefully) be in control of that. If I needed them partitioned, then that would be a case for a delegation or a separate OpenID.

It's not perfect, and OpenID isn't really a security protocol so much as a way to let security-focused firms handle the grunt work of authentication for your website.

The last bit makes sense. We shouldn't have every web site reinvent the wheeel. But it's not a benefit to the user, except in that there are fewer sites to check into their security, and hopefully the OpenID sites will be reliable as to their security.

One ID, many passwords!