The Virtual Quill

The role of roles

2008-07-01T08:21:00.000-07:00

Ian Glazer has just released his first post since signing on with the Burton Group, and it's a good one, about the wrong-headed notion which appears to be taking hold in the market place that roles and role management are needed before provisioning can occur. As Ian puts it:

Implicit in the idea that an enterprise cannot attempt user-provisioning because it is not ready for role management is the notion that user provisioning has no value to the enterprise without role management. This is an outdated argument that is simply not true.

In fact, the opposite is true - roles, while not requiring it, will benefit from a good provisioning implementation.

Look at it this way, even without computer-based Identity Services people need to be provisioned into the resources they will use. eProvisioning simply automates that task. While the concept of roles may be present, roles-as-a-tool is only useful within a digital context.

Acquiring, piloting, prepping and rolling-out provisioning services should really be a no-brainer decision, especially today - almost 10 years after eProvisioning was first introduced - when so much of the setup and rollout is scripted, wizard-ed, template-ed and cookie cutter-ed. It's easy to demonstrate the efficiency gains (and the budget gains) from provisioning apps & services. There's also the fact that the successful launch of a provisioning service establishes a baseline and a platform for creating the rest of a full-blown identity services implementation, even beyond role management. Govenance, Risk Management, Entitlement Management, Security Audit, Simplified Signon, Priveleged Account Management and more have a much better chance of being successful if they follow a well executed provisioning rollout.

New tricks and old tools

2008-05-16T08:09:00.000-07:00

Kim Cameron follows up on Clayton Donley's post with some thoughts of his own. And ends by quoting Clayton:

"The real solution here is a combination of virtualization with more standardized publish/subscribe for delivery of changes. This gets us away from this ad-hoc change discovery that makes meta-directories miserable, while ensuring that the data gets where it needs to go for transactions within an application."

and adding: " As soon as applications understand they are PART OF a wider distributed fabric, they could propagate changes using a publication pattern that retains the closed-loop verification of self-converging metadirectory. "

I couldn't agree more with these two erudite gentlemen.

Unfortunately, today's applications, and especially yesterday's applications still hanging around on our networks, but even tomorrow's applications for some time to come won't be written to be a part of a "wider distribution fabric," especially as that fabric doesn't yet exist in any meaningful way. And, as Kim said in an earlier posting, "Here�s the problem. Infrastructure people cannot dictate how application developers should build their applications. " We can build the infrastructure that will excel in a publish-subscribe world, but getting the apps developers to buy in to that model, well, that's something else. I'm all for building the infrastructure and plumbing of the future, but we need to adapt today's tools so that we can get the job done while waiting for the new plumbing.

optimization and expense

2008-05-12T10:11:00.000-07:00

Neil Macehiter comments on the last post:

But the issue is not with the language you use to perform the query: it's where the data is located. If you have data in separate physical databases then it's necessary to pull the data from the separate sources and join them locally. So, in Kim's example, if you have 5000 employees and have sold 10000 computers then you need to pull down the 15000 records over the network and perform the join locally (unless you have an incredibly smart distributed query optimiser which works across heterogeneous data stores). This is going to be more expensive than if the computer order and employee data are colocated.

The "expense" is there no matter how you do it. Putting all of your potentially useful data in one RDBMS is incredibly wasteful of storage space and comes at the cost of slowing down all queries. It also means that synchronizations need to be done almost constantly in order for the most up to date data to be available, a network "expense". But the search can be optimized before any data is pulled. For example, query the HR database for the lowest employee number issued after the first date you're interested in (assuming that employee numbers are issued sequentially). Then query the orders for PC purchases by that employee number or higher. Yes, it's two steps, but it's also faster than pulling down all the records to do a local join. And, I hold, less "expensive" than maintaining a huge silo of all potentially useful data.

Getting more violent all the time

2008-05-12T08:46:00.000-07:00

The distinguished Mr. Cameron has restated what he thinks is our major disagreement over synchronization and replication of identity data on the so-called "identity bus." He says:

"Sometimes an application needs to do complex searches involving information 'mastered' in multiple locations. I�ll make up a very simple 'two location' example to demonstrate the issue:
'What purchases of computers were made by employees who have been at the company for less than two years?'

