You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am hoping someone can help clarify a few things for me.
If the holder a VC, issued by some issuer's keys resolvable using a custom documentLoader. And the holder creates a presentation of this VC and signs it against a challenge provided by the Verifier using the keys associated with the credentialSubject.
How is the Verifier supposed to verify these two different signatures?
The current README is misleading as the proof created by signing the challenge on the credential states the verification method is that of the issuer, which would not be the case in a real situation. See location here.
Currently, the only way I have found that works is running verify twice, once with the subject keys and once with the issuer keys. Which seems weird to me:
In addition to this, I am confused why the Verifier is passing in the suite's at all. These appear to provide access to public and private keys unless I am mistaken. Which clearly the verifier would not have.
I would have expected the verifier to resolve the appropriate keys required for this verification process by identifying the relevant ID's in the presentation object and using the documentLoader. Which in my mental model is acting as the resolver.
The document loader will be used to resolve the verification methods unless they are given in the suites. Allowing them to be passed via the suites enables them to be retrieved either out-of-band or pinned vs. going through the document loader.
As for why the suites are passed in (whether or not the verification methods are provided in them -- which, again, is optional), is to ensure that the verifier only specifies those suites (cryptographic methods) that they are willing to accept.
It's not surprising that users of this library can be confused by the multiple options and when to use them. The documentation around this should clearly be improved to reduce that confusion and ensure that the most common defaults are given in examples. Similarly, when you may choose to use the more advanced features (and what they do) should be similarly well documented but put under an advanced section of the README.
Hey,
I am hoping someone can help clarify a few things for me.
If the holder a VC, issued by some issuer's keys resolvable using a custom documentLoader. And the holder creates a presentation of this VC and signs it against a challenge provided by the Verifier using the keys associated with the credentialSubject.
How is the Verifier supposed to verify these two different signatures?
The current README is misleading as the proof created by signing the challenge on the credential states the verification method is that of the issuer, which would not be the case in a real situation. See location here.
Currently, the only way I have found that works is running verify twice, once with the subject keys and once with the issuer keys. Which seems weird to me:
In addition to this, I am confused why the Verifier is passing in the suite's at all. These appear to provide access to public and private keys unless I am mistaken. Which clearly the verifier would not have.
I would have expected the verifier to resolve the appropriate keys required for this verification process by identifying the relevant ID's in the presentation object and using the documentLoader. Which in my mental model is acting as the resolver.
Am I just missing something?
Note this appears related to issue #78
The text was updated successfully, but these errors were encountered: