E' previsto un aggiornamento della documentazione?

Si potrebbe descrivere:

• come calcolare se il green pass appartiene ad una persona che rientra nell'obbligo partendo dalla data di nascita scritta nel green pass stesso in base a cosa prevede il decreto: 50 anni compiuti il giorno della verifica oppure 50 anni compiuti ad un determinato giorno (quindi nati prima di una data ben precisa)
• descrivere cosa deve succedere se il green pass da tampone di persona che rientra nell'obbligo e' mostrato nella modalità di verifica "base"
• la data di entrata in vigore prevista è il 15/2, è prevista una "regola" nei settings per gestire questa data di entrata in vigore o si intende "cablare" nel codice questa data ?
• l'eta per l'entrata in vigore prevista è 50 anni, è prevista una "regola" nei settings per gestire questa età di entrata in vigore o si intende "cablare" nel codice questa età ?

@astagi
Dalla documentazione DRL.md:

[https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1]
Il Server risponderà a queste request con delle response contenenti le informazioni necessarie ad aggiornare la DRL versione 1 per renderla equivalente alla versione 3:)

Ho due domande:

1. ottengo una risposta con una DIFF non dalla URL [(https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1)] ma dalla URL [https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=1] (senza la parte /check) - ho perso qualcosa della documentazione?
2. non ho capito a quale chunk dell'ultima versione porta la DIFF restituita.

Grazie

Buongiorno a tutti,

attualmente in DgcReader quando viene richiesta la validazione di un greenpass, la libreria consente l'utilizzo di valori non aggiornati, avviando il download degli aggiornamenti di certificati, regole e blacklist in un task in background, fornendo quindi un risultato immediato all'utilizzatore e causando un leggero ritardo nell'utilizzo di valori aggiornati (in pratica, è come se si posticipasse per il tempo necessario al download la scadenza di tali valori, dato che la richiesta di validazione avvierebbe il download, e solo la richiesta successiva potrebbe utilizzare effettivamente i valori aggiornati).

Se però tali valori fossero più vecchi di una soglia limite, definita come MaxFileAge, oppure se nessun valore fosse disponibile (download mai eseguito), allora verrebbe comunque atteso il completamento del download prima di fornire un risultato.

Questo comportamento non causa problemi con certificati e regole, che richiedono pochi secondi per il completamento del download, mentre l'aggiornamento della blacklist al primo download può richiedere anche alcuni minuti.

Mi viene chiesto di consentire di poter saltare l'attesa sul download della blacklist al primo utilizzo, avviando il download in background ma fornendo quindi un risultato senza che la DRL sia stata verificata.
Nella Documentazione per la DGC Revocation List leggo:

1. la verifica della DRL dovrebbe essere implementata come uno step opzionale del processo, in maniera tale che il suo stato possa essere guidato da un apposito configuration item propagato tramite la Piattaforma Nazionale;
2. il mancato aggiornamento della DRL implica una visione potenzialmente non corretta e non completa dell'insieme dei DGC prodotti dalla Piattaforma Nazionale, per tanto dovrebbero essere previsti dei controlli sullo stato di aggiornamento della DRL in grado di inibire la scansione dei DGC

Mi chiedevo quindi se lo step di verifica della DRL potesse essere considerato "opzionale" o comunque non bloccante, in modo da poter posticipare il download e consentire una validazione quasi immediata al primo utilizzo.
In questo caso, potrei aggiungere un parametro opt-in che consentirebbe questo comportamento, ma non sono certo che questo sia conforme al comportamento previsto

Hi,
today the new settings for "full cycle" and "dose booster" IT / not IT are online.
I see that the type is "GENERIC" for all of them.
Can it be assumed that vaccines will no longer be differentiated?
I ask that to know if i have to update the library which now checks "type" (now it works correctly because not finding it cause the correct default values ​​being used).

Collecting the revocation list from scratch today (10/01/22) reports this

{
  "id": "61dc2c60c204fc53f99cd361",
  "version": 35,
  "chunk": 1,
  "numDiAdd": 193786,
  "totalSizeInByte": 10200000,
  "sizeSingleChunkInByte": 510000,
  "totalChunk": 20,
  "totalNumberUCVI": 193786
}

but according to https://github.com/pcm-dpc/COVID-19 (visualization here:
https://opendatadpc.maps.arcgis.com/apps/dashboards/b0c68bce2cce478eaac82fe38d4138b1 ) there are
1,943,979 individuals currently infected.

In my understanding the key totalNumberUCVI is the number of vaccinated GP currently infected + people under attention (people in close contact with the disease). Is this number really less than 10% of current infections or am I misunderstanding its meaning?

Più che una Issue è una richiesta di chiarimento su come dovranno essere fatti i controlli a partire dal 15 Febbraio e se ho capito bene.
Perdonatemi se commetto errori, ma mi sto un po' perdendo tra le differenze.

• Per accesso ai luoghi di lavoro, da parte dei lavoratori, basterà il certificato BASE, ma per gli over 50 servirà il RAFFORZATO.
• Per accedere come visitatori alle strutture residenziali, socio-assistenziali, socio-sanitarie e hospice servirà il BOOSTED o RAFFORZATO + TAMPONE.
• Per accedere invece in negli altri luoghi in cui è previsto il la richiesta del greenpass, non da lavoratore ma come visitatore, basterà il BASE.
• Tralasciando c'è obbligo vaccinale per gli over 50, ma per loro, anche nel caso di visita in altri luoghi dove previsto GP, dovrà esserci un GP rafforzato oppure basterà il base?

Grazie

Issue content

Then openapi.yaml link in the README.md is broken