Federated Authentication: Creating Identity over the Web

I'm fairly certain that most of you have received an email that peaked your interest about a new Web service or application. It might be something that your bank is offering or perhaps a way to track your physical fitness routine online. So you visit the site. And what's the first thing you're asked to do?

Create a unique user name and password.

Personally, the incentive must be pretty high to get me to do this. I'm already managing this kind of information for scores of different Web sites and services. Why must I do it yet again?

Well, you shouldn't have to. And times are changing fast. Very fast. And museums need to be aware of what's happening and prepare. Today.

If you're as old as I am, you remember when your bank made its first ATM available. You could withdraw cash from a machine placed outside the bank! Within a very short time, you found that you could withdraw cash from an ATM at any of your bank's branches. And before long, banks were establishing trusted networks so that you could withdraw cash from nearly any bank world wide. This is what is happening on the Web. Organizations are getting together, working out standards and establishing trusted relationships.

Before too long, you will have a single identity on the Web and will be recognized no matter what service you access.

The National Institutes of Health (NIH) is leading one such effort. Last fall, they held a "Federated Authentication" Town Hall meeting. Federated authentication allows staff to collaborate with colleagues from diverse universities and organizations across the world.

In simple terms, it works like this. John Doe from the NIH may wish to collaborate with Mary Buck at the Center for Disease Control (CDC). The NIH and the CDC have both joined a "trusted" network. That is, the NIH and the CDC have each agreed to trust the other organization to authenticate its own staff. This means that if Mary wants to access resources on John's network, John simply needs to let his network know which resources Mary is being given permission to access. When Mary tries to access those resources, John's network asks Mary's network to authenticate her. Once authenticated, John's network then opens up access to the permitted resources.

The key point is that Mary doesn't need a separate userid and password to access John's network. She uses her CDC credentials. The CDC authenticates her and the NIH gives her access to permitted resources.

This example illustrates the start of a very, very important trend.

Someday, you will always be connected to the resources that help you do your job and lead your life. Your mobile phone will likely be the device that facilitates this initially. You will need to move seamlessly from one network to another. You'll need access to the varied resources that exist on different networks. Each of these networks and resources will know who you are and what your preferences are. You'll have access to the tools you need to do your job and you'll have access to information that helps you manage your life. Looking for a restaurant in a strange city? The local networks will recognize you and your preferences. It will know where you're located and alert you to the location of your favorite eateries as well as a little cafe that your mother ate at last month...

Facilitating collaboration between research staff at two different museums or with a university is the start. For more information on one approach, please visit the InCommon Federation. If you're aware of similar collaborations in the museum community, please post a comment here!

Is there a divide between Web 2.0 and Web 3.0?

Fair-warning... this is a straw man topic. I began by making the overly-haughty provocation on a web 3.0 (I guess?) enabled space, "Before we, the self-appointed 'committee of the whole,' get too unwieldy in scope and participants to actually communally-generate useful, shared tools, can we establish a representative subcommittee who can recommend initiatives back to the group at large and potentially commit the resources of our respective institutions to a central pool?" In response, I was asked how I would recommend bridging Web 2.0 and Web 3.0 communities. Implicit in this question, I think, was the assumption that Web 3.0 community was a more appropriate sphere for cultural organizations (the "authorities") than Web 2.0 (everybody else, including authorities in mufti).

So, to attack the straw man. If Web 2.0 is defined as social/wiki websites on which users participate in generating site content and Web 3.0 is the semantic web, an interlinking of reliable, bot-filterable metatags (and their respective communities the authors/participants in said content generation), I'm not sure there's really a divide. To the extent that the semantic web is reliant on reliable, consistent metadata and shared taxonomies (I dislike the term 'ontology,' which seems like a malapropism to me), it would seem that the Web 2.0 is the place where these will begin to be built and continually tested. Having read Cory Doctorow's 2001 "Metacrap" article today, I think I have a more immediate understanding of the potential pitfalls of unguided folksonomy and unmoderated wiki (or vice-versa), but I likewise think that the types of techniques Luis Von Ahn has and continues to propose are one way around them [go here for more on Luis]. Furthermore, top-down metadata development like adherence to latin naming conventions, Dublin Core, and the kind of metadata entry required by SIRIS and the Library of Congress, which are already of use to the semantic web-building of academia (and by extension, lay researchers with "serious" purpose accessing collections), are likewise promoted through shared workspaces such as this and social networking environments (such as this, for those coming to this blog via my Facebook page).

