-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove DID validation from Issue Credential Request processing #2714
Comments
The error message is from here in the DidIndy method. In that case, perhaps the message and function should remain the same -- but should be removed in the place it is being checked. |
Error is here where the validation is "validate=INDY_DID_VALIDATE" and it shouldn't be -- it should be any string value. |
The anoncreds-rs library allows use of either a prover did or an "entropy" value. If you provide a prover did then it will validate it. If you provide "entropy" instead (pass our "prover did" as the "entropy") then we get a failure later on because we don't have "entropy" in out marshmallow models. I think we'll need to include both prover did and entropy in our models. |
We can provide both, but there is no need to verify that a “prover_did” is a DID. There is no requirement it be a DID — just bad naming by an implementer. |
If we do want to make a DID permissible, it needs to support any DID. |
For anoncreds, it makes sense to allow the holder to include either the All of the libraries (anoncreds-rs, credx and indy-sdk) allow I think for now we need to make sure that the anoncreds-rs I don't think is makes sense yet to start using the |
We need to support peer DIDs in general, which is where the issue arose. peer DIDs need to work with all libraries, so we need to be sure that the validation doesn’t break anything. Neither credx or indy-sdk support entropy. As long as the validation doesn’t affect any of the AnonCreds implementations, we’re good. I do think it is fine to get rid of any DID validation, since it is just a mistake that it is called that. |
Created issue hyperledger/anoncreds-rs#307 |
To remain backwards compatible the AnonCreds spec describes that entropy MAY only be used if a qualified identifier is used (then we're sure the implementation supports entropy as qualified identifiers came with the new anoncreds spec). If unqualified identifiers are used, prover_did should be used. I think indy_sdk did not verify the value of prover_did at all -- and so it's odd we do it in AnonCreds RS. That should be removed, yes |
Should be fixed now |
There is an issue with this currently failing integration test:
./run_bdd -t @T001-RFC0454-DID-PEER
. Resulting error is below.The issue is:
The "prover_did" coming from the Holder need not be a DID at all, and in fact, per the AnonCreds v1.0 specification what used to "prover_did" is now simply a string that is used for generating entropy (called "entropy"). In the original AnonCreds (Ursa) implementation, it was called
prover_did
, but there is no cryptographic checking of the validity of the DID, no use of the public key associated with the DID, and there is no reason for it, in fact, to be a DID. It definitely need not be an Indy DID.Thus, the verification that it is a DID must be removed. A string check could be made, I guess, if that makes sense.
Suggest the description be something like:
metadata={"description": "Prover DID/Random String/UUID", "example": "<insert UUID>"},
The text was updated successfully, but these errors were encountered: