Nikolaj recently reminded me of tinyurl.com - the tongue in cheek URL forwarding service that cuts overlong CGI permalinks down to size.
It's a nice idea - in part because of the nice execution and in part because of the problems it highligts.
The idea is nice, and entire URL spaces work OK, so you can abbreviate parts of your URL space to http://tinyurl.com/myspace/mysuburl etc.
The problems highlighted are at least threefold:

1. The TinyURL space itself becomes meaningless. It points everywhere and nowhere.
   
2. Impossible to use with secure URLs. Obviously forwarding your secure data via TinyURL is a bit of a problem.
   
3. Impossible to use for private applications. And private applications are in extra need of this kind of service - being usually defined on some.ugly.subdomain.of.a.corporate.domain
   

How could TinyURL fix the privacy problems: avoiding implicit trust with an intermediary and opening of private namespaces?
Avoiding the implicit trust of the intermediary requires a two way encrypted communication between the ultimate client and the server tinyurl is a proxy for.
That sounds like a Public Key Infrastructure application. A public registry of certificates avoids the need for the client to have a relationship with every server - while allowing intermediaries like tinyurl.
But if the intermediary is to add any value, the data can only be partially clouded. In particular the target urls must be known to the intermediary. So some kind of partial trust protocol needs to be layered on top of the certificate technique. One imagines a mixed payload with encrypted and unencrypted parts.
While PKI and all of the upcoming digital signature concepts provide a cryptographic basis for this kind of work they do not provide the real value giver, namely the protocol allowing mixed trust and without no network effects. In fact, I think I'm following Bruce Schneiers train of thought when pointing out that the real source of trust is the entire relationship between the truster and the trustee. It is an open question if they really need centralized crypto to build or maintain that trust.

The second aspect is reminiscent of the first: A lot of interesting resource for intermediation are on private networks because of safety concerns. Adding crypto to these services before allowing intermediaries access can be difficult and the current certificate infrastructure is such that it is expensive to add and manage certificates.
Second problem is that the certs don't offer fine grained control in this situation either. With public crypto registers I can easily trust any counterpart - but if I want monitored audited access only, crypto isn't it (without a lot of expensive middleware)

In short - an open dynamic architecture for trust and permissions is needed. That was (some of) whaty digital identities was supposed to do - but they don't seem to have made any impact just yet.
The big ideas (project liberty et al) at last glance just seemed to be a new crossplatform 'closed identity' solution.

An unrelated thougt:
The meaningless TinyURL space makes a point about language. Sometimes it is easier to remember a complex grammatically sound statement than it is to remember a short meaningless one. In fact I'll bet good money that statement was easier to remember than the number 49205710362881947293, even though that is only one digit per word of the previous sentence. But that was not really the main point so I left it for the MORE block
What that means is that carefully designed URL spaces are easier to remember than tinyurls