Closed mrubiero closed 7 months ago
Ciao Marco, questa distinzione è stata introdotta un po' di mesi fa a seguito dell'apertura di PDND ad ANAC e alle piattaforme di e-procurement.
In questo caso è l'erogatore a creare la finalità che poi il fruitore si andrà a trovare già compilata in quanto è l'erogatore che va ad indicare il caso d'uso per cui intende raccogliere i dati.
Ciao Federica, ma in questo caso per staccare un voucher per un servizio che riceve dati un fruitore deve comunque inserire l'id della finalitá nella client assertion? Se sì come può recuperarlo dato che la crea l'erogatore?
Nel caso di un erogatore pubblichi un servizio che riceve dati e volesse staccare un voucher per testare che funzioni correttamente, in questo caso come può farlo?
Grazie, Marco
Ciao Marco,
allora:
La finalità la crea il fruitore comunque, quindi non cambia niente nel flusso. Semplicemente, associa alla finalità un'analisi del rischio compilata dall'erogatore.
può fruire del suo e-service come se fosse un qualsiasi e-service che eroga dati. Solo che quando chiama il suo servizio lo farà tramite POST invece che GET
Buonasera, vorremmo un chiarimento riguardo al processo di creazione di un e-service che riceve dati.
Innanzitutto vorrei chiedervi se la discriminante tra servizio che eroga dati e riceve è sempre stata presente o è stata introdotta successivamente.
Al netto di questo, nel processo di creazione, selezionando al primo step "Riceve", appare tra gli step la necessitá di creare una finalitá per i dati ricevuti.
Scorrendo però tra le varie domande, questa ci sembra ambigua in questo contesto in quando stiamo creando un servizio da erogare ma nel contempo siamo fruitori del dato.
In questo caso quale delle parti assume il soggetto erogatore del servizio?
Grazie, Marco