imho Ocean Semantic…..

All:

Semantic interoperability is a non-issue when everybody adopts the same vocabulary, frame of reference, and expectations from the get-go, and when there’s no question who governs the domain in which these shared understandings apply. Interoperability only becomes an issue when autonomous semantic domains must interact for their mutual benefit. In those cases, all parties must agree on a mapping or translation between their respective vocabularies. In such circumstances, how do semantic domains square, coordinate, mediate, and reconcile their domain-specific ontologies with ontologies in other domains, or with foundation ontologies that apply more horizontally?

Governance among autonomous domains--that’s the essence of federation, as I’ve discussed previously in this blog on several occasions over the past 30 months. To dust off and slightly extend my prior definition of federation (last rehashed in the “Arch of Governance” thread a year ago): Federation is a governance structure in which autonomous domains choose to honor each other’s decisions and accept each other’s assertions in some realm of human endeavor—such as identity management, semantics/data management, or SOA management--subject to business contracts, trust relationships, interoperability agreements, and local policies.

One thought that occurred to me is that semantic federation can be modeled along the same general lines as identity federation. Within any federated interaction (semantic, identity, etc.), at least one party “asserts” some statement about some entity, and at least one party “relies” upon that assertion when making one or more decisions. Where semantic federation is concerned, we’re not talking SAML “assertion” messages or anything of the sort.

Rather, we’re construing an ontology (expressed in OWL, RDF, or any other knowledge representation language) as asserting that a particular controlled vocabulary applies in some domain (e.g,. your organization, your application, your system, etc.). And we’re interpreting ontology-compliant data structures (expressed in XSD or other schema standards) as assertions/statements about specific entities/classes/relationships/etc within a domain. And we “rely” on these semantic assertions (ontologies and data) when we choose to discover, access, retrieve, and import them from the asserting/source domain, and then reformat, match, map, translate, merge, aggregate, store, and otherwise use them in our target domain.

Of course, that semantic-bridging process is how cross-system interoperability has been conducted since the dawn of distributed computing. Integrators have always ascertained the meaning of source data in its original application, process, or system context, while also considering the meaning, schema, and format of equivalent data elements in target systems, and then defining the mappings necessary to ensure that the meaning/context of the data is preserved when being translated between the source and target systems.

In a federated semantic environment, interoperability needn’t require reciprocal handshakes (i.e., business contracts, trust relationships, interoperability agreements, etc.) among interacting parties. In fact, interoperability can be and often is a one-way flow of metadata from source to target systems. All that’s necessary is that at least one party—usually, the source/asserting party--make its full meaning and expectations completely transparent and unambiguous to the others, and that the others (the relying parties) agree to accept that meaning and live up to those expectations. At least one party must control the vocabulary, and all parties—asserting and relying--must consistently adhere to that vocabulary.

If governance over that federated lingua franca is shared, that’s all well and good, but not absolutely essential, for understandings to be mutual. In fact, it’s best that most of the foundation and domain-specific ontologies are controlled/decreed by various “higher authorities” (e.g., standards bodies, industry associations, etc.), so that most common vocabularies are as transparent and unambiguous as possible. And to the limited extent that the interacting parties choose to “handshake” the definitions of the remaining vocabulary elements through common ontology repositories, or through an agreed-upon data stewardship/governance administrative workflow, the common understanding is nailed down solid.

Semantic stewardship. That’s the process under which organizations—internally and externally—work out the policies regarding which ontologies (i.e., vocabularies, glossaries, metadata, definitions, etc.) will be asserted, in which formats/schemas, and which will be relied upon, per which ontology-controlling authorities, under which governance roles and workflows, and with which mappings and translations, under which requirements, use cases, and circumstances.

Federated semantic stewardship. The decision to accept, map, and adapt some other domain’s vocabulary to your circumstances. Because it fits.

More to come.

Jim

imho Ocean Semantic....

All:

Semantic interoperability requires shared understanding by all parties of the full context, content, and consequences of their actions within a given application domain.

The focus of the W3C's Semantic Web initiative has been on shared understanding as crystallized and governed by domain-specific "ontologies." An ontology is a grammar and vocabulary for representing entities and relationships, constraints and containments, applications and manifestations within a domain. RDF, with its subject-predicate-object "triples," is one such grammar, and OWL expands RDF's expressive power for making meaningful, machine-readable, URI/XML-based statements about any entity and any relationship in any domain that chooses to represent itself online.

But ontologies can't be shared unless two or more parties choose to agree on them, or if they are mandated by whoever controls the domains within which two or more parties agree to interact. And they can't serve as a stable, broadly understood and accepted common denominator unless they are under governance by some recognized authority within the domain they purport to support. Which leads to some key questions, where semantic inteoperability is concerned. What is a semantic domains? What authorities control the domains? From what sources do these domain authorities, controllers, governors, or stewards derive their authority? What procedures do they use to define, disseminate, administer, and revise ontologies for their domains? How do they square, coordinate, reconcile, and federate their domain-specific ontologies with ontologies in other related domains, or with foundation ontologies that apply more horizontally?

Semantic domains are springing up all over, often as B2B data-standardization initiatives within particular industries. Look at the RDF and OWL specs for a glimpse at domain authorities in the birthing. Under RDF spec, section 6, "Some RDF Applications: RDF in the Field," note the intiatives and their scope/applicability/institutional backing: "Dublin Core Metadata Initiative" (ECM vendors, digital library operators, electronic publishers), "Publishing Requirements for Industry Standard Metadata (magazine publishers), "RDF Site Summary" (online content syndicators and aggregators), "Common Information Model" (electric power research institute), "Gene Ontology Consortium" (biomedical researchers), and "Describing Device Capabilities and User Preferences" (mobile device, infrastructure, carrier). And that document's a couple of years old...there are many fresher examples of horizontal, vertical, regional, B2B, intra-corporate, and other ontology-making bodies and initiatives.

Of course, an ontology is only one component in a "domain model," which should also define the governance, roles, workflows, data matching/cleansing, exception-handling, and master-data-management rules, and other policies and best practices that prevail in that (real or virtual) (B2B or intra-corporate) slice of the universe. Taken all together, the domain model is the practical/institutional context within which all participants adopt a common, controlled vocabulary (i.e., ontology) to catalyze shared understandings.

Notice the word "federation," earlier in this post, in the same sentence as the word "ontologies." Shared understandings are hard to catalyze when the world is fragmented into fiefdoms. But that's the world we will always live in....the SemanticWeb governance structure is and will remain indelibly federated.

More to come.

Jim

imho Ocean Semantic...

All:

Scoping for my upcoming BCR article on Semantic Web, per the proposal I just floated last night to Eric and Sandy:

· Semantic Web is an industry initiative to expand end-to-end, standards-based semantic interoperability throughout SOA environments.

· The concept of a Semantic Web takes the notion of the World Wide Web (WWW) a step further:

o Essentially, the WWW treats the Internet as an open book that—through common interoperability standards such as DNS, IP, HTTP, HTML, and XML—makes content everywhere readable, searchable, and comprehensible to human consumers.

o The Semantic Web extends that concept to non-human consumers, so that the meaning, context, structure, operations, reference, use, goal state, implied processing, relationships, scope, and purpose of any entity, especially content, can—through XML-based interoperability standards such as RDF and OWL--be everywhere unambiguously readable, searchable, comprehensible, and actionable to services, applications, bots, and machines, and also, via that machine-mediated abstract virtualization layer, to human beings.

· In theory, the concept of the Semantic Web can be interpreted either very broadly or very narrowly:

o God’s eye view: as a supermagical identification, metadata, description, representation, and policy layer that enables universal, automatic, comprehensive end-to-end interoperability across every macro or micro entity on every imaginable level.

o Worm’s eye view: as standardized XML-based schemas that define how content can be tagged with self-describing metadata in accordance with controlled, domain-specific, agreed-upon semantic vocabularies known as “ontologies.”

· In practice, Semantic Web techniques can potentially be applied in the following areas:

o Enterprise content management (ECM): enable more powerful/flexible content discovery, indexing, search, classification, cataloging, aggregation, correlation, navigation, mapping, transformation, and management across federated domains

o Enterprise service bus (ESB): enable speedier, automatic, policy-driven, multilayered application, process, and service interoperability across federated domains

o Enterprise information integration (EII): support virtualized, composite, unified viewing, query, and update of disparate data that has been retrieved from heterogeneous sources across federated domains

· So far, there is considerable academic discussion of Semantic Web concepts, and standards definition at the W3C, but surprisingly little commercial implementation of such Semantic Web specifications as RDF and OWL in the ECM, ESB, and EII markets.

