K-12 Middleware Primer
draft-nklingenstein-k12-primer-00.html
Version 1.0, August 24, 2001

By Nate Klingenstein
Internet2 Middleware Initiative

1. Executive Summary
2. Scenarios
Individual Access to Personal Academic Information
Class-wide Access to Sensitive Information
Anonymous but Authenticated Access
Increased Professional Development Opportunities
Project Collaboration
3. Basic Middleware Concepts
Identifiers
Authentication
Directories
Authorization
Beyond Core Middleware
4. Implementation Issues
Technology
Pedagogy
Policy
5. Opportunities
6. Acknowledgments

1. Executive Summary

Higher education, the research community, and government leaders are working together to foster the creation of a second layer of connectivity on top of the Internet to better network people, services, and information with each other. This set of tools, called middleware, consists of core components, such as directories and authentication services, and advanced tools, such as desktop video, collaboration environments, and distributed computing systems, built on those core components. Middleware presents remarkable opportunities for education and collaboration, as well as difficult policy issues.

Middleware is more about hiding technology from the user than showing it, performing important functions seamlessly and invisibly. With this transparency, new applications can be enabled through simple use of a powerful middleware groundwork, making both development and operation of new programs much easier. Unlike physical networks, middleware requires limited capitalization (though the policy issues can be time-consuming) and can offer some new economies for operation. The performance of middleware is relatively independent of the underlying network, making it viable for both sides of the Digital Divide. Students, parents, teachers, administrators, curriculum developers, and information service providers may all find significantly lower barriers to network use once middleware has been deployed.

There are many similarities and linkages between the groups that are driving middleware development and K-12. These groups have much in common. For example, interactions between members of autonomous communities, be they school districts or universities, are of great value. Enabling collaboration and educational tools is of critical importance. There is also a requirement to preserve individual privacy where appropriate. In addition, there is a shared desire for low cost, simple software and systems, and an open-source continuing development. Lastly, the traditional strong partnerships between higher ed and K-12 can be strengthened with middleware tools.

There are salient differences that must be noted as well. Privacy issues are much less clear in K-12 than in higher education. Relatively few schools or districts have enterprise middleware services. There are significant differences in approaches for management of technology. Even the computing platforms prevalent in K-12 are somewhat different from the ones in use in higher education and research.

The deployment of middleware technologies in K-12 will raise significant issues. Technical issues will include defining relevant data standards, developing "enterprise-wide" authentication services, and adapting the emergent middleware tools to the computing platforms in K-12. Policy issues will range from who can create "official" (or curricular or individual) data to who can view it. Perhaps the most challenging and inviting issues are in curriculum and pedagogy. Beyond the immediate opportunities of adapting existing curriculum to use these emergent tools lie the deeper issues of what new forms of curriculum, professional development, and learning can be created.

This primer presents some scenarios in which middleware can be used to enable new applications or greatly simplify existing ones. This is followed by a brief overview of the underlying technologies and infrastructure. The primer then begins a conversation about deployment issues, a topic that needs considerable discussion.

Work on middleware in higher ed began several years ago and has steadily gained momentum. Standards are being established and critical pieces of operational software will be deployed later this year. Over the next eighteen months, we anticipate a broad deployment of core middleware within higher education, development of upper level tools built on this core, and evaluation of costs and benefits. During this same period, we hope to begin extensive and effective discussions on middleware for K-12.

2. Scenarios

Middleware sits between the actual transmission of 1's and 0's and the application software such as email, browsers, and search tools that can use it. Ideally, it is transparent to users but provides new capabilities, security, and privacy. It should also be easily implemented by administrators, receiving data automatically from existing enterprise systems and permitting ease and economies of workstation management. Middleware has a broad range of potential uses in all communities, including K-12. If middleware is effectively in place, many things become much simpler. For example, controlled Internet resources which teachers are entitled to can be accessed with a local account. This removes the need for multiple passwords and the hassle and security difficulties associated with them.