We absolutely need fora for communities to gather and spitball/play out ideas. But that still leaves action to chance. It would be nice for the community itself to empower a subgroup itself responsive to and accountable back to the community that is capable capable of action. The empowering resources required are money (whether tithed or derived from third-party funding sources), server/storage access (the workshop for development and testing), and time (for example, via commitment of relevantly skilled staff to patronized projects). I'm assuming that the online community can serve as its own extranet regarding reporting requirements, publication (of white papers and/or code), and distribution.

Wuxtry! Wuxtry! Step right up and donate your money to build the semantic web!

I was coincidentally invited by Mark Baltzegar to join a social networking group called "Museum Futures" on the Twine betasite (www.twine.com) at the same time that Jim so generously offered me a forum here. On Twine, a would-be angel posted some provocative questions. Speaking as one who has worked in museums for a while (without speaking in an official capacity), I've tried to address these questions informally. I'm a lawyer, not a programmer, so I invite anyone to format and add to my response(s) as they see fit.

One of my most pressing concerns right now, as a funder, is in understanding better the technology capacity of the museum community. What skills are embedded in the museums themselves, v. their vendors?

My experience is that this varies from museum to museum, even within a larger complex like that of the Smithsonian Institution. Museums, like the communities of nonprofits and especially those of arts/cultural organizations which they inhabit, are chronically underfunded. I've seen different strategies adopted for dealing with this. Everyone needs a base infrastructure, whether begged, borrowed, or bought, and I've seen acquisition of enterprise-level CMS, DAM, e-mail, and ERP apps for IT staff to maintain and parcel out to the boots on the ground (and more often workaround apps which lack the same capacity to scale but which are easier/cheaper to use and support until the independent, redundant silos overwhelm).

For activity which has direct impact on research or public education on the web, I've seen two approaches. Some hire significant staff (with varying levels of HTML, Flash, KML, and other design and programming skills) in hopes of internally managing Museum work. This represents a significant and continuous commitment to web development, but has a few significant potential drawbacks: (1) it restricts concurrent development of multiple projects to the bandwidth that available human resources can accomplish; (2) it limits institutional knowledge and capacity to the capabilities of those willing to accept a $30-60K annual paycheck as supervised by those willing to accept $90K or less; and (3) it is at the mercy of often frequent attrition. Others throw money at ad hoc development projects as they succeed in soliciting funding. Given the golden rule ("S/he who has the gold…"), this likewise presents significant drawbacks, some of which include: (1) it can skew a museum's agenda by prioritizing development arbitrarily on the basis of that which can be successfully pitched or otherwise capture donors' (or development officer's) interests instead of as dictated by institutional mission or strategic goals; (2) it often limits the control and scope of development to the budget and cash flow secured for the project; and (3) it risks kudzu-like deployment of incomplete apps and functions in an environment where information-sharing throughout the museum is frequently less than perfect (ever try to harmonize the intent of education staff focused on primary-school outreach with curator-historian-academics with exhibition developers… not even considering the pressures imposed by administrative entities?).

