Checklist to finish specification

[swcurran]

We are getting close to finishing the specification. The work from @aritroCoder has gotten the "hard to do" things out of the way, now to get the text ready. Here is a checklist of the remaining items that I think need to be done to finish the specification:

• Fix the "Requirements" section -- seems to have some extra text in it.
• Add an example presentation that includes all types of data, including self-attested and unrevealed.
• A pass over the full text for clean up.
  • Incorporate revocation best practices from Aries RFCs #132
  • Minor: Define Abbreviations on First Use #54
  • Use anoncreds library models instead of ledger models #73
  • Should the specification require enforcement of the uniqueness of Schema name/ver and CredDef tag? #143
  • Ambiguity of "holder" makes the spec inconsistent #100
  • Clarify what is and is not verified by AnonCreds and what is the responsibility of the calling framework and application #145
  • Replace instances of prover_did and entropy from credential_request and have issuer generate it #149
• Finalize the [[def: ]] entries in the Terminology section.
• Finalize the [[ref: ]] entries to match up to the Terminology section.
• Remove the "Cryptography Protocols" section no longer needed -- it's now inline.
• Security considerations
• Privacy considerations
• References
• Acknowledgements and Author Addresses

OK -- not a short list, but not too bad either!

[swcurran]

Addition -- update the warning about weak issuer keys to cover the impacts based on conversation with Mike.

• anyone can detect that the keys are weak.
• The use of weak keys also results in the "sharing" of the private key, and hence the ability for others to issue the same credential as if they were the issuer.

Also, update the verification section to reference the "ge_proof" as "ne_proof" -- not equal.

[RieksJ]

I would not have closed #100 because in the issue itself, as well as the discussions, some points were made that I don't think have been adequately addressed. Also, I've noticed some other things that may need clarification. Here's a list of what I think are (potential) issues:

• the idea was to expressly state that 'holder' refers to IT (software), and that this would also be clarified for 'issuer' and 'verifier'. This remains to be done.
• an 'issuer identifier' would (then) identify an IT component with issuing functionality (similar for 'holder identifier' and 'verifier identifier', if they were to be used. Please consider that in a business setting, it is people (and organizations) that are interested in any data that has identifiers, and that they are typically not interested in the IT components that work for them, but in the parties that control them.
• one of the old issues I have with AnonCreds (and their ABC predecessors) is that credentials are bound to the link secret (implying the holder (IT component)), rather than to its subject. My colleague Oskar and I have played with an implementation (by others, using issuers that we did not control), and showed that we could get a gov't ID-credential for Oskar and a bank credential for me in the same holder. I haven't seen anything in the spec that enables verifiers to make sure that the subject of both credentials is in fact the same entity. I did see that the spec allows a holder to create a presentation that selectively discloses the name attributes of the 'oskar-credential' and the bank account attributes of the 'rieks-credential', then proves they come from credentials issued by the expected (and trusted) issuers and haven't been tampered with, and that credentials haven't been revoked. All this seems to be according to the spec. But it also shows that AnonCreds would be useless in practice.