Much of middleware is concerned with conveying and protecting the electronic profile of a person or an object. Identities, how they are established, and other characteristics about them (such as aliases, preferences, privacy tools, etc.) are parts of these electronic profiles. By placing these services within the network as part of an infrastructure, many useful applications can be enabled. The following scenarios provide examples of how these services may appear to students and teachers.

Scenario 1 - Classroom and School Publishing: Remote Authentication

As the Web emerged over the past decade, schools have made excellent use of it to make school publications (such as the local high school newspaper) available to the wider community and to students at other schools, and to maintain archives. Classroom teachers made good use of the Web to showcase the work of their students. However, schools began to recognize potential danger to students and consequent liability when student names and photographs, combined with information about how to find students at a specific school, was widely available. School districts are currently in the process of setting up elaborate guidelines to define if and how student names and photos can be used, with many opting to keep all personal information off the web site. Clearly the sense of community that school publications aim to foster gets greatly diminished as schools insist on anonymity to protect students from potential dangers.

Middleware services such as remote authentication will allow schools to safely resume the use of personal information (including photographs). In the past, print publications ensured that information had a limited circulation; in the future remote authentication will serve this same purpose. A high school newspaper might only be accessible to authenticated parties who are members of some well-defined community such as students, family members of students, or residents of the town.

Scenario 2 - Curriculum Resources: Controlled, Classwide Access

The Survivors of the Shoah Visual History Foundation (VHF) disseminates information, including multimedia and HDTV testimonies from Holocaust survivors, for tolerance education. Some of the materials have restrictions on their access set by those providing the testimony. These restrictions may restrict access to tolerance education instruction or to specific research activities. The lack of effective mechanisms to implement these restrictions greatly limits their use.

A teacher of ninth grade here at Averageburg High School wanted to be able to use multimedia in the curriculum to reach students more effectively. This can be very difficult and time-consuming. If he had wanted to show these videos from the VHF to his students, he might have had to order and store the tapes and pay for all the associated costs of materials. The IT staff here recently informed him of a new system they had set up, so he leads his class to the computer lab to try out the system. He had asked the VHF by email to set his class up to be able to use their materials. They replied with a URL for his class to visit, and no further configuration or validation was needed anywhere.

The class sits down and types in the URL and soon sees an impressive reference of literally hundreds of interviews. Some are marked as limited only for educational purposes, others for research alone, and others as being general access. Students are able to view any movie that intrigues them, both of the sort limited to education and the general purpose movies. A simple, short error page confronts them, however, when they try to access the research movies.

The magnitude of the event and the number of lives affected is much more apparent to the students when they can see the broad scope with their own eyes and navigate the whole archive securely themselves. The teacher asks the students to note certain movies that they found especially interesting.

After the class has explored these archives for a while, they return to the classroom. They are then able to watch some of these movies together, and the teacher discusses the interviewees' background and historical context. He can easily select the films by reference number, and he asks some of his students to note these reference numbers. Instead of asking his students to take notes throughout this process, he could let them absorb the feeling of the era and understand the stories more deeply.

The students are sent home with a brief writing assignment that asks them to draw on what they have learned, utilizing specific quotes from the films they saw. At home, or from a library or other public kiosk, the students can log on to the school's homepage. From here, they can follow a link from their class page back to the VHF site. This allows them to view the same videos they had seen at school. In fact, they could even demonstrate these films at community events or other schools.

Scenario 3 - Professional Development for Teachers: Authenticated Registration

Many schools, states, and districts have designed systems to help engage K-12 teachers with some of the recent research that scientists and historians are conducting. These classes are typically offered through local universities, professors, and researchers during the summer. Some teachers have professional development requirements and receive certification for successful completion. Middleware unlocks many new possibilities and offers great simplifications for this system.

A teacher can access her school's site to review the types of classes she needs to take. Once she finds a suitable university - which could be anywhere across the country - she can easily register online for the courses just by clicking. Relevant school and district information can be provided to the university automatically with appropriate middleware.

