Privacy with Hidden Attribute ACDCs (HACs) and Ricardian Contracts

--- tags: ACDC, TEL, Private, Hidden Attribute email: sam@samuelsmith.org version: 1.00 --- # Privacy with Hidden Attribute ACDCs (HACs) and Ricardian Contracts ## Hidden Attribute ACDC A *hidden attribute ACDC* MUST include a nonce field, `n`, in its attribute section, `a`. The nonce field value is pseudo-random number with a minimum length of 16 bytes for 128 bits of entropy i.e. cryptographic strength. The default format for the `n` field value is a 16 byte random number encoded as CESR salt string. The value of the attributes field, `a` of a *hidden attribute ACDC* MUST be the SAID of its attributes block. To clarify, the value of the `a` field (attributes section) MUST NOT include attributes themselves but only the SAID of the block of those attributes. This makes the attributes hidden. For short we call a *hidden attribute ACDC* a *HAC* for (Hidden Attribute Container or Credential). The fully populated block of attributes with its embedded SAID may be provided as a private attachment to an issuance or presentation exchange of its associated HAC. The rules , `r`, section of the HAC may impose confidentiality on any non-issuee recipient of the attributes block as identified by the attributes block SAID therefore discouraging any unapproved sharing of the hidden (private) attributes or any unapproved correlation to the block's SAID. To clarify, the SAID of the complete HAC is a self-referential digest whose digested contents include an attributes section given by field, `a`, and whose value is merely the SAID of the hidden attributes block not the hidden attribute fields and values themselves. ## Nonce `n` field in Attributes Section A pseudo random nonce field as part of the hidden attributes prevents a brute force dictionary style attack on the set of attributes as identified by their SAID. Without the nonce, given the SAID and the schema of the attributes and the issuee identifier, an attacker could brute force try all the values for the other attributes until it found a set that matched the SAID. But with the nonce, merely knowing the SAID and schema of the hidden attributes and the issuee identifier does not allow the verifier to mount a successful brute force attack. The entropy in the nonce is sufficient make such an attack infeasible. ### One-Time-Use HACs The nonce also makes a given issuance of an set of attributes unique and traceable to any recipient of that set. Any provable correlation is traceable correlation. An issuer could for example issue multiple one-time use HACs of the same attributes except for the nonce. The holder could then choose to use a unique copy with any given verifier. Later exposure of the HAC identifier would be unique to the copy. This also may make GDPR compliance easier because each use could include and erasure requirement. (see below on GDPR) - Side Note: provable correlation is not the same as statistical correlation. No technology I know of prevents statistical correlation this includes ZKPs. A ZKP may make provable correlation to a third party more difficult but any relying party may accept statistical correlation as sufficient to monetize the correlation. Indeed the vast majority of monetized correlation (by data aggregators) is merely statistical not provable. Only in some very narrow contexts is provable correlation important. But chain-link-confidentiality protects against statistical correlation because it imposes a liability cost on the correlator (aggregator). One way to make attributes traceable for statistical correlation is to add textual watermarks. This can be done with randomly placed white space, punctuation, and hyphenation in string values. This works best when the string values are longer. ## Privacy Preserving HAC Registry ### Privacy Preserving Attribute Disclosure As mentioned above, the SAID of the full hidden attribute ACDC is computed on an attributes field that only includes the SAID the attributes block not the attributes block itself. The SAID of the HAC makes a cryptographic commitment to the SAID of the attributes which in turn makes a cryptographic commitment to the attributes block itself consisting of fields and values. When provided with the actual attribute block itself a verifier may verify that the attributes are consistent with the SAIDs of the public ACDC. But without the attribute block a verifier has no knowledge of the attributes and cannot induce those values merely by examining the HAC itself or attempting a brute force attack to discover them. Moreover because the issuee (subject) identifier is included in the hidden attributes block as its `i` field, a HAC by itself does not provide any public correlation to the issuee of the HAC. Correlation to the issuee may only occur when the hidden attributes themselves are disclosed. The holder of the hidden attributes may make that disclosure in a confidential manner of its choosing. This does not mean that a recipient of a disclosure is technically prevented from publicizing that disclosure and the associated correlation between the HAC and the issuee. Control over further disclosure, however, may be constrained by imposing a confidentiality liability on any disclosure recipient. To elaborate, this construction means that any publication of the HAC by itself does not expose or disclose the hidden attributes including the identifier of the issuee but merely makes a cryptographic commitment to those attribute values. A holder of the actual attributes of the ACDC may choose to disclose those attributes to a given verifier. But that disclose may be performed via confidential communication between the holder and verifier. Moreover, an ACDC rules section may impose liability on the verifier who receives such a disclosure to maintain the confidentiality of the disclosure. A properly structured issuance or presentation exchange may impose a form of chain link confidentiality that provides privacy preserving signed limited consent of any future disclosure of the attributes of any HAC. The rules section on a HAC may be conceptualized as a Ricardian contract that follows the bow-tie model. ### Privacy Preserving Issuance and Revocation Registry A public KERI TEL (Transaction Event Log) controlled registry is a database that provides the issuance and revocation state for an Issuer of its issued HACs. The registry provides public visibility of the issuance/revocation state of any HAC listed in its registry. It does not provide any visibility to any of the attributes including the issuee attribute of its HACs. Thus merely examining the Issuance/Revocation Registry does not inform a third party as to the revocation status of a given HAC with regards to a specific issuee. The third party would first have to know the attributes to correlate a given issuance and revocation status to a given issuee. Because each registry entry is independent to a given HAC, an Issuer could populate its TEL with any number of fake HAC issuance/revocation registry entries and randomly change the issuance/revocation state of those entries. This provides a type of herd privacy for any third party correlators attempting to correlate behavior by an issuee or issuer with a given HACs revocation state. For example every issuance could be a batch issuance and every revocation a batch revocation with a fixed batch size. Batching provides group or herd privacy on the order of the batch size. If the number of real transactions is lower than a batch size then the appropriate number of fake transactions are added. An observer can only correlate a given behavior by an issuer or issuee to a given batch not to a given HAC. This is essentially what a cryptographic accumulator does but much more compactly. But cryptographic accumulators often require large amounts of computation and special crypto-libraries that are not commonly available or supported across operating systems and languages. ### GDPR Consideratons Additionally because each registry entry is independent to a given HAC, an issuer may delete a registry entry for a given HAC without impinging upon the state of any other HACs. A missing registry entry makes the HAC effectively revoked because its issuance can not be verified. This means that the only trace of the HAC left is the anchor digest in the KEL/TEL of the issuance and revocation events. After the fact a third party can not discover that the HAC ever existed, unless it keeps its own copy of the registry. Deletion of registry entries may be useful for compliance with GDPR right of erasure. Of course it depends on how broadly the definition of PII (personal identifiable information) in the context of GDPR is interpreted. Specifically to what extent is a cryptographic commitment (such as a hash) to PII also PII. Is erasure sufficient in the case where all that remains is a hash of a hash of a hash of PII (the latter two hashes and PII have been erased)? In general cryptographic commitments of all types including cryptographic accumulators provide the equivalent of a correlatable hash. Verifiable proof of a commitment to PII is a point of correlation. Anyone in possession of that proof may make provable correlation to that PII. In this case if someone is in possession of the hidden attributes and the HAC then they can use the SAID of the HAC to correlate to those attributes. If someone is not in possession of the hidden attributes then they cannot make provable correlation. Likewise given a chain of cryptographic commitments from head to tail with PII at the tail of the chain, if someone is not in possession of the full chain (i.e. one or more of the links are missing including the PII itself at the tail) they cannot make provable correlation from head commitment all the way to the PII at the tail. The longer the chain of commitments the more difficult the task to recreate it once any of the links have been deleted. Only someone who maintains the full chain is able to correlate. Often correlation only becomes valuable after the fact. A one time use credential makes that after the fact correlation very difficult. For example suppose the HAC hidden attributes include the name and address of a private individual. The HAC SAID is a hash that includes in its hashed contents the hash of the attributes that include the name and address. The name and address are not included in the HAC itself but must be provided separately by the holder of those attributes when presenting the HAC. The SAID of the HAC is included in the contents of the issuance and/or revocation transactions of that HAC on the HAC issuer's registry. The hash of those transactions is included in the KEL of the Issuer. An entry in the KEL makes a cryptographic committment to an entry in the Registry which makes a commitment to the HAC which makes a commitment to its hidden attributes (each commitment is a cryptographic hash (some are signed)). All but the entry in the KEL may be deleted or erased. The KEL itself may be deleted but than means all HACs issued by the identifier supported by that KEL must also be effectively revoked. Thus one way to ensure complete right of erasure would be use bespoke issuing identifiers for a given HAC and then hide those in a registry with fake HACs. (This is more verbose version of a cryptographic accumulator)