Tabella dei contenuti
FAQs
My voucher request is rejected
To identify the reason for the rejection, the quickest method is to use the Client Assertion Debug Tool, available in the front office under: Developers Tools → Client assertion debug.
What the tool checks
The system verifies that the entire authorization chain is active:
- active e-service version;
- active service request;
- active purpose;
- correct client;
- client associated with the active purpose;
- public key uploaded within the client;
- matching signature between public and private keys.
If the chain is valid, the tool then checks that:
- the client assertion contains only the allowed claims;
- the values of the claims are of the correct type.
Allowed claims in the client assertion
- Header: kid, alg, typ
- Payload: iss, sub, aud, jti, iat, exp, purposeId
- Optional: digest, containing two fields (alg, value)
Expected data types
| Field | Data type |
|---|---|
| kid, alg, typ, iss, sub, aud, jti, purposeId, digest.alg, digest.value | string |
| iat, exp | long integer |
A practical example of a client assertion is available in the dedicated tutorial [TODO] for voucher generation.
The nbffield is missing
Correct: the nbf field is defined in the standard but is not among the allowed claims and must not be included in the client assertion.
Where should I include new custom claims (producerId, consumerId, eserviceId, descriptorId)?
They do not need to be added by the consumer: PDND automatically includes them in the voucher issued to the consumer.
Is the digestfield mandatory?
No. In the context of a Bearer Token voucher, the digest field is optional and should be included only if required by the producer for a specific e-service.
How can I pass additional information (e.g., userId, userLocation, etc.)?
These pieces of information must not be inserted in the client assertion. They are additional data requested by certain producers and fall within the direct interaction between producer and consumer.
To transmit them:
- Create the second token required by AgID Audit REST 02;
- Include it in the request header to the producer with the key Agid-JWT-Tracking-Evidence;
- Compute the token’s hash using SHA256;
- Insert the resulting value in the digest field of the client assertion, for example:
1digest: {
2 alg: "SHA256",
3 value: "MY_HASH"
4}
5How to verify if the client assertion works
Use the debug tool: Developers Tools → Debug client assertion.
What does a voucher issued by PDND look like
The voucher structure depends on its type:
- Bearer Token (basic [TODO] or with additional information [TODO])
- DPoP (basic [TODO] or with additional information [TODO])
Each dedicated tutorial [TODO] shows the detailed format of the corresponding voucher.
Where to find more information
- In this technical manual, under the dedicated section on vouchers.
- In the technical webinar, which demonstrates the full process.
Next page → Delegations
Hai bisogno di aiuto?
Apri un ticket utilizzando l’apposita funzione all’interno della tua Area Riservata
