Newsgroup: it.lavoro.informatica
Titolo: identificare univocamente una persona

ciao a tutti, forse sono ot. in caso mandatemi a cagare.
al momento stiamo cercando di decidere come identificare una persona tra 
sistemi diversi (anche tra aziende diverse).
pensavamo di usare il codice fiscale, visto che l'agenzia delle entrate 
scrive che[1]
"Il codice fiscale rappresenta lo strumento di identificazione del 
cittadino nei rapporti con gli enti e le amministrazioni pubbliche."
ma
- non rimane univoco nel tempo:
   - esistono casi di omocodia (14.000 all'anno circa) nei quali il cf
     viene sostituito
   - esistono cf provvisori
   - se uno cambia nome gli cambiano il cf
- non è univoco: due persone potrebbero avere lo stesso cf
allora che fare? un db nel qualce censiamo tutti i nostri utenti e tra le 
app ci passiamo l'id? o ignoriamo i problemi di cui sopra e facciamo come 
il resto dell'italia (ma è veramente così?) il cf?
voi come fate?
[1]
http://tinyurl.com/2fh2t8b


Sul codice fiscale sei fuori strada (tranne sul fatto che se una
persona cambia nome, allora cambia il cf: non sono sicuro che sia
cosi'): la procedura utilizzata in caso di omocodia risolve il
problema dell'univocita' del cf. Due persone non possono avere lo
stesso cf.
Il problema che stai affrontando forse e' un po' piu' sottile:
a)Stai cercando di usare un attributo che puo' variare per
identificare un (s)oggetto.
e/o
b)probabilmente il (s)oggetto e' identificato in maniera differente in
sistemi diversi
Nel caso a) o stai usando un attributo (o un insieme di attributi) che
non e' chiave, oppure stai usando una chiave che varia nel tempo. Mi
spiego: il nome di una nazione e' univoco nel tempo. P.es. URSS
e' (era) univoco. Poi si e' divisa ed e' nata la Russia. Russia ora e'
univoco. Tanto tempo fa era gia' univoco. Hai un caso di attributo che
e' univoco in un dato istante. Una persona che lavora/ha lavorato
nell'ambasciata italiana di Mosca ha lavorato nell'ambasciata italiana
in URSS, nell'ambasciata italiana in Russia....ed anche se non si e'
mai mosso di li' sembrerebbe che abbia lavorato in N posti diversi.
Nel caso b) hai un (s)oggetto che e' noto in un sistema con un insieme
di attributi, ed in un altro con un altro insieme. Non e' detto che i
sistemi abbiano tutti gli attributi. 
p.es
. un utente puo' essere
identificato dal numero di patente, dal numero di carta di identita',
dal cf.
In questo caso un utente (id) ha 3 attributi che lo possono
identificare univocamente (cf, patente, C.I). Non e' detto che questi
valori siano sempre presenti e/o che lo siano nello stesso sistema. Un
utente puo' non avere una patente, l'anagrafe del Comune avra' la
C.I., ma non avra' la patente (viceversa per la patente).
La modalita' con cui gestire questa situazione dipende dai requisiti
(da quello che vuoi fare).
Ciao
Gimmi


lo faccio annusare ad un Deutsche Schäferhunde
se non lo riconosce.... lo azzanna!
ciao
fm

 
esistono strumenti per leggere le impronte digitali, e l'iride.
Devi spiegare cosa vorresti fare.
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 sistemi diversi
sicuramente. l'azienda sanitaria ha un suo user store, il negozio di vino 
quarda il tesserino sanitario dell'utente.

 spiegare cosa vorresti fare.
devo trovare un modo per identificare univocamente una persona tra due o 
più sistemi. i sistemi invocano operazioni di servizi esposti tra di loro, 
e quando comunicano devono passarsi "qualcosa" in modo che si capiscano 
che stanno parlando sempre della stessa persona.

insomma non vorrei progettare un sistema che faccia penare 'sti 
poveracci :)
http://www.digital-forum.it/showthread.php?t=48727


Se devi far dialogare banche dati diverse, mi sa che ti tocca aggiungere i 
parametri nome, cognome, data nascita, stato nascita, cod istat comune 
nascita, prov. nascita. E invece di un boolean fai tornare un codice di 
uscita.

 uscita.
di solito se c'è un errore faccio un'exception. ma questa è questione di 
gusti.

 parto dal presupposto che sia così.
