Closed docmanni closed 3 years ago
I think the issue is that verifier must assemble the presentation request itself -- the one from the proposal is not used automatically. as part of the request. That sounds like what you have found in the code.
We can dig further if needed, but please try that.
Thanks for your very fast help! This indeed worked. Does this mean that the API command .../{pres_ex_id}/send-request should not be used? If so, does that lead to a "dangling" proposal if the prover initiates the whole presentation process?
No -- that should be used. The proposal is used for two things:
In both cases, the verifier should send construct and send the request that it means to send -- it should not just pass on what the holder suggests. The holder may suggest asking for less information than the verifier needs -- or perhaps not ask for a revocation check. Basically -- the verifier should take into account what the holder says, but should still construct the request according to the verifier's needs.
Make sense?
Ok, now I understand! Again, many thanks for your help, much appreciated! I will close the thread as I consider it solved.
When trying out the v2.0 version of present-proof, I have successfully sent a proposal (/present-proof-2.0/send-proposal) as prover, and want to send a cred request on the verifier side by using present-proof-2.0/records/{pres_ex_id}/send-request. This throws an error in the agent of the verifier:
When looking at the code, I see that request_data is not being set when the chain of method calls starts at routes.py. Therefore, request_data is always "None". Has anyone else experienced this error? Or is the mistake on my side?