Integrate Multi-VC linking into OpenAC

[vplasencia]

Description

Integrate Multi-VC linking into OpenAC.
Enable proving relationships across credentials, such as shared attributes or identifiers, without revealing underlying values. Integrate the mechanism with generalized predicates and existing proof flows such as revocation.

[vplasencia]

Possible Solutions

1. Support multiple credentials directly in show
2. Add a preprocessing circuit per credential (same device)
3. Use recursion
4. Use folding

Performance and Implementation Considerations

• The current zkDSL used in OpenAC is Circom
• Proving time
• Memory (mobile)
• Proof size
• Complexity
  Monolithic: simplest
  Recursion / folding: significantly more complex

1. Support multiple credentials directly in show

Description

Since claim extraction and normalization are already performed in the JWT circuit, we can instantiate multiple JWT components (one per credential), collect all normalizedClaimValues, and pass them into an extended show circuit.

The show circuit is updated to:

• accept a larger, flattened claimValues[] array across all credentials
• allow predicates to reference claims across different credentials

Cross-credential predicates (e.g. attr_A == attr_B) are evaluated directly over this unified claim namespace.

Pros

• Simplest end-to-end proof model
• One proof, one verifier call, no proof composition
• Fits current architecture naturally
• JWT already outputs normalized claims and show already evaluates predicates over them
• Minimal engineering overhead
• No recursion, aggregation, or new proof system components required

Cons

• Poor scalability on the prover side
• Each additional credential adds a full JWT pipeline:
  • signature verification
  • payload parsing
  • claim extraction
  • normalization
• Circuit size grows linearly with number of credentials
• This leads to:
  • larger proving time
  • higher memory usage (important for mobile)
• Rigid circuit sizing
• Maximum number of credentials and claims must be fixed at compile time
  When it makes sense

When it makes sense

• the number of credentials is small
• mobile proving remains practical
• simplicity and fast prototyping are priorities

2. Add a preprocessing circuit per credential (same device)

Description

After the OpenAC Prepare phase, introduce a per-credential preprocessing circuit that performs signature verification and extraction of claims that will be used.

Each credential is processed separately, producing normalized claims that are then passed into a final show circuit, which evaluates cross-credential predicates over a unified claim namespace.

All components are still composed into a single proof generated on the client device.

Pros

• Cleaner modular design
  Separates credential verification from predicate evaluation
• Extensible
  Easier to support multiple credential formats
• Prepares for recursion or aggregation

Cons

• No reduction in proving cost
  Still one monolithic proof
• Scales poorly
  Each credential adds a full verification and extraction pipeline
• Fixed circuit size
  Number of credentials must be bounded at compile time

When it makes sense

• small number of credentials
• focus on clean architecture
• preliminary step towards proof composition

3. Use recursion

Description

Generate a separate proof per credential that verifies the JWT and outputs normalized claims.

Then construct an outer recursive circuit that:

• verifies all per-credential proofs
• aggregates their outputs
• evaluates the cross-credential predicates

This produces a single final proof.

Pros

• Scales well
  Credential verification is modular and not duplicated in one large circuit
• Small final circuit
  Outer proof only checks proofs + predicates
• Verifier simplicity
  Single proof to verify
• Flexible
  Supports dynamic number of credentials

Cons

• High implementation complexity
  Recursive verification is non-trivial in Circom
• Multiple proofs required
  Each credential still needs its own proof
• Prover overhead
  Total proving work is not eliminated, only structured

When it makes sense

• many credentials
• need a single proof output
• verifier simplicity is important
• long-term scalable architecture

4. Use folding

Description

Process each credential incrementally using a folding scheme.

Each step verifies one credential and updates an accumulated proof state that encodes:

• validity of all processed credentials
• extracted normalized claims

At the final step, the accumulated state is used to evaluate the cross-credential predicates and produce a single proof.

Pros

• Incremental proving
  Credentials can be processed one at a time
• No need for a large fixed circuit
  Avoids monolithic circuit over all credentials
• Produces a single proof

Cons

• Complex to design
  Requires custom folding-friendly circuit structure
• Less natural fit
  Cross-credential predicates require global access or careful accumulator design
• Not standard in current Circom workflows

When it makes sense

• incremental or streaming credential processing
• large or unbounded number of credentials
• research-oriented or advanced proving setups