Open sander opened 1 month ago
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.
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:
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: