Page Comparison

Summary

Excerpt
Revocation Registry List Data Model Validation of Identifiers - specification vs. implementation What is the "prover_did" data item? Checkin: anoncreds-rs implementation progress, requests Open Discussion

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

	Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct.

Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

...

Issue 108: Revocation Registry List Data Model
- This data model is sufficient for a holder to an AnonCreds implementation
- Within the AnonCreds implementation, the calculation of the witness must be derived from that.
Issue 111: Validation of Identifiers - specification vs. implementation
- Change the spec. to be MUST for a URI (which includes the legacy Indy format) and that validation is required.
Issue 107: What is the "prover_did" data item?
- Seems to be used in generating the credential, but is not used anywhere in the verification process – not shared beyond that
- Could be deprecated, with the issuer "creating" the value if not supplied
- Seems like it was an afterthought addition to the specification, that was not documented
- Second, related issue is the use of the nonce, and the fact that the nonce in the Cred Offer is different from the nonce in the Cred Request.
  - Expectation (to be checked) is that:
    - The Issuer created CredOfferNonce is used by the holder in the CredRequest correctness_proof and verified by the Issuer
    - The Holder created CredRequestNonce is used by the issuer in the Credential correctness_proof and verified by the Holder
Checkin: anoncreds-rs implementation progress, requests
Open Discussion

Issue 102: AnonCreds object signed by the key of the publisher
- Which is related to Issue 74: issuer_did and schema_issuer_did should be IDs?
Checkin: anoncreds-rs implementation progress, requests
Open Discussion

Backwards Compatibility
- PRs in (#82, #105) that seem to change public data structures – ones that are handled outside of AnonCreds and/or by two or more participants (issuer, holder, verifier)
- We want to retain compatibility with existing data – credentials that have been issued and the published AnonCreds objects on which they rely.
- That extends to business logic – e.g. the handling of the objects not just by AnonCreds, AnonCreds Methods and Aries Frameworks, but also by business applications built on Aries.
- Suggestion:
  - Include in the specification a statement about backward compatibility
    - Perhaps this is what Ankur had planned to do?
  - Formalize what data structures will be expected by AnonCreds
    - This is being done throughout the specification and verified against the current implementation.
  - As needed support sending and receiving data in "old" and "new" formats, but (for now) always sending "old" formats.
    - TBD if there are any such cases.
Ankur to add paragraph about philosophy of the AnonCreds API, styles
Review the Issuing and Presentation sections to exclude Legacy Indy impacts, and to formalize the Abstract API for writing/reading published objects
Cred Def Generation + PRIVATE_CRED_DEF -- non revocation, and plus revocation
Normative/Non-normative references
- Collect from documents mentioned below (under action items) and from previous meeting

...