Secure Area interface: support batch operations

[paulbastian]

Within eIDAS, the most prominent solution currently to achieve certain privacy goals (especially RP-RP unlinkability) is to support batch-issuance of one-time credentials. If you employ a Remote WSCD, sending multiple createKey function calls will create multiple network calls. Therefore the proposed solution is to add batch support, particularly to createKey, sign and delete.

[davidz25]

I can see how it'd be useful to batch-create a bunch of keys, for example SecureArea.createMultipleKeys(createKeySettings: List<CreateKeySettings>): List<KeyInfo> and also for deletion but I'm less convinced that batched operations like signing make sense?

[davidz25]

Some more thoughts:

• Don't know if you noticed but all methods on SecureArea are now suspending... so from a practical point of view, it might be a lot more natural and idiomatic for apps to use coroutine primitives instead of a new parallel batch API.. e.g. you want to create N keys, launch N coroutines in parallel, join all the results together.

• I think it actually might be more efficient to not bunch everything together in a single network call... for example, say I want to create 100 keys or sign with 100 different keys, you're saying bunch it all up in one message, send it to the Remote WSCD. But what if your Remote WSCD is highly distributed, wouldn't it be better to actually have 10 requests land on 10 different servers instead of a single server handling 100? Of course this could all happen under the hood of the implementation of the batch API but that sorta-kinda defeats the point.

• Also, if your protocol is relatively simple (single request->response shot) then I think things like HTTP pipelining might help and doing 100 requests right after each other wouldn't actually be a lot more work than doing just 1.

[paulbastian]

I can see how it'd be useful to batch-create a bunch of keys, for example SecureArea.createMultipleKeys(createKeySettings: List<CreateKeySettings>): List<KeyInfo> and also for deletion but I'm less convinced that batched operations like signing make sense?

It depends on the proof_type used in OpenID4VCI issuance:

• with jwt proof type and batch issuance, we actually need batched sign operation because of the PoPs needed
• with attestation proof type you are completely right 👍

[paulbastian]

Some more thoughts:

* Don't know if you noticed but all methods on SecureArea are now suspending... so from a practical point of view, it might be a lot more natural and idiomatic for apps to use coroutine primitives instead of a new parallel batch API.. e.g. you want to create N keys, launch N coroutines in parallel, join all the results together.

* I think it actually might be _more_ efficient to not bunch everything together in a single network call... for example, say I want to create 100 keys or sign with 100 different keys, you're saying bunch it all up in one message, send it to the Remote WSCD. But what if your Remote WSCD is highly distributed, wouldn't it be better to actually have 10 requests land on 10 different servers instead of a single server handling 100? Of course this could all happen under the hood of the implementation of the batch API but that sorta-kinda defeats the point.

* Also, if your protocol is relatively simple (single request->response shot) then I think things like HTTP pipelining might help and doing 100 requests right after each other wouldn't actually be a lot more work than doing just 1.

Thanks for your feedback!

I am wondering if it wouldn't be better to leave the decision of this to the Secure area implementation, because then it can make better decisions based on the fact it knows how many things are coming. And then it could still distribute those 100 requests on its own. For our current design of a Remote WSCD, it would be cheaper to avoid too many network calls.