Skip to content
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

Send a problem report if a proof you approve/decline is not associated with a session any more #579

Open
loneil opened this issue Jul 11, 2024 · 1 comment

Comments

@loneil
Copy link
Contributor

loneil commented Jul 11, 2024

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.

@esune
Copy link
Member

esune commented Jul 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Assignment Ready
Development

No branches or pull requests

2 participants