Re: Longfellow ZK (google-zk)

[Replies inline]

On Wed, Jul 2, 2025 at 4:05 PM Stephen Curran <swcurran@cloudcompass.ca>
wrote:

>
>    - If a circuit is defined as (for example) "mdoc, 2048, 5", can it be
>    used by a verifier based on any small enough input mdoc VC to prove any
>    arbitrary 5 attributes defined by the verifier/selected by the holder?
>
> Yes.  Today "prove" means "compare for equality".  If you have other
predicates in mind let's talk.

>
>    - If a circuit is defined as "mdoc, 2048, 5", can the verifier
>    request/the holder disclose *fewer* than 5 attributes, such that the
>    presentation is still verifiable?
>
> Yes.  Today you do it by disclosing the same attribute five times.
Basically the circuit compares ATTRIBUTE[i_j] = VALUE[j] for 0 <= j < 5,
and it doesn't care whether all i_j's are the same.  One technicality is
that today you must disclose at least one attribute, and you cannot
disclose 0 attributes.  That's easy to fix if needed.

That latter flexibility would be extremely useful in limiting the number of
> circuits that will need to be defined and shared.
>

Yes.  Ideally we'll have one circuit for all cases, or maybe one fast
circuit for <= 3 attributes and one slow circuit for <= 100 attributes, or
something.


>
> A second question is around the other useful/required ZK VC features,
> whether they are possible to add, and where they would be implemented -- in
> the code to process the circuits, or in the circuits?
>
>    - Pseudonymous identifiers
>
> Not implemented yet, but doable.  Our thinking is to say that
PSEUDONYM=SHA256(HID, RPID) where HID is a random nonce associated with the
holder and stored in the MDOC, and RPID is a nonce chosen by the relying
party.  The relying party chooses RPID as public input, the holder computes
PSEUDONYM as public input, and the circuit proves that the pseudonym is
correct hiding HID.  Many variations on this are possible, for example if
you want multiple pseudonyms (e.g. you want to have two amazon accounts one
for home and one for business).


>
>    - Revocation
>
> It seems to me, these would be like the handling of the signatures -- an
> agreed upon (opinionated) mechanisms to accomplish an agreed upon approach.
>

We have a few experimental schemes.  Our opinionated idea would work like
this.  Each holder has a unique revocation id, e.g. the public key of the
secure element.  The issuer has a list REVOKED[i] of M revoked ids, where
hopefully M << N and N is the total number of active MDOCs.  Assume that
REVOKED[i] is sorted in ascending order.
Then, ignoring boundary cases, the issuer signs the triples (VERSION,
REVOKED[i], REVOKED[i+1]) for all i.  Each triple (V, L, R) means that, at
time V, L and R are revoked, and no ids strictly between L and R are
revoked.  Every time VERSION changes, e.g. once a day, the holder downloads
the triple from the issuer that contains its revocation id.  The circuit
verifies the signature on the triple and proves that L < id < R.  This
costs say 50ms or so.  Many variations are possible, e.g. the issuer
partitions the space of revoked keys into ranges of up to 100 revoked ids,
and provides L, R, and REVOKED[i] for all L <= REVOKED[i] <= R.  Now the
circuit proves that L < id < R and that id != REVOKED[i] for all i.  This
is also straightforward.