Curricula can be presented online in the form of web pages, slide shows, and streaming video, allowing easier dissemination of information, and enabling teachers to schedule their own time for lectures. These tools can be accessed through the teacher's high school account, removing the necessity to use a separate name and password to access the educational materials. At the end of the course, certification occurs digitally, eliminating the need for paperwork. The college will notify the teacher's high school that she has acceptably completed the course and will sign a digital diploma so that the high school will know for certain that the course was completed. The school's database would automatically update itself to reflect that the requirements have been met.

Scenario 4 - Guidance Counselors: Ease of Access to Personal Academic Information

A state university, through a state-wide K-12 initiative, has set up a system to permit guidance counselors to view their students' admission status at the university. These pages provide information on which application documents have been received and other application status information. In the past, such access required extensive paperwork between the counselors and the university and the assignment of university accounts and passwords to the counselors.

Now, using the newly implemented middleware, an authorized guidance counselor who wants to check on a student's application need only log in to the school's server. She can then visit a web site at the university and select which student records she wants to see. This automatically retrieves the most recent data on the student's pending admission and portfolio. She could do this securely and safely from any school computer or from another location if necessary. She need not even pre-register with the university; her role as a guidance counselor in the school's directory is sufficient to provide instant access control.

Students and parents can be optionally authorized to check on their own data through school computers or from home. This allows the students to know at a glance what admissions documents and materials have been received and what is still needed.

Scenario 5 - Anonymous Reporting: Anonymous but Authenticated Access

Schools across the country have been concerned about the nationwide escalation of tension and violence in classrooms. They believe this is the result of an increase in bullying. Attempts to encourage victims of bullying to seek help are usually ineffective since students are often afraid to speak out because they worry that the bully will find out and punish them for their efforts.

Middleware permits a school to design a simple computer system that would allow students to anonymously submit reports of bullying or other concerns. The system could be used from any lab computer or from home, and would return to the school truly anonymous submissions. To guard against fraud and malicious reporting, especially by people outside of the school, the system must be limited to members of the community. The middleware automatically ensures that submissions come only from members of the community, but also provides anonymity.

3. Basic Concepts in Middleware

There are several basic units and functions within middleware which together form a core. They offer a good idea of middleware's essential ingredients. Later definitions assume familiarity with terms and concepts introduced in the prior ones.

Identifiers

An identifier is a unique way of naming something. A social security number, a student number, and an email address can all be considered identifiers because they uniquely name a person. Similarly, a school's address, name and district, and registration number can all be identifiers for that school because they all can be traced back to that particular school. In middleware, identifiers can name anything in this way, including abstract concepts such as certain applications or a certain security clearance. The entity named by the identifier is known as its subject.

The issues in assigning appropriate identifiers to electronic objects are less technical than they are practical. For example, a full name may not be a proper identifier in some situations because there are multiple John Smiths in the world. Use of this identifier would make it difficult to know which John Smith is the subject, while a social security number is unambiguous. It is important for identifiers to be clear and unique, including means to be readily recognized either by computers or by humans. Each wants to be certain it is handing out information and privileges to the right John Smith, and wants an easy method of picking out the right John Smith's identifier. At the same time, if there is only one John Smith (and every other name in a school), then for applications only within the school, a full name is an acceptable identifier. The domain within which an identifier is unique is known as the identifier's scope. Examining who gave the object a particular identifier, known as the issuer of that identifier, also helps to reduce the confusion of having multiple John Smiths. A particular John Smith can be known as John Smith from Averageburg High School.

Most identifiers are absolute and will always refer to one particular entity. A person's social security number will not change, so this can be considered both unique to the domain of the USA and permanent. Not all identifiers are permanent, however, and some can be reused. Some schools recycle student numbers, for example, so the identifier "Student 512" might not always refer to Marcus Down and could actually refer to a new subject for a new term. This means that people relying on identifiers need to also be aware of the validity period for a given identifier, because sometimes identifiers have been reassigned to another subject. The recipient of an identifier who uses it to perform some function is generally known as the relying party.

There are also some cases where a user may be uniquely identified, but still anonymous. Identifiers that don't visibly correspond to a subject are known as opaque or pseudonymous, while ones that can be mapped back to entities are known as transparent. Opaque identifiers can be useful where the relying party doesn't need to know the specific identity of the subject and where greater privacy is desired. Identifiers can also be broader than individual subjects and refer uniquely to an entire set of people or things. This is acceptable as long as there is no other object in the same namespace using the same identifier.