Here we have to query 'all the purchases of computers' from the purchasing system, and 'all employees hired within the last two years' from the HR system, and find the intersection.

Although the intersection might only represent a few records, performing this query remotely and bringing down each result set is very expensive. No doubt many computers have been purchased in a large company, and a lot of people are likely to have been hired in the last two years. If an application has to perform this type of query with great efficiency and within a controlled response time, the remote query approach of retrieving all the information from many systems and working out the intersection may be totally impractical.

Compare this to what happens if all the information necessary to respond to a query is present locally in a single database. I just do a 'join' across the tables, and the SQL engine understands exactly how to optimize the query so the result involves little computing power and 'even less time'. Indexes are used and distributions of values well understood: many thousands of really smart people have been working on these optimizations in many companies for the last 40 years."

What Kim fails to note, however, is that a well designed virtual directory (see Radiant Logic's offering, for example) will allow you to do a SQL query to the virtual tables! You get the best of both: up to date data (today's new hires and purchases included) with the speed of an SQL join. And all without having to replicate or synchronize the data. I'm happy, the application is happy - and Kim should be happy too. We are in violent agreement about what the process should look like at the 40,000 foot level and only disagree about the size and shape of the paths - or, more likely, whether they should be concrete or asphalt.

The COBOLization of LDAP

2008-05-10T08:51:00.000-07:00

In a panel discussion at the recent European Identity Conference I referred to LDAP (Lightweight Directory Access Protocol) as "The COBOL of Identity." It came amidst a discussion of future identity-sharing protocols and was intended as 1) a cheap laugh; and 2) as a short, memorable way of saying that LDAP would always be with us.

I mentioned it again in a newsletter about the show ("Building an Identity Bus, Part 2") which has now been misread by a couple of people, so let me set the record straight.

Jeff Bohren writes: "That�s cute, but not terribly accurate. COBOL has had competing languages almost from the very beginning. If you chose to use COBOL, you did so because you felt it met your requirements better than the other existing alternatives. So Dave, what is the alternative to LDAP today? What will it be in 5 years?" That was the point, Jeff - that, like COBOL, LDAP will always be with us.

Clayton Donley opines:

"There's no pressing need to get rid of LDAP in existing applications. None at all. It works. The applications support it and will continue to support it indefinitely.
Even in next-generation application I see LDAP support being integrated -- hardly what I see of COBOL ...
What does this say about any future identity services?
They must support LDAP-enabled applications.
Does this mean that they will only support LDAP? No."

Exactly.

It does seem that when a bold thought is made as an pithy, somewhat humorous statement that it's seen as some how denigrating the subject. so let me say it once again -

Like COBOL, LDAP is so deeply ingrained in our computing arsenal that it can never be entirely replaced.

Now since one is a programming language while the other is a protocol the analogy will break down upon close inspection. But I will stand by it.

A herring of a different color

2008-04-11T08:12:00.000-07:00

You almost had me, Kim. I read your latest entry and was ready to share that olive branch. Right up to the last paragraphs when you say (about me):

"...He keeps saying I propose 'a directory that gathers and holds ALL the data from ALL your other directories.' Dave, this is just untrue and unhelpful. �ALL� was never the goal - or the practice - of metadirectory, and you know it. The goal was to represent the 'object core' - the attributes shared across many applications and that need therefore to be kept consistent and synchronized if stored in multiple places. Our other goal was to maintain the knowledge about what objects 'were called' in different directories and databases (thus the existence of 'connector space').

Basically, the �ALL� argument is a red herring..."

Not at all. Let's step back a pace or two, or a posting or two, and think about the reasons for having this meta/virtual directory. Yes, it helps to normalize the data and keep it in sync. But if that were all, than a couple of keyboard monkeys could handle the chore and, at least in the case of normalization, could do it more quickly than a semi-automated process.

But the real reason we want to do this is so that identity data is available to applications. Available to them using a single vocabulary and a single protocol. Not that there can't be multiple vocabularies and protocols, but any one application would only need to use one of each - each application programmer would only need to use the vocabulary and protocol she was most familiar with.

But for this to be effective, the programmer needs to know that any identity data they need is available through this mechanism. And the only way any data can be available is if all data is available. The identity data must be pervasive and ubiquitous - available whenever and wherever you need it.

