Anoncreds create credential #3369
Conversation
|
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. |
|
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. |
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
jamshale
force-pushed
the
anoncreds-issuance
branch
from
ad1eecd
to
b60f20f
Compare
|
When
cheqdwas attempting anoncreds issuance they were getting aentropy requirederror 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 theprover_didparameter. https://hyperledger.github.io/anoncreds-spec/#constructing-the-credential-requestI 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.