Tag: cardspace

Mark MacAuley in Las Vegas: Personas and Legends

Having just read about Mark’s exploits in Vegas and being reminded about a conversation he and I had, I ended up trawling back through my posts to find the conversation in question.  I think this is what he was talking about.  Funny to see I wrote this all the way back at IIW2005… time flies.

Mark raises the question how hard would it be to “become someone else?”  He claims:

“how over a period of years you could really craft a persona and migrate it to a full blown identity in short order through social engineering, working the system”

Migrating a persona to an identity?  Is that like migrate a 3270 app to .NET?  Seriously though, you can’t migrate a persona to an identity.  You can, however, grow a persona into a legend.  A persona is an episodic, contextually scoped set of assertions.  An avatar.  For this reason alone, I wonder how meaningful CardSpace will be to the typical home user.  There is a decent sized population of people who are comfortable with the concept of avatars.  Your IRC handle, SecondLife name, and MUD login are all avatars.  For these users, presenting an InfoCard here, there and everywhere feels familiar.  However, there is an even larger population of users for whom these concepts are alien.  For these people, they are who they are and it never occurs to them that there is a layer (or three) of abstraction between their butt in their chair and their representation in Amazon, Hotmail, and E-Bay.  Furthermore, the idea that they can “exploit” this abstraction for any number of reasons is even more foreign and strange.

But exploiting enough of these abstractions creates a legend.  A legend is the complete package.  An entire fictions pseudo-identity with all the trimmings: credit history, employment records, government records, etc.  In the non-espionage world, you don’t need all the trimmings but just enough to create a high enough level of credibility to pass a solid sniff test.  To Mark Mac’s point, I think you can create a legend with a little bit of effort.  That “guy” on LinkedIn who wants to link to you because you worked together at Company X… that guy is creating his legend.  He’s likely a combination link-whore, recruiter, or combination of the two.  But that being said, by linking to him you are reinforcing the credibility of his legend.

What may start as a persona, say a fabricated LinkedIn account, can grow over time into a legend.  Add some corroborating Facebook entries… a couple of tweets from Twitter and sure enough, you can start to put together a fine legend.

A final side note: managing enterprise employees’ identities (all aspects thereof) is an exercise in legend management, while managing “customer” identities is a persona management exercise. Who says HR data is clean after all? 😉

SPML Decision Followup… followup

Conor has graciously explained the “strangeness” I felt in the Advanced Client scenarios. He explains that this part of advanced client work:

addresses the problems involved in provisioning functionality to a secure container that is associated with a user somewhere nearby

That snippet was enough for me to grasp it. Read the rest of what he has to say for more.

I wanted to clarify on two points he made. First:

Ian seemed to connect this work to Cardspace, Higgins, and OpenID. I am not aware of this connection.

Agreed. This was a case of my braining running ahead of my hands. I started with the ICP stuff and somewhere along the line my brain hopped on to a different topic… sorry, lack of conversational turn signals. This (barely) provides a little bridging between my thoughts.

Second:

Ian seemed to think that this provisioning was just about provisioning a credential. That isn’t the case.

That would be my user provisioning baggage. Account/credential = functionality. Dogmatic on my part. The reality is that a collection of attributes can (and do) define different sets of functionality and/or access. We used to call them virtual accounts in my IBM days.

Is SPML irrelevant in the coming CardSpace/Higgins/OpenID identity world?

I was reading about Conor Cahill’s workshop at RSA on secure provisioning of network credentials over the wire. It was a joint proof of concept between Intel, BT, and HP using Liberty’s ID-WSF Advanced Client. They talked about how to get credentials from service providers down into a client environment. (Although it is not a requirement, clearly Intel would love it if the client environment was a TPM-like object.)

One aspect of all this is a provisioning service, one for which Liberty has cooked up a spec. As a user provisioning guy this model of provisioning looked a bit strange to me. Think telephone service provisioning, not enterprise user account provisioning. The funny thing is, I thought there already was a perfectly good provisioning service standard out there – Service Provisioning Markup Language (SPML).

That got me thinking. Provisioning is an aspect of the identity lifecycle that you don’t really hear about in talks on Higgins and CardSpace and such. This is a bit of history repeating itself. Back in the day, the authentication guys got all the glory, all the publicity, and when it came time to make sure there were actually credentials in back-end services, they waved their hands. It was the lowly user provisioning system, the late-shift janitor of the identity world, that actually had to do the dirty work. Who is this janitor in the user-centric identity world?

Before I go on without a better understanding, I’m looking for comments on this one. Where does SPML fit in this brace new identity world? Is the intention that SPML will be passed as part of a larger SAML assertion to establish credentials? Is the PSTC working on scenarios like this?