In a long post, Eve Maler discusses a lot of the issues around identifiers, like OpenID URLs, such as when they should be public and when private. She's asking some questions, and here is a stab at answering them:

First question: If I already know what public persona I want to use with a web app, can I give them the persona URL directly? (I'm assuming that if I've got a bunch of them and can't keep them all straight, it's useful just to get over to my IdP and pick one from some kind of drop-down interface or something.)

Excellent question. What we do at NetMesh is to make an assumption: if you used identifier X at a particular site last time, you most likely will want to use the same identifier next time you visit. (To make the point that this is a reasonable assumption, try to think of a case where that assumption is not true, and it would be unnatural to have to press a logoff button first. There are some, but not very many examples.) Thus, we store the OpenID identifier in a long-term cookie and automatically (and typically transparently) re-authenticate you next time you visit.

So Eve's point really only applies the first time you visit a site and authenticate: at that time, it's reasonable to think about what you want the site to know, and who else knows you by this identifier. Later, you don't have to do that any more.

Second question: Is there a way to ensure that I, the user, can't abuse/ruin a "private" identifier created for security purposes? ...it seems best if I never know it, particularly if it's in easy-to-remember URL/XRI form.

Keeping users safe from themselves is always a difficult thing — on several levels. Personally, I have encountered a lot fewer cases where this is really needed than I expected. However, that doesn't mean we can't do it ... for example, there is nothing that prevents an identity provider / identity host implementation from putting a "lock" on any particular identifier, refusing to authenticate with that identifier at any site other than a limited, locked set, displaying an error message such as: "Dear user, you are trying to use your premium-membership identifier in the XXX club at your church's site. I don't think I can let you do that."

Johannes discusses the essential nature of having yourself be addressable on the web to exist. Though it took some time for me to get my head around it, this now makes a ton of sense to me in the open-Internet context ... However, if you want to allow for an anonymous-authorization use case or for any level of privacy at all with something like OpenID, is it sufficient to make the identity provider addressable?

First, I believe OpenID 2.0 will allow that. But regardless, keep in mind that the relying party necessarily needs to have some kind of "handle", relative to the identity provider, that uniquely identifies my account there, as opposed to somebody else's. (Otherwise I would get their shipments, or they my invoices.) By concatenation of the identity provider URL and the local handle, we arrive at the same privacy (or lack thereof) as in case of using the identity URL in the first place.