Eli and I went to a potluck dinner in Seattle last night, hosted by Kaliya and also attended by, among others, Drummond and Gabe. That was the good part — a great time was had by all, and Kaliya was a gracious host not only during the dinner party, but also when we showed up on her doorstep twice (evening and morning) after failed departure attempts.

Here are some of the many lessons we learned in the last handful of hours:

• By all rights, Seattle should be paralyzed by chance of snow.
• It’s called Capitol Hill for a reason.
• Real snow extraction devices are better, but square Tupperware works pretty well as a shovel.

With luck, we’ll be able to extract our car later today. I didn’t have the heart to take pictures, but if you want to see dramatic images of the white stuff further north, try these.

And to think we moved from Boston to Seattle exactly four years ago yesterday for some snow relief. :-)

The DocuBank Emergency Card provides immediate access to your healthcare directives, any time, anywhere they are needed. DocuBank provides access to the following critical documents: Living Will, Health Care Power of Attorney, HIPAA release, organ donation form, hospital visitation forms, burial instructions and more. DocuBank makes your healthcare directives work.

They give you a card for your wallet that acts as the “discovery service” to get to the documents, and you need to have authorization to see them: either they’re about you, or you’re a healthcare provider who has specially registered to get access to this type of information.

Poking around online, I also just learned about the Washington State Living Will Registry, which seems to function much the same except that it’s run by the state.

I’m glad there’s a choice of providers for healthcare directives in break-glass scenarios — and I’m also glad I don’t have to host such information myself on the computer under my desk. After all, I could never offer myself a service-level agreement that I’d find acceptable…

George says:

[F]or aggregation to work in the “open web”, it must be able to access my data whereever I’ve chosen to place it.

I agree. If we’re looking to empower people, it’s not realistic to insist that all their information live in a single place. Just as inventing a new identifier type isn’t sufficient to eliminate all the various identifiers we already have in our lives — there are good reasons, not just legacy reasons, to have more than one — solving the problem of storing everything in one place isn’t sufficient to eliminate all the places information about us is stored. Here are two non-legacy reasons.

First, you should be able to choose (as George says) where to store information you created, and you might have reasons for choosing different hosts for information that has different levels of sensitivity, needs for high-availability access, needs for fine-grained access control specific to certain data types, etc. There needs to be an option not just to import/export everything en masse from one competing hosting environment to another, but also to tolerate multiple sources of data at once. It almost feels anti-web to prefer an architecture that requires everything to live together on one server.

Second, it doesn’t make sense to throw information about you for which you’re not authoritative (like your credit score, or really any reputation data) into one aggregation pile; you can’t control the value, but it’s still “yours” in lots of other senses. You might have the right to track who sees it, but a live copy shouldn’t reside in your one big database where you have write access. (I liked Gerry Gebel’s insight around this: Try to think of any application that relies on data from elsewhere to be stateless with respect to it. Another way to think about it is that you want to achieve a sort of “first normal form”, where information properly lives wherever its authoritative source chooses it to live.)

George notes that if you can authorize a relying party to get the data from whatever your preferred source is, you can get the best of both worlds. It’s aggregating some parts of data provisioning, usage, and auditing, but not the actual residence of the data.

I’ve become convinced that multi-sourced data access is a requirement for the core permissioned data sharing issue that’s common to identity, VRM, and social networking use cases.

I happened to do a webcast yesterday that describes the VRM proposition — you can watch the recording if you register for a free account — and I went into a bit of detail about the technical requirements I see, along with reviewing some of the architectures at our disposal for achieving them. (The good news is, there are already several…) [UPDATE: Slides are now available here.] I think I need to start adding this requirement to my list.

Here are some tidbits I’ve been collecting since I came back from vacation:

• OpenSSO Enterprise 8.0 released — it covers lots of protocols, and even supports circles of trust that mix federation protocols, but this is SAML-related by virtue of OpenSSO’s uniquely solid row of SAML2 interop certifications…

• Great progress on leveraging the SAML2 metadata format in WS-Federation

• Microsoft’s announcement of the Geneva server and its planned SAML2 support (further details)

I first met Don in early 2005, as part of a joint team of Microsoft and Sun folks working on early forms of single sign-on interop (Pat’s old post here, photographic evidence of the Pat and Don show here). This partnership has deepened over the years in service of our many mutual customers, and Don is a delight to work with. Congrats to him and the Geneva team on taking these steps, and I look forward to continuing our joint interop work.

On vacation last week in Sin City, I got an offer someone thought I couldn’t refuse, and was put under surveillance in an interestingly creepy way.

