Start a new group Find groups

LOGIN

×

Simple proposal Assegnare un identificativo immutabile ad una persona all'interno di un gruppo

accettata

Results

Quando a seguito delle certificazione di un utente desideriamo che questo utente si iscriva, annotiamo i suoi dati anagrafici e mandiamo l'invito di iscrizione (oppure ne accettiamo la richiesta).
Una volta entrato nel gruppo però l'utente può decidere di modificare ogni aspetto anagrafico del suo profilo, diventando quindi a questo punto irriconoscibile all'interno del gruppo agli occhi di un amministratore.

Per gli utenti già iscritti ad un gruppo che richiede la certificazione solo in un secondo momento

Quando un gruppo già avviato decide in seguito di imporre una certificazione ai propri utenti, c'è il problema di decidere cosa fare di chi è già iscritto.

Questo problema è un problema di ordine generale, ma ne proporrò qui una bozza di soluzione, che dovrà essere discussa comunque separatamente. Appositamente non la inserisco in una soluzione.

Agli utenti che si trovavano già iscritti verrà concesso un periodo di tempo nel quale dovranno essere in grado di certificarsi. Contemporaneamente verrà loro inviata una notifica di ciò, assieme ad un messaggio dell'amministratore con le istruzioni per procedere alla certificazione. Dopo lo scadere del periodo predeterminato in cui potranno convivere i vecchi utenti non certificati e i nuovi utenti certificati, chi non avrà provveduto ancora alla certificazione verrà automaticamente escluso dal gruppo.

Solution 1: Aggiungere un identificativo sul rapporto utente-gruppo

Come avviene in LiquidFeedback, realizzare un campo fisso impostabile solo ed unicamente dall'amministratore (o da chi per lui avente diritto) che descrive attraverso un codice un identificativo relativo al gruppo, univoco della persona.
Esempio:E un codice di iscrizione o di tesseramento.

IIl campo èè associato all'iscrizione dell'eutente nel gruppo, e non al solo utente. Questo per rendere in grado ogni gruppo di impostare il proprio identificativo in base alla propria organizzazione interna.

Solution 2: Personalizzare il tipo di informazioni fisse

Un amministratore di un gruppo può realizzare una serie di campi a piacere da associare all'iscrizione di un utente in un gruppo.

Come la soluzione precedente, ma in questo caso l'amministratore non sarà legato ad un solo campo, ma potrà personalizzare il numero e i tipi di campi.

Ad esempio, se io amministratore gradisco che nel mio gruppo di utenti certificati ognuno appaia per chi realmente è, posso decidere di inserire i campi "Nome reale", "Cognome reale" e "Codice fiscale" immutabili dall'utente, ma che descrivono in maniera più precisa l'identità di una persona rispetto ad un semplice codice di iscrizione.

Rispetto alla prima soluzione questo metodo offre a chiunque la possibilità di verificare chi sia realmente chi all'interno della piattaforma, non limitando la possibilità ai soli amministratori che hanno la tabella di associazione codice-identità, ed invita quindi ognuno a porsi responsabilmente.

Solution 3: Delegare ad un'organismo terzo il compito di certificazione

Si delega ad un organismo terzo universalmente riconosciuto (ad esempio ddelle Certification Authorities autorizzate dalla normativa italiana ed internazionale) il compito di certificare in qualche modo direttamente l'account della persona. A questo punto avremmo degli account certificati universalmente, riconosciuti da tutti i gruppi poichè l'ente certificatore è accettato universalmente.

  • Libera i gruppi dall'onere di dover eseguire loro le certificazioni
  • La certificazione è posta sull'utente direttamente, e non è posta sul rapporto di iscrizione ad un gruppo. Questo semplifica in un'ottica di un account che coesiste contemporaneamente in gruppi differenti, i quali si trovano universalmente a ricnoscere tale account condiviso.
  • Poca elasticità a specifiche esigenze di certificazione dei singoli gruppi
  • Nessun controllo da parte dei gruppi sul processo di certificazione di un utente. Se ce ne fosse la necessità non sarebbe possibile accellerare i tempi di certificazione
  • Nel caso dello stato la procedura ha importanti implicazioni dal punto di vista organizzativo
  • Porterebbe ad introdurre burocrazia in Airesis per quanto riguarda la certificazione e a rallentare il processo di certificazione stesso
  • Diventiamo "dipendenti" da un ente terzo per quanto riguarda la procedura di certificazione