However, there is a growing emphasis on and implementation of heterogeneous semantic interoperability—considered broadly—in all of these markets. To some extent, the so-called Semantic Web standards and initiative are only one piece of a much larger puzzle that is coming together in a environment that should more properly be called “Semantic SOA.”

So you can sort of see where I'm going with "federation" re "ontologies." But I still need to flesh that out.

More to come.

Jim

imho Ocean Semantic..

All:

I don't know if I ever mentioned this. Day in and day out, I cover the data management industry for Current Analysis.

One of the key segments of my coverage area is data integration (DI). And within that is a broad space called "enterprise information integration" (EII), which is often contrasted with "extract transform load" (ETL). So as not to bore you with unnecessary distinctions, EII primarily deals with logical dynamic integration of heterogeneous data across dispersed repositories, whereas ETL deals with physical integration of that data into a common, persistent data store called a data warehouse. That's slightly oversimplifying the matter, but please indulge for a moment. There is a payoff.

Principal vendors of EII solutions include IBM, BEA, Business Objects, Informatica, Sybase, Actuate, Composite Software, Ipedo, Inetsoft, and MetaMatrix (note: the latter vendor is in the process of being acquired by Red Hat and having its EII software open-sourced under JBoss.org.). In the EII space, most of the vendors offer solutions that incorporate what they often call a "semantic layer." Here now's a smattering of what is often included under the discussion of a "semantic layer":

• data management layer
• efficiently and reliably enables federated access to a wide range of heterogeneous data sources
• support enterprise implementation of virtualized, composite, unified views of disparate data that has been retrieved from heterogeneous sources, including ERP systems, line-of-business applications, transactional databases, and Web services
• federated data services and metadata management
• enables data to be accessed from disparate data sources and used in any form in any application.
• organizations can reduce the application development and integration costs associated with accessing and reconciling disparate data, while improving its overall utilization and consistency
• resolves data access challenges and the physical and semantic differences among disparate, physical data sources.
• provides a semantic-interoperability data services layer that decouples applications from their data sources and makes data assets available as services in an SOA, freeing data from single application silos.
• instead of managing multiple data sources for different applications and trying to keep them reconciled with one another, users can take any data from any data source and use it with any application.
• developers and architects create, deploy, and manage data services that access, transform, integrate, and aggregate data to provide the information needed by applications while hiding the complex details of diverse physical data sources
• alleviates the need to create yet another new copy of the data
• simultaneously provides mechanisms for data consistency, security and compliance
• through a model-driven approach, application teams can create, deploy, and manage data services that simplify data integration.
• enables users to access a single view of their data from multiple disparate systems
• performs the necessary semantic mediation and vocabulary management to get the data into the right form - all without software programming.

All of which seems to be core to most industry discussions of "semantic Web." How is this all not the "semantic Web"? Is it all not here and now, and eminently feasible, thanks to the EII market? Do any of these commercial solutions depend on any of the core specs (i.e., RDF, OWL) usually associated with the W3C's flavor of "semantic Web"? (answer: no). Does Red Hat's decision to acquire MetaMatrix, open-source its EII technology, and bundle it with the JBoss Enterprise Middleware Suite represent a critical step toward making SOA-enabled EII (i.e, semantic Web) ubiquitous? (answer: you betcha).

And where do "ontologies" and "federation" fit into this picture?

More to come.

Jim

imho Ocean Semantic.

All:

This notion of a "semantic Web" is one of the great perennial "boil the ocean" topics. Germinated and perpetuated by Sir Tim Berners-Lee, it's been kicking around the industry for a few years now. It keeps going and going, and morphing into new contexts.

