EUDI ARF mapping

OpenAC is positioned for compatibility with the European Digital Identity Architecture and Reference Framework (EUDI ARF). Rather than replacing any part of the ARF's Wallet Unit transaction, OpenAC adds a proof layer over existing issuer-signed credentials inside that transaction.

Reading order

1. Implementation profile §3–4 — system context diagrams and the trust boundary.
2. Paper application section (Paper) — appendix tables mapping Group A / B / C requirements to mechanisms.
3. In-repo LaTeX sources paper/eudi_application.tex, paper/actal_eudi.tex, paper/AC_and_EUDI.tex for detailed tables.
4. Annex A of the implementation profile — normative requirement-family mapping.

Where OpenAC fits in the ARF transaction

The ARF describes a presentation flow where a Relying Party Instance requests PID or attestations from a Wallet Unit. OpenAC is inserted into that transaction as the proof layer; it does not replace the transaction itself.

The surrounding ARF checks — relying-party authentication, user approval, issuer trust validation, status/revocation, device binding, and User binding — remain in place. OpenAC acceptance is a necessary but not sufficient condition for final relying-party acceptance. See ARF §6.6.3.5, §6.6.3.7, §6.6.3.8, §6.6.3.9.

ARF requirement-family coverage summary

The following table summarizes how each ARF / ETSI requirement family is handled by OpenAC. For the full normative treatment see Implementation profile — Annex A.

Requirement family	Handled by OpenAC?	Notes
Unlinkability and presentation privacy	✅ Core	Depends on Reblind discipline; transport and logging leakage remain outside the proof layer.
Selective disclosure	✅ Core	For issuer-authenticated values that pass through a supported credential binding.
Predicate proofs	✅ Core	For declared predicate classes; see Generalized predicates.
Supported credential families	✅ Core	Baseline: SD-JWT VC and ISO/IEC 18013-5 (mdoc).
Authenticated credential input	✅ Core	Only values identified by the credential binding may become OpenAC statement input.
Freshness and request binding	✅ Core	Response bound to verifier nonce/challenge and audience.
Device binding	⚠️ Conditional	Handled when included by the selected statement type; not inferred from User binding.
User binding	⚠️ Conditional	Handled when the credential binding and deployment rules support it.
Relying-party authentication	❌ External	Supplied by EUDI environment; OpenAC binds to request context only.
User approval	❌ External	Precondition to releasing the response; not an OpenAC-proven fact.
Issuer trust validation	❌ External	OpenAC proves over issuer-authenticated data; whether the issuer is trusted is decided outside the proof.
Revocation and status checks	❌ External (baseline)	Can be included via a declared status statement type; not in baseline OpenAC. See Revocation.
In-proof status representation	⚠️ Extension	Requires a declared status statement with defined proof relation and privacy analysis.
Issuer hiding	⚠️ Extension	Requires a declared issuer-hiding statement.
Pseudonym semantics	⚠️ Extension	Requires a declared pseudonym statement with scope, inputs, and linkability limits.
Cross-credential relations	⚠️ Extension	Requires declared relation statement with witness linking and composition rules.

Credential categories handled by ARF

ARF category	Role in OpenAC
PID (ARF §5.2.2)	External credential input; OpenAC does not redefine its format.
QEAA (ARF §5.2.3)	External attestation category.
PuB-EAA (ARF §5.2.4)	External attestation category.
EAA (ARF §5.2.5)	External attestation category.

Public ARF reference

• European Commission digital strategy hub: European Digital Identity Architecture and Reference Framework
• ARF 2.8.0 online: eudi.dev/2.8.0/architecture-and-reference-framework-main

Wallet perspective

Map ARF "wallet unit" expectations to the PoC layout in Wallet unit overview. The implementation profile §4.1–4.2 shows exactly how OpenAC is inserted into the ARF presentation context.