Solution 4: Autocertificazione dell'account con validazione da parte dei gruppi singoli

Un utente inserisce direttamente nel suo account i propri dati di riconoscimento.
Si intendono in questo luogo dati di riconoscimento tutti e solo i dati che collaborano alla definizione di un codice fiscale, codice fiscale compreso. Uso il codice fiscale anzichè altri metodi poichè è un sistema standard ufficiale per contraddistinguere l'identità di una persona. In Italia i codici fiscali sono infatti univoci.
Abbiamo quindi come dati di riconoscimento il Nome, Cognome, Sesso, Data e Luogo di nascita.Viene quindi eseguita dall'utente una "auto certificazione".

A questo punto ogni singolo gruppo può decidere se apporre o meno la propria "firma" sull'autenticità dei dati di riconoscimento autocertificati. Il ruolo del gruppo quindi sarà quello di andare a verificare l'utente, controllare i dati immessi e la loro validità, ed eventualmente dire "io, gruppo XYZ certifico che questo account è realmente di questa persona".
La certificazione quindi in questo caso si pone direttamente sull'account della persona e non sull'iscrizione di questa ad un particolare gruppo.

La coerenza dei dati è mantenuta poichè, all'eventuale modifica dei dati di riconoscimento da parte dell'utente, automaticamente decadono tutte le firme poste dai gruppi su tali dati. L'effetto incorre solamente se nella modifica dell'account sono coinvolti uno o più dati di riconoscimento, non incorre se ad essere modificati sono altri dati, come ad esempio la residenza. Ovviamente l'utente viene ben avvisato di questo durante la procedura e viene chiesta un'adeguata conferma sull'operazione. Modificando quindi i propri dati di riconoscimento immessi perderemmo la garanzia che ogni gruppo ha posto su di noi.

È possibile imporre che l'iscrizione ad un gruppo sia valida sintanto che esiste una firma di garanzia posta da uno specifico gruppo, che non deve nemmeno essere necessariamente il mio. Se ad esempio io pongo una firma di garanzia ed impongo che per appartenere al mio gruppo ci debba essere tale firma, alla modifica da parte dell'utente dei propri dati esso viene automaticamente escluso dal mio gruppo sino a nuova certificazione.
Nel caso in cui il mio gruppo accetti l'autorità di certifica di un'altro gruppo, posso fare lo stesso procedimento cercando però eventualmente anche soltanto la firma di tal'altro gruppo, senza che sia necessaria la presenza del mio.

Implicazioni sulla privacy di partecipazione: per poter partecipare anonimamente con un nickname ad un gruppo (o spazio pubblico) che non richiede certificazione sarà possibile definire un alias (o modalità anonima) manualmente o in maniera automatica all'interno dell'account che "nasconda" le informazioni certificate dell'account stesso. Ovviamente l'alias non potrà essere certificato.
Alcuni gruppi chiusi a cui non si vuol mostrare pubblicamente che si partecipa potrebbero voler richiedere una certificazione. In questo caso sarà possibile decidere di nascondere una firma ricevuta e di non renderla pubblica. Ovviamente una firma nascosta non sarà valida per la certificazione in gruppi differenti da quello che l'ha emessa.

Pro rispetto alle soluzioni precedenti

  • La certificazione viene posta sull'utente e non sulla registrazione ad un gruppo, ereditando quindi questo vantaggio dalla soluzione precedente
  • Rispetto alla soluzione precedente il gruppo ha pieno controllo sul processo di certificazione. Questo evita di inserire burocrazia, colli di bottiglia, contratti e dipendenze da enti terzi. Riusciremmo quindi a gestire "tutto in casa"
  • Ogni gruppo è indipendente nei tempi della certificazione, e non deve attendere nessuno
  • Ogni gruppo può definire i propri standard di certificazione (ad esempio alcuni richiedono l'invio di un documento, altri l'incontro di persona)
  • È possibile delegare a piacere e singolarmente per ogni gruppo il processo di certificazione ad altri gruppi ritenuti fidati
  • Viene mantenuta la libertà dell'utente di modificare personalmente i propri dati, e non c'è nessun ente incaricato di fare questo per lui. Ovviamente la pena per questo è di perdere le firme di certificazione ottenute. Questo però rende il sistema molto agile

