Send a problem report if a proof you approve/decline is not associated with a session any more
loneil opened this issue · 1 comments
Was discussing with Clecio about how the Wallet experience could handle when a user goes in manually and shares a proof that is no longer relevant to a VCAuthN session. Below could be one path, maybe we think of other ways of handling this?
This has been discussed a bit as an improvement that can maybe help for a better user experience in a wallet if you come back and pick an old proof that's not associated with your current login attempt.
So consider a case like this
- I go to a VCAuthN website and go to log in
- I get the proof come up in my wallet
- For any variety of reasons (I forget about it, get distracted, phone crashes, I close the app accidentally, whatever) I don't do anything with that proof
- I leave VCAuthN and come back later, or I leave it on the page and it times out, or I refresh manually
- I go and scan to log in again
- Again I go back (intentionally or accidentally close the app, anything)
- Now when I go back into the BC Wallet I have a multiple proofs, I don't really know which one to select so users can pick the (or one of the) old ones and approve that.
- Then it shares the proof but nothing happens in VCAuthN because that old proof is not tied to the session up on my screen.
The proof is still in a request state and so when sharing it verifies through ACA-Py and the webhook comes back to VCAuth.
The proof exch ID is looked up, no session ID is found.
So at that point VCAuth could (we think) problem report on that.
The wallet doesn't handle the problem report at that point yet I think, but in the future could message that the proof was for an invalid login session or something so it doesn't just look like nothing is happening.
I think we will need #513 implemented first, as I am not sure using connection-less we would have the information on where to send the problem report to the mobile wallet. I might be wrong, in which case we could do this right away as it seems like a good pattern to follow - as long as the wallet doesn't break by receiving a problem report we could implement anytime.