http://it.wikipedia.org/wiki/Codice_fiscale#Cambio_di_nome

Apro e chiudo la parentesi sui cf: l'unico ente che puo' assegnare cf
validi e che gestisce e risolve il discorso omocodia e' l'agenzia
delle entrate. Quando scopre un caso di omocodia  cambia un codice
(purtroppo) a caso dei due. Piu' corretto sarebbe stato verificare un
cf prima di assegnarlo e poi risolvere l'eventuale omocodia
sull'ultimo cf (dove ultimo e' quello richiesto per ultimo). Questo
non toglie che un cf sia univoco. Il problema e' che un cf puo'
cambiare nel tempo. Per anni hai un cf valido, poi arriva un neonato
che ha il tuo stesso cf e, anziche' assegnare un nuovo cf diverso dal
tuo al neonato, lo cambiano a te.
Quindi un cf identifica sempre una persona (in un dato istante). Il
problema e' che le variazioni del cf non possono essere gestite nei
sistemi. Se ti e' cambiato il cf nessuno lo sapra'.
Tornando a bomba:
hai due sistemi che condividono lo stesso ID.
Cosa c'e' di strano nell'implementare getPermessoDiComprareIlVino(ID)?
Il problema forse e' un altro: ID non e' significativo per gli
operatori che probabilmente avranno il cf, oppure nome e cognome,
oppure la tessera del club degli ubriaconi...
Devi ricavare ID dai dati che hai e devi consentire la ricerca per
altri attributi (
p.es
. un operatore inserisce il numero della tessera
e compaiono a video tutti i dati). Non e' detto che la procedura si
possa automatizzare.
P.es. hai nome e cognome (Mario Rossi). Cerchi Mario Rossi nel tuo
sistema e ne trovi 10. Qual'e' l'ID corretto?
A questo punto nessun programma puo' individuare il Mario Rossi
corretto. Un (eventuale) operatore vedra' a video una lista di 10
Mario Rossi e potra', aiutandosi con altri dati, (residenza, data di
nascita, numero tessera club ubriaconi) individuare il Mario Rossi con
l'ID corretto, spuntare la classica checkbox e consentire al sistema
di effettuare la su getPermessoDiComprareIlVino(ID)
Se l'operatore non c'e', puoi tentare altre strade (
p.es
. passare
tutti gli attributi  in comune che hanno i due sistemi nella
getPermessoDiCompareIlVino) ma di fatto ti puo' capitare che:
comunque non riesci ad indentificare un unico soggetto
Se non hai difficolta' a recuperare ID usa ID: e' una chiave condivisa
tra i due sistemi.

 i due sistemi.
quello che penso anche io. vieni a lavorare da noi? avrei bisogno di uno 
che la pensa come me :)


se i sistemi che devono comunicare sono disgiunti e le informazioni
utente non sono condivise, o aggiornate simultaneamente, nessun
sistema garantisce la univocità dell'identificativo dell'utente, forse
il DNA, ma non è ancora un dato disponibile (per fortuna!) per tutti.
Credo che probabilmente il codice a barre nella tessera sanitaria
possa costituire l'elemento che cerchi, ma non sono sicuro che sia
univoco e utilizzabile, forse il codice della carta d'identità (più il
codice dell'anagrafe che lo ha emesso?), ma è necessario che i vari
sistemi abbiano questi dati censiti e, se cambiano nel tempo, abbiano
un meccanismo di sincronizzazione.
Gianmarco

 che sto iniziando a pensare di avere torto. forse è così.
Forse ID non e' in comune tra i due sistemi, ma e' semplicemente un
progressivo?
Fatti spiegare perche' non va bene.



Il n° della carta di identità non va bene ?
ciao,
Gabriele

 Fatti spiegare perche' non va bene.
nono, ID è in comune, e se non lo fosse lo si fa diventare. semplicemente 
si decide che IdP è il DB master degli utenti e ci si passa tutti gli ID 
di quel IdP.
si spinge verso il CF perchè l'agenzia delle entrate dice che
"Il codice fiscale rappresenta lo strumento di identificazione del 
cittadino nei rapporti con gli enti e le amministrazioni pubbliche."
e se lo dicono loro dobbiamo usare quello.
quindi se non ci sono controindicazioni SERIE si usa quello.
volevo un po' di esperienze di vita reale di gente che forse si è trovata 
a risolvere lo stesso problema, e sapere se utilizzano il CF come 
identificativo univoco del cittadino/utente e per propagare l'identità 
dell'utente.