For example, from last week (now it's "Web 3.0"):

Web 2.0 Arrives to Find Web 3.0 Under Way.
http://www.informationweek.com/story/showArticle.jhtml?articleID=199000940

Or just the other day (it's "Web 3.0," but also "semantic SOA"):

SAIC Pushes Past Web 2.0 to Web 3.0

http://soa.sys-con.com/read/368248.htm

So what, if anything, is the "semantic Web"?

Is it some supermagical metadata, description, and policy layer that will deliver the nirvana of universal interoperability by making every networked resource automatically and perpetually self-describing on every conceivable level?

Or just some banal XML tagging schema or folksonomy that everybody will be exhorted to apply to every scrap of online content so as to facilitate more powerful metadata discovery, indexing, and search?

Or what?

Last week, I debated the issue with a host of other SOA industry analysts in the weekly podcast at www.briefingsdirect.com, hosted by Dana Gardner of Inter-Arbor Solutions. The stream and transcript won't be posted there for a few weeks, but I'll bring you up to speed on my evolving thoughts on this matter. Thanks especially to David Linthicum for his insightful commentary (much of it from articles he published 3 years ago....a period when I jotted some thoughts on the topic as well....I responded to him only in the past week).

More to come.

Jim

imho Appliance hype building to fever pitch

All:

Enterprise software vendors have devised many ingenious new approaches for crafting solutions. Over the past few years, vendors have ventured well beyond their traditional focus on licensed software packages. Many have begun to offer solutions that incorporate such diverse approaches as open source software (OSS), service-oriented architecture (SOA), and software as a service (SaaS).

Some software vendors have even taken a bold step into the world of hardware. A growing number are offering “appliances,” which integrate software with CPU, storage, and other hardware to deliver function-specific, performance-optimized solutions for quick deployment. Essentially, an appliance allows a vendor to pre-equip a “shrink-wrapped” infrastructure component to fit a particular functional role and support a specific capacity, throughput, and performance profile.

Appliance wars are upon us, as can be seen in IT vendors’ eagerness to slap the label on a growing range of hardware-integrated solutions, most of which are much bigger than a breadbox, and also far more complex and costly (though, ostensibly, less so than the software-centric solutions they hope to supplant).

Appliance hype is building to a fever pitch. Every vendor claims that its appliances are true “plug-and-play” solutions, though few customers are so naïve as to imagine that a complex IT solution can be as easy to install and setup as, say, a toaster-oven. In addition, vendors and industry observers are starting to line up behind competing definitions of what constitutes a “true appliance.” Depending on whose religion you subscribe to, an appliance must be a simple “black box” device (such as a blade), or it can be a complex assemblage of processing, input/output, storage, and other components integrated across one or more racks in an enterprise data center.

Of course, there are plenty of opportunities for overzealous vendors to stretch the concept of an appliance to the breaking point. Unfortunately, one of the core features that most people associate with appliances—their physical tangibility--is starting to fall by the wayside. Increasingly, vendors are exploring the nouveau notion of the “virtual appliance.” This refers to the concept of a self-contained software package that can be deployed rapidly to diverse operating and hardware platforms through virtualization technologies such as VMWare and Xen. It’s not clear how these “virtual appliances” differ from existing development paradigms, such as Java, that also promise the ability to “write once run anywhere.”

But like it or not, appliances—in all their bewildering proliferation—are here to stay, and they are moving into the mainstream of enterprise computing and networking.

Many IT professionals have already taken a first foray into this new world, in the form of content-aware network appliances from the likes of Cisco, Juniper, F5, Citrix, and IBM. Usually deployed at the network perimeter, these appliances look into the contents of application messages and take various policy-driven actions, such as fine-grained access control and dynamic rerouting, in response to what they find in payload data.

Just as important, appliances have begun to take up permanent residence at the heart of the data center, in the form of data warehousing (DW) appliances. In the past few years, DW appliance pure-plays such as Netezza, DATAllegro, and Greenplum have seen their market share grow. Even longtime software-oriented DW vendors such as Teradata, Oracle, and IBM have begun to offer integrated solution packages for appliance-type deployments.

These trends have been developing for several years, but the appliance market reached a turning point in March when IBM announced that it had re-architected its entire DW product family as appliances. At that time, Big Blue launched the most comprehensive, scalable enterprise DW appliance solution family on the market. Its new “Balanced Warehouse” family of appliances addresses DW price-points and requirements ranging from high-end enterprise DWs down to smaller, function-limited DWs and low-end departmental data marts.

That very same week, business intelligence (BI) market leader Business Objects announced that it too was putting appliances at the core of its ongoing go-to-market strategy. To develop BI, DW, and data integration (DI) appliances for various customer segments, Business Objects is partnering with a wide range of complementary vendors, ranging from large established server/storage providers to pure-play appliance startups. It has even factored “virtual appliances” into its long-range roadmap, demonstrating the breadth of its vision.

Without a doubt, appliances will have an impact on every component of the enterprise application architecture. If nothing else, the need for incrementally scalable application infrastructure components will continue to grow, stoked by relentless increases in transaction and data volumes across the service bus.

Enterprise IT professionals should begin right away to factor appliances into their SOA strategies.

Jim

rfi User-Centric Identity and Frontispiece

All:

The article's done, edited, revised, and in the publisher's hands. Check out next month's issue of Business Communications Review. Thanks to everybody who responded to my request for interaction (rfi). I've given my blog readers the benefit of a preview, plus my developing perspectives on many related topics.

Jim

rfi User-Centric Identity and the Odd Geography of Mutuality

All:

I’m no role-play gamer, but today’s IdM metasystems are starting to remind me of Dungeons & Dragons.

The more hyper-heterogeneity we throw into the IdM mix, the more convoluted and confusing and treacherous it all feels from the user’s viewpoint. Looking at Ping’s convergence use cases (integrating OpenID with CardSpace with SAML) or the Higgins/Bandit convergence demonstrations from RSA 2007 (throwing Liberty into the stew), it all seems a tad more complex—hence, lower on the assurance scale--than it needs to be. As if we’re introducing more IdM terra incognita into every online transaction, hence more scary monsters that might swallow us whole or ocean-edges off which we might merrily sail.

IdM metasystem heterogeneity introduces odd geography into the mutuality equation, threatening to turn what should be direct interaction paths (i.e., logins) into indirect odysseys involving card-cluttered conversations, eerie URI-infused interactions, insistent assertion insertions, and restive roundabout REST-y redirect ricochets among too many moving part(icipant)s. In the process of researching this article, and considering all the many initiatives/standards/specs, I sketched out the multifarious dimensions, entities, and relationships that must be represented in any truly comprehensive identity metasystem taxonomy. No, I’m not going to exhaustively list them here (try Liberty Alliance’s wiki for a good dose of heterogeneity). But, in order to stave off personal bewilderment, I cobbled together a working IdM metasystem taxonomy that includes (in no particular order) myriad use cases, interaction patterns, standards, identifiers, attributes, cards, card selectors, credentials, protocols, authentication contexts, federation topologies, domains, identity agents, directories, IdPs, authentication authorities, attribute authorities, attribute brokers, certificate authorities, validation authorities, in-person proofing agents, discovery services, RP/SPs, TTPs, PKI trust paths, etc. (hmmm….I sort of broke my promise not to go exhaustive…pardon me).

So excessive heterogeneity is the enemy of both abstraction/simplicity and mutuality/assurance. To fondle another touchstone from nerd-culture, today’s complex IdM systems make us feel a bit like a hobbit traversing the dangers of middle earth to ascend to the seventh level of mordor (or whatever--I never read the books, and enjoyed the movies but totally lost the plot). Ambling among sovereign domains, you constantly wonder if you have the right papers, passport, currency, vouchers, and reputation to secure your safe passage to the land of the next overlord, and you worry that neighboring domains may not be on friendly terms, with you caught in the crossfire, clapped in irons, or ostracized entirely, kept from climbing whatever mighty mountain beckons.

User-centric identity systems don’t change this odd geography, or save us from this odyssey. In fact, taken to the “strong form” extreme, they just intensify the heterogeneity by adding sovereign self-asserting personal-IdP and personal-RP domains to the mix. Every user becomes a self-sufficient realm all their own, needing the potential of hooking up, on various levels, persistent or fleeting, with any other domain as needs dictate. Think of the higher order of combinatorial explosion in the density of negotiated cross-domain relationships. Here’s a good point for me to rehash/mash the definition, levels, and stakes of mutuality:

• An internet-scalable identity metasystem enables interactions built on mutual recognition, assurance, risk, recourse, restitution, and responsibility among all parties.
• Mutuality requires shared, assured, cross-domain, transitive, balanced, equitable, symmetric, commensurate, and reciprocal interactions among end- and intermediate-points, implemented in the context of ubiquitous business/legal, trust/PKI, federation/IdM, and reciprocal permission-based resource-sharing relationships from end to end.
• End-to-end mutuality allows any end- or intermediate point to participate in the identity metasystem with confidence that they can fend for themselves and actually benefit from plugging in.

How can parties rely, users prove reliable, and mutual relationships emerge and remain durable in a cosmically vast, comically dynamic, and freakishly fragmented crucible such as this?

Odd indeed.

Jim

rfi User-Centric Identity and Reputation

All:

What's the intersection of user-centric identity and reputation? I've been reading Phil Windley's many great blog postings on the topic of reputation. I've also doubled back and read my own past musings on the topic (a year-plus ago...). I was commenting on some reputation proposals by Marco Barulli and Giulio Cesare Solaroli. Still processing.....

Taken to a logical extreme, wouldn't user-centric identity require some concept of "self-asserted reputation"? But isn't that, on the face of it, absurd and conceited? Sounds like someone walking around shouting "trust me" and "I'm the best" and so forth. Of course, it's not totally outside the pale. This is what we pay agents (ie., PR and marketing) to do for us: stoke up a wished-for reputation by vouching for our magnificence.

Reputation lacks assurance if it doesn't seem to spring organically from collective evaluation, by others, of our character, deeds, trustworthiness, and so forth. In other words, it must (at least appear to) be "other-asserted." It's not "trust me" but "trust them" (with "them" being others who seem to know whereof they speak, and aren't in fact our surreptitiously paid spokespersons).

But here's the rub: the "unreliable narrator." If I'm a relying party (RP) who wants to know if you can be trusted, I can't necessarily ask you your opinion (each of us is assumed to be the most unreliable narrator/voucher of our own life story, since we have every vested interest in distorting it to our advantage). And I can't necessarily trust others either, unless I have some special access to their heads, hearts, backgrounds, personal agendas, and relationship to you. They--IdPs, attribute authorities, reputation authorities, circles of reputational trust, or what have you--are also unreliable vouchers of our trustworthiness until they can prove otherwise.

That latter concern--who you trust to tell your life story--is what motivated this prior post:

• "Reputation feels anti-governance, hence unfair. It feels oppressive. It’s the collective mass of received opinion, good and ill, weighing down on a particular identity. It feels like a court where the judge, jury, prosecuting attorney, jailer, and lord high executioner are phantoms, never showing their faces, but making their collective force felt at every turn. It feels like outer appearances, not inner character, ruling our lives."

Earlier in this thread I asserted that, in user-centric identity systems, the user is the sovereign of their identity, having total control over which of their identities, credentials, and attributes are disclosed to which relying parties. But where reputation is concerned, I would switch that focus around 180 degrees. Reputation is never user-centric; rather, it's always RP-centric. The RP can factor any, all , or no third-party assertions (from yourself, peers, reputation authorities, etc.) into their decision to transact or not transact with you.

So, in reputational systems, the RP, not the user, is sovereign. Actually, I came pretty close to arguing that point in those words a year or so ago, per this excerpt:

"Reputation isn’t an identity, credential, permission, or role. It isn’t exactly an attribute, in the same sense that, say, your birth date or hair color are attributes. And it isn’t something you claim any privacy protection over—it’s the exact opposite: the court of public opinion over which you have no sovereignty and little direct control.

In the identity management context, reputation is more of an assurance or trust level—an evaluation of the extent to which someone is worthwhile to know and associate with.

Reputation is relying parties’ evaluation of our reliability, of their liabilities, and of the degree to which associating with us makes them ill at ease.

Relying parties —- the ultimate policy decision and enforcement points in any interaction —- need many levels of assurance if they’re going to do business with us. They gather assertions and data from many “authorities” (authentication authorities, attribute authorities, etc.) before rendering their evaluations and opening their kimonos."

Again with the kimonos. I have to find new metaphors. Anyway, I was thinking about the notion of reputation springing up organically in user-centric identity systems through negotiations between sovereign entities: user and relying party (forget about intermediaries such as authentication and attribute authorities--they're not necessary in the pure model). What's the mutuality-enabling "conversation model" (to borrow a phrase from the Ping paper) in which reciprocal reputational assurance can emerge in a world without "other-asserted" reputation? Windley had a really good statement on the stakes of reputation:

• "To have social value, reputation has to be the basis of trust in the society and there has to be reciprocity. Reputation is a measure of an entity’s past actions and factual attributes. Trust is an expectation of future behavior. Reciprocity is the idea that 'good' actions will be met by society with positive results and 'bad' actions with negative results....To really function, social systems have to have reputation, trust, and reciprocity baked in. Without it, there’s no real social contract and no real society."

So what's the conversational model for reputational assurance in a non-intermediated, negotiated dual-sovereign system (user and RP)? It's fairly close to Hobbes' "state of nature." In that case there's no "society," no "social contract," and no third-party "vouching," just interacting parties transacting for their mutual benefit, and abrogating at the risk of mutually assured destruction.

The conversation model is terse and to the point: a shuffle of sharp words, done deeds, and big sticks.

Jim

rfi User-Centric Identity and Conor Cahill’s Take

All:

Prepare for run-ons and re-runs.

Awakened in the middle of the night by a call from the Louvre….young girl in distress…lost, scared….quickly resolved with a few calls to others in and around Paris….not Audrey Tautou….nobody you’ve ever heard of….no colorless clerics….no conspiracies….no holy grail or anything remotely metaphysical….just me paternally PO’d pale and sleepless six time zones to the west…having completed all the household chores the day before, I had taken me a pleasant self-guided walking/driving/jamming tour of DC yesterday…new ballpark going up in no-mans-zone southeast….passed by my old waterfront haunt, now vacant and awaiting the eventual and much-needed wrecking ball…saw the startling neighborhood transformation going on near the Navy Yard…followed M Street to what I could see of the Anacostia…huge vacant fenced away abandoned 60s project….will these new 00s project seem as forlorn in the 2040s?....then up through Capitol Hill…Mall….DeVotchKa, Shins, Peter Bjorn & John….call from the going-on-20 boy….Cherry Blossom Festival….tons of out-of-town tourists….parked in the West End….walked the C&O canal in mid-60s springtime solitude and serenity…tripped down that ancient red-brick Georgetown interior waterway….galleries….historical smokestack in/above the new Ritz-Carlton….empty office buildings….second-floor gallery overlooking a single alleyway blossom tree…then up to mainline M, along/above Rock Creek Park…quiet traffic…full of early spring potentialities…then stayed up late to catch the rerun of SNL with Arcade Fire….I bought “Neon Bible” last week….on SNL, they were great (wish the comedy had been up to par)….”Intervention” “Keep the Car Running”…live they came off just as intense and sprung as their recordings…Win smashed his acoustic guitar at the end….bravo bravissimo.…anyway, now, involuntarily adrenalized and semi-boggled I’m figuring I might as well rattle off the latest installment in this thread….good thing Starbucks opens early…belatedly writing up another phone chat from a week and a half ago with somebody just one county over here in northern Virginia.

Where was I? Oh, yes…Conor Cahill….identity architect with Intel, who’s been working with Liberty Alliance from the start. In March, it took us a few weeks to hook up, but I’m glad we did. He has an interesting perspective on user-centric identity. I used my interview questions as a rough track for our discussions, but primarily I asked Conor to deliver his take in whatever order he wished. According to Cahill (I’m putting these loosely paraphrased points in a slightly different order from my raw semi-illegible-even-by-my-own-lax-personal-standards notes):

• User-centric identity is great marketing term, referring to identity systems that give users control over their identity info
• Most users don’t want to be in every identity transaction…once I federate with a relying party, should implicitly set up auto-sharing (identity, credentials, attributes) rule that executes upon each return visit
• Most enterprise federated IdM implementations give users some control over the sharing of their identity info with service provider/relying parties, but not complete control
• User-centric identity is central to SAML and Liberty Alliance initiatives, which have addressed permission-based attribute control from early on
• User-centric identity is to some degree supported in most commercial SAML-enabled IdM products---in the sense that the IdP is allowed to ask users which of their attributes should be disclosed to federated relying parties—though this feature is not explicitly called out in the SAML standard protocol(s) and may not be implemented by users in many real-world SAML deployments
• OpenID is great for low-value transactions, such as blog posting authentication, but not beyond that, due to need for legal agreements between IdPs and relying parties, under which domains agree on risk and liability for inappropriate authentication etc.
• OpenID is user-centric identity in the limited sense that the user directs the relying party to an IdP that the user explicitly selects, but 1.0 doesn’t implement permission-based attribute sharing (that’s in attribute exchange service in 2.0)
• OpenID assumes user wants to know they’re using OpenID, and willing to type in long URI, hence enabling easy IdP discovery for benefit of relying party, whereas SAML does IdP discovery through the common cookie mechanism, and Liberty through Discovery Service specified in standard
  
• OpenID like SAML and Liberty in that it makes use of dumb browser (though Liberty goes it one better by specifying Liberty-enabled client)
  
• OpenID lacks disconnected client support, a feature integral to Liberty’s advanced client
• Possible future Liberty integration of Oracle-contributed IGF specs into ID-WSF is exciting to enable users to exercise life-cycle control/expiration/shredding of attributes that they choose to disclose to relying parties
• CardSpace is first stage beyond dumb browser, has great user experience, adds more value to SSO than to attribute sharing
• Surprised that when CardSpace came out, with Vista availability, that Microsoft didn’t announce any CardSpace relying parties right off the bat (Passport redux?)
• Real driver will be strong authentication, which CardSpace has

Without much prompting from me, Conor tied together lots of themes/concerns that I’ve heard from others and also things I’ve posted to this thread from the top of my noggin. Still, I think his statement that most commercial SAML implementations support user-centric identity is provocative….and I’m not sure I agree with it….I mean, if a feature (e.g., permission-based attribute sharing) is purely implementation-specific and is not explicitly called out or defined in the underlying standard, can we legitimately attribute it to the standard?....or simply to the fact that this is an important requirement that necessitate that IdM vendors commercially color outside the SAML lines until the standard (inevitably) evolves (through mashup with ID-WSF, OpenId 2.0, IGF, etc.)?

Coffee's drained. Me too. Up against the wall of consciousness. Need a nap. And a PB&J. Baby went to Amsterdam….she put a little money into traveling….now it’s so slow…so slow…baby went to Amsterdam…four or five days by the big canal…now it’s so slow…so slow.

Jim

rfi User-Centric Identity and Da Ping Paper

All:

Ping Identity has weighed in on the topic of Internet-scalable identity systems. It published a whitepaper in February right around the time of the RSA Security conference.

One of the most useful aspects of the Ping whitepaper is its heterogeneity-embracing “conversational model,” which outlines, for an identity metasystem, the key entities and relationships, including user/client, IdP, RP/SP, identifiers, attributes, authentication, identity flow, trust model, and discovery.

This isn’t an exhaustive model, but the good folks from Ping use it to crisply analyze the differences between SAML, Liberty ID-WSF, OpenID, and CardSpace, and to highlight their respective strengths. Then they present two convergence/coexistence use cases that tie together SAML, OpenID, and CardSpace (somehow, ID-WSF is left out of the hypothetical cases, though it could be inserted at the risk of adding even more heterogeneity).

What Ping’s scenarios have in common is the following, per my model:

• Abstraction: assume card/browser/portal/REST as principal elements of user-experience abstraction
• Heterogeneity: assume assertion-based identity/attribute interchange amongst users, IdPs, and RP/SPs with various IdP discovery approaches (URI-based authentication initiated at RP/SP vs. IdP-initiated authentication) as the principal domain-interaction impedance-matching mechanism for heterogeneity
• Mutuality: assume cross-domain federation (a la SAML) and PKI (a la digitally signed SAML assertions exchanged cross-domain) as backbone of mutual recognition, assurance, risk, restitution, and responsibility across all users and domains

The paper ends on an ambiguous note: the authors aren’t quite clear on whether we should push for true convergence among these approaches (where, ostensibly, SAML, ID-WSF, OpenID, and CardSpace mash up into some grand unification standard) or settle for uneasy coexistence among persistently separate approaches over the long haul. Here’s their closing statement:

• “The Identity Metasystem is the promise of a secure, privacy enabling Internet-scale identity system comprised of heterogeneous technologies operating together in a compatible and cohesive manner. Such coexistence implies determination of the areas in which current identity systems like SAML, OpenID, Windows CardSpace and ID-WSF are duplicative in functionality and scope – this is necessary to determine where and how these systems can be compatible. This white paper demonstrates that these systems have unique characteristics and strengths – and suggests some representative scenarios in which these strengths complement rather than compete. These identity systems will coexist and they all offer sufficiently unique capabilities that will allow them to flourish independently to some extent. Notwithstanding the unique capabilities, there is a significant degree of duplication of functionality between the various systems. Convergence between the systems would eliminate such duplication and result in a simpler identity landscape.”

Simpler, yes, but ipso facto better? If we converge the periodic table down to just hydrogen and helium, it would be simpler universe, for sure, but not quite as scalable, or as rich with potential.

Jim

rfi User-Centric Identity and Master Data Management

All:

Here's another installment in the ongoing saga of me attempting to intersect all creation with user-centric identity.

What exactly is master data management (MDM)? I have a many-layered response to that:

• Enterprise requirement: need for corporate systems of record that are authoritative, consolidated, current, and internally consistent; also known as need for a “single version of the truth” continuously feeding business intelligence applications with actionable business information
• Best-practices paradigm: infrastructure, tools, and workflows for life-cycle governance of master reference data sets, such as customer records, product information, financial data, etc.
• Product segment: comprehensive solution portfolios that include software for data quality (profiling, cleansing, enhancement, etc.), data integration (extract, transform, synchronize, replicate, load, etc.), data consolidation (data warehouses, operational data stores, DBMS, etc.), data modeling (metadata, mapping, semantics, etc.), data administration (stewardship, monitoring, security, version control, access control, etc.), prebuilt domain data models (horizontal applications for customer data integration, product information management, financial consolidation etc.; industry-specific for financial services, manufacturing, carriers, etc.)
• Coverage area: my core focus as principal analyst for data management at Current Analysis
• Solution Assessments: new class of Current Analysis reports that I’m publishing and will keep current continuously, focusing on leading MDM vendors such as IBM, Oracle, Teradata, SAS, TIBCO, SAP, etc.
• Telebriefing: that I’m presenting next Wednesday-Thursday, introducing the new Current Analysis MDM Solution Assessments and discussing the market, vendors, differentiators, etc; check www.currentanalysis.com for further details

So there's my plug for my bread-and-butter. I'll bet you're still wondering how MDM overlaps with user-centric identity. I have a multi-layered answer to that as well:

• Customer records are identity data sets.
  
• One of the principal enterprise applications of MDM is customer data integration (CDI)--i.e., extracting customer records from multiple source apps/databases; then analyzing, profiling, matching, de-duplicating, correcting, enhancing, and transforming those records; then consolidating and loading them into data warehouses; then applying version and access controls to the records; etc.
• Consequently, CDI functions are essentially IdM operations, similar in many ways to directory synchronization and meta-directory operations, in which diverse customer identity namespaces (i.e., the source customer data schemas in your CRM and other apps) are synchronized and/or joined into a composite and/or consolidated enterprise-standard namespace

Getting to the user-centric identity relevance...bear with me a moment longer...OK.....so there are some genetic similarities between traditional IdM and CDI/MDM, but there is a key difference in how IdM-reliant and CDI/MDM-reliant applications generally "rely" on the respective identity data sets:

• Traditional IdM treats the identity/user as a "subject"--i.e., performs various and sundry dir-sync/meta-dir operations in order to manage identity data necessary for user-inbound security services such as authentication, access control, role administration, etc.
• Traditional CDI/MDM treats the identity/customer as an "object"--i.e., performs data integration/quality/consolidation functions in order to manage identity data necessary for user-outbound commerce services such as direct marketing, billing and collection, service and support, etc.

Getting closer...be patient...the payoff's on the horizon...now, neither approach--traditional IdM or traditional CDI/MDM--qualifies as user-centric identity. And why is that? Because--keeping in mind the notion that user-centric identity "empowers the user"--it's clear that neither of these approaches serves that purpose. Instead, they both empower the managed IdP (be it a classic IdP or a CDI/MDM data warehouse). Neither approach provides "you" (the user, in classic IdM, or the customer, in CDI/MDM) with the information and/or tools that you need to control your identity. In both of these approaches, regardless of whether they treat "you" as a "subject" or "object," your identity is controlled by "them" for "their" purposes.

Here's the payoff: Classic user-centric identity requires that "you" be the master of your own personal identity data. In other words, makes you the "sovereign," not the "subject" or "object" of your identity. By contrast, classic CDI/MDM requires that "you" the customer/prospect/direct-marketing "object" cede that personal-identity control to a master managed third-party IdP (i.e., the owner of the data warehouse in which your identity data has been consolidated under strong governance).

So there you have it. Any questions?

Jim

rfi User-Centric Identity and Extended Validation Certificates

All:

Empower the user. That's the heart of user-centric identity, however the concept gets interpreted and implemented. With that in mind, I took a fresh look at these two Microsoft announcements from this year's RSA Security:

• A Windows CardSpace proof-of-concept demonstration, and collaboration with the OpenID 2.0 specification
• Support of Extended Validation (EV) SSL Certificates in Internet Explorer 7

They both empower the user. CardSpace does it by letting the user select the identities, attributes, and credentials they want to use in each transaction. EV SSL Certificates empower the user by giving them a clear indicator--a green background in their browser address bar--when they're visiting a legitimate website whose current owner has a valid certificate, attesting that both the site's owner and their certificate authority (CA) have jumped through the following trust hoops:

• The CA that issued the EV SSL certificate has passed a "WebTrust for CA" audit of its security practices, demonstrating that it follows stringent guidelines in the operation and management of the approved EV SSL CA service, and that it only issues EV SSL certificates to legally incorporated organizations and government entities.
• The EV SSL Certificate is only issued to an organization that has provided sufficient documentation to the CA, and submitted to a background investigation, to show that it is incorporated as a legal entity, has a physical location, is engaged in a business activity, and has exclusive rights to the domain name that is included in the certificate. In addition, the certificate remains valid only if the owner of the website pays the premium price to the CA for keeping its validation in good standing.

It's not just the greening of the browser address bar. The browser also provides the user with further information about the holder of the EV SSL Certificate, with whose website they are sharing information over a standard server-authenticated SSL confidential session. Under the user-centric identity principles that I posited in this blog thread, these features fall under "mutuality," per the following language that I scraped from my own earlier posts:

• Mutuality: An internet-scalable identity metasystem enables interactions built on mutual recognition, assurance, risk, restitution, and responsibility from end to end.
• All user identity-based interactions are engaged in by the user with full knowledge, transparency, and nonrepudiation of the relying parties.
• Transitive trust is shared, assured, cross-domain recognition of the identities of people, applications, servers, and other entities through mutual implementation of X.509 certs, cross-certified or bridged certificate authorities, common certificate policies and certification practice statements, legal/business agreements, and so forth.

It also falls under "abstraction," to wit:

• Abstraction: An internet-scalable identity metasystem presents a simplified, virtualized, complexity-hiding interface (e.g., a warm green light) to all entities, from end to end.
• The idea of SSL sessions for relationships practically screams for one or more trusted third parties (TTPs) to vouch for the good reputation/behavior of participants in a (user-centric and/or traditional federated) IdM interaction, and possibly to see to it that appropriate sanctions are applied in cases of bad behavior.

But it's not particularly "lightweight," is it? In fact, almost any PKI-based mutuality assurance mechanism automatically fails the lightweight litmus test, because you get TTP "authorities" (certification, revocation, validation, etc.) and crypto and trust relationships and so forth in the loop. Add to that the need for background investigations and in-person proofing, and, before long, you realize that the "green" in the browser refers to the heavy chunk of money that foots the bill for this level of "extended validation." Anytime you introduce a significant complexity/cost/bureaucratic overhead into the assurance equation, you price it out of the reach of most website owners, and most individual users (in cases where we run our own personal websites, and operate as our own personal service providers and relying parties).

All of which brings back the critical issue:

• How do we extend lightweight user-centric identity to the long tail of web sites/presences that don't and won't implement a heavyweight trust/federation/mutuality model such as PKI, SAML, or Liberty requires just to do strong bilateral authentication?

So, we must ask: Is strong end-to-end mutuality truly Internet scalable (i.e., empowers users with knowledge of each other's trustworthiness without encumbering each party under an unfunded heavyweight trust mandate)? Or does it require legions of investigators and proofers, plus universal adoption of commercial IdM trust/federation/assurance frameworks? Will we as users ever require "extended validation"/high assurance on each other's personal end-entity certificates, if doing so requires that each and every person submit to the equivalent of an FBI background check every so often?

Or will we just take our chances on each other, hoping for the best in each interaction? Or use other avenues (e.g., Googling each other beforehand) to check each other out before we get in too deep?

Jim

rfi User-Centric Identity and What Craig Burton Said

All:

Actually, he didn't say it to me. He was paraphrased by Doc Searles (http://www.linuxjournal.com/article/5798) as saying the following:

• "Craig Burton says it's the nature of infrastructure to commoditize itself and that it's the nature of commodities to ubiquitize as well. That's why he believes every company playing the infrastructure game in the computer and networking business needs an open-source strategy....
• "That infrastructure is essentially an underlying condition that's easily conceived as a place. Bob calls the condition "connectivity". Larry Lessig calls it the Net's "end to end" architecture. Craig Burton has my favorite description for the place itself: a hollow sphere in which every point is visible to every other point across an empty space in the middle -- a vacuum where the virtual distances are zero. Fittingly, we conceive of the Net in place-like terms. We have "sites" and "locations" with "addresses" that are "on" the Net.
• But here's the problem: what Bob and Larry and Craig talk about is obvious to us, but not to the majority of netizens to whom the Net is a remote place one "visits" by "dialing" there. The place-like nature of the Net is also not obvious to the telecom and cable backbone companies that still think of the whole thing as a distribution system -- a concept they share with the entertainment business (and, regrettably, many lawmakers)."

Me again: In the user-centric Web 2.0 paradigm, Burton's "points" are us. His "hollow sphere" is the medium through which points point to other points and thereby fuse into communities. Mutuality is built on visibility across those points. Heterogeneity in the IdM universe clouds that visibility with distracting complexities. But abstraction filters away the complexities and delivers the simplicity upon which points frame their personal views of the metasystem and coalesce into galaxies of tighter mutuality.

Jim

rfi User-Centric Identity and Abstraction

All:

Hmmm...let's see....:

• "Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies."

Nah...How about this:

• Abstraction: An internet-scalable identity metasystem presents a simplified, virtualized , complexity-hiding interface to all entities, from end to end.

Which brings me now to the card-based interaction metaphor: anything but simple. Let me now re-present what I paraphrased Eve Maler as saying:

• "She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the 'human present' mode, which, as Eve stated memorably, means that the 'user's policy is in their brain.' By contrast, she pointed out, Liberty's ID-WSF was developed to support both the 'human present' and 'human absent' modes."

Yikes, you mean I'll have to actually, actively, in real time, and with cloudy cognition of the possible consequence select cards from those that my card-selector coughs up? Or I'll somehow have to write rules to that effect that my automated identity agent will use to select my cards on my behalf? And/or delegate this delicate responsibility to some hopefully responsible human being(s)? And somehow find a way to sync cards across the diverse card selectors in my diverse clients and server-based identity agents? Has this ever-pushy opt-in paradigm spared us from spam in the e-mail universe? What happens when my card selector environment is overstuffed with cards that I opted to receive in the past and am not sure whether I should keep or kill now? What happens when a relying party says that 37 of them are acceptable for this next contemplated transaction? Which should I choose?

In the interest of simplicity, why not simply go back to a default password of "password"? That's user-centric isn't it? In "human-absent-minded" scenario?

Jim

rfi User-Centric Identity and Heterogeneity

All:

Re this one:

• "Heterogeneity: An internet-scalable identity metasystem must enable seamless, standards-based interoperability across diverse identity use cases, interactions, design patterns, credentials, protocols, IdPs, RP/SPs, platforms, etc."

That's pretty tight as is, so I'll keep it without modification. But I will add that it also applies to a heterogeneity of user-centric IdM schemes. In other words, I don't buy this notion that OpenID will ever evolve to be the one-and-only user-centric identity scheme. I don't think OpenID's developers truly believe that, though I side with them in believing that they have significant momentum and are spreading their URI-based approach into the very sinew of Internet-scale IdM.

Going back to a user-centric IdM framework that I proposed near the beginning of this blog thread, I see considerable convergence going on among three principal approaches. But I believe those individual approaches will continue to evolve independently of each other to address diverse use cases in the stubbornly heterogeneous IdM world. Here now, benefiting from the month-plus of research, analysis, and conversations in this "request for interaction" are those user-centric IdM frameworks (with new and improved definitions):

• Assertion-based user-centric identity: Under assertion-based approaches, such as Liberty ID-WSF, users define rules that control which of their identities, credentials, and attributes get presented to relying parties by a managed identity provider (IdP)—such an enterprise directory service--subsequent to successful logins. Typically, IdPs and relying parties, also known as service providers (SPs), interact under pre-established federated IdM trust relationships. IdPs present user identity information to SPs in standard data formats known as “assertions,” “claims,” or “tokens.” Depending on the federation implementation profile, these assertions may flow directly from the IdP to the SP subsequent to a login, or be forwarded from the IdP to the SP through the user’s client/browser. When implemented in a federated IdM environment that implements Liberty ID-FF, Liberty ID-WSF enables users to selectively control which of their identity-related attributes are disclosed by IdPs, via Liberty/SAML assertions, to other IdPs and SPs among which SSO is enabled within a “circle of trust. ID-WSF can provide a flexible infrastructure for user opt-into complex personal-resource-sharing scenarios in an SOA or Web 2.0 networking environment.
  

• Card-based user-centric identity: Under card-based approaches, such as Windows CardSpace, users select which of their identities—with associated credentials and attributes—will get presented to SPs from their client environment within the context of each identity transaction. Typically, identity interactions flow through the user’s client environment without need for direct interaction between IdPs and SPs, and without need for pre-established federation relationships between IdPs and SPs (though all IdPs and SPs must implement the same card-based IdM technology). Rather, the user’s client controls the flow of the selected identities, credentials, and attributes directly to the SP after retrieving them from the IdP (which may be a managed, external IdP or a “personal IdP” that runs totally on the user’s client device). In order to retrieve the requisite identity information from the relevant IdP, the user selects the appropriate “identity card” from any of several that are displayed by the “card selector” user interface in their client environment. Identity cards--also called “i-cards,” “information cards” or “infocards”--represent identities, with associated credentials and attributes, that the IdP had previously provisioned to the user upon identity registration. These identity cards are purely virtual constructs presented to users within the IdM environment, but are not physical tokens such as smart cards or wallet cards (though, to some degree, the card-selector environment in which they run functions like an electronic wallet).
  

• URI-based user-centric identity: Under URI-based approaches--such as XRI/XDI, LID, and OpenID--IdPs provide users with URIs that serve as personal identifiers. These URIs, such as a user’s blog address, may be used to login to diverse SPs (called “relying parties” under this paradigm) that participate in the same URI-based IdM scheme implemented by the issuing IdP. Generally, the SPs and IdPs need not have a pre-existing federation trust relationship in order to log the user into the SP through cross-site proxy authentication mechanisms.

Now, it's clear to me that the URI-based approaches have already substantially converged into each other (though they stand/evolve alone as well). Also, if recent industry events are any indication, the URI-based approaches are also converging with the card-based (Windows CardSpace and Higgins), and with the principal assertion-based approach (i.e., Liberty ID-WSF) to a great degree. Consider all of the following:

• LID supports use of OpenID Authentication.
• LID and OpenID both implement Yadis, which is a protocol (created by LID and OpenID’s developers) that supports transparent discovery of the framework and IdP under which a user’s URI has been registered.
• LID is interoperable with XRI i-names, enabling i-name owners to leverage LID protocols to control third-party access to their personal identity information.
• Yadis is currently being incorporated into the XRI Resolution Working Draft of the OASIS XRI TC.
• Microsoft’s Bill Gates and Craig Mundie announced at the RSA Conference in February 2007 that the company will work with Sxip, VeriSign, and JanRain to integrate OpenID with CardSpace.
• Microsoft will work with the OpenID community to create a "Using InfoCards with OpenID" profile.
• OpenID’s developers will add support for InfoCards to their respective identity solutions and will extend the OpenID specifications to allow relying parties to request and be informed of the use of phishing-resistant credentials.
• Eclipse Higgins—spearheaded by federated IdM software vendors Novell and IBM--is developing a card-based, user-centric alternative to Windows CardSpace, along with a robust attribute-exchange and trust framework. Higgins’ developers are designing their approach to interoperate with other user-centric IdM approaches, and also with a wide range of federated IdM standards and other established identity approaches. More broadly, the Higgins reference implementation and API will provide an extensible, platform-independent, IdM-protocol-independent identity framework for permission-based attribute sharing, privacy protection, and user convenience. It will virtualize identity sources and provide a unified view of identity information across heterogeneous IdM systems.
• At RSA 2007, the Eclipse Higgins and Bandit projects demonstrated interoperability of their open-source user-centric identity implementations with Windows CardSpace. At the same time, they also demonstrated interoperability with a Liberty Alliance-based federation implemented via the commercial Novell Access Manager product.
• Many of the leading IdM vendors—including Microsoft, IBM, and Novell—are actively incorporating user-centric approaches into their federation-oriented solutions.
• Liberty Alliance is actively engaging with the OpenID/LID/YADIS etc. community to cross-synthesize their respective approaches.

Heterogeneity means stubborn complexity with a common interoperability backplane. I suspect that the URI/REST-based approaches are that backplane.

Jim

rfi User-Centric Identity and Mutuality

All:

Now for the editing and elaboration. First off, per the previous overstuffed formulation:

• "Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth."

Won't do. Can't keep it in my head. That's one of the things that's cool about short poetry--in fact, the core redeeming value: memorizability (and hopefully, memorability). Let's whittle this definition down to a more ipod-like form factor:

• Mutuality: An internet-scalable identity metasystem enables interactions built on mutual recognition, assurance, risk, restitution, and responsibility from end to end."

Yeah, that slips nicely in the inside coat pocket, and I can hear it beeping for me now. What it's telling me is that "mutuality" as an uber-concept anchors user-centric identity into a broader context of trust and federation across cross-domain IdM environments. In fact, you can rethink these all as different levels of mutuality:

• Trust: transitive trust is shared, assured, cross-domain recognition of the identities of people, applications, servers, and other entities through mutual implementation of X.509 certs, cross-certified or bridged certificate authorities, common certificate policies and certification practice statements, legal/business agreements, and so forth.
• Federation: federated identity is shared, assured, cross-domain recognition of identities, authentications, and attributes through mutual implementation of common standards (SAML/Liberty et al.), federation frameworks, legal/business, agreements, and so forth, plus mutual risk and restitution (i.e., "mutually assured destruction" in terms of legal recourse) if either party abuses the trust/federation relationship
  
• Reciprocal permission-based resource sharing (i.e., the core use case of user-centric identity, including/especially the "dataweb" XRI/XDI approaches): this is the "mutual kimono opening" scenario that I described earlier, under which the user operates as his/her own personal IdP, and essentially also his/her own personal SP, disclosing personal attributes and other resources to relying parties only on a "need to know" basis (with full user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, etc.), with the relying parties providing tit-for-tat access to their own resources--a balanced, equitable, symmetric, commensurate, and mutual interchange of goodies
  

Getting back to a question I posed earlier in this thread (with "mutually" substituted for a near-synonym):

• In user-centric identity environments, how do personal/private IdPs mutually federate to each other, in the absence of (one or more) trusted third parties to vouch for their respective good reputations/behaviors?

They do it through a koy kabuki-like koreography of mutual kimono openings and closings. Through the same means by which you or I evaluate each other's trustworthiness in the analog realm. Who skrewed whom.

Jim

rfi User-Centric Identity and Principles of Internet-Scalable Identity Metasystems

All:

Just to publish a thoughtstream that's been trickling and babbling like a breaking brook in my brain.

First off, I'd like to suggest that what we should be focusing on is not "user-centric identity," per se, but "internet-scalable identity metasystems" (a thought that Andre ping'd me on and Dick got me to take to hardt). What are the principles for making our identity metasystems truly internet-scalable? Could it be that user-centricity (however defined) is a necessary (but perhaps not sufficient) condition for internet-scalability?

Now, let's look back to that previous post where I enumerated the main internet-scalability questions that Mr. Hardt laid out for our consideration:

• How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust?
• How do we enable the free movement of claims from anywhere to anywhere?
• How do we extend lightweight identity management to the "long tail" of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication?
• How do we leverage the same core universal lightweight internet design patterns--i.e., REST using URIs and HTTP/HTTPS--to do internet-scale ubiquitous identity?

Now I'm going to slightly shift the context for a moment to Kim Cameron's "laws of identity," and then attempt to map that, plus Hardt's concerns, back to the notion of what it takes to make an identity metasystem truly internet-scalable. First, what I'll do is just republish Kim's actual written principles, but in a different order:

• Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
• Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
• Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
• User Control and Consent: Technical identity systems must only reveal information identifying a user with the user’s consent.
• Minimal Disclosure for a Constrained Use: The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
• Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
• Directed Identity: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

Now, I'll reclassify/regroup/rewrite these principles into three higher-order principles:

• Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies.
• Heterogeneity: An internet-scalable identity metasystem must enable seamless, standards-based interoperability across diverse identity use cases, interactions, design patterns, credentials, protocols, IdPs, RP/SPs, platforms, etc.
• Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth.

Now, how would conformance to these three wordy uber-principles contribute to internet-scalability? Well, abstraction is the face of the universal interoperability backplane of any ubiquitous infrastructure (be it REST, SOA, ESB, or what have you). And heterogeneity is the fabric of any hyper-decentralized, federated, multidomain interoperability environment. And mutuality (i.e., a balancing of rights, responsibilities, risks, restrictions, rewards, etc.) is essential for any endpoint (e..g, the end user, an RP/SP, etc.) to participate in this heterogeneous, abstract environment with any degree of confidence that they can fend for themselves and actually benefit from plugging in.

User-centric identity got going as an industry concern when it became clear that federated identity environments are not always mutual, from the end user's point of view. In other words, under "traditional" federation, some "attribute authority" (not necessarily under your or my direct control) may be coughing up major pieces (attributes) of our identity to unseen RP/SPs (also not under our control) without consulting us on the matter. In other words, those RP/SPs can selectively deny us access to the resources (i.e., apps, data, etc.) we seek, but we often can't selectively deny them access to the resources (i.e., our identity attributes) that they seek. Doesn't seem like a balanced equation, does it?

Now, tying all this back to Dick's key design criteria for the identity metasystem (in summary): open, free, lightweight, ubiquitous interaction patterns. Seems to scream for abstraction plus heterogeneity plus mutuality, which are necessary and, taken together, sufficient conditions for internet scalability.

In other words, necessary for the identity metasystem to be universally feasible, flexible, interoperable, implementable, extensible, and acceptable.

Jim

rfi User-Centric Identity and What Roger Sullivan Said

All:

We spoke on Feb 16, and he spoke primarily in his capacity as president of Liberty Alliance. We're scheduled to speak again next week.

First off, Roger said that Liberty wants to participate in industry discussions and work to develop user-centric identity into a tangible, practical reality. In fact, several people active in Liberty--including Brett McDowell, Eve Maler, and Conor Cahill--are taking a more proactive role in this regard.

I pointed out to him that, when I first looked closely at this new wave of user-centric identity projects, I experienced deja vu. A few years back, during my Burton Group days, I did a consulting gig with Liberty during the period when they were first developing ID-WSF, and I noted that the core use case then--"permission-based attribute sharing"--seems to be also the core use case for CardSpace, OpenID, and other efforts now. Why is this? Did ID-WSF miss the mark? Or is it too heavyweight? Or are the new up-and-comers reinventing a perfectly fine wheel? Or is it a fifth wheel for a vehicle still under assembly?

"Yes, Liberty Alliance collaborated on this use case a few years ago for ID-WSF," said Roger. "Now I don't want to dampen the enthusiasm of people who are working on these new projects [outside Liberty]. There are legitimate new use cases being developed: anonymity, rightful anonymity, and transition from such an environment to a more trusted relationship. We must bridge from self-asserted identity environments to federated identity environments such as Liberty and SAML." He mentioned that Liberty has scheduled an open forum to work on these issues at its upcoming April session in Brussels, and that the forum is open to non-Liberty members. He also pointed out that non-Liberty members are encouraged to participate in the Liberty-hosted wikis at openliberty.org.

Bottom line about user-centric identity, though, says Roger, is that it's only half the equation: "People usually discuss this topic as referring to having complete control over my own identity and credentials at some level. But for you to trust me, the attestation of my credentials must come from a trusted third party. The challenge the industry faces now is that a novice person comes to the identity management space and their instinctual reaction is 'I don't want anybody to know anything about me.' But how do you do e-commerce [under those conditions]? How can I have trust in you? The novice might respond: 'from that little lock in the lower right corner of my browser.' But of course that's ridiculous. To grow the [identity management] industry, proponents of self-asserted identity models must come to reconciliation with third-party-reliance services, in order to define use cases that move from user-centric identity to [mainstream federation] environments within e-commerce."

Roger said a lot more, all of it interesting. When I circle back with him, I'll flesh out this blogpost, or do a new one, that brings it all into the thread.

Jim

rfi User-Centric Identity and What Dick Hardt Said

All:

I spoke with Dick yesterday. Just before the call I realized that we had met in a previous life, when I covered the anti-spam space and he ran ActiveState....which he sold (to who?...I forgot) and started SXIP a few years ago. I covered anti-spam as an identity management problem. Anyone out there remember that paper? I might have rehashed it in this blog somewhere in the early days...don't recall. Anyway, just want to point out that I periodically inject identity management back into new contexts in my career (such as the advisory report I'm germinating in my head for Current Analysis, wherein I'll converge IdM with MDM via CDI....still keeping that pot on the back burner....overtaken by more pressing things to dissect...such as today's Oracle acquisition of Hyperion). Or new assignments (such as this gig for BCR).

Anyway, nuff a me, more of Mr. Hardt. He drew a distinction between user-centric identity (the new waves of identity systems in which identity data flows through the user/subject/principal...equivalent to Eve Maler's take on user-centric identity, but also, interestingly, refers to the original SAML implementation profiles as well....browser/artifact and browser/post) and domain-centric identity (i.e., traditional identity systems, characterized by the primary flow of identity data through the directory, IdP, etc.). He also quickly moved the discussion away from user-centric identity, per se, to "internet-scalable identity" (i.e., the same focus taken by Andre Durand and Ping Identity in their excellent recent whitepaper).

Dick asked (and here I'm paraphrasing several things he said at several points during our discussion): How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust? How do we enable the free movement of claims from anywhere to anywhere? How do we extend lightweight identity management to the "long tail" of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication? How do we leverage the same core universal lightweight internet design patterns--i.e., REST using URIs and HTTP/HTTPS--to do internet-scale ubiquitous identity?

As regards identity system scalability, Dick proposed a really interesting analogy (again I paraphrase): Domain-centric identity is like a leased line. Federated identity is like frame relay. User-centric identity is like IP packets.

He said user-centric identity--where it's incumbent on the user/subject to collect, assemble, and present their diverse claims/attributes to each RP/SP they wish to access--might be the most scalable, lightweight, feasible approach for making roles and entitlements portable across federated domains. And for easing the role administration burden within domains. As long as the claims/attributes they're presenting are currently valid in the trusted attribute authority domain that issued them.

Which brought my head back to this thought of user-centric identity for personal role multiplicity management. Or whatever I called that mashup of a notion at the beginning of this current blog thread.

Jim

rfi User-Centric Identity and What Eve Maler Said

All:

Eve sounded as rushed and frazzled today in our call as I always sound (and feel). She only had a limited amount of time, and I understood totally. But we got in a good half-hour of quality interaction, and she was articulate and insightful as always.

I ran down my list of interview questions, skipped some, and let her expand on topics of special interest to her. What stuck with me most was her approach to discussing the definition of user-centric identity.

She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the "human present" interaction mode (i.e., the actual human user/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the "human absent" interaction (i.e., the human user/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).

She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the "human present" mode, which, as Eve stated memorably, means that the "user's policy is in their brain." By contrast, she pointed out, Liberty's ID-WSF was developed to support both the "human present" and "human absent" modes.

Eve said she didn't want to be understood as arguing that one or the other mode is best, but simply that they both have their proper roles and should both be supported in a comprehensive identity environment (user-centric or whatever). She took pains to point out that user-centric identity is orthogonal to, not mutually exclusive with, "traditional" federated identity of the SAML and Liberty variety. I pointed her to the excellent whitepaper recently published by Ping Identity that lays out the convergence scenarios (OpenID+Liberty+SAML+*****) in wonderful brain-opening detail.

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users' identities open to possible correlation by unauthorized third-parties. But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them...that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal "space."

At which point, what each of us might need is a federation of personal cardspaces (this last thought just came to me....Eve didn't offer up this particular thought...but she inspired it...thanks Eve...next time I'm up in Redmond or thereabouts....coffee).

Jim

rfi User-Centric Identity and SOA Mashup Governance

All:

User-centric identity is just one subtopic in a more completely user-centric SOA/Web 2.0 world.

In fact, most of the Web 2.0 paradigm is user-centric. It focuses on enriching users’ interactive online experiences, letting them express themselves as they wish, build personalized presences, reach out to each other, create community, and concoct new content. Consider the many approaches subsumed under the heading of Web 2.0--AJAX, RSS, blogs, wikis, social networking, folksonomies, podcasting, mashups, etc.—and you can see that it’s mostly focused on helping users thoroughly shape, populate, and colonize the online environment.

As a growing phenomenon, much of user-centric identity has grown directly out of the Web 2.0 application paradigm. For example, OpenID was designed by the blogging site LiveJournal as a means for chaining logins among federated blogs so that a browser can leave authenticated comments at other blogs they visit. Essentially, this is user-centric identity federation, where users self-assert their identity (i.e., their blog URL, such as jkobielus.blogspot.com), self-publish their own identity attributes (i.e., the descriptors about themselves that they choose to place in their online profiles), and self-publish their own content (i.e., postings such as this), and/or mashups of content culled from the online universe.

As a Web 2.0 development approach, mashups are highly user-centric, or should be. On the one hand, a “mashup” application is essentially the same as a “portal” application—i.e., an aggregation of links to content/services generated/hosted elsewhere. But a mashup is something that the end user—not just professional programmers--can and should create, drawing both from their own resources and linking to whatever they can discover on the open Internet (and intranet, and extranet). Also, a mashup is something that represents the user’s own style and soul: spontaneous, individualistic, anarchic, creative, transitory, funky, unpremeditated, edgy, etc. And a mashup is something that repurposes others’ networked resources without necessarily gaining their prior permission.

This latter point is where the intellectual property lawyers—and privacy advocates--start to get real nervous. Likewise, anybody who has gravitated to the user-centric identity paradigm because they want to enforce “permission-based attribute sharing” over relying partners’ access to their own self-asserted identities (and to the self-asserted/published attributes and content linked to those identities) might worry about someday seeing themselves and their creations mashed up into an alien (non-revenue-producing) context by total strangers.

Which brings me to the notion of “mashup governance.” I didn’t originate the term—it came from a recent article by Dave Linthicum:

Enterprise mashups meet SOA
http://cwflyris.computerworld.com/t/1284237/1375321/51908/2/

"Governance -- the creation and enforcement of design time and runtime policies -- is tricky business for mashups. Given that mashups are made up of services and may indeed become services themselves, you need to manage these services across the entire lifecycle, as with any service or process contained in an SOA. Among other things, this means selecting, building and maintaining a mashup-aware registry/repository. However, although mashups need to be managed, you should avoid overloading them with policies and procedures, or you'll discourage developers from creating them.

Mashup security is critical, considering that you're looking to leverage interfaces, content and services you neither created nor own. No one wants to discover that an innocent-looking AJAX mashup is actually sending customer data to some remote server and compromising the business. Care must be taken to implement security policies and technology layers that will protect the value of the mashup platform. This should mesh with your SOA security or become an extension to it."

This interesting concept deserves greater development. How exactly would one represent complex, creative, presentation-layer compositions in a "mashup-aware registry/repository"? Do RDF, OWL, and the rest of the Semantic Web paradigm come to the forefront in this new order in defining the hypercomplex linkages of many mashups? How about the identity management side of the equation? How does one represent the welter of entitlements, access controls, and federation relationships among mashup providers and consumers in such a registry/repository?

In design-time mashup governance, one’s first impulse is to apply the same formal/professional design-time SOA governance regime (best practices, approval workflows, service promotion life cycle, access/version controls on registry/repository, etc.) to mashups as to any other service. But that’s essentially strangling the very notion of a what makes a mashup special—the ungoverned, unpremeditated, unprofessional expression of motivated users cobbling together found resources into a bold new creative synthesis. That’s what Dave gets at with his statement: “you should avoid overloading [mashups] with policies and procedures, or you'll discourage developers from creating them.” Of course, from there it’s a slippery slope toward dissolving any and all design-time governance controls on creation of any SOA/Web applications—on the grounds that to enforce those controls stifles developer creativity.

One middle ground is to provide users/developers with corporate-standard mashup development tools/frameworks that prevent them from coloring too far outside the lines of permissibility, in terms of the provenance of the resources they can mashup, the look-and-feel permutations of supported mashups, and the presentation platforms to which the mashups can be published. They can exercise all the mashup creativity they wish, but within the constraints of standard mashup toolkits and policy environments.

Spontaneous-but-governed user-centric identity mashups are already here. Look at any MySpace site, with its mashed-up these-are-my-friends aggregated-profiles pages. The governance there is simply the ability of the attribute-owning/asserting parties (your friends) to deny you or anybody else in MySpace from viewing and/or auto-publishing/aggregating that info on your own MySpace pages.

There should be a standards-based mechanism for enabling a identity mashup governance in Web 2.0 environments. Ideally, federated blogging and social-networking communities should provide the means for users to be prevented from mashing up each others’ personal profile attributes. One way to do this is for the federated blogsites/communities to implement the IGF specifications that Oracle developed and recently submitted to Liberty Alliance.

Under IGF, the attribute-relying parties (i.e., the people who wish to access and mashup other people’s personally identifiable identity attributes) would place Client Attribute Requirement Markup Language (CARML)-based requests for these attributes, and indicate desired operations and usage on these attributes. At the same time, the attribute-owning parties (i.e., the people whose personally identifiable identity attributes are available for third-party mashing) would declare Attribute Authority Policy Markup Language (AAPML) policies (essentially XACML 2.0 profiles) that specify conditions under which those attributes may be used by relying parties. An intermediary IGF “Identity Attribute Service” would enforce policies that govern access by CARML-requesting entities to attributes controlled by AAPML-declaring entities.

That IGF Identity Attribute Service would be the key run-time governance component in a user-centric identity-mashup environment. It will be interesting to see how Liberty Alliance mashes up IGF with the permission-based attribute sharing features of ID-WSF 2.0.

Jim