In qualità di soggetto aggregatore dovremmo creare un metadata per l’autenticazione SPID di determinati servizi di un certo comune che però ha già un metadata.
In passato ci è già capitata una situazione simile: metadata esistente a cui ci siamo aggiunti noi, ma non eravamo soggetti aggregatori.
Ora che siamo soggetti aggregatori, è ancora possibile accodarsi ad un metadata esistente non fatto da noi?
No, dovete farne uno vostro per il comune aggregato.
Ma non va a sovrascrivere il metadata già esistente, fatto da altra ditta che copre alcuni servizi del comune, diversi da quelli che dobbiamo coprire noi?
No, perchè l’'EntityID sarà necessariamente diverso. Rileggi l’Avviso SPID n°19
1 Mi Piace
OK, grazie. Ma questo vale solo nel caso in cui si è soggetti aggregatori?
Perché quando non lo eravamo ci siamo dovuti accodare, per un altro comune, ad un metadata creato da un’altra ditta.
Esatto.
La creazione del ruolo dell’Aggregatore ha anche lo scopo di minimizzare la co-gestione dei metadata dei SP.
2 Mi Piace
In qualità di aggregatore, è possibile unire i metadati di autenticazione SPID esistenti anche se non sono stati creati. Assicuratevi che i metadati siano compatibili con il vostro ruolo di aggregatore e allineate la vostra integrazione con la configurazione del comune esistente. Per assistenza e risorse più dettagliate, è possibile visitare il sito red sfr mon compte.
È possibile, non obbligatorio, giusto? Altrimenti diventa esattamente l’opposto di quanto ha scritto AGS.
Esiste un metadata per un comune fatto da chissà chi per determinati servizi. Noi, in qualità di soggetto aggregatore, dovremo creare un altro metadata autonomo per altri servizi del comune e che non si accoderà a quello esistente. I due metadata vivranno autonomamente e nessuno dei due sovrascriverà l’altro, anche se si riferiscono al medesimo codice IPA. Questo è quanto ha scritto AGS ed è ciò che vorremmo fare.