For custom service, you have to pay — in money, attention, or personal data. The Wynn hotel-casino (which is gorgeous, but has such a useless website that I’m not linking it) desperately wanted me to sign up for its Red Card loyalty club. Here’s the deal: If I sign up for the card by showing them a valid government ID and giving them my full name, Social Security Number, date of birth, mailing address, email address, and cell phone number, they will give me a buffet meal for free. This is all listed right on the rather large offer card, and there’s nothing about privacy policies on there either. The Wynn buffet is a treat, but I’d rather give them mere dollars for that, thanks. (One person in my traveling party — a frequent gambler, something I’m not — did go for the deal.)

And if you want to be a bit of a coquette in the twenty-first century, apparently you have to be put under close and possibly recorded observation without any notice given or consent obtained whatsoever. Hey, I’ve watched CSI – I realize that in Las Vegas you aren’t safe from security cameras anywhere except the bathrooms. But then I sat down at the iBar in the Rio and started futzing around with the Big-Ass T…uh, I mean the Microsoft Surface. At first I didn’t realize other private citizens could observe me closely from their B.A.T.’s elsewhere in the bar. It’s supposed to be for flirting:

Flirt Vegas style by adding a hip ultra-lounge vibe to the flirting experience. This application allows guests to create an exciting new way to chat and meet people from one Surface to another. Strategically placed video cameras at each Surface add even more energy to the action, allowing guests to interact with old friends, flirt with new acquaintances, and take and send photos across the lounge.

Luckily, this also meant I could observe the action at other B.A.T.’s myself, which was useful when I couldn’t figure out how to find the Virtual Earth app and caught the camera’s-eye view of the people at the next table using it. Well, honestly I could have just looked over to see that, but using the spy-eye gave me such a sense of power. :)

Eli and I did play a few games of virtual bowling, which was fun in a flashback-y sort of way. It reminded me of one of the bars my first band Sleeper played regularly in ‘80-’81 — the long-lost 23rd Step in Kailua. They had a game table where you could sit across from someone and play Galaxian. It was just offstage next to my keyboard setup, and I would lunge for it whenever we finished a set, about the time the other band members were lunging for the next-door 7-Eleven if it was before midnight and beer could still be legally bought. Ah, good times.

(In case anyone else who loves those old games goes to Vegas, check out the dim corners of the Gameworks on the south Strip, where you’ll find Space Invaders, Centipede, and — yes — Moon Patrol.)

Um. And with that, I think I’ve proven once again that I’m the queen of TMI (why does that acronym spring to mind every time I bring up video games here?).

Exit question: Are privacy policies positively pointless for someone who just spews random data about themselves on a public website anyway?

The first pattern is human-initiated. This is when you reach out to an app — say, visiting a browser bookmark for Dopplr — in order to use it in real-time. These days, often you log in somewhere else (at some identity “provider”) so that the app you want to use can “consume” information about you to do the job you want. Think single sign-on and login-time transfer of data about you.

The second pattern is app-to-app. This is when an app, having been previously introduced to other apps that are sources of info about you, talks to them about you on your behalf, even if you’re not around — like when FireEagle and Dopplr share your location info. But it’s done in a way that’s privacy-enhanced and sensitive to your preferences. OAuth has been great for demonstrating why this is valuable, and of course it’s the central point of Liberty Identity Web Services too. (Check out Paul Madsen’s helpful series comparing OAuth and ID-WSF.)

I’m thinking it’s time for the pattern of the third kind to get more attention: app-initiated. This is when an app needs your attention and reaches out to you to get consent, or data, or an acknowledgment of receipt. Today in the wild, we see lots of notices sent through email and SMS (package tracking, flight cancellations), but don’t have a good way to set up our preferences for the way apps request action on our part. The Liberty Interaction Service could be a part of the solution.

This third pattern seems absolutely key for managing privacy robustly, assuming you’re properly auditing the app-to-human contact and its results. Here are some of the scenarios that have come up recently.

Emergency contacts: When you travel internationally or sign up to get treatment from a doctor or surgeon, you usually have to provide an emergency contact. It would be better to do this by telling apps how to look up how to contact the person in question, rather than giving phone numbers or email addresses that can go stale or be inappropriate (too synchronous or asynchronous, or too unlikely to elicit a response) for a particular purpose. This would also be useful for a variety of delegation-type tasks, like indicating who’s willing to sign for packages while you’re away — especially in conjunction with the Liberty People Service.

Integrating identity selectors: This was suggested by Pamela Dingle (in response to my critique of “classic” identity selector behavior at Burton Catalyst). Provision your Interaction Service to know how to fire up your identity selector when you’re online, so apps could use it to initiate contact with you to gather consent and get new claims. Cool idea, and maybe worth exploring a profile someday; I ended up mentioning it at a meeting of the Web Services Harmonization SIG we we wouldn’t lose it.

Health research: Gather consent when new uses of previously collected data arise (aggregating study data in a privacy-sensitive way), and gather more data over time for longitudinal studies. This idea came up at the Project VRM workshop in Boston, and it’s useful for not just health research but pretty much all VRM-enabled data-sharing scenarios — it can increase an app’s ability to gather less data on initial contact (the fewer required fields, the better!), and thus a human’s comfort level with choosing this vendor.