Worse, from my 30,000 foot view, is the opportunity cost that is engendered the ongoing commitment of scarce museum resources on a piecemeal museum-by-museum basis. Were cultural organizations capable of sharing development, building upon, and improving a core toolset, all would be significantly more productive and better off, leveraging economies of scale not only on the costs of independent development but also saving funds which otherwise would be expended in one-off discrete online exhibition development. From this vantage point, projects like GMU's Omeka or the IMLS-funded Project Steve (www.omeka.org and www.steve.museum) are extremely welcome and need to be encouraged, promoted, and funded (hint, hint) inasmuch as they carry the potential to prevent museums from dropping between $50,000-125,000 on a URL silo site which while nice on its own, is ultimately incapable of growth. The irony of this is that in terms of outreach, these costs represent a small fraction of the investment inherent in traditional museum means of communication (physical exhibition development, traveling exhibits, audiovisual productions, and hard copy publication) while carrying the potential to reach much greater audiences. I am a staunch believer that museums get their greatest ROI (in terms of audience outreach) from their investment in new media/internet projects.

How are the skills distributed among institutions, by size, category, or any other salient dimension? Most of our work involves funding collaborations--we seldom fund a single institution to do anything--so I'm particularly interested in collaborative nexi or loci (present or nascent) for museums and technology.

Rather than waiting for a coalition to emerge for funding purposes (look to a temporarily derailed NOAA/NMNH Ocean Portal project as an example of good intentions that appear to have been groupthought -- among other factors -- into hopefully transitory submission), I think you're better off finding an initiative leader with a promising project, even (especially?) if self-nominated. The project funding should be split appropriately (not necessarily evenly) between the amount required for development and the amount required for promotion to and adoption by like organizations. Diffusion theory represents an area of significant academic and empirical study (see Everett M. Rogers "Diffusion of Innovations") as well as getting some recent lay attention (most notably via Malcolm Gladwell's "The Tipping Point"). According to Rogers, large-scale adoption is often dependent upon a leader who can provide a model for successful adoption, offer a reasonable or low barrier to entry, and provide a means for "reinvention" of the product to suit the specific needs of the adopter. This is a primary reason why I'm such an advocate (if nonetheless naïve) of joint tool development with broad application. The emphasis must be on broad, since museums (committees in and of themselves) act inherently modularly.

We're also committed to the sustainability of the projects that we build, so my definition of 'capacity' extends to include what museum leaders understand about designing, creating, and managing technology solutions. I know that most leaders don't understand the bits and bytes--no reason why they should. But do they understand how to plan strategically to maximize the ROI on their tech investments? Do they know how to structure organizational relationships within their institutions to produce the most gain and the least pain? Are they prepared to consider innovative business models around technology, such as "community source" solutions to shared problems, in order to reduce the risk and cost of technology development?

In my painful experience, these assets are extremely hard to come by and, when obtained, become more strained the longer that project development is stretched and the less that the sponsor organization has control over initial funding. In a vaccuum of funds, I have been a strong proponent of "funding" multimedia/software development projects by allowing the commercial developers who were ultimately responsible for production a reasonable opportunity to capitalize commercially on the tools they had developed. Let the museums guinea pig/form the impetus for development of the use of these tools and provide the model for successful deployment and let the commercial providers who capitalize risk reap equivalent reward. However, the longer and more complex the project "funded" in this way, the more frequently the model has failed (I'm being coy here, as I'm not quite ready to name names). The carrot of museums' prestigious imprimatur, incessant wheedling, and -- as a last resort -- threats of default are insufficient to guarantee successful outcome unless the developer(s) remain committed to bona fide execution of museum intent and a true spirit of partnership. All of which brings us back to the venal version of the golden rule, as expressed above.

However, if it is impossible to give a selected museum messiah the power of the purse, another way of giving museums some 'oomph' to put behind these types of "in-kind" deals would be shared physical possession and ongoing publicity. As a means of possession, consider an agreement which requires that fully-annotated code, tested and annotated by a mutually acceptable independent party, be placed in escrow or a copy provided to the museum at each major development milestone, with the museum free to divulge this information or make it available to any other developer upon material breach or protracted dispute. For publicity (yay, sunshine!), share everything with an open-source community under a strict gnu-license as it is being built. Invest in ongoing promotion (the cheap version of which is an e-mailed newsletter) to build a coalition of interested participants/adopters ready to alpha-test, beta-test, and ultimately use the product.

