notes: research/papers/papers-acdc-affordances-confidential-data-protection

This data as json

path title type status classification words body
research/papers/papers-acdc-affordances-confidential-data-protection ACDC Affordances for Confidential (Sensitive) Data Protection and Management summary v0.1 — 2026-10-15: drafted by Claude from the markdown file in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only partner 550 # ACDC Affordances for Confidential (Sensitive) Data Protection and Management **Abstract.** A short working paper in Samuel M. Smith's Papers repository arguing that data shared over the internet should be managed under the established practices for confidential data rather than under the label of privacy, and that the graduated disclosure mechanisms of Authentic Chained Data Containers (ACDCs) support those practices. It sets out a three-party model of data sharing and ends with draft notes on bulk issuance. For readers working on data governance and credential design. ## Summary The paper opens by distinguishing "confidential" from "private" data. It argues that, for data shared over the internet, the difference is in name only, and that the established best practices for confidential, sensitive or classified data are more mature than newer practices for private data. In the author's view the word "private" carries an emotional appeal that implies a protection the data does not have, and some private-data disclosure mechanisms work against confidential-data best practice. It then sets out a three-party model. The first party is the source of the data, the second party the intended recipient, and a third party any recipient who was not intended. Once data reaches a second party, no technology by itself can restrict what that party does with it. The only protections are economic, legal and regulatory: non-disclosure agreements, regulations imposing a duty of loyalty on the recipient, the risk of enforcement, and loss of reputation. The model extends to downstream parties through chain-link confidentiality or chain-link data loyalty agreements, which make permitted downstream recipients effectively second parties. The paper says this framing exposes de-identification of shared data as a way of escaping those obligations. A section on best practices treats confidential data protection as risk management for both first and second parties, since leaks may come from mismanagement or from a breach, and some shared data may eventually be breached. The file ends with unfinished notes on bulk issuance: a sparse Merkle tree (SMT) of independently issued Autonomic Identifiers (AIDs) whose root serves as an internal account identifier, a protected service that answers membership queries, and blinded leaves so that a database breach does not reveal the AIDs without the blinding factor, which may itself be sharded or multiply encrypted. ## Key terms confidential data, private data, three-party model, first party, second party, third party, chain-link confidentiality, data loyalty, de-identification, bulk issuance, sparse Merkle tree ## Claims and their evidence - Once data is shared with a second party, no technology by itself can restrict that party's use of it; only economic, legal and regulatory mechanisms can. [informative] - For data shared over the internet, "private" and "confidential" differ in name only. [informative] - De-identification of shared first-party data can serve to release second parties from confidentiality obligations to the detriment of the first party. [informative] - Blinded leaves in a bulk-issuance SMT keep AIDs undiscoverable after a database breach without the blinding factor. [informative] ## Related ACDC specification (Trust over IP), Revocation (Papers repository), ACDC with Static Age Predicate Proof SMT (Papers repository). ## Provenance Drafted by Claude on 2026-10-15 from the markdown file `whitepapers/ACDCConfidentialDataManagement.md`, read in full (about 900 words; the document gives no author or date line, and the date used is the repository commit date, 2026-01-16). Not yet read by Mark.

Links from other tables