agid / inad_api_extraction Goto Github PK

buongiorno,

Sto effettuando le prime chiamate alla ws /extract
ma mi ritorna sempre errore 400 bad request

mi sarebbe comodo avere una chiamata di esempio raw a cui fare riferimento per costruire bene la chiamata.

la chiamata che faccio e' questa:

GET /rest/inad/v1/domiciliodigitale/extract/MNCDVD96E28B519P HTTP/1.1
Authorization: Bearer eyJ0eXAiOixxxx.eyJhdWQxxxxxx
Host: domiciliodigitaleapi.oscl.infocamere.it

mi sembra di fare tutto correttamente tranne una cosa, nella documentazione ce scritto che bisogna passare in query il practicalReference, ma dentro la chiamata come deve essere inserito?

Nello yaml ho le seguenti definizioni :

Digital_Address:
pattern: ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$
type: string
description: Indirizzo PEC del Domicilio Digitale
example: [email protected]
UUID:
maxLength: 40
minLength: 20
pattern: ^[{]?[0-9a-fA-F]{8}-([0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}[}]?$
type: string
description: Codice univoco della richiesta di elaborazione Report
example: f8c3de3d-1fea-4d7c-a8b0-29f63c4c3454

Sto testando il metodo verificaDomicilioDigitale tramite il client (generato dallo yaml).

Viene fatta una GET in questo modo :
https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/verify/CIOFBA80B29D810R?digital_address=fcioe%252540pecagrotecnici.it&since=2017-07-21&practicalReference=test

Il client effettua in automatico un encode del "digital_address" ad UTF-8 (credo sia corretto) ma il pattern (tramite le RegEx) poi lo rifiuta ed ottengo una BAD REQUEST (a causa della @ codificata)

Se da Postman faccio una GET secca senza "encode" dei campi, funziona.
https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/verify/[email protected]&since=2017-07-21&practicalReference=test

Non ne sono certo ma almeno per le email e lo uuid si possono usare i relativi format

Specifiche OpenAPI : https://spec.openapis.org/registry/format/

Un po' come è stato già fatto qui nello yaml :
dateTimeCheck:
type: string
description: Data/Ora estrazione in formato ISO 8601 <yyyy-MM-dd'T'HH:mm:ssZ>
format: date-time
example: '2017-07-21T17:32:28Z'

Fatemi sapere se è un bug o una gestione NON corretta da parte mia (anche se il client che è autogenerato a partire dallo yaml)

Grazie

Buon pomeriggio,
stiamo avendo problemi nell'interrogare, sull'ambiente di produzione, il servizio di richiesta massiva tramite pdnd.
Di fatto ogni giorno ci va a buon fine, e quindi con l.a response dei cf aventi o meno la pec, solo per la prima interrogazione. Le sucessive rimangono in stato IN_ELABORAZIONE anche dopo diverse ore.
Come esempio riporto le segiuenti interrogazioni massive eseguite in data odierna:

{
"state": "PRESA_IN_CARICO",
"message": "Richiesta elenco presa in carico",
"id": "c62e69b1-9d23-4649-b291-909815ae0cdb",
"dateTimeRequest": "2023-08-01T08:20:07Z"
}
la cui ressponse ha dato l'elenco richiesto nel giro di qualche minuto.

e le seguenti due:
{
"state": "PRESA_IN_CARICO",
"message": "Richiesta elenco presa in carico",
"id": "ed93ce97-3df6-4279-928a-0fa139ed3e20",
"dateTimeRequest": "2023-08-01T08:25:58Z"
}

e

{
"state": "PRESA_IN_CARICO",
"message": "Richiesta elenco presa in carico",
"id": "cc94aebf-cd9c-4f50-a554-0875983c1e8d",
"dateTimeRequest": "2023-08-01T08:56:21Z"
}

che ancora adesso (ore 16:46 del 01/08/23) hanno come state
{
"state": "IN_ELABORAZIONE",
"message": "Richiesta elenco in fase di processamento"
}

è possibile verificare da cosa dipende questa lunga attesa?

grazie

Salve,
ho letto nelle LG del processo di trust ai paragrafi 4.1, 4.2 e 4.3, non conosco bene il processo simile che si effettua sulla PDND; vorrei capire chi è l'ente presso cui richiedere il voucher che emette i claim presente nel JWT da inserire poi nell'header delle richieste?
Il mio scopo sarebbe di utilizzare in un'architettura a microservizi delle chiamate REST ad alcune API presenti nello YML per recuperare la presenza di un DD a partire da un CF.

Mi scuso se la domanda può risultare pleonastica.

Grazie.

Ci sono indicazioni per impostare un intervallo di tempo congruo per il polling su /listDigitalAddress/state/{id} dello stato di avanzamento di una richiesta multipla?

Riferimento, "Documento operativo ModI su pattern di interazione", paragrafo 5.2 (Pattern non bloccanti RPC PULL (busy waiting)):
"Gli intervalli di polling possono essere definiti tra le parti."

Salve,
ho fatto una prova con un'estrazione massiva : /listDigitalAddress e collegati.
Tutto bene, però rispetto alle specifiche:

• Con lista in stato "in elaborazione" ricevo lo status code atteso.
• quando la lista è pronta non ricevo una response con status code 303 ma con status code 404 (not found).

Poi il recupero della lista di domicili funziona.

Vi copio qualcosa che può essere utile:

Risposta a lista pronta:

"timestamp": "2023-06-15T17:40:14.600+00:00", "status": 404, "error": "Not Found", "path": "/v1/domiciliodigitale/elenco/3d271191-0d20-4693-8f5f-48ad49fcec9f/risultato"

Recupero della lista:

{ "list": [ { "codiceFiscale": "**************", "since": "2023-06-15T19:40:00Z", "digitalAddress": [ { "digitalAddress": "***@****.it" } ] }, { "codiceFiscale": "*********", "since": "2023-06-15T19:40:00Z", "digitalAddress": [ { "digitalAddress": "*****@***.it" } ] }, {

PS: ho ricevuto un elenco di codici fiscali censiti in ambiente di test dal supporto Infocamere, li ho oscurati.

Buongiorno,
ricevo l'errore 401 "Unauthorized" dai servizi, ho provato a contattare PDND ma dal loro lato mi confermato vada tutto a buon fine. Sono in fase di collaudo, l'e-service che sto utilizzando è "INAD API PUBBLICHE CONSULTAZIONE", perchè "INAD CONSULTAZIONE DD" non mi risulta nel catalogo di collaudo, quale potrebbe essere il problema?
Cordiali saluti.

Ciao,
sono uno sviluppatore che si sta occupando dell'integrazione INAD su un applicativo della nostra azienda.
Siamo su collaudo e stiamo utilizzando l'e-service INAD API PUBBLICHE CONSULTAZIONE.
Per soddisfare la nostra richiesta abbiamo fatto generare in primo luogo la chiave privata, utile a generare l'assertion (assertion key ha passato con successo i controlli del debug) che chiamando https://auth.uat.interop.pagopa.it/token.oauth2. riesce a farci ottenere il token da utilizzare per la chiamata al servizio INAD.
"client_id": "dd7b1ac0-0c84-4557-88e1-1c8f7a15e061"
"jti": "d32abdb8-a508-4196-9442-e4cb306ead5f"

Per la chiamata al sevizio INAD (https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/RRANGL74M28R701V?practicalReference=asd) aggiungiamo nell'header Authorization: Bearer <(token ottenuto nella chiamata precedente)> (come da guida) e come risposta otteniamo il seguente errore:
{
"status": 401,
"type": "UNAUTHORIZED",
"detail": "Invalid Bearer JWT Token"
}

Guide utilizzate:
Generazione dell'assertion e successivo token
Richiesta a INAD

Chiediamo supporto a riguardo e siamo reperibili in ogni modo per risolvere il problema

Buongiorno,
utilizzando i servizi, ricevo errore 404 "CF not found", sia che uso codici fiscali validi, sia che li uso non validi... ci sarebbero dei CF di test da poter utilizzare?
Grazie

Buongiorno,
provando a invocare con postman in GET https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/{TRVVCN73H02L259I} ricevo sempre
{
"status": 401,
"type": "UNAUTHORIZED",
"detail": "Invalid Bearer JWT Token"
}
anche se ho generato correttamente il token JWT:
{
"access_token": "ey..........",
"expires_in": 600,
"token_type": "Bearer"
}
Sicuramente sbaglio qualcosa ma dopo diversi tentativi non sono riuscito a risolvere, potete aiutarmi?

Salve,
da pochi giorni, utilizzando il servizio d'estrazione ricevo il seguente errore:

{"timestamp":"2023-10-03T10:34:45.654+00:00","status":500,"error":"Internal Server Error","path":"/v1/domiciliodigitale/extract/TRVVCN73H02L259I"}

Ho effettuato la verifica per l'assertion con il tool messo a disposizione della piattaforma e mi dà esito positivo.
L'endpoint utilizzato per la richiesta è il seguente:
https://domiciliodigitaleapi.oscl.infocamere.it/rest/inad/v1/domiciliodigitale/extract/TRVVCN73H02L259I?practicalReference=testdeda

possibili soluzioni?
Grazie in anticipo

I servizi di consultazione di INI-PEC sono attualmente erogati da InfoCamere su Porta di Dominio.
Quando saranno disponibili secondo il nuovo modello di interoperabilità?

Buongiorno,

sto provando ad implementare la chiamata REST verso INAD su Java 1.7.0_51 ma stiamo riscontrando un problema di handshake:

org.springframework.web.client.ResourceAccessException: I/O error on GET request for "[https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/GLLLSS87S05G838N":](https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/extract/GLLLSS87S05G838N%22:) Received fatal alert: handshake_failure; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Caused by: javax.net.ssl.SSLHandshakeException

Ho avuto lo stesso problema richiamando le API di PDND, ma ho risolto abilitando il TLS 1.2, in questo caso sembra che non è sufficiente.

Non ho letto nessuna specifica particolare riguardante i protocolli di sicurezza nella documentazione, potreste darmi delucidazioni a riguardo?

N.B.

abbiamo ancora il problema del 401 UNAUTHORIZED (#20) da Postman

Dalle linee guida AGID sembra evincersi che un soggetto possa avere al massimo due domicili digitali registrati su INAD.
Questo avviene solo nel caso in cui si iscriva e come professionista e come cittadino.

"Per quanto concerne l’elezione del domicilio digitale, solo i Professionisti hanno facoltà di eleggere nell’INAD sia un domicilio digitale professionale sia un domicilio digitale personale. La distinzione tra i due domicili digitali appartenenti al medesimo soggetto è resa evidente all’interno dell’INAD sia all’interessato, al momento dell’elezione del domicilio, sia agli utenti al momento della consultazione dell’INAD. "

Tuttavia uno dei CF presenti nell'ambiente di collaudo presenta ben tre domicili digitali associati.
Cosa ci si deve attendere in ambiente di produzione?

I due metodi "verify" ed "extract", in caso di response con status code 401, restituiscono un payload con chiave "error" e non "detail" come invece scritto nelle specifiche OPENAPI (file .yaml)

Salve vorrei chiedere conferma dell'endpoint corretto da utilizzare per il metodo (es: verify) con dati provenienti dal csv di esempio:
https://domiciliodigitaleapi.oscl.infocamere.it/rest/inad/v1/domiciliodigitale/verify/MNTCRL93H18I452Y
oppure
https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/verify/MNTCRL93H18I452Y

Inoltre la risposta è sempre di tipo 401.
Quale tipo di autenticazione è richiesta (presumo oauth2 con jwt) e come ottenete quindi tali credenziali.

Cordiali Saluti

Sto testando il metodo recuperoDomicilioDigitale : GET /extract/{codice_fiscale}

Tra i campi di risposta ho 'practicedProfession '

"La valorizzazione di practicedProfession è prevista solo per la fattispecie “professionisti che svolgono una professione non organizzata in ordini, albi o collegi ai sensi della legge n. 4/2013 (di seguito Professionisti)”.

Ho provato con vari codici fiscali di professionisti (Avvocati, Geometri, etc.) ma il campo 'practicedProfession ' è sempre null.

Avreste almeno un codice fiscale per testare il practicedProfession?

Grazie

A scopo puramente didattico e di orientamento, sto facendo alcune prove dei servizi di estrazione, utilizzando degli script Python (disponibili in un mio repository non ancora pubblicato, posso invitare come collaborator se utile).
L'interazione funziona, però segnalo alcuni fatti.

Premetto che non so se in ambiente di test ci sono CF e indirizzi registrati, quindi ho utilizzato o dati miei o dati del tutto inventati (anche formalmente non corretti). Non ho quindi mai ricevuto response con status 200 (eccezione fatta per il messaggio di chiusura serale :) )

Segnalo:

• sia con /extract/ sia con /verify/ non mi pare ci siano controlli sulla correttezza formale né del codice fiscale né della data né dell'indirizzo mail da verificare;
• infatti, inserendo una request con parametri del tipo 'codice_fiscale' : 'aaa', 'since' : '2023-31-31' o 'since' : '2023', ricevo comunque una response con status code 404 (not found) mentre ci si potrebbe attendere una 400 (bad request)
• lo stesso se nei parametri della chiamata a /verify/{cf} ometto uno dei paramenti marcati come obbligatori nelle specifiche yaml, per esempio 'digital_address', di nuovo response con status code 404.

Proposta: consentire di reperire informazioni su registrazione e titolare di un domicilio digitale senza fornire il codice fiscale.

Caso d'uso:

• l'art 65 c. 1 lett. c-bis del CAD prevede che l'istanza e la comunicazione inviate dal domicilio digitale registrato nei 3 registri (INAD, INIPEC, IPA) è valida (anche se non provvista di firma digitale, cioè);
• questo rende necessario verificare che la casella certificata da cui si riceve il messaggio sia domicilio digitale registrato dell'autore di istanza o comunicazione;
• siamo fuori da una procedura di presentazione di istanze guidata, quindi il sistema (protocollo informatico, direi) che riceve il messaggio non ha il codice fiscale del mittente come dato strutturato, non è quindi possibile invocare un automatismo per verificare se la casella mittente e' un domicilio digitale registrato dal mittente;
• un controllo semimanuale risulterebbe oneroso e disfunzionale (per via dei volumi) e talvolta impossibile (esistono casi in cui il mittente è chiaramente identificabile ma non se ne conosce il codice fiscale - ripeto, siamo in un contesto di trasmissione di documenti non guidata);
• invece, un controllo (anche da fare solo ed esclusivamente via API) che dall'indirizzo della casella fornisce riposta con codice fiscale (e magari nome e cognome) del titolare, potrebbe consentire di automatizzare la verifica se la casella mittente è un codice fiscale;
• la corrispondenza fra titolare del domicilio digitale e intestatario/autore dell'istanza/comunicazione può poi essere demandato a chi cura l'istruttoria del procedimento o le attività conseguenti.

Il README qui su GitHub menziona la PDND come intermediario per stabilire il trust fra erogatore e fruitore.

La PDND non è mai menzionata nelle specifiche tecniche delle API: https://domiciliodigitale.gov.it/dgit/home/public/docs/inad-specifiche_tecniche_api_estrazione.pdf

Le specifiche pero' ai paragrafi 4.2 e 4.3 descrivono un processo che è del tutto simile a quello che si fa su PDND per ottenere il token JWT da spendere nell'header delle chiamate all'e-service.

Si deve intendere che quanto descritto ai paragrafi 4.2. e 4.3 si fa con la PDND?

Buongiorno,
al fine di riuscire ad utilizzare propriamente le API offerte da INAD, chiederei cortesemente di specificare più chiaramente il significato del parametro practicalReference, presente nelle varie GET.

In particolare,

• non è chiaro se sia atteso un valore particolare che faccia riferimento al "numero di protocollo" della pratica da notificare o, per esempio, sia una sorta di "costante" da utilizzare per indicare la tipologia di procedimento che ha portato alla necessità di richiedere il domicilio digitale
• non è chiaro se sia presente una qualche verifica del suddetto parametro lato INAD (e quali siano le eventuali logiche di controllo)

Rimanendo a disposizione per eventuali ulteriori chiarimenti sulla richiesta, si attende cortese riscontro.
Cordiali Saluti

Buonasera,
stiamo provando ad effettuare una chiamata con Postman al servizio INAD in ambiente di interoperabilità collaudo.
Abbiamo effettuato la connessione nel sistema di interoperabilità collaudo e ottenuto il corretto client_assertion (verificato anche tramite il degub presente all'interno dell'interoperabilità)
Fatto questo, tramite l'API https://auth.uat.interop.pagopa.it/token.oauth2 abbiamo ottenuto il token per l'e_service INAD API PUBBLICHE CONSULTAZIONE.
Quando effettuiamo una qualsiasi chiamata ai servizi esposti su https://api.inad.gov.it/rest/inad/v1/domiciliodigitale otteniamo in risposta {"status":401,"type":"UNAUTHORIZED","detail":"Invalid Bearer JWT Token"}.
Dove stiamo sbagliando? C'è qualche ulteriore configurazione non riportata nella guida?

Segnalo inoltre che la guida, pur essendo uno yalm, non è leggibile con swagger.

Allego un dettaglio della chiamata.

POST https://api.inad.gov.it/rest/inad/v1/domiciliodigitale/listDigitalAddress
401
82 ms
POST /rest/inad/v1/domiciliodigitale/listDigitalAddress HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJSUzI1NiIsInVzZSI6InNpZyIsImtpZCI6IjMyZDhhMzIxLTE1NjgtNDRmNS05NTU4LWE5MDcyZjUxOWQyZCJ9.eyJhdWQiOiJkb21pY2lsaW9kaWdpdGFsZWFwaS5vc2NsLmluZm9jYW1lcmUuaXQiLCJzdWIiOiI1ZmQ2N2JiYi04ZGQ0LTQ4NjUtODAzMi1iYjQ0MzExNWRiNTIiLCJuYmYiOjE3MDM4NTY4MzksInB1cnBvc2VJZCI6IjI4N2IzZWNhLWMwZDMtNDQzZS05MTU0LTUxNGVlZDMxMmI5MCIsImlzcyI6InVhdC5pbnRlcm9wLnBhZ29wYS5pdCIsImV4cCI6MTcwMzk0MzIzOSwiaWF0IjoxNzAzODU2ODM5LCJjbGllbnRfaWQiOiI1ZmQ2N2JiYi04ZGQ0LTQ4NjUtODAzMi1iYjQ0MzExNWRiNTIiLCJqdGkiOiIzNGFkMTIyMS1kZTc5LTRiMDgtODY5Ny0yNmZhZDBlNmY3MzYifQ.DVg8MokPyaal2igBW1s8l0D0klecq60d-ruWNHxdfhbiKB1GgHbsOMRkdxL6sC-hZogvDO9HYBS708DOvgL3GIH5iQJ-yWjs6Qqz69Oe7BiQQ5rJkLQqGBH5N8TfUC_WxjfzgGIdlyf06uUU-K6qCT8uUjAa2tCPqUKDaOyGE5J90oxJrvRNY5GY50VV5sTBEV4opAjk9PQdfMBww28t8bvOam2c_NlUbYnlTa0pK-4svu7M-toVndeF0e7B7iH3AJxL3mWi4rIcqOZE1jZhwCrt5eLwvYQq9MPQgd9I4dw7KSKtYrumn0DQsbw8Gzy9DL-zcn_aBvA8QAhNGZ4Fkw
User-Agent: PostmanRuntime/7.36.0
Postman-Token: b94af0a0-b26e-4288-93a0-584a3dd1c83a
Host: api.inad.gov.it
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 82
Cookie: 34c274f102110c314e7714720f9f288f=d3d61b9c138776e793e708bf15aa1cae

{
"codiciFiscali": [
"RGGSNO93E57C619T"
],
"praticalReference": "1234"
}

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Content-Length: 72
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1 ; mode=block
Referrer-Policy: no-referrer
connection: close

{"status":401,"type":"UNAUTHORIZED","detail":"Invalid Bearer JWT Token"}

Buongiorno,
l'ente per il quale lavoro (società in-house) non presenta, su PDND, gli attributi richiesti per la fruzione dei servizi.
A chi è possibile chiedere l'esttensione degli attributi utilizzabili? Il supporto sul sito INAD non è stato in grado di fornire risposta.
Grazie, saluti
PP