Feature request: add callback when device response has completed about identity-credential HOT 2 CLOSED

Currently, there is no signal when the mdoc has completed transferring the device response.
In our implementations, a callback would be useful for performing an activity like terminating the session.

I have to check what the standard actually says but the general idea we've been working with in the ISO working group is that the mdoc reader might want to make multiple requests, in the same session. This is also why the standard has a session termination message which must be used (it's considered a bug if the mdoc or the mdoc reader just disconnects). In the case of just a single request it goes like this

1. device engagement
2. reader -> mdoc: SessionEstablishment which contains encrypted DeviceRequest (no status)
3. mdoc -> reader: SessionData which contains encrypted DeviceResponse (no status)
4. reader -> mdoc: SessionData which contains session termination (status 20), no data [1]
5. mdoc disconnects

Our reference reader app actually used to hang up after a single request but we changed that so it keeps the connection open and allows multiple requests ... this was mostly to check that our reference mdoc app worked well with multiple requests. We actually found during the test events that many mdoc apps just disconnects w/o session termination after having served a single request which of course is wrong...

That said, I can still see value in conveying to the mdoc when all data has been sent (or at least handed off to the OS, there still might be some buffering at lower levels we can't control)... so something like onDeviceResponseSent() makes sense... e.g. you may want to show a spinner and stop that spinner when the data has been sent. Maybe we'd even want progress reporting to fill up a status bar as the data is transferred [2].

Also, maybe instead of onDeviceResponseSent() we could have the user pass a callback (e.g. interface with a progress reporting method) to sendDeviceResponse()?

[1] : the standard also allows for a transport-specific way to terminate the session... right now only defined for BLE

[2] : although maybe progress callbacks would be overkill... I mean, after all we want data transfer to be fast. Might be nice anyway.

from identity-credential.

Yah, the spec as I recall was sort of vague on the point of which side should/can terminate, but certainly my intention is to send the termination message before disconnect, but leaving it up to implementation to override the default behaviour and send the "transport specific" termination if desired (which is supported in the library now). Either way, the idea is to make sure the current feature of allowing multiple serial requests in a session intact -- I did a smoke test of that with my branch and it does still work FWIW.

As for a progress callback...yah, I think it's a good point. I talked to a UX person I trust, and even if it's generally going to be a 1-2 second transfer (which seems somewhat typical with mDL required fields), they would want the option to present a progress indicator (it just makes things feel faster in their opinion). I also think the interface is a little better if we pass in a (nullable) progress listener to sendDeviceResponse() instead of adding another required callback method which may be unused by many implementations. On the other hand, implementing progress indication for all transports might be tricky / fiddly / hard to test. Lemme take a stab and see where it goes...

from identity-credential.