Currently our Anoncreds trait and anoncreds-rs implementation is hardcoded to take in prover_did instead of entropy. This is a legacy method - it's used in "indy" anoncreds exchanges, but modern anoncreds exchanges prefer entropy.
This is particularly problematic as anoncreds-rs enforces this a bit with some validation, e.g. "if using modern credential-definition-identifier (qualified), then entropy must be used instead of prover did".
However it may not be as simple as permanently switching to usage of entropy instead of prover_did, as "indy" anoncreds exchanges might be expecting the presence of prover_did...
This should be investigated and determine a suitable approach. Some ideas:
- choose
entropy vs prover_did on behalf of the consumer based on the type of identifier they provide (legacy or not)
- allow a config/flag to be passed in to choose between
entropy or prover_did - this way, protocols utilizing "indy" exchanges can opt-in to using prover_did.
related issue (see thread): openwallet-foundation/acapy#3369
Currently our
Anoncredstrait and anoncreds-rs implementation is hardcoded to take inprover_didinstead ofentropy. This is a legacy method - it's used in "indy" anoncreds exchanges, but modern anoncreds exchanges preferentropy.This is particularly problematic as anoncreds-rs enforces this a bit with some validation, e.g. "if using modern credential-definition-identifier (qualified), then entropy must be used instead of prover did".
However it may not be as simple as permanently switching to usage of
entropyinstead ofprover_did, as "indy" anoncreds exchanges might be expecting the presence ofprover_did...This should be investigated and determine a suitable approach. Some ideas:
entropyvsprover_didon behalf of the consumer based on the type of identifier they provide (legacy or not)entropyorprover_did- this way, protocols utilizing "indy" exchanges can opt-in to usingprover_did.related issue (see thread): openwallet-foundation/acapy#3369