Group Collaboration MechanismsIn an open environment, any interested user may ask to join a collaboration. The traditional approach to joining a collaboration is to let a system administrator review a registration form and all qualification credentials of that user and then make an account for that user (or reject their application). This human-interactive one-way authentication is not suitable for dynamic and large-scale applications. If the applicants have questions about a group, more human intervention and delay will be introduced. OC uses the concept of automated trust negotiation to avoid this administrative overhead. ATN works as follows: an applicant sends a request to join a group to a group recruiter (which may actually be an agent, i.e. an a computer program running autonomously and without human input), and the group recruiter sends join requirements back to an applicant. The join requirements may include some attribute-based credentials (e.g. Age>18) and possibly other credentials, such as the electronic equivalent of identity or membership cards. After the applicant receives the requirements, they check their local policy pool to see where any required credentials are considered sensitive. If sensitive, they will have a release policy that protects this credential. In this case, the applicant sends back a counter-request indicating the requirements for releasing this credential. If the recruiter can satisfy the counter-request, the applicant will send the requested credentials. Once the recruiter receives and verifies those credentials, the applicant is issued a credential indicating that they are a member of the group. The entire procedure can be executed by the system automatically. In a specific OE application, a collaborative group may require that some services, e.g. public file sharing, should be open to everybody while other services, e.g. sensitive file sharing, should be open only to a qualified subset of users. In our approaches, we use role based trust management to control data access. When a user joins a group, they are automatically assigned a role, typically as a guest or junior member. If they want to obtain additional roles, they must repeat the application procedure again specifically for a desired role to get a role certificate. Different services may be protected by different policies, some of which ask the requester to present specific role certificates. When required, a user uses their role certificate to request these services, e.g. the downloading of certain files. Using a peer-to-peer approach removes the need for a centralized server. A "pure" P2P network does not have the notion of clients or servers, but only equal peer nodes that simultaneously function as both "clients" and "servers" with respect to the other nodes on the network. This model of network arrangement differs from the client-server model, where client communication is usually to and from a central server. Since in many situations in this domain each participant could be both a data provider and a data consumer (i.e., be both a server and a client), P2P meets the need of open health environment groups very well. P2P networks are also more efficient for data sharing and avoid the single point of failure problem since data are distributed among the peer nodes (if desired, with some level of redundancy). |
Figure 1: OC interface. |