> allora che fare? un db nel qualce censiamo tutti i nostri utenti e tra le
Il consolidamento delle anagrafiche è un argomento complesso, esistono
specializzazioni (giuro) e si presenta frequentemente ai system
integrator.
Detto questo si va avanti con grano salis e rendendo storico anche il
codice fiscale.

 voi come fate?
CF per quanto sopra :)

 Il n° della carta di identità non va bene ?
Non è obbligatorio averla, e non è obbligatorio dichiarare proprio la
carta invece di un altro documento. Potresti avere A con associata CI
e B con associata patente, credere che sono due persone diverse, quando
invece è sempre la stessa persona che ha dato due documenti diversi
in due diverse occasioni.


Ma dai, non ci credo...
Ma in quei casi poi non sarebbero obbligati a rilasciare un cf corretto ad 
hoc per renderlo univoco, dubito seriamente che la base dati dei cf 
dell'agenzia delle entrate mantenga cf duplicati anche a parità di dati 
anagrafici.


Scusa, come fa ad essere in comune se dovete riferirvi a base dati esterne 
che non sono vostre?
E come pensate di farlo diventare comune?

 "tre" ha scritto nel messaggionews:hvoj9i$3i1$6...@news.eternal-september.org...

1- il tipo trolla e alla grande
2- PRIMA che quel cf entri nella base dati,
   sara' stato "normalizzato" da almeno 10 anni,
   per quei casi esiste il codice di controllo, l'ultimo carattere
felice&pago
alberobello
.

 cf alla/alle persona/e coinvolta/e.
Ricorda che il codice fiscale reale lo conosce solo l'Agenzia delle
Entrate, proprio per il discorso della omocodia.
Che comunque dovrebbe essere riconoscibile perchè il penultimo
carattere da numerico diventa alfabetico, ad esempio AAABBBAAMGGH501X
può diventare AAABBBAAMGGH50YX. In un caso del genere non puoi a
priori dire se il c.f. è stato inserito male, oppure è un omocodo.
Pertanto tutti i programmini di generazione del c.f. da nome ecc. sono
destituiti di qualunque validità. Solo un quesito diretto all'A.E. può
validare i c.f. Ed è quello che fanno i grandi enti, mandano il file
dei c.f. con nome, data nasc., ecc. e l'A.E. li valida.
Il c.f. può invece cambiare collettivamente se cambia il codice del
comune, cosa che effettivamente capita ogni tanto.
E naturalmente anche l'A.E. può sbagliare, quindi certamente il c.f.
di un singolo può sempre cambiare per qualche motivo.

 sono neanche pochi.
Tempo fa avevo sentito che in un paese del Veneto, forse Chioggia, ci
sono talmente tanti "poveracci" omonimi che hanno consentito di usare
il soprannome nei documenti di identità, e forse nel c.f.! :-)

 wrote:

Dove hai trovato il numero 14000? a me pare un po' alto.
 Sullo stesso link che posti
dell'Agenzia delle Entrate è scritto che in caso di cambio
nome è possibile richiedere
l'aggiornamento del codice fiscale.
Qualcuno qui ha detto che l'agenzia delle entrate non verifica
se un codice è doppio quando lo emette, ma siamo sicuri? In
questo caso sicuramente vengono fuori casini.

 comune, cosa che effettivamente capita ogni tanto.
O quando ci sono secessioni o partizioni o acquisizioni o perdite o
scambi territoriali per i nati all'estero.
--
ale
http://ale.riolo.co.uk


Vero. I nati all'estero sono un'altra croce (e delizia? :-).
Per esempio quelli nati nelle province fiumane quando facevano parte
dell'Italia.
Comunque, a mio parere, cercare un codice identificativo univoco che
sia anche immutabile nei decenni è solo una perdita di tempo. Il c.f.
è quello che, in Italia, più si avvicina alla stabilità richiesta ed
all'univocità sulla popolazione trattata.
E' vero che se devi trattare anche soggetti senza cittadinanza
italiana, il c.f. è già invalidato in partenza come id univoco.

 app ci passiamo l'id? 
- ogni utente afferisce ad un ente ed ha un id univoco in quel dominio
- per la ricerca inserisci l'identificativo ente e id della persona che
cerchi
potrebbe andarti bene?

 italiana, il c.f. è già invalidato in partenza come id univoco.
