In both cases, the answer to “who are you?” depends on who’s asking. When I’m the server, I’d like to know who’s asking.

In the simple case of calendar sharing, a lower tech facet of this solution (as I just commented on one of your previous posts) is to share full calendar information with close contact and FreeBusy information with more distant contacts. That’s progressive disclosure for calendars, but it’s I have to control it by giving out different references to different types of calendar feeds, and (as you indicated), there’s no simple way to visualize what’s been shared with whom.

I recently went back to a couple of pages that had not been touched in years (my first weblogs, dating back to 1999) and inserted a little bit of tracking javascript to see where the hits were coming from. I hadn’t expected to have much traffic, but there is a steady background radiation of 15-30 hits a day on pages that haven’t been changed for a long time.

The “surface area” viewer I make the best use of at the moment is 103bees, a search log analysis tool. The embedded javascript relays the search engine query terms to a stats gatherer, which in turn collates results. Not perfect – you can’t embed it on Flickr, for instance, or on comments you leave – but mighty handy when it does work.

I know this is only a piece of the problem. Like you, I rely on the privacy of the embargoed URL and trusting that no one plants a link to it in a visible web page, a blog or whatnot. If it was something I cared more about, I could watch the log reports to find out how the URL is being used (especially the referrer report).

If I were to do more, I would put a real server password on that embargoed section, already in a folder with a not-guessable name created using a password generator. Other than making things more difficult, I don’t think I have accomplished anything other than add a slightly-higher level of protection for something that there’s a mutual interest in keeping private.

It seems to me that giving out a password or a URL is workable but does not scale. I don’t think it is about passwords, I think it is about authorization. I would want to authorize the possessor of a particular certificate to access the material. Having a certificate and the (unknown to me) private key associated with it seems as strong as it gets for practical privacy agreements. Now only if the certificate is compromised, or I accepted the certificate of an imposter in the first place, is there a problem. But it is easy to revoke the access rights of that individual certificate once the compromise is known. This does mean that I would have to keep track of the specific certificates I had granted access to, but that would be good enough for the cases I have in mind.

So, it sounds like something like InfoCards (sorry, I can never remember the married name of that technology) with its easy self-generated certificates might be a reasonable way to set up a private realm shared by a modest number of participants.