...
- 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.
- 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 confirmed 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
- Expectation (to be confirmed by Belsy) is that:
- From Chat:
- Checkin: anoncreds-rs implementation progress, requests
- Open Discussion
...