From the application's point of view, it should appear to be a single silo but in reality, the data will be distributed throughout the fabric of the network both within and without the enterprise, the identity provider or other data store.

The promise of the meta/virtual directory is that it can serve up the current, correct data on demand from wherever it resides. And to do that, it has to aim to provide all identity data.

Now, to forestall some people, let me add that the security of this system is a given- there need to be strict and fine-grained access controls for the data. There need to be well designed mechanisms allowing for whoever controls a bit of data to authorize its release. Without these things the system is useless because no one would use it.

But this systems needs to aim to have available all identity data, every conceivable bit of it. Because without that, the application programmer can't be sure that the bit he needs is there and so will set up alternative storage for the bits that that application needs.

We're not there yet, but we need to go that way.

Your mother was a hamster and your father smelt of elderberries!

2008-04-09T09:58:00.000-07:00

Here I'd thought I'd offered Kim Cameron a bit of an olive branch in the virtual/meta/uber directory discussion. But did he take it? Yes, he did, then attempted to whack a bunch of folks about the head and shoulders with it!

In a further attempt to clarify what he meant, Kim says:

"By 'next generation application' I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP."

Why Kim feels that LDAP is beyond the ken of today's application developers is beyond me, but the darker part of this is that he seems to say that only through the use of the Microsoft-controlled WS-* protocols (you can read their propaganda at their web site) can this be achieved. Nonsense.

Still, if any developers feel that only XML based scripting is acceptable to use, then I'd suggest they consider the very good LDAP replacement, DSML which has, sadly, languished for a number of years. Or there's SPML (for provisioning services). Even XACML could be used (although it would need a bit more work). The point is that there are open protocols, openly arrived at, that will do the job and today's application designers are bright enough to know how to use them.

I'm reminded by Phil Hunt's post on this issue that his work on the Identity Governance Framework, now an OpenLiberty project, also satisfies the requirement of open protocols, openly arrived at.

Another one bites the dust

2008-04-07T13:42:00.000-07:00

Well, that might be too strong, but another veteran independent Identity vendor has been acquired. M-Tech announced today that Hitachi had acquired a majority interest in the Calgary, Alberta firm.

M-Tech owns a large segment of the provisioning business in Canada, especially government (federal and provincial) provisioning. But beyond provisioning, M-Tech (now officially called Hitachi-ID) offered the full panoply of the Identity suite - password management, authentication and authorization, role management, audit and entitlement, etc. It'll be interesting to see how long it takes Hitachi to digest the acquisition (I don't think it will be very long) as well as how this will change the playing field (especially in Asia) for Sun, IBM and the others in this space. It could get very interesting.

The blind philosophes of Identity

2008-04-07T08:55:00.000-07:00

Kim has now responded ("Through the looking glass") to my Humpty Dumpty post, and we're beginning to sound like a couple of old philosophes arguing about whether or not to include "le weekend" and "hamburguer" and other Franglais in the French dictionary.

We really aren't that far apart.

In his post, Kim recalls launching the name "metadirectory" back in '95 with Craig Burton and I certainly don't dispute that. In fact, up until 1999, I even agreed somewhat with his definition:

"In my world, a metadirectory is one that holds metadata - not actual objects, but descriptions of objects and their locations in other physical directories."

But as I continued in that Network World column:

"Unfortunately, vendors such as Zoomit took the term 'metadirectory' and redefined it so it could be used to describe what I'd call an �berdirectory - a directory that gathers and holds all the data from all your other directories."

Since no one took up my use of "uberdirectory," we started using "metadirectory" to describe the situations which required a new identity store and "virtual directory" for those that didn't.

So perhaps we're just another couple of blind men trying to describe an elephant.

Get on the bus!

2008-04-02T16:00:00.000-07:00

Everybody else is. Dale Olds has commented. So has Phil Hunt. Let's all get together at the European ID Conference in Munich later this month and talk about the Identity Hub, the Identity Bus, the death of the metadirectory and so much more. Suggestions for a suitable meeting place (i.e., biergarten) near the Deutsches Museum are welcome - post as comments to this post.

See you there!

Cardspace context UPDATE

2008-03-28T15:57:00.000-07:00