I get the idea that a lot of my Liberty colleagues haven’t gotten excited about the potential of the Interaction Service the way I do. Am I nuts? Am I missing other juicy use cases? What would it take to get something like this working in a standard way with things like OAuth?

• 4th ACM Workshop on Digital Identity Management: This workshop will be held October 31 (pack your Halloween costume…) in Fairfax, VA. Early-bird registration ends October 10. You can register for just the workshop if you can’t attend the ACM CCS2008 conference with which it’s colocated. The program this year looks really interesting; the theme is “services and identity”.

• Identity Forum 2008: I’m a late addition to the program of this conference, speaking on Project Concordia on October 7 in Rotterdam. Should be a great trip. If you’re planning to be there, I hope you’ll say hi.

• Project VRM Standards Committee: This group is holding its first proper face-to-face meeting and coding camp on October 15-16 in Cambridge, MA. (I can’t attend but will be calling in.) RSVP to Joe Andrieu. (I have in the past described this group’s telecon series as “like crack” — if you’re addicted to rapid-fire idea generation and lots of “ooh, now I grok it” moments.)

• Net-ID 2009: This conference on identity, trust, privacy, and security is being held February 16-17 in Berlin, and the Call for Papers is now open.

(Has Mr. Winky the IdentiCat met Mr. Winkle the dog?)

I’ve been trying this out on folks for a while now, and used it in a couple of recent talks, particularly my Gnomedex 8.0 one. Here’s my thinking behind it. (This is more than a straight Venn because of the metaphorical shadow thingie. Couldn’t resist! My web services Venn “cheated” too.)

Digital identity management is, at base, about identification so app usage can be correlated and audited, authorization to provide secure controlled access, and personalization, all counterbalanced by privacy. It has a strong individual (single-human-to-app) bent, though sometimes it involves Shibboleth-style scenarios where you mostly track anonymous group members rather than unique people.

Social networking is about building feelings of connectedness and offering the benefits of collaboration, such as crowdsourcing. Social apps focus on human-to-human relationships, but to provide infrastructure for this, they have to do plenty of the human-to-app variety. Social networking today stresses revelation of personal details (the OpenSocial best practices doc is one example) much more than it stresses privacy, though the latter is an increasing concern.

VRM partly involves what could be called restriction of data flow — undoing vendors’ grip on users’ info in a way that’s familiar to proponents of privacy-enhanced and user-controlled IdM. But other VRM scenarios involve enhancement of individuals’ opportunities to share personal information, for example by issuing a personal RFP to potential vendors. As Doc Searls has said, VRM is “personal first and social second”, so it seems to have a closer kinship with digital identity but could provide new social opportunities as well.

Each area has its unique features. But all share a common trait — differentiated app behavior depending on special aspects of you (whether this comes from attributes, claims, and transactional details in IdM; social graph data and user-generated content in social apps; or proactive requests and other personal data offered up in VRM). And to deliver on this promise they all share a common requirement — knowing more about you, with permission.

By contrast, where apps know about you through improper data gathering or aggregation, you get digital shadow effects — like direct marketing that is distinctly not permissioned or welcomed. Today, permissioning is still something of an art rather than a science, hence the title of this post.

We have a number of infrastructural options that more or less satisfy the requirements of the intersection, and later I hope to provide further thoughts on that. For now, I hope you’ll let me know what you think of this new instance of John Venn’s invention.

Lots of people have done roundups, so I’m mostly going to be lazy and point to Beth Kanter’s, which gives a great sense of the breadth, the depth, the value, and the occasional silliness of this event. I was very glad to meet Beth and to see her demonstrate, right in front of our eyes, the principles she was teaching. Really, the two-plus days were a virtual parade of interesting people, compelling stories, and cool tech.

Speaking of virtual… Gnomedex’s sheer level of online+meatspace social connectedness was something new for me. The 8.0 community feeling started early, with the @gnomedex Twitter feed. It continued with the conference badges that came with a social network. It got really strong while several hundred people watched the conference from home on the video feed (archive) and hung out on Twitter or in Chris’s chat room. (I daresay this feeling wouldn’t have been possible without the single-track setup.) And it continues even now. I mean, I tweet, and I speak at conferences, but I’ve never before sat down after giving a talk to find that dozens of people — some in the same room and others a world away — have just started following me. Delighted to meet you all! (Admittedly, I also exchanged business cards with some folks during coffee breaks, the old-fashioned way.)

I’ll post some thoughts later about my talk on online data-sharing relationships. But, staying “meta” for now, I’ll just send you to one more roundup, Micah Baldwin’s 3 Rules of Gnomedex 8.0, which I think nicely captures what made it special. Quoting will just spoil it, so just go ye and read…