Mia moglie aveva il CF ben prima di sposarmi, in realtà lo può
chiedere chiunque, cittadino o meno (anche se non è detto che glielo
rilascino!).
A proposito, dopo che ci siamo sposati mia moglie ha cambiato cognome
(per la legge turca le donne o prendono il cognome del marito o lo
aggiungono al proprio, mia moglie ha scelto questa opzione per cui ora
ha il doppio cognome) ed il consolato italiano a Londra (che per noi è
l'ufficio a cui dobbiamo rivolgerci per queste questioni) non ha
voluto accettare la richiesta per il cambio del CF (IMVHO avrebbe
dovuto), ma ci ha comunque fatto avere il CF su tessera plastificata
(che né io né mia moglie avevamo mai ricevuto in passato).
--
ale
http://ale.riolo.co.uk

 soprannome nei documenti di identità, e forse nel c.f.! :-)
Si`, e Chioggia, ma li` siamo quasi al limite dei matrimoni tra 
consanguinei...
Ci sono praticamente 2 o 3 cognomi in tutto (ok, ce ne sono anche altri, 
ma la stragrande maggioranza ha uno di quei due).
Bye.

 (che né io né mia moglie avevamo mai ricevuto in passato).
Un bel gadget in omaggio dallo stato italiano! :-) Mi sembra che la
tesserina cc.f. con banda magnetica l'ho usata 1 o 2 volte in tutta la
vita, su un totem in un ufficio Inps, se ricordo bene.

 voi come fate?
DB interno, censimento utenti interno e tra le app. ci passiamo l'ID.
L'id potrebbe essere anche il numero del record, che a leggerlo ad alta 
voce non ti dice poi molto sulla persona cui riferisce.
Ciao
M.
-- 
Nessun Bit e' stato maltrattato o ucciso
per scrivere questo messaggio
http://www.qtp.it/Gallery/profile.php?uid=2311

 che la pensa come me :)
E' quello che succede spesso a me.
Lascio il nome.
Vedono che ce ne sono almeno altri 2 e mi chiedono chi la residenza, chi 
la data di nascita, chi il numero di badge (in ditta eravamo 4 omonimi) ...
Praticamente uso "John Smith" come nick anche perche' corro meno rischi 
di omonimia!  :)


- non è univoco: due persone potrebbero avere lo stesso cf
e' falso. 
Anche se astrattamente e' possibile che due Paolo Rossi, nati entrambi
a Milano il 25 dicembre 1970 possano avere lo stesso cf, in realta' e'
l'agenzia delle entrate a distinguerli quando si accorge dell'omocodia
e lo fa modificando *entrambi* i cf secondo regole ben precise e
standardizzate.
Quindi se tu identificherai i tuoi utenti sulla base dei dati che loro
ti daranno, vai tranquillo ed utilizza il cf (magari non proprio come
PK di db) ma essendo abbastanza certo che i tuoi utenti saranno
facilmente identificabili.
Preoccupati piuttosto d'applicare le corrette procedure di controllo
come pubblicate nelle specifiche tecniche dell'AE e non credo avrai
mai problemi.

 allora che fare?
oggi c'è stata la riunione globale totale degli architetti. abbiamo 
deciso di utilizzare comunque il codice fiscale, prendendo atto delle 
possibili eccezioni che ci possono essere gestendole in caso a mano.

    codice di controllo, l'ultimo carattere
cosa c'entra lo sai solo tu.



le base dati esterne avranno tutte un id_idp per mappare l'utente loro a 
quello nel db centrale master, che diventerebbe quello dell'IdP. scusa se 
sopra mi sono espresso male.

 cambia uno dei due come sopra.
succede che finchè l'agenzia delle entrate non si accorge che cene sono 
due uguali non li cambia. in quel periodo girano due persone con lo 
stesso codice.

 sicuramente vengono fuori casini.
infatti.

 potrebbe andarti bene?
il problema diventa mappare gli id tra i due enti: per poter dire che 
t...@example.org
 = 
qua...@dominio2.com
 devi avere un qualche 
identificativo (o più di uno) che entrambi conoscono.

 di cui si discute da qualche anno
interessante. non ne ero a conoscenza. vado a cercare.

questo caso sicuramente vengono fuori casini.
Infatti l'AE controlla se si presenta una omocodia al momento
dell'emissione del codice ed agisce di conseguenza.

 che stanno parlando sempre della stessa persona.
