1 Conceptual Design of Obligation of Trust Protocol U. M. Mbanaso Informatics Research Institute (IRIS) School of Computing, Science and Engineering University of Salford, Salford, UK G.S.Cooper Informatics Research Institute (IRIS) School of Computing, Science and Engineering University of Salford, Salford, UK Abstract— This paper describes a conceptual design of Obligation of Trust Protocol (OoT), a bilateral symmetric approach to authorization, privacy protection and obligation enforcement in distributed transactions. We introduce the concept of the Obligation of Trust (OoT) protocol as a privacy enhancement and authorization mechanism that is built upon the popularized eXtensible Access Control Model Language (XACML) standard. The OoT allows two interacting parties to dynamically exchange their privacy and authorization requirements and capabilities, which we describe as a Notification of Obligation (NoB), as well as their assurances to fulfilling each other’s requirements, which we term Signed Acceptance of Obligations (SAO). We demonstrate some applicability of our design and show how they can be integrated into distributed access control systems for onerous privacy and confidentiality control. Access Control, Trust Negotiation, Privacy, Obligation of Trust Protocol I. INTRODUCTION The general principles and conceptual framework that underline preserving privacy and confidentiality in a distributed access control can be thoroughly examined and described, in the context of remote enforcement of privacy. To this extent, the basic concept is built upon the assumption that parties in distributed transactions have no means of enforcing obligating constraints placed on a remote party. In a traditional XACML model [1], an obligation is an action that should be performed by a Policy Enforcement Point (PEP) entity in conjunction with the enforcement of an access control decision. However, XACML describes an Obligation element as a set of attribute assignments, with an attribute FulFillOn which signifies whether the consuming PEP must fulfill the obligation if the access control decision is “Permit” or “Deny”. When a Policy Decision Point (PDP) evaluates a policy containing obligations, it returns the access control decision and a set of obligations back to the PEP [2]. However, in a distributed environment, we assume that the service PEP is unlikely to be in the same security domain as the client. The implication is that there is no guarantee that any obligations required by the client can either be incorporated into the policy used by the PDP, or even if they can, be enforced by the PEP. Given this, it makes sense to address the remote enforcement of obligations by allowing a service to convey back to the client an acceptance or rejection of their obligating constraints. The OoT protocol, is the concept that addresses this interaction. In this paper, the OoT protocol and its components are formally described. The encoding scheme and format describe the extension of a (Security Assertion Markup Language) SAML request-response protocol schema, and how the WS- XACML assertion fits into the framework [3, 4]. Two trust negotiation strategies are described, which define the order and sequences of messages exchanged between negotiating parties plus the algorithm that implements the strategies. Additionally, the binding of the OoT protocol within the web services security environments in the SOAP header is described. Finally, the algorithms for matching two XACML assertions based on OoT are described. II. THE FORMAL OOT PROTOCOL DEFINITION Obligation of Trust is a protocol that defines a standard mechanism enabling two or more communicating parties to exchange obligating constraints as well as proof of acceptance. The basic concept addresses the problem that a client currently has no means of enforcing obligations placed on a remote party. The protocol is divided into two steps: Notification of Obligation (NoB) (which may be signed or unsigned) and Signed Acceptance of Obligation (SAO) (which must be signed), and it is symmetrical. An initiating party sends a NoB outlining the obligating constraints it is placing on the other party, and the commitments it is willing to make if the other party accepts its obligations. The other party, after evaluation, sends back either a SAO of the constraints it accepts and the commitments it requires, or initiates more service negotiations with its own NoB, or rejects the request and terminates the session. Because the NoB and SAO are constructed using standard XACML policy constructs ( XML documents), both communicating parties have a common language for expressing their requirements and commitments, and are able to feed these constraints directly into an appropriate policy decision engine and ensure their ultimate enforcement by their respective obligations services. There are basically two ways the SAO can be constructed:  The SAO can contain digitally signed Requirements and Capabilities of a party, signifying that this providing party is willing and able to provide the signed Capabilities if and only if the relying party satisfies the Requirements.  Alternatively, the SAO can contain digitally signed Capabilities of the providing party and the Capabilities promised by the relying party. In this scheme, it indicates that the providing party agrees to release the Capabilities provided the