Solution 5: Autocertificazione dell'account con validazione da parte dei certificatori singoli

Come la soluzione precedente, ma questa si pone come variante che porta ulteriori vantaggi.

La firma non viene posta solo a nome del gruppo, ma a nome del certificatore stesso che per il gruppo è autorizzato a certificare gli utenti. Eventualmente il certificatore può porre la propria firma segnata come "a nome del gruppo XYZ", e quindi varrebbe come duplice firma sia a nome del certificatore, sia a nome del gruppo.
Questo permette di mantenere traccia in ogni momento di chi a certificato chi altro. Se in un qualsiasi momento sorgessero dei problemi con un tale certificatore che ad esempio ha autorizzato delle iscrizioni invalide, io gruppo sarei in grado di:

  1. Rintracciare tutte le persone certificate da questo certificatore
  2. Iniziare una procedura di contatto degli utenti per ripetere il processo di certificazione con un altro certificatore considerato attendibile
  3. Rimuovere il riconoscimento della firma del certificatore invalidato per quanto riguarda la validità d'iscrizione al mio gruppo. Automaticamente tutti e solo gli utenti che sono stati validati dal suddetto certificatore e non da altri smetterebbero di essere accettati

Questa soluzione eredita quindi tutti i vantaggi della precedente, aggiungendo un controllo più sottile per quanto riguarda chi ha agito come certificatore per nome del gruppo e verso chi, permettendo di agire quindi su tutte e solo le certificazioni da lui eseguite.

Eredita anche le implicazioni sulla privacy.

Solution 6: Status quo

Tutto rimane com'è ora

Solution 7: Utilizzare un codice univoco dell'utente impostato automaticamente

Dato che esiste già un codice univoco relativo ad ogni utente inserito nel database per motivi tecnici, con questa soluzione si chiede soltanto di pubblicare quel codice in maniera che ogni utente diventi tracciabile.

Solution 8: Soluzione ibrida tra "Delegare ad un'organismo terzo il compito di certificazione" e "Autocertificazione dell'account con validazione da parte dei certificatori singoli"

Partendo dalla base descritta nella soluzione con autocertificazione, si aggiunge la possibilità alle autority certificatrici di porre la loro firma su di un account per assegnare valore legale, universalmente riconosciuto e non ripudiabile all'identità di tale account. La presenza di questa firma è facoltativa, ed al lato pratico può essere posta o meno come quella di un qualsiasi altro certificatore. Al gruppo la decisione se richiederla o meno come necessaria, e all'utente la scelta se farsi certificare da un'autority o meno.
Con questa soluzione è possibile anche prevedere di avere più autority e gruppi che contemporaneamente saranno in grado di porre la propria firma, e questo può aumentare il grado di sicurezza di tale account.
Per aumentare ancora ulteriormente la sicurezza delle certificazioni (e la non alterabilità da parte di un admin/hacker) è possibile prevedere che le autority utilizzino una chiave pubblica/privata per firmare la propria certificazione, esempio certificato SSL.


Loading contributions, please wait...

Mark the contribution

You can point out to the editors of the proposal that this contribution does not contain relevant information to find a solution to the proposal.
If the contribution is marked 3 times, the editors of the proposal can delete it from the discussion and place it in the "noise" folder.

Non attinente alla discussione o non costruttivo
Duplicato

Report the contribution

You can point out to the webmaster that this contribution violates the laws currently in force.
Once the infringement is ascertained the contribution will be removed. Don't abuse this tool.

Contenuti commerciali o spam
Pornografia o materiale a carattere esplicitamente sessuale
Incitamento all'odio o violenza
Materiale protetto da copyright
×
Europe
America
Asia
Africa
Oceania
  • Europe
  • France
  • Hungary
  • Italy
  • Deutschland
  • România
  • España
  • Portugal
  • Greece
  • United Kingdom
  • Ireland
  • Serbia (Cyrillic)
  • Serbia (Latin)
  • Serbo-Croatian
  • Bosnian
  • Montenegrin (Latin)
  • Russia
  • USA
  • Brasil
  • Ecuador
  • Chile
  • Argentina
  • Indonesia
  • 中国
  • South Africa
  • Australia
  • New Zealand
×
Cookies Text Learn More