allora fai come gli spagnoli: aggiungi il cognome della madre e estendi
il CF con altre tre lettere. In questo modo aggiungere un'altra
variabile e rendi un poì più remota la possibilità che i codici siano
duplicati.
In questo caso, dovrebbero essere nati nello stesso giorno, nella
stessa città, due persone, con lo stesso nome, con lo stesso cognome, e
addirittura con la madre che ha lo stesso cognome.
E se non ti basta, puoi anche aggiungere - ad esempio - la data di
nascita del padre...
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo



aggiungi il cognome della madre (come si usa in Spagna) e metti quindi
tre lettere in più nel CF .... ti puoi anche inventare di aggiungere la
data di nascita del padre.
-- 



La prima parte del cf può essere uguale anche per nomi e cognomi simili, non 
è detto che debbano per forza essere identici.
Per quello che mi par strano che, completando il cf con le indicazioni 
anagrafiche in chiaro, ci siano ancora duplicati.

 stesso codice.
Ma non puoi farci niente: se hanno lo stesso codice, vuol dire che hanno
uguali *tutti gli altri dati identificativi* - nome, cognome, luogo e data
di nascita. Purtroppo non hai "tu" un modo per distinguerli finché non è
lo Stato a farlo per te.


Io per nome e cognome non sarei cosě sicuro.

 stesso codice.
Ma come fai a dire una pallonata del genere? Ma secondo te nell'anno
del signore 2010 l'AE non ce l'ha un db con tutti i c.f. in cui fare
una ricerca? Ci metterà 1 giorno, 1 settimana, ma insomma....

 una ricerca? Ci metterà 1 giorno, 1 settimana, ma insomma....
Non confidare MAI nell'efficienza della PA!

 Io per nome e cognome non sarei così sicuro.
Si, certo, in effetti combinazioni nome/cognome "simili" possono generare
lo stesso codice, in questo caso potresti riuscire a distinguerli - ma non è
certo insolito avere due persone con lo stesso esatto nome, cognome, luogo e
data di nascita. E cito un caso personale: non solo IO ho un perfetto omonimo
totale, ma perfino mio padre! Quante sono le probabilità che accada? Eppure,
con sessanta milioni di persone, succede, eccome se succede.

 anagrafiche in chiaro, ci siano ancora duplicati.
Tutti i nati di una stessa città hanno la parte finale uguale... e in
una metropoli non è difficile che due nati nella stessa città e nello
stesso giorno abbiano pure nomi simili.


stesso giorno abbiano pure nomi simili.
Banalmente associare un CF a un altro CF (es. quello materno) e
implementare comunque la storicizzazione dell'anagrafica in caso di
cambio nome e emissione di nuovo CF?
Anche se probabilmente si aprirebbero altri scenari.
Saluti
-- 
Living in Barbaropoli
http://www.barbaropoli.com


nella mia ipotesi ogni utente afferisce ad UN (e solo) ente, non si pone
neanche il problema di mappare id su domini diversi.
e se anche una persona avesse due 'account' su domini diversi verrebbe
trattata come se fossero due persone distinte, questo non è un problema
se il resto delle informazioni sono coerenti.
Sono rimasto all'esempio cliente enoteca/azienda sanitaria, magari per
il tuo caso reale non va bene questa (semplice) soluzione.

 cambio nome e emissione di nuovo CF?
Ma devono implementare la gestione dell'antiterrorismo?? :-))
Addirittura il c.f. della madre!
Io partirei dal dati di fatto che la chiave univoca assoluta non
esiste, e progetterei bene il sistema per gestire eventuali cambi
della chiave identificativa, oltre a valutare la percentuale attesa.
Potrebbe essere che la percentuale dello 0,000001 possa essere gestita
razionalmente con qualche controllo ben messo e due update SQL quando
serve.


E' abbastanza dura per un neonato avere lo stesso cf di un altra persona, 
per i motivi sovraesposti; tuttavia per quanto improbabile che accada è più 
plausibile che possa esserci una persona che:
a) abbia un cognome e nome (anche diverso) le cui prime lettere del cf 
coincidono con il cognome e nome di un altra persona;
b) abbia una data di nascita identica a quella di un altra persona
c) risieda nello stesso comune di appartenenza dell'altra persona.
In tal caso si applicano precise regole per evitare casi di omonimia. Non 
conosco la natura di queste regole, ma è certo che vi sono.
-- 
Impastato Marcello
www.blueware.it
 


Non c'entra la residenza, il comune considerato nel cf è quello di nascita.