Authentication

Authentication is the process by which a user or object proves it is the subject of an identifier. This service is generally performed by the middleware layer so that applications above it don't need to have their own mechanism. In current designs, authentication is most frequently accomplished by asking a user to input a username and a password, but many other approaches can be used. Although more secure approaches have been developed, these passwords are often transmitted through unprotected communication channels in common implementations today. The primary issues to be considered about any authentication system are those of how secure and how strong the authentication process is.

The quality of the authentication depends on the guarantee that can be given that the authentication process was not fraudulent. There are many factors that can affect the confidence that should be placed in an authentication. For a username/password system, a school may consider how the password is protected by users, whether the password is transmitted on an unsecured network, or how easy it would be to guess the password. Other schemes that remedy some common problems with password-based designs have difficulties which must also be understood. The general concern is to limit the chance of impersonation through better protection of the means of proof. For some authentication processes, the level of proof required to establish that a user corresponds properly to a subject is significantly more rigorous, such as passwords that can only be used once. Many new technologies for performing secure and trustworthy authentication with relative ease are in development. The important consideration for K-12 is ensuring that the strength of the authentication matches the security requirements of an application.

Directories

Merely having a valid identifier doesn't tell very much about a subject. While an authenticated identity may be sufficient for some purposes, it is often important to acquire more information, such as preferences, email aliases, electronic credentials, etc. Identifiers become far more powerful when they are combined with a technology known as directories. Along with many other uses, a directory links an identifier with other attributes about a common subject.

Directories are composed of many sets of information that all share a similar format. A set of information is generally called an entry, and a piece of information within a set is called an attribute. For example, a database of phone numbers and home addresses for every person at a school could be stored as a directory. In this design, each student or faculty member would be an entry in the directory, and ZIP codes and phone numbers would be attributes. Many other sorts of information could be collected in a directory, such as science project data, student writing, or school clubs. You could imagine this as a traditional table, although directories are not formed in precisely this manner; in fact, much of the power of a directory lies in its ability to store many other structures for information, such as trees and linked lists.

A primary function of any directory is looking up a given attribute from a given entry, such as one student's street address. To do this, there must be means of finding this field. This leads to the importance of having what is known as a directory schema. The schema describes the sequence of and names for the fields of all entries within the directory, which makes it easy to call up a field if you have the correct entry since the format for each entry is always the same.

The challenge then is finding the correct entry, and this is where identifiers can be effectively applied. Using identifiers as an index for the database allows a person or computer to easily select the right entry for that subject. Using this entry and schema, a teacher can then pull out the desired attribute. The process of using an identifier, or list of identifiers, to recall useful information from a directory is known as a query. A teacher could find out a student's email address by querying a directory using an identifier, such as a name or a student number. Alternatively, a teacher could be given permission to place a URL for class material in students' bookmark files, which can be stored in a directory, so students can find materials and their own personal bookmarks from wherever they're logged in. Another type of directory query could pull down the email addresses of all the students in a class. A large variety and amount of information about subjects can be stored in almost any format, but certain forms are more useful than others. Schema and identifiers must be wisely constructed to make for useful directories.

This need for appropriate design becomes much more important when directory queries begin to stretch institutional boundaries. If Averageburg High School has implemented a funky directory style, it would be very difficult for any other school to get the information it needed about Marcus Down. On the other hand, very powerful applications become possible if the directory structure is standardized. If Averageburg High School were storing information from a science project in a common directory format used by all schools participating in the project, it would be very easy for another school to share this data and use it with their own project. Similarly, if Averageburg High School stored information on students in a standard format, it would be easy for other schools to look up information about subjects. Typically, such standards describe the meaning of the information in an attribute and the format the attribute should take to be easily understood.

