(PuB/Q)EAA section to the IT-Wallet technical specifications according to ETSI TS 119 472-1

[peppelinux]

• Decide the new section (single RST/HTML page vs. inclusion within the credential model section).
• Add a short overview chapter (IT + EN) stating how QEAA and PuB-EAA fit the IT-Wallet ecosystem and pointing to TS 119 472-1.
• List in-scope credential formats for (PuB/Q)EAA in IT-Wallet (e.g. SD-JWT VC, mdoc-CBOR) and out-of-scope realizations unless later adopted (e.g. W3C VC JSON-LD, X.509-AC per TS 119 472-1).
• Cross-link the new section from architecture overview, onboarding, registry, and credential data model landing paragraphs.

2. Normative references and definitions

• Add ETSI TS 119 472-1 to docs/common/common_definitions.rst (and docs/common/standards.rst if applicable) with stable URI to the published deliverable.
• Add or confirm references to ETSI TS 119 471 (policy requirements for EAA providers) if the section covers provider obligations.
• Add ISO/IEC 23220-2 where non-mDL mdoc (PuB/Q)EAA types are in scope, alongside ISO/IEC 18013-5.
• Include Regulation (EU) 2024/1183 and Implementing Regulation (EU) 2024/2977 references are explicit where Annex V (QEAA) and Annex VII (PuB-EAA) contents are reflected in data elements or flows.
• Extend docs/*/defined-terms.rst (IT + EN) with glossary entries or pointers for QEAA, PuB-EAA, attestation identity code, technical vs administrative validity if not already sufficient.

3. Semantic profile (ETSI “EAA metadata” and Annex requirements)

• Document mandatory indication of category for QEAA (urn:etsi:esi:eaa:eu:qualified) and PuB-EAA (urn:etsi:esi:eaa:eu:pub) in each supported format, with mapping to claims / elements / namespaces.
• Specify issuer identification for MS and legal/natural person issuers (including registration identifiers per EN 319 412-1 where required) for both credential formats.
• Specify unique attestation identity (attestation identity code) and how it appears in SD-JWT VC and in mdoc.
• Clarify subject identification vs pseudonym (also_known_as / ETSI rules vs existing domestic sub and privacy rules).
• Cover technical validity vs administrative validity (validity of MSO/credential vs validity of attributes such as licence expiry).
• Document status / revocation obligations for QEAA and PuB-EAA when attestations are not short-lived (status service, TOKEN-STATUS-LIST / Bitstring Status List as applicable).
• Document optional or omitted features per format: EAA audience, one-time use, renewal service, attributes evidence—explicitly for mdoc vs ISO profile vs SD-JWT.
• State requirements for qualified electronic signature or seal on credentials and pointer to certificate location (e.g. x5u / download URL) where the TS or CIR mandates it.

4. SD-JWT VC profile for (PuB/Q)EAA

• Add a subsection that maps TS 119 472-1 SD-JWT VC realization (clause 5) to existing IT-Wallet SD-JWT VC rules (claims, type metadata, selective disclosure, _sd_alg).
• Check that QEAA/PuB-EAA-specific claims and vct / metadata conventions are listed and consistent with the catalog and issuance flows.
• Align issuer key distribution (e.g. x5c, federation kid) with TS expectations for certificate availability.

5. mdoc-CBOR profile for (PuB/Q)EAA

• Document namespace org.etsi.01947201.010101 data elements required by TS 119 472-1 (category, optional schema, iss_reg_id, also_known_as, oneTime, shortLived, status / status list integration, etc.) with MUST/MAY per QEAA and PuB-EAA.
• Document mDL vs non-mDL: org.iso.18013.5.1 vs org.iso.23220.1 data objects for non-mDL mdoc (PuB/Q)EAA.
• Resolve and document COSE issuerAuth headers: protected x5u and x5t (SHA-256) for QEAA/PuB-EAA vs current IT-Wallet x5chain in unprotected header—state normative precedence, profiles, or dual support.
• Align MSO status and shortLived with TS 119 472-1 and existing “long-lived > 24 h” IT-Wallet rule; remove ambiguity.
• If multi-subject attributes are excluded for (PuB/Q)EAA, state it; if allowed in future, document SubAttr structure from TS.
• Add precision rules for validFrom/validUntil (UTC, whole seconds, no fractions) if you adopt TS wording for interoperability tests.

6. Registry, catalog, and taxonomy

• Update credential catalog / taxonomy rules so (PuB/Q)EAA types declare legal classification (qeaa, pub-eaa) consistently with registry.rst patterns.
• Ensure schema registry entries support CBOR/JSON schema for new ETSI namespaces where needed.
• Add or adjust examples (non-normative) for a QEAA and a PuB-EAA per format.

7. Trust infrastructure and onboarding

• Tie (PuB/Q)EAA issuance to Trusted Lists (QTSP TSL for QEAA; LoTE for non-qualified / PuB-EAA where applicable) without contradicting the new credential section.
• Confirm National Trust Anchor and MS TLP narratives include pointer to the new (PuB/Q)EAA technical profile.

8. Presentation and wallet behaviour

• Reference OpenID4VP / HAIP constraints for presenting (PuB/Q)EAA in remote flows; reference ISO 18013-5 proximity where mdoc presentation applies.
• Add or update wallet verification steps: category URN, status checks, signature validation, issuer certificate path, time validity—per format.
• When ETSI TS 119 472-2 / 472-3 are adopted, add pointers from this section to presentation and issuance profiles (placeholder bullet if not yet stable).

9. Test specifications

• Add test cases (or extend existing plans) for QEAA and PuB-EAA issuance and presentation for each supported format.
• Include negative tests (wrong category URN, missing status when required, invalid COSE headers for MSO).
• Align conformance criteria with identifiers EAA-… / QEAA-… / PuB-EAA-… from TS 119 472-1 if traceability is required.