small logo PRACTICAL ARCHITECTURAL APPROACH FOR COMPOSING EGOCENTRIC TRUST

subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link | subglobal1 link
subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link | subglobal2 link
subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link | subglobal3 link
subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link | subglobal4 link
subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link | subglobal5 link
subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link | subglobal6 link
subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link | subglobal7 link
subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link

The PACE Project

PACE Guiding Principles

An architectural style consists of a set of constraints and principles that describe what components and connectors are included in an architecture and how they interact. Similarly, PACE includes a set of constraints and principles that guide the construction of a trust-enabled peer architecture.

Using threats critical to decentralized systems as the basis, we have identified the following set of guiding principles that have been incorporated within the PACE architectural style -

1. Use digital identities - Without the ability to associate identity with published information, it is a challenge to develop meaningful trust relationships. The concept of identities, both physical and digital, are necessary to facilitate meaningful relationships. However, it is important to understand the limitations of digital identities in respect to physical identities. There may not be a one-to-one mapping between digital and physical identities as one person may utilize multiple digital identities or multiple people may share the same digital identity. Additionally, anonymous users may be present who resist digital identification. Therefore, it is not always possible to tie a digital identity to one physical individual and make accurate evaluations of a person. Instead, a critical criteria of trust relationships in decentralized applications should be the actions performed by digital identities not by physical identities. PACE, therefore, considers trust relationships only between digital identities.

2. Separate internal and external data - Reflection on our previous work in decentralized emergency response applications revealed the importance of modeling external data separately from internal data. This separation helps resolve conflicts between externally reported information and internal perceptions. For example, a peer may favor information it has perceived directly and believes to be accurate over reported information. A peer may also not want to disclose sensitive data, so it must have the privilege to report information which differs from what it actually believes. Explicit separation of internal from external data supports this, and is adopted by PACE.

3. Make trust explicit - Without a controlling authority that governs the trust process, peers require information to make decisions whether or not to trust what they perceive. Active collaboration between peers may provide enough knowledge for peers to reach their local decisions. In order to process this trust information internally across the entire architecture, trust cannot be localized to only one component. Each component responsible for making local decisions needs the ability to take advantage of this perceived trust. If the perceived trust is not visible, then accurate assessments may not be able to made. Therefore, PACE requires trust relationships to be visible to the components in the peer’s architecture as well as published externally to other peers.

4. Make trust comparable - Ideally, published trust values should be syntactically and semantically comparable - that is, equivalent representations in one implementation should have the same structure and meaning in another. If the same value has different meanings across implementations, then accurate comparisons across peers cannot be made. There has been no clear consensus as to which trust semantics provide the best fit for applications[Abdul-Rahman, 1997 #2346][Marsh, 1994 #2359], therefore it is believed that enforcing a constraint at the architectural level to use a particular trust semantic would be too imposing. While trust values should but are not required to be semantically comparable, PACE imposes a constraint that trust values must be syntactically comparable by enforcing that they be represented numerically.

5. Dependencies of Functionalities - There are four functionalities intrinsic to every peer: Communication, Information, Trust and Application. Communication handles the interaction with other peers in the system and is responsible for transmitting and receiving messages. Information is responsible for storing all data, including application and trust-related. Trust is responsible for computing trust values of receiving messages and peers in the system, and Application houses application-specific functionality.

Since the activity of data collection does not depend upon data storage or analysis, Communication is not dependent upon any other functionalities. Trust requires access to trust and application data and is therefore dependent upon Information. Application requires access not only to data but also requires the services provided by Trust and Communication. It is thus dependent upon Information, Trust and Communication.

6. Implicit trust of internal components - PACE assumes implicit trust of components that constitute the internal architecture except for components belonging to the Communication layer. This is because the Communication layer components are not responsible for validating messages received from other peers.


Internal Architecture in PACE

Home | Institute for Software Research | UC Irvine | Contact Us |
This material is based upon work supported by the National Science Foundation under Grant No. 0205724, 0438996, and 0524033. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.