Anoncreds create credential

[jamshale]

When cheqd was attempting anoncreds issuance they were getting a entropy required error when using the anoncreds library to create the credential. After some research it looked like we should be using the entropy parameter, but were using the prover_did parameter. https://hyperledger.github.io/anoncreds-spec/#constructing-the-credential-request

I don't know why this works for an indy credential request and not the cheqd. Maybe something internally in the anocnreds library. But it looks like using the holder_did value in the entropy works and I tested with indy and cheqd and issuance succeeds.

Then noticed some indy parsing when storing the credential that shouldn't be in the anoncreds holder. I couldn't figure out why we would need these extra tags so I removed them. If we did need them then the parsing should go into the actual registry.

[swcurran]

Frustrating — sorry that got messy. The orginal AnonCreds implementation (in Indy) used “holder_did”, but semantically, that was wrong — the “did” had nothing to do with the operation. Clients were using the “DIDComm DID” of the relationship between the holder and issuer — but it was not checked and could be anything. We looked into the code, and it was determined that the purpose of the data was simply to add entropy into the operation. A very minor change, but not everyone got the memo, and all it does is create friction. Likely the best way to handle it is for the issuer to accept either, and pass it on to AnonCreds with what it expects. Painful - sorry about that. The “clarification” of the purpose does not make up for the interop problems this has caused.

[jamshale]

Need to look into failing tests... Thought I had tested this.

(edit) Seems to be some compatibility issues with indy issuer to anoncreds holder. I'll get back to this in a bit.

[jamshale]

I think we can ignore the sonarcloud report. Most of the duplication is because of the extension of the registry base class and there's not really much to cover with unit tests, and it's covered by the scenario test.

[gmulhearn]

FWIW, i also ran into compatibility issues when testing VCX against cheqd's acapy fork/branch. The issue was that VCX (using anoncreds-rs) was creating cred request attachments that had entropy instead of prover_did, but then the ACApy schema/model validation for the cred request was upset at this. My quick fix was to change the model from prover_did to entropy.

Looks like this is the more permanent fix - cheers!

question; is it still necessary to include both prover_did & entropy in the anoncreds cred request attachment model? Would it be too aggressive to make the assumption that if you're using the 0771 attachment format, you're abiding by the anoncreds spec, which i believe means you must be using entropy instead of prover_did?

Maybe that's too aggressive, as i don't think the anoncreds spec explicitly denies usage of prover_did, infact the cred request example uses prover_did: https://hyperledger.github.io/anoncreds-spec/#constructing-the-credential-request 👀. Should this be updated? @swcurran

[gmulhearn]

I don't know why this works for an indy credential request and not the cheqd. Maybe something internally in the anocnreds library. But it looks like using the holder_did value in the entropy works and I tested with indy and cheqd and issuance succeeds

yeah i ran into this too. here's the source where all the validation rules are applied: https://github.com/hyperledger/anoncreds-rs/blob/main/src/data_types/cred_request.rs#L27

different behaviours depending on whether or not the cred-def-id is qualified ("legacy") or not

[dbluhm]

These changes will get hit by the anoncreds scenario, right?

[jamshale]

Yes. The anocnreds scenario test is testing askar/indy (issuer) --> askar-anoncreds (holder) and askar-anoncreds (issuer) --> askar/indy (holder). And the verifier scenario.

The anoncreds holder now uses entropy instead of prover_did, and the indy credx holder still uses prover_did.

The only issue would be an old version of an indy issuer, issuing to a new anoncreds holder. In this case it wouldn't know what to do with the entropy attribute.

[swcurran]

If it helps — the “prover_did” property that would come from an Indy request can be used as the value of “entropy” — they are the same value.

[swcurran]

Updated that last comment to be “prover_did” — not “holder_did”

[DaevMithran]

@jamshale we need to get_schema_info_by_id even in the presentation anoncreds handler to replace the indy parsing. Maybe we also need a get_credential_definition_info_by_id

[jamshale]

@jamshale we need to get_schema_info_by_id even in the presentation anoncreds handler to replace the indy parsing. Maybe we also need a get_credential_definition_info_by_id

👍 Ok. Thanks for pointing this out. I had tried to run through the presentation protocol as well with your branch but was having other issues so I never got through it. This looks like an obvious place to apply the method. Let me know if you see any others please.

[sonarqubecloud]

Quality Gate failed

Failed conditions
20.7% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[esune]

👍🏻