ACDC Rules Section as Ricardian Contract

--- tags: ACDC, Rules, Ricardian Contract, KERI, email: sam@samuelsmith.org version: 1.00 --- # ACDC Rules Section as Ricardian Contract The rules section, field label, `r` may be used to impose a Ricardian contract that constrains the disclosure of information provided in the attributes section of an ACDC. This is a mechanism to achieve protect privacy via chain link confidentiality of correlatable information. ## References ### Ricardian Contract https://en.wikipedia.org/wiki/Ricardian_contract https://medium.com/ltonetwork/ricardian-contracts-legally-binding-agreements-on-the-blockchain-4c103f120707 https://101blockchains.com/ricardian-contracts/ https://iang.org/papers/ricardian_contract.html ### Chain Link Confidentiality https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2045818 ## Components How to provide a Ricardian Contract: - SAID on the Rules section satisfies the hash function identity requirement for Ricardian Contract - Using JSON provides a markup language compatible format that is machine readable and parsable (as would any of the serialization we support CBOR, MsgPACK, CESR and others such as YAML, MarkDown, HTML etc) - Issuer signature proof on the ACDC is also a signature proof on the embedded rules section so the included Ricardian contract is signed by the issuer. - A signature on the SAID of the ACDC is equivalent to the Ricardian Contract concept of *hidden signature*. Any later transactions or receipts such as presentation exchanges can sign the SAID of the ACDC or Schema . I think what is meant by *hidden signature* in the Ricardian terminology is that what is being signed is hidden by the hash not that the signature itself is hidden. This is similar to the meaning of *blind signature* where the signer is blind to the thing being signed. The contents being signed are blinded so the signer can't see them. So a hash is weak form of blinding the contents being signed. I believe they use the term hidden to indicate weak blinding via a hash instead of an invertable encryption which is the blinding mechanism in Chaumian blind signatures. - A digital signature or receipt by the holder during issuance makes it doubly signed by the issuer and holder. The issuer makes a Ricardian contract with the holder. - A digital signature or receipt by the holder during presentation to the verifier provides a double signature to the verifier. So the verifier is assured of the contract between issuer and holder. - A digital signature or receipt by the verifier back to the holder provides a digital signature by the verifier enabling a Ricardian contract between holder and verifier. Thus also making the ACDC triply signed. - A chained credential can be used to associate unique Ricardian contracts with each exchange or any future exchanges. ## Liability on Holder and Verifier The holder signature on the issuance exchange and the verifier signature on presentation exchange is important for any NDA, Waiver, Disclaimer proof back to the Issuer and Holder respectively for issuance and verification. This enables the Issuer to wither both impose liability on the holder and/or remove liability from the issuer at issuance. Likewise this enables the holder to impose liability on a verifier and/or remove liability from the holder at presentation. Typically an issuer wants the holder to sign a waiver of liability with respect to the issuer and the holder wants the verifier to sign a non-disclosure or limited consent such as chain link confidentiality with respect to the holder. The discussion below uses a presentation exchange as an example but the same logic applies to an issuance exchange but with a different pairing of parties. In the GLEIF vLEI the primary use case is the Issuance exchange that includes a liability disclaimer by the chain of issuers. ### Mechanism Discussion One way to do this is to include the actual legal language in the schema for the Rules section. This way the verifier can be presented with the schema as part of the presentation exchange and then sign the schema or SAID for the rules section as well as the SAID for the yet to be disclosed Attributes section. This allows the verifier to review and agree to the terms of the ACDC before the information in the attributes section has been disclosed to them. The legal language in the rules section includes the terms under which a signature by the verifier on the attributes said is valid. I.e. the attributes must be in accordance with the schema and the rules section must verify against the schema. This makes the schema for the rules section the NDA by virtue of specifying the exact field values in the scheme not just the field types. and then the ACDC itself is a disclosure in accordance with that NDA. In JSON Schema one can specify a `const` constraint on a value including a string that means that the actual rules section matches the `const` values in the rules section schema. A regex `pattern` for JSON schema can also specify an exact string as a value. That string itself could be JSON so the schema could specify that a given rules field have as its value a specific JSON serialization of the Ricardian Contract as JSON. Alternatively the schema could specify a `const` value that is the SAID of the Ricardian contract i.e. the rules section and then attach the rules section to the exchange message that is then receipted by the verifier. ### Simple Approach To elaborate, the simplest approach is to have the schema specify the exact value of the SAID field of the rules section and then attach the rules section or use a compact or hidden ACDC with the rules section included but the attributes section is hidden behind its SAID. In the presentation exchange the holder provides a compact or "hidden" ACDC where only the SAID of the attribute section is included in the ACDC but the rules section is provided either embedded in the ACDC or attached. Likewise the schema is either embedded or attached. When attached the ADCD includes the SAID of the appropriate section. The attributes section is not attached, it is hidden from the verifier but the SAID of the attributes section is provided in the ACDC. We can call this a 'hidden attribute' ACDC. #### Hidden Attribute ACDC The schema of the rules section specifies the exact SAID of the rules section and that rules section is provided to the verifier. The schema of the attributes section provides the exact format of the attributes in terms of fields but does not disclose the values of the attributes. The verifier can thereby read the rules section with the legalese and interpret it with respect to the attributes to be disclosed.. The verifier then signs (receipts) the compact or hidden attribute ACDC and returns the receipt to the holder. The holder now has a secure agreement to the terms in the rules section and may then disclose or un-hide the attributes via a response or exchange message. #### Nonce `n` field in Attributes Section To prevent a brute force attack on the hidden attributes section a nonce field must be added to the attributes section: Suggest `n` for nonce. The value of the `n` field is a 16 byte random string encoded as CESR salt. Thus knowing the SAID and schema of the hidden attributes does not allow the verifier to guess the values of the attributes. So we have privacy preserving signed consent disclosure of any ACDC that follows the Ricardian contract bow-tie model. (see references above) Said-ification just makes it easier to construct and reason about the transactions in any Ricardian contract attached to any ACDC via the 'r' section. ## Chain Link Liability The concept of chain link confidentiality can be generalized to `chain-link liability`. Contracts between two parties simultaneously both impose liability on a given party and release liability from a given party. These impositions/releases may be encoded as Ricardian contracts on any exchange of ACDC credentials between the two parties in that exchange using the `r` section. ACDC chaining provides a rigorous mechanism for linking multiple credentials so that new unique Ricardian contracts may be added at any exchange. So for example and vLEI may include a Ricardian contract release of liability on GLEIF with respect to the QVI on the QVI vLEI and similarly the a ricardian contract release of liability on the QVI with respect to the legal entity on the Legal Entity vLEI. The legal entity when it presents is vLEI or more likely an engagement role vLEI to a third party may want to create a custom ACDC that provenances its engagement role vLEI and has in its rules section a non-disclosure agreement to keep confidential the PII in the engagement role credential attributes section. Alternatively the original engagement role credential could have in its rules section language that specifies that any receipient of that credential who is not the Issuee must abide bye the confidentiality clauses the rules section. This obviates the need for a linked credential merely to include the confidentiality terms. Of course if generic confidentiality terms are inapproprate for a given recipient then a linked bespoke credential can alwasy be used. I feel an IIW presentation coming from this. ## Side Note Although not directly related to chain-link confidentiality, the website chain.link provides smart contract services consisting of on-chain and off-chain portions where the on-chain portions are cryptographic hashes of off-chain data. https://research.chain.link/whitepaper-v2.pdf What I found interesting is that KERI does this but without shared distributed ledgers. A KEL is the on-chain part the seal is the anchor to the off-chain data and SAIDs and AIDs provide the cryptographic identifiers But with KERI there is no need for a decentalized oracle network each KERI controller is their own oracle. Its already completely decentralized.