PID Data Model alignment with ARF PID Rulebook v1.3 and CIR 2024/2977 #913
Conversation
…d PID mdoc example (ITA and EN)
… + Update PID vct transition strategy Introduce format-agnostic metadata attributes layer and map SD-JWT/mdoc-CBOR parameters to common semantic attributes. Update PID vct transition strategy for EUDIW operability. Add data types and improve documentation clarity.
fmarino-ipzs
requested review from
ghosteagle1,
giadas,
grausof and
peppelinux
There was a problem hiding this comment.
Pull request overview
This pull request aligns the Italian IT-Wallet PID data model with the ARF PID Rulebook v1.3 and Commission Implementing Regulation (CIR) 2024/2977, implementing significant structural changes to support EUDI Wallet interoperability.
Key Changes:
- Adds
x5cas a REQUIRED header parameter (replacingtrust_chain) per HAIP requirements - Restructures credential data model with format-agnostic and format-specific metadata attributes
- Introduces domestic extension namespaces for Italian-specific attributes (tax_id_code, verification)
- Aligns PID attribute naming with ARF specifications (birthdate vs birth_date across formats)
- Adds transitional phase support for national identifiers during pre-EUDIW operability
Reviewed changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| examples/vc-metadata-type.json | Simplified to minimal Type Metadata structure with only name and description |
| examples/qeaa-sd-jwt-example-*.json | Updated QEAA examples with new header format (x5c), status_list mechanism, and domestic vct identifier |
| examples/pid-sd-jwt-example-*.json | Updated PID examples with ARF-compliant structure, domestic extensions, and EUDI namespace |
| examples/pid-mdoc-cbor-example.txt | Restructured with EUDI namespaces, added domestic extension attributes in separate namespace |
| examples/pid-json-example-payload.json | Updated claim names (birthdate, place_of_birth) and structure alignment |
| examples/qeaa-json-example-payload.json | Updated with new status mechanism and domestic attributes |
| docs/it/credential-data-model.rst | Major restructuring: added format-agnostic attributes section, PID-specific data models, domestic extension documentation |
| docs/en/credential-data-model.rst | English version of the above restructuring with ARF alignment details |
| docs/it/test-plans-credential-issuer.rst | Updated test CI_136 to reference SD-JWT-VC Section 6.2 instead of internal table |
| docs/en/test-plans-credential-issuer.rst | English version of test plan update |
| docs/it/credential-issuer-metadata.rst | Removed OIDC-IDA references from trust_frameworks_supported and evidence_supported |
| docs/en/credential-issuer-metadata.rst | English version of metadata documentation cleanup |
| docs/common/standards.rst | Removed OIDC-IDA standard reference |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
| - [NSD]. OPTIONAL. The identifier of the subject of the Digital Credential, the User, MUST be opaque and MUST NOT correspond to any anagraphic data or be derived from the User's anagraphic data via pseudonymization. Additionally, it is required that two different Credential instances issued MUST NOT use the same ``sub`` value. | ||
| - OPTIONAL. *String*. The identifier of the subject of the Digital Credential, the User, MUST be opaque and MUST NOT correspond to any anagraphic data or be derived from the User's anagraphic data via pseudonymization. Additionally, it is required that two different Credentials issued MUST NOT use the same ``sub`` value. | ||
| - `[RFC7519, Section 4.1.2] <https://www.iana.org/go/rfc7519>`_. | ||
| * - **iat** |
There was a problem hiding this comment.
Is "iat" mapping with "issuance_date"? if yes, I suggest to add the mapping as done for the other attributes
There was a problem hiding this comment.
issuance_date typically refers to the administrative validity period, while iat refers to technical validity. They may be the same value, but this is not true in general.
docs/en/credential-data-model.rst
Outdated
|
|
||
| A non-normative Digital Credential metadata type is provided below. | ||
|
|
||
| .. literalinclude:: ../../examples/vc-metadata-type.json |
There was a problem hiding this comment.
The non-normative example contains only name and description, is it right?
There was a problem hiding this comment.
yes, we decided to remove most of the information originally put here to avoid information duplication (metadata, catalog, etc.) We keep type metadata optional, as per the sd-jwt-vc spec.
Co-authored-by: Giada Sciarretta <[email protected]>
Co-authored-by: Copilot <[email protected]>
…n-normative example
Align the PID data model with the ARF PID Rulebook v1.3 for both SD-JWT-VC and mdoc-CBOR formats, with support for domestic extensions.
x5cas REQUIRED header parameter (HAIP)This PR: