|home||specifications||WIJIS URIs||gateway||CDCL||GJXDM example||warrants/po exchange||wijis articles|
A schematic of the landscape of the working parts of CDCL
Impact on Data Document "Containment"
Can anyone just appear on the scene and claim some sort of redaction authority over any ol' type of document or over any certain primary custodian's messages?
Answer: No. Doing so would raise the specter of denial of service attacks by some black hat-wearing prankster or enemy whose aim would be to include a policy that redacted all data all the time. Stakeholder Directories play a critical role here in allowing communities of stakeholders to govern community membership.
In addition to Stakeholder Directories, Rulesheet Repositories also have a role. On the Rulesheet Repository side, an author may be permitted to claim that a rulesheet is applicable to any chosen Problem Space and to any Primary Custodian. However, the legitimacy of claims will be defined and persisted in Stakeholder Directories.
For this discussion, it's important to remember that a document (a file of data) submitted for disclosure control to a CDCL Gatepoint is characterized by two pieces of metadata: the document's primary custodian and the document's "problem space", which is the type of document being exchanged between parties.
Problem Space versus Document Type
"Document type" can be an overloaded term. Therefore, within the discussion of CDCL, we try to avoid the term. Instead, documents utilize file types (structures) for information processing purposes, and documents represent problem spaces - or information exchange spaces - for business domain purposes. Any existing reference within CDCL documentation to "document type" shall mean "problem space" unless there is obvious context to the contrary.
A document has a single problem space, and this is synonymous with the business purpose or meaning of the document's existence, such as for the explicit exchange of information between parties. For example, a problem space can be "Wisconsin Incident Report IEPD". Often, the problem space can be represented by the document's schema, particularly for documents of XML file type.
For example, assume an author has been given the privilege to manage rulesheets for the fictitious Acme Accountants Inc., and assume the author created "rulesheet A". This author may claim that rulesheet A for stakeholder Acme Accountants Inc. governs disclosure over "Canadian Inter-Provincial Monetary Transfers" (this is the problem space) for both Quebec (a "primary custodian") and Ontario (a "primary custodian"). The rulesheet and this claim would be persisted in Rulesheet Repository 888. Yet, a Gatepoint, which conducts policy collation, evaluation, and enforcement, will reference Stakeholder Directories to determine legitimate claims of stakeholder interest for disclosure control. In our example, Gatepoint IceCube will reference Stakeholder Directory XYZ, and the response could be:
In summary, there are three points at which legitimacy is determined when collating all stakeholders' rulesheets during a Gatepoint's disclosure control event. They are:
The primary purpose of a Stakeholder Directory is to persist validated associations between parties claiming to have a stake in the disclosure of a given information exchange and to provide information pertaining to these associations to Gatepoints that query for same. A Stakeholder Directory is a system envisioned (not required) to behave like an X.500 or LDAP directory.
Validating Stakeholder Directory Entries
Creation of associations between a Primary Custodian and a claiming stakeholder or between a Problem Space and a claiming stakeholder is subject to business requirements that may differ from one stakeholder directory to another. This is internal to each directory, and no universal requirements exist other than that each directory administrator must publish for public view the rules by which primary custodians are registered, by which stakeholders are registered, and by which stakeholders' claims are deemed legitimate.
Conveying Authorizations of Rulesheet Authors
Each rulesheet author is identified by a URI that describes both the author and the Rulesheet Repository in which the author has account access for rulesheet management. The Stakeholder Directory sends authorization information via a message to Rulesheet Repositories, which are determined from the author URIs associated to each stakeholder. The association itself between the URI and the stakeholder represents the authorization. This authorization information sent to the Rulesheet Repositories shall be:
Responding to Gatepoint Queries
For more information, see this schematic of the landscape of the working parts of CDCL.
Composition of a Stakeholder Registry Entry
Concerning Data Documents
There is one and only one primary custodian for any document. Multiple primary custodians may not exist within a document. If multiple parties wish to claim joint custodianship, then those parties ought to form a joint entity, and this one joint entity may become the sole primary custodian of the document.
When a document is a mixture or conglomeration (i.e. a mash-up) of information from disparate primary custodians, the sole primary custodian of the document explicitly assumes primary custodianship & responsibility for disclosure of the information taken from the other parties.
One implication of this difference between Primary Custodians and Stakeholders is that documents do not contain other documents, from CDCL's standpoint.
As aforementioned, documents do not contain other documents. However, documents are not prohibited from being attached together whereby each document remains independent from the others and maintains its own primary custodian. For example, "document A" and "document B" are attached together in and comprise all the data for "information exchange E". The disclosure policy written by primary custodian A must exist in the rulesheet deck for redaction of document A, and likewise, the policy by primary custodian B must exist in the separate rulesheet deck for redaction of document B. This does not preclude the entity serving as primary custodian A from drafting a stakeholder disclosure policy, which might be included in the rulesheet deck for redaction of document B (and vice versa concerning entity B serving as stakeholder in the disclosure of document A).
In the hypothetical example above, how would a rulesheet author specify a dependence on the individual document and a dependence on the business information exchange in which the document is being passed? This can be viewed in two parts. For the first part: Within Stakeholder Directories and within the Rulesheet Repository, the author's rulesheet may be associated with a document's Problem Space (such as relevant to "A-like documents" or to "B-like documents"), subject to business validation by the stakeholder community. So, any rulesheet dependency on the individual document's Problem Space is handled via this association within the stakeholder directory every time the Gatepoint assembles the rulesheet deck. If the author has a further dependency on the fact that the document is being passed within the context of a specific information exchange, the rules are permitted to be defined with dependencies on the client context. The client context is all the information known by the Gatepoint's client, which is making this request for disclosure control. This client context is passed by the client to the Gatepoint in the transaction for disclosure control, and therefore, this information is available to be referenced from any rule. For example, this author's rulesheet may have a rule with a dependency on "information exchange E", which might be found in the client context.
From CDCL's standpoint, the ramification of this is that both "outcome inheritance" and "inter-outcome dependencies" (e.g. prohibiting line-item redaction) do not cross document boundaries, such as would otherwise have to be the case if CDCL respected the concept of document containment within other documents. So, in a containment model, an author would be permitted to write just a single rule governing disclosure of a document node that contains another document, and that contained document would inherit the applicable outcome. But since containment is not recognized and since there is no respect for relationships between documents, the author must consider drafting a separate policy for the other document. Remember that rulesheets may be associated to document Problem Space and/or to Primary Custodian at the rulesheet level. They shall not be associated to "information exchange" at this same level. Instead, as outlined above, dependencies on "information exchange" may be part of individual rule dependencies on client context.
Since inheritance and inter-outcome dependencies are only conveniences for defining elaborate outcome logic, there is actually no negative impact if allowing such when crossing document boundaries; containment does not necessarily violate respect for primary custodianship, in other words. However, a problem lies in the fact that policy may differ when an entity is acting as primary custodian versus acting as a stakeholder. In an environment that permits containment, there is no economical way (perhaps no reasonable way) to assemble the rulesheet deck such that entity A's primary custodian policy is enforced for only document A content and not for document B content. At the same time, there is no economical way (perhaps no reasonable way) to assemble the deck such that entity A's stakeholder policy is enforced for only document B content and not for document A content. Containment creates scenarios where entity A's primary custodian policy and its stakeholder policy, which may be contradictory or possess logical discrepancies when taken together, are enforced simultaneously on the same data. It is for this reason that containment (i.e. more than one primary custodian appearing within a document) is an unrecognized concept within CDCL and that document attachments as a concept is favored. However, this does not prohibit the entities engaged in an information exchange from moving forward with their own containment concept, but this necessitates that all the data in the resulting document is to be considered under the auspices of a single primary custodian.