Good post today ("No User Context Decisions in your Enterprise?") from Pam Dingle summarizing her panel at Brainshare (which I'm now sorry I missed). Cardspace and other user-centric ID schemes have a definite place in the enterprise, if only for the context-switching that Pamela outlines.

UPDATE: A video of the session ( with Pam Dingle, Patrick Harding, Kim Cameron and Dale Olds) has now been posted at the Bandit Project site.

We'll be exploring this same topic at the European Identity Conference when I host a panel of Dale olds (Bandit Project), Johannes Ernst (OpenID) and Robin Wilton (Liberty Alliance) called "Putting Context in Identity: User-Centric Context." It's an area that will heat up in the near future...

Every day I get in the queue...

2008-03-27T10:22:00.000-07:00

Eve Maler is a pretty good guitar player & singer who also happens to work for Sun and is a Liberty Alliance evangelista. She posts today about the Identity bus/hub and states, succinctly, "I don�t get it."

"I get that people would like identity information to be understandable across widely disparate systems, and that people would like services related to (deep breath) identity, authentication, attribute lookup, authorization, and auditing tasks to be widely available so that developers can concentrate on writing secure applications rather than security applications.

It�s fair to call this an �identity layer�. But that layer is more about semantics than about simple conveyance methods or syntax, because identity is way up in the stack. These aren�t random TCP/IP packets or HTTP messages, but information about us that we want our applications to understand and treat with care and consistency."

Exactly, Eve. And that's what the proposed "Identity Hub" would do - transform protocols and data from one system and schema to another. It's not a lightweight project, there's a great deal of heavy lifting that needs to be done. But we did it for email and we did it for databases - and identity isn't that much more difficult, if at all. In fact, it's more of a synthesis of those two.

But Eve doesn't just say that and leave it alone. Oh no. She then has to get all Microsoft on us. Not, I hasten to add, that she advocates the "identity metasystem" (one of her b�te noires) but she goes on to claim that if we would only all adopt SAML and the Liberty Alliance specs all of our problems would be solved.

Well, rock musicians have always been idealists, but getting to everyone using SAML? World peace is probably easier to achieve.

Meta-directories? Your father's ID store...

2008-03-26T10:18:00.000-07:00

Kuppinger Cole's Felix Gaehtgens posts today ("Meta-directories? I�d say quaint, but not quite dead.") on the demise of the metadirectory and the rise of virtualization. Felix should know, he's formerly the VP at Symlabs, a major Virtual Directory provider. He says:

"Microsoft has made an investment into that technology by rewriting MIIS pretty much from scratch. And Siemens to this date probably has the most comprehensive and advanced meta-directory implementation with its DirXmetahub component that is part of its Dir-X offering. Nevertheless, meta-directories are arguably still around mostly because Microsoft forces this technology onto its customers for what I think are political reasons: Several people working for Microsoft in the field have told me that is was in Microsoft�s interest to have Active Directory as a central component, and believe it against Microsoft�s interest to have a �filtered access�, such as a virtual directory in front of AD, abstracting information away from what should be the authoritative source. I never really understood this fear, but recently it seems that this brick wall may be slowly starting to crumble."

Read the rest of his post for a synthesis of the argument Kim and I have been having, a synthesis that could be close to a solution.

with Kim Cameron as Humpty Dumpty...

2008-03-25T11:09:00.000-07:00

One of my favorite passages from Lewis Carroll is the dialog in "Through the Looking Glass" between Alice and Humpty Dumpty:

"There's glory for you!"
"I don't know what you mean by 'glory,' " Alice said.
Humpty Dumpty smiled contemptuously. "Of course you don't�till I tell you. I meant 'there's a nice knock-down argument for you!' "
"But 'glory' doesn't mean 'a nice knock-down argument,' " Alice objected.
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean�neither more nor less."
"The question is, " said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty. "which is to be master�that's all."

Kim responded to yesterday's post in the "metadirectory" discussion with a Humpty Dumpty answer. He starts off with a Cameronesque peace offering ("It seems like some of our disagreement is a matter of terminology.") He then goes on to re-define "metadirectory" so that it becomes the answer to his question:

"Let�s make it clear that I see metadirectory as an evolving thing.

* First generation metadirectory dealt exclusively with a managing applications that had been conceived without reference to each other - or to any common framework (In truth, this is still an issue - see Jeff Bohren�s recent posting called �Which is better, Phillips or Flat-head?�).
* Second generation metadirectory has an additional focus: providing the framework by which next-generation applications can become part of the distributed data infrastructure. This includes publishing and subscription. But that isn�t enough. Other applications need ways to find it, name it, and so on. "

First to Jeff's posting. It's lovely. But it doesn't address the question. The application developer only cares about knowing how to access the data that the application needs. What form or format it's stored in doesn't make any difference. If the application developer only has SQL as the means of accessing data, then this puts the developer in the role of someone with a Phillips-head screwdriver trying to remove flathead screws, not the identity architect who provides multitudes of access protocols and methods for the identity data.

Kim talks about a "second generation" metadirectory. Metadirectory 2.0 if you will. First time I've heard about it. First time anyone has heard about it, for that matter. There is no such animal. Every metadirectory on the market meets the definition which Kim provides as "first generation". It's time to move on away from the huge silo that sucks up data, disk space, RAM and bandwidth and move on to a more lithe, agile, ubiquitous and pervasive identity layer. Organized as an identity hub which sees all of the authoritative sources and delivers, via the developer's chosen protocol, the data the application needs when and where it's needed.

I think, I hope, that Kim will agree with me that this ID layer (the "ID bus") instituted as a hub (or transformation device) is what we need to go forward. I'm not wedded to calling it the Virtual Directory, but I'm certainly not going to call it the metadirectory, either.

Michel Prompt (who Kim quotes extensively) calls it the "context server." I can certainly live with that.

It's unsanitary, Kim!

2008-03-24T08:14:00.000-07:00

In a blog entry today, Kim Cameron both puts words in my mouth and twists the ones that come out to serve his "straw man" purpose.

In commenting on my recent post about the death of the metadirectory, he says: "Who would want to get in the way of Dave�s metaphors? He�s on a streak. But he�s making a fundamental mistake, taking an extreme position that is uncharacteristically naive."

What did I do? I advocated the virtual directory as the better vehicle for all of the ID data needed in the SaaS world.

Kim implies that, somehow, I called for the virtual directory to be authoritative. That's simply not so. the virtual directory is merely the conduit to the authoritative source, wherever it might be. The application developer doesn't even need to know the authoritative source of the data - or need to re-write code if that source changes.

But then he goes on to say: "Application developers like to use databases and tables. They have become expert at doing joins across tables and objects to produce quite magical results. As people and things become truly first class objects in our applications, developers will want even more to include them in their databases."

I couldn't agree more. As a developer, I always prefer to have a local cache of the data I need in a (for me) easily manipulated data structure. But that does not mitigate against the use of a virtual directory. Far from it. The application database (for those who cling to it like Linus and his blanket) now can serve two purposes - one to subscribe to virtual directory data and one to publish!

The application database is the authoritative source of the application-generated data, and should be linked to the virtual directory which will consume this data and make it available for other applications and services. At the same time, any data which the application consumes - but which it is not authoritative for - can be populated at run-time from the virtual directory. For the developer who thinks this is a performance hit (and for whom accuracy is less important than an extra millisecond), a "synchronization stored procedure" would handle data changes without stealing precious time from the user-application interaction. It really is win-win.

Now the argument could be made that a synchronization engine (such as in a provisioning system) could periodically update all of the various datastores with any new or changed identity data, but that simply takes the well-known synchronization problems of the metadirectory and magnifies them by the dozens, hundreds or thousands of application datastores within the organization. That's a recipe for disaster. If an individual developer, for an individual application, wishes to sacrifice accuracy and risk the potential of error caused by out-dated data, or data whose location has changed in the hope of a spurious speed improvement (almost immediately unnoticeable due to the fluctuating nature of network thruput), they'll quickly learn, I believe, that "haste makes waste."

The further error Kim makes, though, is to believe that a virtual directory can't look like a SQL database to the application (or an XML database for web services developers). The folks at Radiant Logic would certainly disagree. It's all about the context. I'd invite Kim, and other skeptics, to our sessions on Identity and Context (including one about context and user-centric identity, as well as context and virtual directories) at next month's European Identity Conference in Munich.

Killing the Metadirectory

2008-03-21T08:00:00.000-07:00

Kim Cameron comments today about my column ("Is the metadirectory dead?") which was inspired by Kim's erstwhile colleague Jackson Shaw's blog entry ("You won't have me to kick around anymore!") which included the lines: "Let's be honest. The meta-directory is dead. Approaches that look like a meta-directory are dead."

My interpretation is that the metadirectory has finally given way to the virtual directory as the synchronization engine for identity data. Kim interprets it differently. He talks about the "Identity Bus" and says that "...you still need identity providers. Isn�t that what directories do? You still need to transform and arbitrate claims, and distribute metadata. Isn�t metadirectory the most advanced technology for that? " And I have to answer, "no." The metadirectory is last century's technology and it's day is past.

The Virtual Directory, the "Directory as a Service" is the model for today and tomorrow. Data that is fresh, always available and available anywhere is what we need. The behemoth metadirectory with it's huge datastore and intricate synchronization schedule (yet is never quite up to date) are just not the right model for the nimble, agile world of today's service driven computing. But the "bus" Kim mentions could be a good analogy here - the metadirectory is a lumbering, diesel-spewing bus. The virtual directory? It's a zippy little Prius...

Off Course-On Target

2008-02-15T08:11:00.000-08:00

Wayne Hodgins blog is called "Off Course-On Target" and subtitled "Where unexpected paths lead to great discoveries." Today he took a look at digital identity and fretted over the lack of uniform standards. But it's the analogy and stories Wayne tells - especially about how the shape of screw threads could have lost World War II for the allies - that make it such fascinating reading.

And the moral - perhaps best stated as "the perfect is the enemy of the good" - is something the entire IdM community should take to heart. Consensus and compromise should be our watchwords.

Unexpected moves

2008-01-25T09:10:00.000-08:00

Right out of left field comes the announcement that Mike Neuenschwander, formerly Burton Group Vice President and Research Director, has joined Mycroft, Inc. as General Manager. I covered Mycroft ("A marriage, a hot couple, and a single looking for a date at Catalyst") at last summer's Catalyst conference where they announced the merger with Talisen Technologies. Their business is implementing IdM solutions from other vendors - they're in the service delivery and solution implementation business.

The press release said little about what Mike's role will be, so we'll just have to see how it evolves, but I am saddened that I won't have Mike to "kick around" anymore after his Catalyst speeches!

Whose data is it?

2008-01-11T08:33:00.000-08:00

The Burton Group's Bob Blakley has a great post ("Antisocial Networking") today about the Facebook-Scoble story. The essence (or, at least one essence) of Bob's note is that relationships are a different order of data from attributes. As he says:

"Even the fact of your relationship with Scoble is not Scoble�s property, it is common property, like the kids in a joint custody arrangement. Both you and Scoble are obligated by the laws of relation here and here to treat the fact that you have a relationship, and also the details of the relationship, according to certain understandings and social conventions. If you don�t believe this, meditate on whether you think it would be OK for adultfriendfinder.com, match.com, and linkedin to share friend lists. The information Scoble tried to take out of Facebook is NOT Scoble�s property; it is relationship information. Scoble is not free to do whatever he pleases with relationship information; if he violates social understandings and conventions by disclosing the existence of or certain information about his relationship with you in the wrong context, he may embarrass or endanger you, and he will certainly endanger the relationship."

And that's what it's all about.

Of course, not all relationships are reciprocal. I have a relationship with Edith Piaf - I'm a great admirer of her singing. The relationship isn't reciprocated, of course, and not only because she's been dead for many years. But I also have a relationship with the very lively Tom Hanks, of whom I'm a fan. I don't think Tom is one of my regular readers, though, so I doubt the "fan" relationship is reciprocated.

Human relationships may need to be classified similarly to mathematical transitivity. There are:

reciprocal relationships (e.g., a is friends with b and b is friends with a);
non-reciprocal relationships (e.g., a is a fan of b but b is not a fan of a);
relatively reciprocal relationships (e.g., a is father to b, b is daughter to a); and
asymmetric relationships (e.g., a loves b, b can't stand a).

Some of these relationships will need joint permission for publication, some won't. Some will allow unidirectional publication, some will require it. It's not going to be easy, it's not going to happen soon, but a relationship calculus is going to be necessary for this to work at all.

Big fish, little pond?

2008-01-07T07:54:00.000-08:00

A Press Release I just read promotes L-1 Identity Solutions decision to acquire Bioscrypt, which is referred to as "Bioscrypt Inc., the leading provider of enterprise access control solutions headquartered in Ontario Canada,..."

I wonder how many other providers of enterprise access control solutions are headquartered in Ontario? :)

Promulgating the social graph

2008-01-03T17:42:00.000-08:00

Julian Sanchez, over at Techdirt gets it while many in the identity community - and even more who are involved in social networking - don't.

"Intuitively, it makes sense for users to be able to make whatever use they please of information about their own social networks. But in a social network, "your" information is someone else's as well."

Exactly!

The point about relationship data is that there is a relationship. And a relationship, like a contract, has two sides (well, it could have more - but that's kinky). Both sides need to be involved in the decision to distribute the relationship data. Both sides need to agree. Unless, of course, the whole "friendship" is one way. But imaginary relationships are best had with imaginary friends...

Happy Holidays!

2007-12-21T07:57:00.000-08:00

The end of 'user-centric' identity?

2007-12-15T13:10:00.000-08:00

In light of the last "tools" posting it's interesting to note that either Digital ID World's Eric Norlin recently posted their predictions for 2008 at CSO online and included this one:

"User-centric� identity protocols will stop calling themselves �user-centric�: This is an adoption story. �User-centric� protocols will gain some actual adoption in 2008 (yes, I'm implying that they haven't yet gotten any �real� adoption). In so doing, the �folks in the know� in that movement will *stop* prefacing everything they say with the words �user-centric,� as they realize that their protocols may have been designed with that laudable goal in mind, but the terminology is just getting in the way. Instead of describing an ideal, they'll begin describing what they *do.*"

It is about time we stopped debating philosophy and started talking implementation, isn't it?

Tools are just tools, you know

2007-12-13T14:23:00.000-08:00

I've always been impressed by Pamela Dingle's ability to cut through the rhetoric and get to the heart of a problem. She's done it again.

Patrick Harding, Nishant Kaushik, Johannes Ernst and Matt Flynn recently participated in an impassioned (if not actually heated) discussion of User-Centric identity in the enterprise. Pamela chimed in with her usual level-headed approach.

Then, after the guys debated philosophy, Pamela - once again - reminded them that using the tools of so-called "user centric" identity (CardSpace and OpenID, for example) doesn't require buying into any sort of philosophy of data control. They're simply tools. As she put it: "If you try to tell me that using a tool such as the Identity Metasystem to accomplish something other than a user-centric philosophy is wrong, I will also laugh at you."

As I said last spring, "I�m addressing the enterprise market, which needs to pay attention to CardSpace right now." CardSpace and the identity metasystem - whether all Microsoft or using open source tools - can be a very useful tool in the enterprise, especially in an enterprise which uses a lot of home-grown applications and services. Not only for authentication (and the simplified signon possibilities), but also for authorization, role management and fine-grained entitlement control.

Tools are just tools. Use the tool that does what you want at the price you're willing to pay and let others worry about the philosophical implications.

IIW ages gracefully

2007-12-06T08:23:00.000-08:00

We've just finished the fifth Internet Identity Workshop, and it appears that a milestone has been reached - or, perhaps, that a corner has been turned. Phil Windley posted a good, succinct, history of the previous meetings in his review, and I do agree with his conclusion that reputation services appears to be the "next big thing" for IIW. But what I saw this week was a decided maturing of the event - the Concordia people, for example, were there - but spent almost all their time closeted with each other. Likewise, those involved in OSIS spent most of their time planning their next interoperability event.

The 2.0 spec for OpenID was finalized (and released) and discussion begun on the next version. The conversation has moved from "do we need OpenID" to "how can we leverage OpenID?"

Dale Olds (from the Bandit Project) even lead a session entitled "Open source identity systems in the enterprise," a topic that would have been anathema for this group just a couple of years ago.
Not that there was a lack of wild-eyed idealism, mind you, just that it was tempered a bit by progmatic considerations and the possibility that personal, user-centric identity can peacefully co-exist with enterprise-centric identity. Not only are the ID Geeks getting older, they also appear to be getting wiser.