Page Comparison

Summary

Recording of Call: 20221212 AnonCreds Specification Working Group Call Recording.mp4 dummyfile.txt

Notices: 

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

Meeting Attendees

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?
  • From Chat:

    • From Timo Glastra : We also use that (the holder's DIDComm peer DID for the connection) in AFJ

      • Note: Interesting to know what is used when there is a connection-less issuance.

    • From Rodolfo Miranda : For object identifiers I like this DID-Linked Resources Specification that was proposed by cheqd on ToIP Utility Foundry WG: https://wiki.trustoverip.org/display/HOME/DID-Linked+Resources+Specification

    • From Keith Kowal : So it sounds like Prover_DID=Holder DID. So this would be the pairwise DID - which might cause problems in some recovery scenarios...

    • From Timo Glastra : Seems like an issue to solve on top of AnonCreds, not in AnonCreds

    • From Steve McCown : +1 for Timo’s comment

    • From Timo Glastra : We could deprecate it. Problem is that for legacy indy anoncereds this will be a breaking change, while until now we've been able to avoid breaking changes in the exchanged data models. I.e. an old legacy implementation could still interact with a system that follows the ledger agnostic anoncreds spec, as long as they use the legacy identifiers

      • Idea would that it would be optional, and if the holder did not provide it, the issuer would generate something suitable to replace it.  That would work since it seems in the cryptography, it doesn't matter what it's value is anyway...

    • From Timo Glastra : One thing to note, the prover_did would need to be a did (legacy did) as ACA-Py validates the prover_did value to be an unqualified indy did. So it can't be just a string

       
  • 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 checkedconfirmed by Belsy) 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?

To Dos:

• Issue to be added and further investigation into what happens to the nonce(s) by Belsy.
• Updates to the spec. re: revocation data model, prover_did and nonces uses
• 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

...