Add RFC for zmix layout

Signed-off-by: Michael Lodder <[email protected]>

text/0002-zmix-api/README.md

@@ -0,0 +1,135 @@
+- Feature Name: Zmix project API and layout
+- Start Date: 2020-06-15
+- RFC PR:
+- Ursa Issue:
+- Version: 1
+
+# Summary
+[summary]: #summary
+
+Zmix aims to provide a common API that provide zero-knowledge proofs based on three distinct but not exclusive roles:
+
+- Issuer: any entity that issues credentials to holders. Issuers control what types of signatures to use, to whom they issue,
+criteria for issuance, credential validity periods, and revocation registries if desired.
+- Holder/Prover: any entity that manages credentials or secrets to prove to another party in zero-knowledge information about themselves or others
+- Verifier: any entity that checks zero-knowledge proofs and is convinced of their truthfulness or not.
+
+# Motivation
+[motivation]: #motivation
+
+Ursa is beginning to have many primitives that serve to construct a la carte zero-knowledge methods. 
+Unfortunately, there hasn't been a project plan until now for organizing and layering these primitives together.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+Zero-knowledge proofs can be divided into the following categories:
+
+- Predicates: prove knowledge about statements like inequalities, ranges, andd set memberships
+- Knowledge proofs: prove knowledge about statements like signatures and commitments.
+
+Knowledge proofs tend to center around using credentials like cryptographic signatures and proving knowledge of the signature
+instead of revealing it or knowledge of committed values. Signatures may be generated by third-parties (Issuers) or self-attested
+by the Provers themselves. Credentials are signatures over 1 or more attributes or claims. Attributes may or may not be disclosed
+in a proof but that is the extend of knowledge proofs.
+
+Predicate proofs tend to center around proving subsets of details about attributes or data in credentials without revealing the entire
+value. For example, revocation can be verified without revealing the credential identification number against a specific registry or
+the expiration date can be checked if the current date is less than the credentials validity period.
+
+## Issuers
+[issuers]: #issuers
+Issuers have the most complicated role due to the necessity of publishing signature verification keys to trusted oracles
+either under their control or another trusted party, managing to whom the credentials have been given, to be able to revoke them if incorrect data
+is signed or in the case of credential abuse or fraud. This RFC defines all functions needed by Issuers
+
+- GenerateKeys: Create digital signature keys
+- GenerateSign: Create a digital signature
+- GenerateBlindSign: Create a blind digital signature
+- RevokeSignature: Revoke a digital signature either for incorrect data or behavior
+- UpdateKeys: Change digital signature keys to new keys or nullify to revoke
+- GenerateRevocationRegistry: Create a revocation registry used for checking if a digital signature is currently vali
+- UpdateRevocationRegistry: Add or remove entries in a revocation registry or nullify to invalidate
+
+## Holders
+[holders]: #holders
+
+Holders are the most involved role in a zero-knowledge proof system. They hold data and prove statements about them to verifiers.
+Holders may receive credentials from other Issuers or self-attest data. This RFC defines all functions needed by Holders:
+
+- PrepareBlindSign: Prepare data to be signed blindly by an Issuer
+- UnblindSignature: Unblind a blind signature received from an Issuer
+- GenerateSPoK: Create a zero-knowledge proof for a signature
+- GeneratePoCV: Create a zero-knowledge proof of committed values
+- GeneratePredicate: Create a predicate proof
+
+## Verifiers
+[verifiers]: #verifiers
+
+Verifiers validate received proofs and signatures. This RFC defines all functions needed by Verifiers:
+
+- VerifySignature: Check if a signature is valid
+- VerifyProof: Verify a zero-knowledge proof: signature, commitment, and/or predicate.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+This is the technical portion of the RFC. Explain the design in sufficient
+detail that:
+
+- Its interaction with other features is clear.
+- It is reasonably clear how the feature would be implemented.
+- Corner cases are dissected by example.
+- Any new or altered interfaces should include pseudo-code.
+
+The section should return to the examples given in the previous section, and
+explain more fully how the detailed proposal makes those examples work.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we *not* do this?
+
+# Rationale and alternatives
+[alternatives]: #alternatives
+
+- Why is this design the best in the space of possible designs?
+- What other designs have been considered and what is the rationale for not
+  choosing them?
+- What is the impact of not doing this?
+- For incorporating new protocol implementations what other implementations
+  exist and why were they not selected?
+- For new protocols, what related protocols exist and why do the not satisfy
+  requirements?
+
+# Prior art
+[prior-art]: #prior-art
+
+Discuss prior art, both the good and the bad, in relation to this proposal.
+A few examples of what this can include are:
+
+- For other teams: What lessons can we learn from what other communities have
+  done here?
+- Papers: Are there any published papers or great posts that discuss this? If
+  you have some relevant papers to refer to, this can serve as a more detailed
+  theoretical background.
+
+This section is intended to encourage you as an author to think about the
+lessons from other distributed ledgers or cryptographic libraries and provide
+readers of your RFC with a fuller picture.  
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+- What parts of the design do you expect to resolve through the RFC process
+  before this gets merged?
+- What parts of the design do you expect to resolve through the implementation
+  of this feature before stabilization?
+- What related issues do you consider out of scope for this RFC that could be
+  addressed in the future independently of the solution that comes out of this
+  RFC?
+
+# Changelog
+[changelog]: #changelog
+
+- [10 Jan 2019] - v2 - a one-line summary of the changes in this version.