Posted 9:52 AM (0) comments

The Peter Principle of Protocols

A good Post today from Eve Maler reminding us that it's not just people, and it's especially not just on-line people, that have identity issues.

"I realize that the description I’m after is more like 'human-centric identity'. It comes with both online and offline scenarios and still needs to allow for (real-time or not) informed consent and attribute exchange."

This might be a good time to, once again, plump for "persona" as the term for what many call "on-line identity" so that we can keep straight what a real identity is.

She also alludes to the fact that not all identity protocols need to be able to do everything.
There's still room for lightweight, on-line digital person identity systems (vide OpenID) to be used within limited situations. It's not a criticism of OpenID to suggest that it only be used in low-value transactions. What is wrong is to apply a sort of "Peter Principle of Protocols" to OpenID, extending the original Peter Principle (formulated by Laurence J. Peter almost 40 years ago) thru the "Generalized Peter Principle" promulgated by Dr. William R. Corcoran: "anything that works will be used in progressively more challenging applications until it causes a disaster." Let's keep, and improve, OpenID for the things it does best. Let's not try to teach that pig to sing.

Labels: attribute exchange, digital identity, liberty alliance, openid, persona

Posted 9:36 AM (4) comments

More on the Identity Oracle

I tried to leave this comment on Kim Cameron's blog, but pushing the "post" button seems to send IE (which I have to use there in order to submit an identity card) into the never-never..
********************************************
Drop it while you can, Kim. Bob's right on this one. The "Identity Oracle" is a business model, not a technology feature. As I've said many times (and countless others have re-iterated), the technology is easy, it's the people that are the hard part.

"Claims transformation" is simply changing data from one format to another, or one protocol to another, etc. It's technology. It may be a necessary part of the infrastructure for an Identity Oracle, but it's only one small part.

For my take on the Identity Oracle, watch next Wednesday's Identity Management Newsletter.

Labels: attribute exchange, cardspace, oracle

Posted 8:46 AM (4) comments

A virtual solution

Conor and Eve's responses to "Putting ID all together" correctly note that the Liberty spec is 'location agnostic' about data. I'll even agree with Eve when she states

"If all you’re storing is self-asserted info about you personally, then sure, it’s handy to consolidate all of it in one place over which you have direct control, whether that’s a traditional web app/service, a device you carry on your person, etc. But as soon as you get into information that someone else has the right to own (including mundane things like your employment status, which comes up a lot when you, say, apply for loans), I can’t see their being okay with giving you the “gold copy” to hold. That’s where multi-sourcing really shows its stuff."

(This in response to Dick Hardt's assumption that the user, having chosen an identity provider [in that discussion, an OpenID Provider or OP], would happily entrust everything about themselves to that one OP and wants all relying parties to upload any interesting facts about the user back to the OP. )

But there is, of course, a third way. And one I think is a better way. It's the tried and true "virtual directory." Data is consolidated into a repository controlled by the user. Applications query that repository for data. But the authoritative source for that data may well lie somewhere else (e.g., Eve's "employment status" data point). All that's needed is a synchronizing join engine (something the folks at Oracle, Radiant Logic, Symlabs, MaXware and the Penrose Project are very familiar with) with a new frontend or two to support attribute exchange via Liberty protocols, WS-* or even OpenID.

Labels: attribute exchange, virtual directory