Some 30 live attendees were very patient with my Internet connection problems, meaning that the slides (large PDF) didn’t advance when they were supposed to and I couldn’t answer questions live. However the good folks at BrightTALK fixed up the recording to match the slides to the audio, and I thought I’d offer thoughts here on the questions raised.

“Framework provider – sounds suspiciously like an old CA (certificate authority) in the PKI world! Why not just call it a PKI legal framework?” Yeah, there’s nothing new under the sun. The circles of trust, federations, and trust frameworks I discussed share a heritage with the way PKIs are managed. But the newer versions have the benefit of lessons learned (compare the Federal Bridge and the Open Identity Solutions for Open Government initiative) and are starting to avail themselves of technologies that fit modern Web-scale tooling better (like the MDX metadata exchange work, and my new favorite toy, hostmeta). PKI is still quite often part of the picture, just not the whole picture.

“How about a biometric binding of the individual to the process and the requirement of separation of roles?” I get nervous about biometric authentication for many purposes because it binds to the bag of protoplasm and not the digital identity (and because some of the mechanisms are actually rather weak). If different roles and identities could be separated out appropriately and then mapped, that helps. But with looser coupling come costs and risks that have to be managed.

“LDAP, AD, bespoke, or a combination?” Interestingly, this topic was hot at the recent Cloud Identity Summit (a F2F event, unlike the BrightTALK one). My belief is that some of today’s tiny companies are going to outsource all their corporate functions to SaaS applications; they will thrive on RESTfulness, NoSQL, and eventual consistency; and some will grow large, never having touched traditional directory technology. I suspect this idea is why Microsoft showed up and started talking about what’s coming after AD and touting OData as the answer. (Though in an OData/GData deathmatch, I’d probably bet on the latter…)

Thanks to all who attended, and keep those cards and letters coming.

All experiences are marked by suffering, disharmony, and frustration.

Suffering and frustration come from desire and clinging.

To achieve an end to disharmony, stop clinging.

(I can’t wait to hear his pearls of wisdom at the Cloud Identity Summit later this month… I’ll be there speaking on UMA. You going?)

This resonated with another plea I’d just heard from Chris Palmer at the iSEC Partners Open Security Forum, in his talk called It’s Time to Fix HTTPS.

Chris’s message could be described as “Stop clinging to global PKI for browser security because it is disharmonious.” He reviewed the perverse incentives that fill the certificate ecosystem, and demonstrated that browsers therefore act in the way that will help ordinary users least.

Why, he asked, can’t we convey more usable security statements to users along the lines of:

“This is almost certainly the same server you connected with yesterday.”

“You’ve been connecting to almost certainly the same server all month.”

“This is probably the same server you connected with yesterday.”

“Something seems fishy; this is probably not the same server you connected with yesterday. You should call or visit your bank/whatever to be sure nothing bad has happened.”

Perhaps I was the only one not already familiar with his names for the theory that can make these statements possible: TOFU/POP, for Trust On First Use/Persistence of Pseudonym. Neither of these phrases gets any serious Google search love, at least not yet. But I love TOFU, and you should too. (N.B.: I’m not a big fan of lowercase tofu.) The basic idea is that you can figure out whether to trust the first connection with a nominally untrusted entity by means of out-of-band cues or other met expectations — and then you can just work on keeping track of whether it’s really them the next time.

The neat thing is, we do this all the time already. When you meet someone face-to-face and they say their Skype handle is KoolDood, and later a KoolDood asks to connect with you on Skype and describes the circumstances of your meeting, you have a reasonable expectation it’s the right guy ever after. And it’s precisely the way persistent pseudonyms work in federated identity: as I’ve pointed out before, a relying-party website might not know you’re a dog, but it usually needs to know you’re the same dog as last time.

Knowing of the desire to cling to global PKI in an environment where it’s simply not working for us, Chris proposes letting go of trust — and shooting for “trustiness” instead. If it successfully builds actual Internet trust relationships vs. the theoretical kind, hey, I’m listening. There’s a lot of room for use cases between perfect trust frameworks built on perfect certificate/signature mechanisms and plain old TOFU-flavored trustiness, and UMA and lots of other solutions should be able to address the whole gamut.

Surely inner peace is just around the corner.

Case in point: The crap that fills the fields of 77% of domain name registrations. (The Register’s headline: Whois in charge? ICANN’t tell. Heh.)

This is where “attribute assurance” could come in, involving a federated identity system that arranges for the data to be supplied by trusted issuers in some fashion. Attribute assurance is akin to identity assurance (as discussed previously here), except that it’s about the quality of specific types of information and their binding to the individual in question. The world hasn’t yet come up with a generic way of handling such assurance, though it’s been a topic of serious discussion. The Tao of Attributes workshop was a great start.

In the domain name registration case, one of the big reasons why people don’t like to supply their real information is that it’s published far and wide — anyone can learn what your address is if you provide your real one. Hence the lying, at least in quite a lot of the cases. This is a real-world situation where needs for level of assurance (LOA) are in a tug-o’-war with needs for level of protection (LOP).

What’s LOP? In short, it’s the reciprocal of LOA. Whereas relying parties want to ensure that the data they’re getting is good when they get it, data subjects and their identity providers want to ensure that the data will be protected and treated with respect when it gets there.

(You can read more about LOP, and some of the elements that need to be lined up to solve it in an Internet-scale way, in The 
Open 
Identity
 Trust
 Framework
 (OITF)
 Model, a white paper I was honored to co-author along with Tony Nadalin, Drummond Reed, Don Thibeau, and our illustrious managing editor Mary Rundle. The proposed model suggests some ways to organize the Pushmi-pullyu nature of federated identity partnerships to raise the quality, and possibly tamp down the quantity, of identity attributes floating around.)