Data Governance and Transparency: Solving the "Black Box" of Collaborative Access Control

TL;DR

In modern collaborative environments—from Google Docs to genetic databases—data rarely has a single owner. This paper introduces a sophisticated Data Governance Model that uses an Archetype Hierarchy to weigh the requirements of different stakeholders. It also breaks the "black box" of traditional authorization by introducing a Transparency Service that identifies and notifies users of "policy mismatches"—situations where their personal security preferences were overruled by the system.

Contextual Positioning

Within the security landscape, this work bridges the gap between Collaborative Access Control and IT Governance Transparency. It doesn't just propose a theoretical model; it provides a practical implementation path using the industry-standard XACML (eXtensible Access Control Markup Language), making it highly relevant for enterprise cloud architectures.

The Problem: The Single-Owner Fallacy

Most security protocols assume a "Owner-User" binary. In reality, a patient's medical record involves the patient (Data Subject), the hospital (Data Controller), and legal authorities (Regulatory Bodies). When these parties provide conflicting rules—for instance, a patient wanting to hide data that a doctor is legally required to see—traditional systems silently resolve the conflict. This lack of transparency erodes trust and discourages collaboration.

Methodology: The Archetype Hierarchy & Viewpoints

1. The Archetype Hierarchy

The authors define an Archetype Hierarchy ($H$) to organize stakeholders. Levels with the same authority are grouped, and inter-level priorities are defined as:

• Total ($t$): Higher level always wins.
• Positive ($+$): Higher level overrides only if it grants permission.
• Negative ($-$): Higher level overrides only if it denies access.

2. Identifying Mismatches via ViewPoints

To detect when a user's policy is ignored, the authors introduce the ViewPoint attribute. When a request is made:

1. The system calculates a Global Decision.
2. The Mismatch Handler reformulates the request for each individual user's "ViewPoint."
3. If the individual "ViewPoint" decision (e.g., Deny) differs from the Global Decision (e.g., Permit), a Policy Mismatch is recorded.

System Architecture

The implementation is integrated into SAFAX, a service-oriented authorization framework. By using a loosely coupled design, the transparency service can "wrap" either the PEP or the PDP.

Experiments & Results

The study evaluated the latency introduced by evaluating multiple "ViewPoints." Key findings include:

• PDP Deployment is Superior: Anchoring the transparency service at the Policy Decision Point is faster because it avoids the communication overhead of the Context Handler (CH) and PEP for every sub-request.
• Scalability: While evaluation time increases with the number of stakeholders (ViewPoints), the "Global Decision" is still delivered quickly. The mismatch analysis can be performed asynchronously (offline).

Critical Insight & Conclusion

The true value of this work lies in its philosophical shift: moving from "Security as a Wall" to "Security as a Transparent Process." By explicitly modeling different levels of authority through hierarchies, the system respects the complex legal and social reality of data sharing.

Limitations: The current model notifies users that a mismatch occurred but doesn't explain why (e.g., "Your policy was overridden by the Regulatory Body's legal compliance rule"). Future research into "Explainable Security" will be necessary to make these notifications truly actionable for non-technical users.

Takeaway: For developers of collaborative platforms, this paper provides a blueprint for building "Privacy with Awareness," ensuring that automated conflict resolution doesn't become a source of user distrust.