13.4. Authentic Source Endpoints

13.4.1. e-Service PDND Authentic Source Catalog

Public Authentic Sources MUST provide the following e-Service through PDND to provide the Credential Issuer with User's attributes required to the issuance of a Digital Credential.

Note

A complete OpenAPI Specification is available here.

13.4.1.1. Get Attribute Claims

Description	This e-Service provides the Credential Issuer with all attribute claims necessary for the issuance of a Digital Credential.
Provider	Authentic Source
Consumer	Credential Issuer

Note

The Authentic Source and the Credential Issuer MUST implement the necessary logic to keep track of the requests and responses exchanged via this e-Service, in order to be able to correlate them with the related issuance of a Digital Credential. In particular,

• both MUST save the jti value in the Agid-JWT-Signature payload of the request to manage Signals related to the deffered issuance of a Digital Credential (see Signals Processing);

• the Authentic Source MUST record the datetime value provided within the last_updated parameter, which indicates the last time the User's attributes were updated in the Authentic Source's database;

• the Credential Issuer MUST read the last_updated value received in the response to be able to check if the User's attributes have changed since the last issuance of a Digital Credential.

13.4.1.2. Example of Authentic Source response

The endpoint response MUST use the HTTP Content-Type set to application/json. Below is a concrete example with fictitious data to clarify the expected shape and content.

Listing 13.1 Example of the response JSON payload (Get Attribute Claims)

{
  "userClaims": {
    "given_name": "Mario",
    "family_name": "Rossi",
    "birth_date": "1980-01-10",
    "birth_place": "Roma",
    "tax_id_code": "TINIT-RSSMRA80A01H501Z",
    "personal_administrative_number": "12345A123A"
  },
  "attributeClaims": [
    {
      "object_id": "6F9619FF-8B86-D011-B42D-00C04FC964FF",
      "status": "VALID",
      "last_updated": "2025-09-15T10:30:00Z",
      "institute_name": "Nome Istituto Universitario",
      "programme_type_name": "Laurea Magistrale",
      "degree_course_name": "Computer Science - Informatica",
      "academic_qualification_date": "2025-06-25",
      "...": ""
    },
    {
      "object_id": "7A0720AB-9C97-E122-C53E-11D05FD075GG",
      "status": "VALID",
      "last_updated": "2023-01-10T08:00:00Z",
      "institute_name": "Nome Istituto Universitario",
      "programme_type_name": "Laurea Triennale",
      "degree_course_name": "Informatica",
      "academic_qualification_date": "2022-11-27",
      "...": ""
    }
  ],
  "metadataClaims": [
    {
      "object_id": "6F9619FF-8B86-D011-B42D-00C04FC964FF",
      "issuance_date": "2025-06-25"
    },
    {
      "object_id": "7A0720AB-9C97-E122-C53E-11D05FD075GG",
      "issuance_date": "2022-11-27"
    }
  ]
}

In summary:

• userClaims: user identity data (first name, family name, date/place of birth, tax id or personal administrative number). At least one of tax_id_code and personal_administrative_number is required when providing user claims.

• attributeClaims: array of datasets; each element MUST contain object_id, status (VALID | INVALID | SUSPENDED), last_updated (ISO 8601 format), plus any dataset-specific attributes (e.g. nationality, residence_address).

• metadataClaims: array of metadata per dataset (object_id required; issuance_date and expiry_date optional).

• interval: required when the request does not include a claims parameter; indicates the number of seconds to wait before repeating the request (e.g. 864000 = 10 days).

The successful response (HTTP 200) returns a CredentialClaimsResponse object formatted as a Payload JSON.

13.4.1.2.1. Signature Verification and Key Management

As the response token is signed, the Credential Issuer (Consumer) MUST verify the signature to ensure the integrity and authenticity of the data received from the Authentic Source.

The signature verification and key retrieval process MUST strictly follow the standard pattern defined for PDND e-Services. Please refer to the Technical Appendix (Section e-Service PDND) for details on JWT validation and specifications for retrieving the Provider's public key via the Interoperability API.

Warning

Alternative mechanisms for distributing cryptographic material (e.g., public .well-known endpoints directly exposed by the Authentic Source or out-of-band distribution) are not allowed. Trust management MUST remain centralized within the perimeter of the PDND infrastructure as described in the references cited above.