Because directories can make information readily available, care must be taken to ensure that sensitive or private information is adequately protected. Access controls refer to the mechanisms that protect entries and attributes in a directory. Access controls can be set to regulate who can read or update specific directory fields. These controls can be set to permit access to specific individuals named with an identifier, groups such as teachers or those enrolled in a certain class, or larger collections, including general access to everyone.

Authorization

Once authentication has been performed, it's often important to go back and retrieve more attributes about a subject before assigning permissions. The fact that the entity using Power Mac #19 is Marcus Down is often insufficient to judge privileges since it's usually important to know more information about Marcus and what he's allowed to do. This process of acquisition of information about Marcus and use of it to regulate what he can do is known as authorization. A directory can store these permissions directly and regulate precisely permissions such as viewing files or use of specific printers. The directory may also hold other attributes such as teacher or physics student which can then be used to decide permissions as well. When directory information is combined with the mapping of an entity to an identifier established in authentication, it is easy to fully describe the user of Power Mac #19, Marcus Down, and what Marcus is able to do.

Authorization has much in common with authentication. The two are often combined into a single step by using passwords to control access to web pages, but they are conceptually distinct and are better performed separately. Once authentication is performed during a keyboard session, then many authorizations can occur with a single cached authentication. This means that during one web browsing session, a user would only need to authenticate once to access many pages for which the user needs authorization. This also allows different applications to use the same authentication but make separate authorization decisions. Authorization checks do not typically involve any input from the authenticated user, since the system already knows that the user is the subject from the authentication and all the permissions of that subject. In current systems, however, authentication must be performed again with every new application, requiring multiple sign-ons in a single session.

Beyond Core Middleware

Almost all the scenarios described at the beginning of this primer could be enabled with core middleware deployments. More educational opportunities are discovered using upper middleware that is being developed to do such things as control remote instruments, invoke distributed computing environments, provide virtual meeting tools, etc. This upper middleware will be integrated with the core middleware, so that these sophisticated applications could be available to the K-12 community.

There are many other types of upper middleware which can also benefit K-12. Portals that allow customized interfaces to students, teachers, or parents can be built in a scalable form if crafted on top of core middleware. Learning Management Systems that provide online delivery of content and management of administration (including grading) are becoming more important. Desktop video, instant messaging, and calendaring are other tools that become interoperable and scalable with consistent core middleware.

4. Implementation Issues

Most of the challenge in middleware design for K-12 and higher ed alike is in the implementation of the system rather than in its theoretical design. Implementation issues emerge in terms of technology, curriculum and pedagogy, and policy, and some issues span all three areas. It is initially daunting to consider widespread, interoperable deployment for middleware. However, other important technologies, such as the Web and email, have had success in approaching broad implementation throughout K-12 and higher ed. Some schools, districts, or states will want to participate in the implementation and maintain their own servers. Others may prefer to outsource and allow a knowledgeable third party, such as a collaborative district or private enterprise, to create their systems.

Technology

Client software and enterprise middleware servers that provide authentication and directories are the two major technical components of a middleware implementation. There is relatively little that needs to be done on the client side since many functions of middleware can be performed by use of existing programs, such as web browsers and email clients. The server side must perform a whole host of new services, however, which each "enterprise" must provide somehow. The middleware system must also provide an effective and secure layer for communication between client and server.

The largest client-side technological challenge most schools will face in putting a middleware system in place is establishment of a comprehensive authentication system. This can be built around passwords, public keys, smart cards, or any number of other schemes, but it must be available on every machine that a user will want to use to authenticate to the central middleware server. This authentication should also be available to other applications so that a student or staff member need only authenticate once per session. It should also be assured that this authentication times out properly (when a user inadvertently leaves a machine without logging out) and is performed securely to prevent fraud, especially on generally accessed computers such as those in labs. LAN environments often provide this but seldom do so on an enterprise level.

In most higher ed implementations, there are many servers to handle the various services a middleware system must provide, such as a directory server, authentication server, and identity server. These functions also need to be provided by a K-12 implementation, and each school needs to assess where each of these functions will be handled. Some may be performed by the school itself, but others may be designed at a district-wide or even state-wide level. For a small, independent school, one server may be able to provide all the necessary services for the campus. Regardless of where these services are housed, a school must ensure that each is in place for a comprehensive middleware system to be effective.