Cultural organizations are not about the apps themselves, as these are merely a means to the end of promulgating ideas: information of and about the collections, cultures, and the world we live in, and preserving same (collections, cultures, and the world we live in) for future generations. Museums' primary focus will (should?) always be on funding this activity first and foremost (well, after staying afloat that is). We crave external technology funders with the willingness, resources, and courage to help us develop the apps we're not even aware we need to succeed.

We also must find a way to stimulate meaningful sharing and codevelopment of these apps to save ourselves precious time and still more precious money.

Folksonomies, Taxonomies and User-centered Design

By their nature, blog postings are informal and personal. So why am I going to start this article with a series of definitions? As the writers of the American declaration of independence said "We hold these truths to be self-evident", I foresee that you will rapidly discern the reason for the definitions and the point I plan to make.

"Taxonomy is the practice and science of classification. Taxonomies are composed of taxonomic units or 'kinds of things' that are arranged frequently in a hierarchical structure..."

Wikipedia, March 26, 2008

"Folksonomy is the practice and method of collaboratively creating and managing tags to annotate and categorize content. In contrast to traditional subject indexing, metadata is not only generated by experts but also by creators and consumers of the content. Usually, freely chosen keywords are used instead of a controlled vocabulary."

Wikipedia, March 26, 2008

"User-centered design is a design philosophy and process in which the needs, wants and limitations of the end user of an interface or document are given extensive attention at each stage of the design process. The chief difference from other interface design philosophies is that user-centered design tries to optimize the user interface around how people can, want, or need to work, rather than forcing the users to change how they work to accommodate the system or function."

Wikipedia, March 26, 2008

If taxonomy has a citadel, then it is surely a museum. The term taxonomy was coined by naturalists in an effort to categorize and organize the Earth's diverse life forms and is now used by museums around the world to bring order and meaning to their collections. So one might expect a little resistance to the idea of folksonomies where visitors essentially create their own informal taxonomies for objects.

User-centered design principles ask that the needs of the ultimate "users" or consumers of a product be accounted for during the design phase. Museums have embraced this philosophy and incorporate user-centered design principles in the creation of exhibits and other interpretive materials. By the same token, museums should embrace folksonomies or user-tagging because it organizes the information in ways that the user or visitor understands.

We don't want to give up our controlled vocabularies or formal classification schemes but if we want to fully engage the visitor then we should embrace folksonomies and other developments coming out of the social media movement.

Retrieving Exchange Email on Your iPhone

I've had a number of people ask me how I managed to set up my iPhone to send and receive mail from my work account. My work uses Microsoft's exchange server to manage email. For security reasons, they don't allow folks to send mail unless they use either the official MS Web client or they're inside the firewall. They do, however, allow you to retrieve your email. This is the key that makes it possible to use your iPhone when you don't have official technical support.

You can set up a new account on your iPhone. For the incoming mail server, use your work settings. I prefer to use "IMAP" rather than "POP" because "IMAP" will synchronize with your exchange account and will also allow you to see any sub folders you may have created.

As for the outgoing mail server, you need to set up a free gmail account. Once that account is set up, you use the gmail outgoing or "SMTP" server. Gmail will allow you to set the "reply to" address to your work address, so to all appearances, when you send email, it comes from your work account.

I haven't included the details here, but this is the basic idea.

Good luck!

Web 2.0 & Brainstorming the Possibilities at CAM

On February 26, 2008 at the California Association of Museums annual conference in Fresno, California, I presented two sessions and promised to make the slides available here.

What's all the Buzz?
Using New Technologies to Educate and Increase Participation
Session Description
Slides (PDF, 26.6 MB)

Web 2.0: Brainstorming the Possibilities
Session Description
Slides (PDF, 6.7 MB)

I will be posting the results of the brainstorming session on this blog as I have the opportunity to write up the ideas. Stay tuned!

Jim Angus