Skip to end of metadata
Go to start of metadata
Governance is the term describing the ION capabilities of electronically tracking the relationships and commitments between the ION users, their agents and their resources. This knowledge is applied to enforce consistent system policy, track resource access and verify system interaction correctness.

Overview

Governance is primarily about independent actors in a system interacting to achieve their respective goals. Agents represent principals participating in the system (user, system operator) and execute their intents. We call the encoding of the principals' intents the "policy" of the agents. Once agents have reached an Agreement, a joint Contract is the result, comprising a set of commitments between the parties. If commitments are violated at some time during their validity, the violating party can be sanctioned. ION provides a framework, comprising Capability Container components, Agents and Services that realize this scenario. Figure 1 shows the main concepts around governance.

Figure 1. Governance: Negotiations between Agents (OV-1)

The figure below shows the protocol of negotiation between agents. See the negotiate protocol specification page for more details.

Figure 2. Negotiate protocol (OV-6)

See also:

The following sections provide an overview of the constituent components of the COI Governance Framework.

Capabilities

Commitment Monitoring

In a distributed message-based environment, the ability to monitor the ongoing messaging conversations between separate parties (or their agents) is essential to ensure policy enforcement and adherence to contracts (or commitments) made between communicating parties. A distributed monitoring ability is required as well as an ability to track each party's ability to fulfill their commitments or act accordingly. Figure 3 illustrates the proposed architecture design for implementing the aforementioned distributed monitoring capabilities.

See also:

Conversation Monitoring

In a distributed message-based environment, the ability to monitor the ongoing messaging conversations between separate parties (or their agents) is essential to ensure the validity of agreed upon conversation protocols between communicating parties. A distributed monitoring ability is required as well as an ability to track each party's ability to fulfill their conversation roles or act accordingly.

See Figure 3 for an integrated view on commitment and conversation monitoring.

See also:

Federated Facility Governance and Policy Management

Based on the conversation and commitment tracking capabilities, as well as Identity Management Services, the Governance Framework enables the definition of Orgs and the application of policy for Org members and resources. Policies are bound to resources of various kinds. The Policy/Governance and the Identity Management services are tightly coupled through the Exchange service to provide an efficient implementation of the policies.

See also:

Governance Implementation and Integration Strategy

The figure below shows how governance capabilities are placed within the COI Capability Container.

Figure 3. Candidate implementation strategy for implementing the Governance capabilities within the capability container.

Decomposition

Governance within ION is performed by applying policies bound to resources. To better illustrate the interaction between the Governance framework, consider the following scenario: a user issues a request for a service from a web browser.

Step 1: From the user browser to the Presentation Framework.

The user's web UI issues the request, which first hits the Presentation Framework (web server). Identity Management capabilities identify the security attributes of this request. At this point, the user may access the system anonymously, or as a registered user authenticated via CIlogon. At any given time, the user can self-register.

Step 2: From the Presentation Framework to the Service via the Service Gateway

The Presentation Framework forwards the request to the Service Gateway, which inspects the security headers of the message and creates a request message in the ION internal Common Message Format. This message is sent to the requested service.

The target service, deployed on a COI Capability Container is protected by a Policy Enforcement Point (PEP) interceptor. This interceptor may consult a Policy Decision Point (PDP) about how to respond to the event. The response typically involves exercising a capability (interacting with a resource), in which case the decision is to permit, deny, enable, or oblige the corresponding domain capability.

Figure 4. Policy Management and Governance Model (OV-2)

For example, we may setup a data stream to upload data from AUV A. The response typically also initiates or advances a Conversation. The policies read by the PDP may consult the status of the relevant conversations. For example, the network may be currently allocated to AUV B, thus causing the PDP to put AUV A on hold. All attributes necessary for enforcing a policy are created and managed by the Attribute Authority (see Figure 2). The requests to the PEP are usually expressed in the domain-dependent form, providing for domain-meaningful specification of Policies. The PDP, however is domain-independent and therefore expects the decision request in a canonical, domain-independent form. Translation from domain-dependent to domain-independent form, as well as collection and transformation of all necessary attributes, is provided by the Context Handler.

Services:

See also:

Governance Concepts

The figure below shows the internal dependencies of identity management, policy and governance mechanisms within the COI Governance Framework.

Figure 5. Architecture of an Agent Combining Identity and Governance (SV-1)

See also:

Behavior

Agents and Monitoring

This page describes a simple way in which we can relate an [agent] (applying a principal's policies) can be reconciled with the constraints (liabilities and privileges) imposed on it by an Org Role. We can imagine that there are two separate rules sets and one set of facts based on which an agent acts. One set of rules captures the policies of the agents and comes up actions that we can think of as the agent potentially attempting.  The second set of rules corresponds to the normative constraints to which the agent is subject, in light of its having adopted one or more Org Roles. The latter could be partitioned on a per-Role basis, if necessary. The idea with keeping the rule sets separate is simply for modularity. They could be realized within the same instance of the logic or rule engine that the agent uses for its decision making, and that engine may even be hosted as a service on the execution environment.

An Agent represents a principal in an Org as a locus of autonomy and identity. An Org Role is an abstraction of a participant in an Org and serves as a locus of normative constraints.

Figure 6. Agent Role architecture

The above figure illustrates a simple, what we term a pessimistic, approach for implementing an agent. Here the agent representing an application carries out its internal reasoning in whatever manner its designers deem appropriate. Examples of such methods include applying a rule or logic engine, applying a conventional procedural approach, or asking a user. Regardless, the application agent attempts to perform some additional action, either because it is proactive or because it is reactive and has received an external stimulus. All actions of the agent are mediated by a monitor, which we conceptualize as being part of the middleware on top of which the agent executes. The monitor is aware of the current state of the conversation as well as any other commitments to which the agent is party. The monitor is derived from the given Org Role and includes specifications of the privileges and liabilities that define the key components of an Org Role. The monitor applies its reasoning to determine if the attempted action may proceed. If it can, it does, thereby leading to a change in the state of the ongoing conversation. If the action may not proceed, it does not. In either case, the agent who attempted the action is notified accordingly. Notice that in the pessimistic approach, the agent may be aware of all key elements of the state of the ongoing conversations. However, the agent need not be aware of such facts and may not wish to reason about them. Here we can think of the monitor as residing at the level of the agent in conceptual terms and potentially below the agent in implementation terms.

In an alternative implementation, the agent is automatically allowed to perform any actions it attempts (assuming it has acquired any and all capabilities needed for that action). The monitor only just captures the changing state of the interactions, and applies its specifications of the privileges and liabilities to determine whether the agent is compliant. The monitor derives these specifications from the Org Role it represents. However, the monitor reports its results to the Org agent for the relevant Org, which might pursue sanctions on the noncomplying agent. Here we can think of the monitor as residing above the level of the agent in conceptual terms and potentially below the agent in implementation terms, because it needs to observe the actions of the agent, i.e., watch the message traffic to and from the agent.

Governance Activities and Interactions

Labels

read-coi read-coi Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.