Efficient mass issuance

[sander]

Each one-time PID/QEAA needs to be sealed with a qualified electronic seal (or in theory, signature). This means applying a QSCD. While QSCDs support batch sealing, the total operation could still be expensive if we assume short-lived one-time attestations:

provider_seals_per_day =
  n_subscribers
* n_attestations_per_subscriber
* n_presentations_per_subscriber_per_day
* 24 / attestation_validity_in_hours

Instead of sealing each individual attestation data, the provider could periodically seal a Merkle tree containing the fresh attestation content data representations for all subscribers.

Since all attestations for all subscribers for this provider are mixed together, this approach still meets the RP-Unlinkability objective, since the seal does not provide extra information: the RP could only learn that two attestations were issued during a single time window by a single provider, which they could learn in the previous approach as well.

This change would impact:

• The attestation format, introducing a Merkle path as a sealed attribute
• The presentation protocol: instead of verifying the seal on the attestation data representation, the relying party uses the Merkle tree root hash and also verifies the Merkle path. This adds an algorithm that includes looping over the path nodes and computing hashes.

[sander]

Discussed 2024-06-03. @ve7jtb notes that with the Wallet Instance Attestations from ARF 1.4, we should consider these extra seals as well.

Also, due to the requirement to issue both SD-JWT and mdoc, we may need to multiply the amount by 2.

[sander]

To consider, not in this repo: could we use similar indirection to not seal the attributes, but a short-lived key that seals them? Could enable usage of algos that are not yet in QSCDs. I see no legal objections, but interesting security risks.