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:
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
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
