Specification

[rot256]

Specify the presentation protocol and formats for interop of (potentially) different implementations.

[chad11111]

hey this looks great, but I have some questions.

1. How does the system handle credential revocation? The current design doesn't seem to address scenarios where an issuer needs to revoke a credential due to compromised keys, changes in user status, or other reasons.

• Is there a mechanism for issuers to revoke credentials?
• How can verifiers check if a credential has been revoked without compromising privacy?

2. Does the use of a consistent owner public key across multiple credentials create a risk of correlation attacks?
   How resistant is the system to timing attacks or other side-channel attacks that might leak information about the hidden attributes? Are there scenarios where metadata could inadvertently reveal sensitive information?

[mitschabaude]

2. Does the use of a consistent owner public key across multiple credentials create a risk of correlation attacks?
How resistant is the system to timing attacks or other side-channel attacks that might leak information about the hidden attributes? Are there scenarios where metadata could inadvertently reveal sensitive information?

I can answer this one!

• The owner public key is not at all revealed when presenting a credential. It's only use is inside the zk proof, to make sure nobody except the owner is able to create that zk proof (because the proof verifies an owner signature)
  • Our system is designed to make presentations of the same credential unlinkable
• The security against timing attacks is the same as for general zk proofs using o1js, namely: Timing attack resistance was never seriously considered and engineered for, and so can't be expected to exist. (Personally I think this is fine, because a timing attack against client-side proof generation already implies that the client machine is compromised, and that would enable much easier attacks anyway)