Tabella dei contenuti
FAQ e dubbi comuni
La mia richiesta di voucher viene rifiutata
Per identificare la causa del rifiuto, il modo più rapido è utilizzare lo strumento di Debug Client Assertion, disponibile nel front office alla voce: Tool per lo sviluppo → Debug client assertion.
Cosa verifica lo strumento
Il sistema controlla che tutta la catena autorizzativa sia attiva:
- versione di e-service attiva;
- richiesta di fruizione attiva;
- finalità attiva;
- client corretto;
- client associato alla finalità attiva;
- chiave pubblica caricata all’interno del client;
- firma coerente tra chiave pubblica e privata.
Se la catena risulta valida, lo strumento verifica poi che:
- la client assertion contenga solo claim ammessi;
- i valori dei claim siano del tipo corretto.
Claim ammessi nella client assertion
- Header: kid, alg, typ
- Payload: iss, sub, aud, jti, iat, exp, purposeId
- Opzionale: digest, che contiene due valori (alg, value)
Tipi di dato previsti
| Campo | Tipo di dato |
|---|---|
| kid, alg, typ, iss, sub, aud, jti, purposeId, digest.alg, digest.value | stringa |
| iat, exp | long integer |
Un esempio pratico di client assertion è disponibile nel tutorial dedicato allo stacco del voucher.
Il campo nbfnon è presente
Corretto: il campo nbf è previsto dallo standard ma non è tra i claim ammessi e non va inserito nella client assertion.
Dove inserire i nuovi custom claim (producerId, consumerId, eserviceId, descriptorId)?
Non è il fruitore a doverli inserire: è PDND Interoperabilità a restituirli automaticamente nel voucher rilasciato al fruitore.
Il campo digestè obbligatorio?
No. Nel contesto di un voucher di tipo Bearer Token, il campo digest è opzionale e va inserito solo se richiesto dall’erogatore per uno specifico e-service.
Come passare informazioni aggiuntive (es. userId, userLocation, ecc.)?
Queste informazioni non devono essere inserite nella client assertion. Si tratta di dati aggiuntivi richiesti da alcuni erogatori, che rientrano nel dialogo diretto tra erogatore e fruitore.
Per trasmetterli:
- creare il secondo token previsto da AgID Audit REST 02;
- inserirlo nell’header della richiesta all’erogatore, con chiave Agid-JWT-Tracking-Evidence;
- calcolare l’hash del token usando SHA256;
- riportare il valore ottenuto nel campo digest della client assertion, ad esempio:
1digest: {
2 alg: “SHA256”,
3 value: “IL_MIO_HASH”
4}
5Come verificare se la client assertion funziona?
Utilizzare lo strumento di debug: Tool per lo sviluppo → Debug client assertion.
Come è fatto un voucher rilasciato da PDND Interoperabilità?
La struttura del voucher varia in base al tipo:
Ogni tutorial dedicato mostra il formato dettagliato del voucher corrispondente.
Dove trovare maggiori informazioni?
- In questo manuale tecnico, nella sezione dedicata ai voucher.
- Nel webinar tecnico dedicato, per una dimostrazione del flusso completo.
Pagina successiva → Deleghe
In questa pagina
La mia richiesta di voucher viene rifiutata
Il campo nbfnon è presente
Dove inserire i nuovi custom claim (producerId, consumerId, eserviceId, descriptorId)?
Il campo digestè obbligatorio?
Come passare informazioni aggiuntive (es. userId, userLocation, ecc.)?
Come verificare se la client assertion funziona?
Come è fatto un voucher rilasciato da PDND Interoperabilità?
Dove trovare maggiori informazioni?
Hai bisogno di aiuto?
Apri un ticket utilizzando l’apposita funzione all’interno della tua Area Riservata
