I made some great connections with people there and mostly observed
the discussion and thought, and thought, and thought. I want to thank David Recordon, DeWitt Clinton, Jesse Robbins, Joseph Smarr , Tim O'Reilly
and many more for all the great conversations that I had and for
welcoming me in as one of the very few "enterprise guys" during the
weekend.
So now what? I have lots of ideas.
The Social Graph and the Enterprise
Much of the conversation was directly directed at providers and users
of consumer-focused applications. Since social networking and variants
were heavily represented in all discussions, this was very appropriate.
While on the consumer side of the application and social networking
world the demand for the convenience of a secure methodology of data
sharing between applications makes a lot of sense, there is still a lot
of conflict even with the vendors and providers of solutions on what
amount of data to share, etc.
The data portability and OpenID communities are quick to label
enterprise solutions vendors as "evil" because they feel that this is
inconsiderate toward users and their desires to have data portability
and freedom to choose.
When I begin to apply these concerns to the enterprise, they are
further magnified by some very significant differences that can not be
underestimated in the enterprise world. As a provider of applications
to businesses who have users in them, I can not simply mandate "We
support OpenID when the entity of the user in a company is not mine." A
user in a company's account belongs to the company.
Let me explain.
The Business Identity & Transaction
When a representative of a business signs up for an application to be
used by a business, they make a representation that they have the
necessary authority to do that at some level. Additionally, when they
begin to add other users inside that application; the business has
administrative rights over the identity of the user inside that
application.
We understand that someone may sign up to try a solution who may not be
the administrative contact once the application is adopted. In this
circumstance, administrative rights are transferred to the necessary
party within the business; but this is all possible. The net result is
that businesses are identities and businesses own other identities
within them.
Let's go to the next level.
Adding Additional Users
With each additional user that gets added within an application owned
by a business, their information in the application and their identity
(assuming it's a business application like CRM) is traditionally an
asset of the company. This includes all data in the system and the very
identity of the email address itself.
Now that may be a shocker to many of you who are employees and just now
discovered your email address at work is not yours (and not private).
Your employer owns it and upon exiting the relationship, it's no longer
yours to have. Nor
is the data that you entered into the system as an employee yours -
it's your employer's. If you thought that the information you type,
import, read, etc. is all yours... sorry to bring the bad news here.
It's not that your employer is bad, it's just the legal details of
ownership of business assets.
Identities as Assets of the Company
The dimension of "ownership of the identity" is where my concern lies.
While I openly embrace the concept of OpenID and OAuth and even Data
Portability, enabling the transfer, federation, collaboration of the
data itself required to improve the users experience is not merely my
decision to make. My "identity" in "the company" is not mine alone and
all correspondence and collaboration with that "identity" is an "asset"
of "the company."
Here is Where it Gets Really Confusing
Currently, what goes on in authentication sharing is more than identity. Unsophisticated models currently allow access to applications and user data can be imported from one application to another. A common example of this is giving access of your web based email service with your username and password to another vendor.
1- Some users will feel victimized if all of a sudden their information that was automatically imported is now an asset of the company that they work for; inside an application that they are a user in.
2- On the flip side, if I enable data portability "outbound" in an application through automation for the users benefit; I must consider that the "business" that this user works for may feel their rights violated and that their assets were compromised.
3- Dimension number three is the contact on the list itself. As an example, I find that I am appearing in more places because of the phenomenon known as the social graph, and social networking. My name is on some friends lists that keep getting imported, exported, and moved around. What was once a private relationship is now being made a business asset and a replacement contact is assigned to me with whom I have no relationship with. How do I feel about that?
Now What?
So now that you've read all this background of applying these principles to the enterprise. Now what? Implementation is critical to a decision to adopt and protecting users and companies, both. Just opening up without the respect of the appropriate identities is reckless. So I have some more things to consider.
Identity Protection Concerns
The biggest concerns I have when I think about consumer solutions are identity protection and data architecture. Enabling collaboration between applications for most vendors comes with a cost that users don't think about. For example; if you want to synchronize your data between apps and you provide your authentication information, you have just given your un/pw info to that vendor in trust. What will they now do with that trust? Where do they keep that data? How secure is it? What permissions did you just surrender? I am amazed at how many users surrender their identities without second thought about what keys they provided to someone to ruin their lives.
Is There a Better Way?
The biggest promise provided in the movement of adopting OpenID and OAuth is that there are better ways to share data in limited fashions that provide the experience the users want, without sacrificing security of the more sensitive information. But simply solving authentication and giving access to all data and to all services doesn't exactly get us there.
I believe that there is tremendous opportunity to improve things if the industry puts new principles in place, and I also think there are more questions to ask before it can effectively be adopted in the enterprise. Do users know that when they import data from a social networking application, their contacts become assets of the company? Do they know their email address is not theirs? And the contents of that email is also an asset of the company? Using an ID that is an asset of the company to work with other consumer oriented sites may also create other risks.
Now granted a lot of these issues effect consumer oriented sites today, because users sign up with their company identity. Regardless of where we are at now, the need is very real to improve how we collaborate and keep information and identities secure.
So What Will Etelos Do?
I can't exactly say what we will do, until we start doing it.
But I believe that the Etelos MarketplaceTM is a great place to start supporting OpenID and/or OAuth. Why? Primarily because users can try and buy multiple applications that integrate with other services; essentially having a central ID that launches many other applications.
Enabling this experience to be as easy as possible is a basic principle we can get behind. After the initial user in an application is deployed, it gets a little foggier about how we can best support both the end-users, the businesses/accounts they work for, and the initial business contact that signed up. Additionally, developers that are distributing applications through Etelos need to decide how to support these initiatives as well. We currently do offer an API to federate data from the Etelos Marketplace to the Apps/Services that we sell and install. We are not far from embracing more, and perhaps better, ways to do this.
We have more to say on this; more investigation on this. Odds are that we will communicate with our users here on our blogs about ideas as we pursue them. So check back on our blogs soon for more on how we choose to embrace these new emerging open standards.
http://www.dataportability.org