You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: