Threat model
Summarized from the in-repo paper draft paper/security.tex and aligned with integration guidance from Implementation profile §12.
Adversaries
- Malicious prover (holder) — may attempt to forge proofs or confuse verifiers; soundness should make success negligible.
- Semi-honest verifier — follows the protocol but tries to infer secrets from transcripts; zero-knowledge holds for hidden attributes.
- Trusted issuer at issuance — baseline issuance is trusted not to sign false claims or leak issuance-side PII beyond what issuance requires.
Malicious verifiers are out of scope in the quoted paper paragraph; authentication of verifier endpoints is not modeled within OpenAC. Relying-party authentication is supplied by the surrounding EUDI deployment environment.
OpenAC acceptance vs final relying-party acceptance
This is the most common threat model failure: confusing what OpenAC can assert with what is needed for access control.
OpenAC acceptance (what the proof establishes):
- The proof verifies.
- The response is bound to the verifier's request (nonce, audience, statement).
- The proven statement has the meaning defined by the applicable statement type.
Not established by OpenAC acceptance (require external checks):
| Claim | Why it is external |
|---|---|
| The issuer is trusted | Trust-list, LoTE, and certificate validation are outside the proof. |
| The credential is not revoked | No in-proof revocation in baseline OpenAC 0.1.0. |
| The user approved the release | User approval is a wallet precondition, not a proven fact. |
| The relying party was authorized | RP authentication infrastructure is outside OpenAC. |
| The credential is currently valid (time) | Validity period checking is external unless included in a declared statement. |
| Service access is permitted | Service policy is a deployment decision. |
See Implementation profile §1.3 and §10.
Binding and witness risks
A proof can verify while proving the wrong value. Main causes:
| Cause | Description |
|---|---|
| Unauthenticated fields in witness | Fields not covered by issuer authentication must not become statement input. The credential binding enforces this. |
| Wrong field selection | Ambiguous claim paths or name collisions can select the wrong disclosure. |
| Inconsistent normalization | If the wallet and verifier interpret the same field differently (encoding, byte order, date format), the predicate proves something the verifier did not intend. |
| Swapped witness indexes | Claim index 0 in a predicate must refer to the same field the verifier expects. |
| Metadata as statement material | Header fields, display metadata, wrapper metadata, and status fields must not enter the statement input. |
Prepared-state and refresh risks
Offline preparation can become a linkability or correctness bug:
| Risk | Consequence |
|---|---|
| Missing Reblind | Stable commitment reuse: two presentations share a linkable transcript component. |
| Unsafe pool fallback | Using a state that does not match the requested binding or statement. |
| State-selection correlation | Selecting prepared state based on externally observable criteria can leak which credential is in use. |
| Expired state use | A prepared state may have been derived from a credential whose validity has since lapsed. |
| Show not linked to the intended Prepare | The verifier checks Prepare/Show linkage; a mismatch is a rejection, not a validity error. |
Transcript and downgrade risks
A valid proof can be attached to the wrong transcript:
- Request or response substitution (nonce or audience replaced).
- Changed predicate parameters after witness construction.
- Changed attribute handles between the approved request and the proven statement.
- Replayed freshness from a prior session.
- Acceptance of a weaker statement than the verifier intended.
The verifier's pipeline must apply transcript binding and freshness checks before statement evaluation. See Integration patterns — verification pipeline.
Verifier overclaim
Verifier overclaim is a distinct semantic failure: the verifier concludes more from the proof than the statement semantics support.
| Overclaim | Correct interpretation |
|---|---|
| Predicate treated as disclosure | Predicate success reveals only the evaluation result (pass/fail), not the underlying claim value. |
| Device binding treated as User binding | A bound device key proves the response came from the device, not that the owner is the User. |
| Issuer signature treated as issuer trust | The issuer signing the credential does not mean the issuer is in your trust list for this credential type. |
| Proof validity treated as non-revocation | A valid proof does not check revocation status unless a revocation statement is explicitly included and declared. |
| OpenAC acceptance treated as service authorization | Proof-layer acceptance is necessary but not sufficient for access. |
| Multi-statement success implying undeclared relations | Passing two separate statement checks does not imply the two credentials describe the same person unless a cross-credential relation statement was proven. |
Operational tracking
Issuer visibility and registry models (flat issuer key vs Merkle of issuers) are discussed in the paper's security section — important when combining OpenAC with online revocation or registry lookups (Paper — security).
Collusion
Colluding verifiers may jointly analyze multiple transcripts. Unlinkability targets computational indistinguishability of joint views vs simulated independent sessions, conditioned on fresh Reblind before each Show. Transport metadata, session identifiers, status-check patterns, and trust-list lookups remain outside the proof layer and can still leak correlation. See Implementation profile §12.4.
External privacy risks
Proof-layer privacy does not remove:
- Network or session metadata (IP, timing, request frequency).
- Repeated request shapes that fingerprint credential types.
- Rare disclosed values that narrow the anonymity set.
- Status-list index lookups that correlate across presentations.
- Trust-list lookup leakage.
- Verifier mediation logs.
- Service-side policy fingerprints.
Implementation risks
- Randomness or side-channel failures in commitment generation.
- Serialization and canonical-encoding mismatches between wallet and verifier.
- Parameter mismatch between proving and verifying key sets.
- Unsafe extension parsing accepting undeclared statement types.
- Weak storage of prepared state or device private keys.
- Dependency bugs in Circom toolchain or WASM runtime.
- Mobile fallback behavior that degrades to weaker proof paths.