What the web has always lacked is a reliable and secure way to identify you.
Sure, there are ways for you to log onto services, and there are servers in the business of letting you borrow their login mechanisms. But that’s just for letting you in the front door.
What about when a commercial site wants to know something about you?
Two executives from open source CMS vendors Jahia and Enonic have been collaborating with each other for about two years on a concept they call Context Server (CXS). At the moment, it’s a partial framework for a protocol that would not only enable a Web site to retrieve anonymized information about a user, but would also enable the user to control how that information is used.
“All different kinds of technologies can participate in this standard, including marketing automation, even analytics,” said Jahia CTO Serge Huber in a conversation with CMSWire. “We really want to get this broad array of vendors involved, because it’ll be key to the success of the standard as we see it.”
Huber is co-author of the ongoing CXS framework proposal document, currently on version 0.7, along with Enonic CTO Thomas Sigdestad.
“We’ve been talking about putting the user in control,” said Sigdestad. “We’re more interested in that part than the use of the data on the back end. It means, I could set a flag somewhere that says, ‘I don’t want you to log anything about me.’”
There are numerous technical gaps that Huber and Sigdestad need to fill, especially as they build a list of supporters. Once that's accomplished, their goal is for CXS to serve as a standard protocol for servers to communicate data about customers, in a policy-managed, privacy-controlled manner.
Or, from the user’s perspective, a way for a CMS or a user experience platform to ascertain the vital details and purchase history for any customer, from any other source that customer may have visited, the moment she logs on, explained Huber and Sigdestad.
Huber and Sigdestad are in the midst of formally proposing CXS to the OASIS industry organization to begin the long process of formal adoption as an industry standard. The formal initiation of that effort began Monday.
The Big Context
When data is exchanged over the web, there is a syntax for specifying that data, and a protocol that determines the order and method for which the exchange takes place.
CXS would be a protocol: a way for designated servers and web clients, like your browser, to agree upon how data is organized. A protocol would be a simple matter if every web server agreed to exchange the same form (name, mailing address, e-mail address, telephone number, etc.) — and, at several times in the web’s history, such a form was discussed.
But CXS attempts to take into account two possibilities: First, there may be certain information about a user/visitor/customer that’s only relevant to a specific class of vendor (weight, years of marriage, college degree, years of education, sexual orientation, military service record, credit score, etc.) that, while applicable, should not become available to just anyone.
Yes, Facebook, I’m talking to you (again).
Second, unless every consumer on the web is expected to become a hermit by default, CXS’ advocates believe, she should be given a method for extending permission to other industry classes or to selected companies exclusively. What’s more, she should always have access to a detailed list of what’s being shared and when.
“We need a common standard to store and deliver consistent user context across different systems,” reads version 0.7 of the CXS proposal document. “This will enable all systems to participate in creating the big context, and share it among each other.”
The Proverbial Devil
Constructing a “big context,” as perceived by Huber and Sigdestad would be an extremely complex undertaking and by no means immediate.
Since exchanges of data are, by nature, transactions, the methods of any context server would apparently be transactional. Users would be given tools with which to construct rules — like the rule set on a security firewall — granting and denying permissions, and perhaps also extending invitations to selected parties to begin exchanging data.
“There are two main concepts you have to understand: the profile and events,” explained Sigdestad in a conversation with CMSWire. “Events can be collected in real time or asynchronously from any source, or they can be injected from any source. As the events go by, they will enable us to create and build profiles.”
It sounds poetic: Profiles would be the collective contributions of all the pieces of data, like leaves, collected about a customer. It is actually not the least bit poetic. For a look at how large-scale contributive transactional databases tend to work, check out the history of Healthcare.gov.
One approach the identity management already takes to the problem of data aggregation is called federation: a protocol between servers in the background that enables them to trust each other to manage all possible interpretations of identity data on each other’s behalf. Today, federation enables an e-commerce server, for example, to trust another server when it says it has already authenticated a user.
Such an approach lets retail Web sites congregate together into a kind of online mall, with a single-sign on (SSO). Has the CXS team considered a similar approach?
“We talked about having different context servers redistributing information between themselves,” Jahia’s Huber told CMSWire. “But the way it’s designed, Context Server can just act as a front end that can aggregate information from systems without even storing it. That’s possible in the existing model we have right now.”
Cross-validation of customer “sources” has not been discussed, Huber added, and has yet to demonstrate a strong need, in his opinion. The system he envisions enables a site to contact a CXS front end, which then assembles the requested data from wherever it may be stored. Such a system already exists as a proof-of-concept; what needs to be deliberated are the details.
The Black Box
Inevitably, such a deliberation would become an open discussion about two contrary subjects: openness and privacy.
Public skepticism about the misuse of identity already has become an industry unto itself. And major firms in the existing industry of gathering customer information— including Salesforce, Google, Oracle, and Facebook — are reselling access to that information as part of their business model.
That access may be anonymized, although it is with limited customer intervention, or even none whatsoever. So the hardest sell for a CXS standard would be to an industry that perceives itself as doing quite well without it.
But the proposal is gaining traction. More recently, other market players have joined, including Liferay and Hippo.
“I think it is absolutely crucial that we build out that standards community, and get other types of vendors into the mix,” said Hippo's Arjé Cahn. His participation and his company’s, he told us, would only have been feasible with the understanding that the CXS group would grow to include different classes of industries, especially including Hippo’s own customers.
One example Cahn offered was a human resources organization that helps skilled individuals to find jobs in the higher education sector. Such a firm already uses Hippo to collect visitor data, and share that data with prospective employers. That’s not a traditional e-retailer, Cahn admits.
But if CXS is expected to gain enough traction to be taken seriously by e-retailers — groups that are already satisfied Salesforce and/or D&B customers — it may need the backing of numerous smaller industry segments.
And as Enonic’s Sigdestad admits, that fact alone creates its own technical challenge.
“We see silos as a huge problem. For every single system you’re building, you’re creating new segments and new rules, you’re collecting different data, and you have a really hard time redistributing them,” Sigdestad said.
His approach to this challenge would be for CXS to employ a tagging system, labeling the industry to which customer data would pertain with what are called “custom segments.” An enterprise data user could create a custom segment however it sees fit.
“You don’t have to use it if you don’t like to,” he added. “You can still trust your own profile in marketing automation. But you can then share it with the Context Server, so that everyone else can benefit from the data you collect.”
A tagging system would alert CXS servers as to which parts of a customer’s profile should be aggregated. In a similar vein to how the BitTorrent system never stores a complete file in any one location, a CXS profile may never exist in any one place in its entirety.
From a legal perspective, this could be a very good thing. It means no single party is responsible for profile storage, and like BitTorrent, every service provider could claim safe harbor.
From a management perspective, however, a consistently growing number of custom segments would give the customer more data classes to track. Exactly how the customer would approach this task, would be one of the items on the OASIS discussion agenda.
“Privacy is definitely something we’ve been talking about on a regular basis,” said Huber. “If we look at what Google is tracking on its users, it’s essentially a black box. They tell you they give you access to what they’ve resolved, but it’s actually aggregations of what they’ve tracked about you, and you have no idea what went into the system... Suddenly, if there’s a standard or an open source implementation, there’s really an opportunity to get some control over what’s going on.”
Prospective members of a broad industry coalition are being invited to meet together in late April, to discuss the prospective agenda for CXS. Should the process move forward, CXS would become, by design, a system incapable of being capitalized by any single provider. Yet, for it to have a chance of success, it may need a sign of support from one of those capitalists.
It’s a long tightrope ahead. And there are already footsteps where others have tread.