Establishing effective and secure communication channels between clients and servers is another necessity for a middleware implementation. Many password-based systems currently transmit passwords as plain text, which allows any onlooker on the network to easily read and acquire the password. This can sometimes be addressed by transmitting data over an SSL or SSH connection that mitigates the danger of a man-in-the-middle attack for end-to-end communications. Attacks on communication can occur at other points of the transmission of proof from user to remote server, however; passwords may be recorded on the client using a keystroke recorder, for example. Other forms of proof are inherently less vulnerable to attack, but may not be applicable to K-12 environments. Administrators should still strive to ensure that authentication is reasonably secure.

Curriculum and Pedagogy

Curriculum and pedagogy refers to instructional goals, assessment methodology, materials used for instruction, the approach to teaching and learning that is implicit in the materials, and the human interactions supported by the environment. The availability of middleware opens the possibility of new approaches to curriculum and pedagogy, such as peer-to-peer secure sharing of information, collaborative projects of increasing detail, and those mentioned in the scenarios above.

New technologies have never quickly or easily found a place in schools, and it is not likely to be different for middleware. The process of curriculum development embodies the classic dilemma of how to achieve a self-sustaining level of use. For curriculum developers to be motivated to use middleware tools, they must be convinced that schools will have access to them; this is clearly true for those who work for publishers, but it is also true for those working in the grant-funded non-profits who are often more willing to try new approaches. Similarly, for schools to invest in these tools, they must be convinced that curriculum will be available that makes use of these tools and that these tools add significantly to teaching and learning. The same argument holds for professional development aimed at school administrators and teachers.

This means that one important consideration in introducing middleware for use in schools is to find a way to initiate a cycle of innovation. Perhaps the easiest way to imagine this - though not necessarily an easy solution - is to create middleware applications where the payoff is very high for schools. While we have identified many good uses of middleware in schools, we have not yet identified this kind of "breakthrough" application that might motivate widespread investment from both curriculum developers and schools. Developing one of the applications that power research in higher ed or elaborating one of the scenarios to be suitably compelling for K-12 will be extremely helpful to starting the process of mutual design around the new capabilities middleware offers.

Policy Level

Determining who has the authority to read or update information within a system is another key issue in a middleware implementation. This must be designed in terms of to whom the school will release which information and who within the school will provide authoritative information. While these restrictions can be implemented technologically, they must be explicitly decided and often written up as contracts or policies.

Stipulations should be imposed on how information is collected. The validity of the data in any directory is dependent on those who maintain the information. For some crucial information, such as identity or role within the school, this should only be entered by trusted persons; for other information, such as the results of science projects, it may be reasonable to let students supply information.

These constraints apply not only to entities outside of the school, but also to the school itself. Most administrators are familiar with the exemption of searches of students' personal effects from the Fourth Amendment. While this is usually applied to physical properties such as items stored in school lockers, it may also apply to digital information such as a student's bookmarks or email. Policies will likely vary from district to district and from state to state; what is important is for the policy to be clear and clearly stated.

5. Opportunities

Once a core middleware fabric has been constructed for a school, many other services become viable. For teachers, middleware can provide seamless calendaring and scheduling services. Portals can be created for the community to allow uniform information access for users to restricted databases. Middleware can also be used to operate videoconferences and manage video-on-demand services. It can be used to control remote scientific instruments and hold local science data in accessible modes. Privacy can automatically be set at appropriate levels.

The potential for inter-realm middleware services is exciting to higher ed because their business is collaboration. Over the next year, a number of new middleware services will be tested in higher ed to evaluate their potential. Many of the capabilities that motivate higher ed may also be of great value to K-12. Processes should start now to examine more deeply the issues in the design and implementation of middleware for our unique community.

6. Acknowledgments

The author extends his thanks to Alan Feldman of TERC, Louis Fox and Jacqueline Brown of the University of Washington, Ken Klingenstein of the University of Colorado and Internet2, and the MACE group of middleware architects chaired by Bob Morgan of the University of Washington.