Proposta: segnalazione requisiti nuove versioni SDK

DevTrevi commented 2 years ago

Buongiorno a tutti,

Per mantenere allineate le implementazioni degli SDK certificati, sarebbe utile avere a disposizione le specifiche richieste per ciascuna nuova versione dell'sdk.

Attualmente per riportare le nuove features dell'sdk ufficiale è necessario analizzare il codice confrontandolo con quello della versione precedente, ed essendo i vari sdk indipendenti organizzati diversamente a livello di codice, diventa facile saltare o male interpretare qualche funzionalità.

Se fosse possibile, sarebbe utile avere una descrizione di ciascuna feature prevista per la successiva versione dell'sdk prima del suo rilascio, in modo da poter allineare gli sdk parallelamente a quello ufficiale. Un'idea potrebbe essere l'utilizzo di issues raggruppate in milestones tracciate all'interno del repository ufficiale, ciascuna delle quali descriva le specifiche e il contesto di utilizzo delle nuove features che dovranno essere implementate

Es:

Milestone 1.1.0
- Issue: deprecato PARTIALLY_VALID (descrizione...)
- Issue: nuova gestione blacklist (descrizione, contesto...)
Milestone 1.2.0
- Issue: nuova feature....

In alternativa si potrebbero usare dei changelog, o delle issue nei repository dei vari SDK Pensate sia possibile implementare uno di questi metodi, oppure qualche altro meccanismo alternativo?

rawmain commented 2 years ago

Buongiorno @DevTrevi

Per mantenere allineate le implementazioni degli SDK certificati, sarebbe utile avere a disposizione le specifiche richieste per ciascuna nuova versione dell'sdk. [...] Se fosse possibile, sarebbe utile avere una descrizione di ciascuna feature prevista per la successiva versione dell'sdk prima del suo rilascio, in modo da poter allineare gli sdk parallelamente a quello ufficiale.

L'aggiunta del changelog - proprio per agevolare gli sviluppatori di SDK/Librerie terze autorizzate nelle verifiche di allineamento aggiornamenti SDK - è già prevista.

Non è ancora confluito in main branch, ma puoi già vederne l'implementazione base in feature branch

https://github.com/ministero-salute/it-dgc-verificac19-sdk-onboarding/blob/feature/changelog/CHANGELOG.md

DevTrevi commented 2 years ago

Buongiorno @rawmain , ti ringrazio, non mi ero accorto che fosse già presente nel repository 👍

astagi commented 2 years ago

@DevTrevi @rawmain CHANGELOG confluito, chiudo la issue. Sarebbe sicuramente utile poter arricchire il changelog anche di pseudocodice che descriva la feature da implementare. Nel caso della DRL c'è una documentazione ad hoc, nel caso della nuova modalità booster forse uno pseudocodice potrebbe aiutare i maintainer dell'SDK, che ne dite?

astagi commented 2 years ago

@DevTrevi @rawmain ecco cosa volevo mettere nel README di onboarding.

Per ricevere le notifiche dei vari cambiamenti nel SDK Android principale, si consiglia di mettersi in "watch" su questo repository. Le pull request che andranno ad aggiornare il file di CHANGELOG (https://github.com/ministero-salute/it-dgc-verificac19-sdk-onboarding/blob/main/CHANGELOG.md) conterranno informazioni utili per gli sviluppatori degli SDK ufficiali di terze parti ai fini di implementare correttamente le ultime funzionalità.

Pensate possa essere un ulteriore aiuto? taggo anche @salmattia @marcoserafini2

marcoserafini2 commented 2 years ago

Grazie @astagi sicuramente aiuta.

salmattia commented 2 years ago

Ottimo, grazie @astagi

DevTrevi commented 2 years ago

Grazie mille @astagi

@DevTrevi @rawmain CHANGELOG confluito, chiudo la issue. Sarebbe sicuramente utile poter arricchire il changelog anche di pseudocodice che descriva la feature da implementare. Nel caso della DRL c'è una documentazione ad hoc, nel caso della nuova modalità booster forse uno pseudocodice potrebbe aiutare i maintainer dell'SDK, che ne dite?

Anche questo può aiutare sicuramente in qualche caso particolarmente complesso, ma già avere una breve specifica potrebbe essere sufficiente. La descrizione della v1.1.1 nel changelog riguardo il booster ad esempio mi sembra chiara, mancherebbe invece una descrizione riguardo la modifica ai certificati di guarigione "isRecoveryBis" Guardando l'implementazione mi sembra di capire che alcuni certificati di guarigione vengano firmati con una chiave diversa per permettere di identificarli e applicare una scadenza diversa, ma non ho ben capito qual'è il contesto. In questo caso una breve descrizione simile a quella per il booster aiuterebbe a inquadrare la modifica

rawmain commented 2 years ago

Ciao @astagi , @DevTrevi , @marcoserafini2 & @salmattia

nel caso della nuova modalità booster forse uno pseudocodice potrebbe aiutare i maintainer dell'SDK, che ne dite?

Good idea. Doc per gestione scanmode (stile quello DRL) agevola in ogni caso nelle verifiche di conformità per flussi validazioni in base a switch scanmode.

Intanto riporto qui flusso base e tabella di controllo per DGC V, in modo che possiate darci una prima occhiata.

Più tardi vedo di trovare il tempo per arrangiare una prima bozza, sottoponendola via PR a feat/documents (o tramite PR distinta, se lo ritenete più corretto).

Flusso_BOOSTER_OK

dn/sd	MedicinalProduct	Vaccination	Status
1/1	JOHNSON	Cycle	TEST_NEEDED
1/2	any	Partial	NOT_VALID
2/1	any	Booster	VALID
2/2	JOHNSON	Booster	VALID
2/2	any except JOHNSON	Cycle	TEST_NEEDED
3/2	any	Booster	VALID
3/3	any	Booster	VALID

astagi commented 2 years ago

Certo, come preferisci @rawmain questo schema è a dir poco fantastico! Grande contributo, grazie mille!

rawmain commented 2 years ago

Ciao @astagi

Certo, come preferisci @rawmain questo schema è a dir poco fantastico! Grande contributo, grazie mille!

Ok & grazie ;).

Ho già impostato la bozza, ma potrò finalizzare il doc per review cmq solo dopo cena / in tarda serata.

Intanto, una domanda operativa = in modo da mantenere allineamento con impostazioni documentazione DGC, avevo valutato il seguente flusso :

PR in repo it-dgc-documentation = aggiunta SCANMODE.md + immagini in subdir \img
PR in repo it-dgc-verificac19-sdk-onboarding = aggiornamento README.md per aggiunta ref/link SCANMODE.md in Documenti

Fammi sapere pls se OK o se ritieni più adeguato altro flusso per inoltro.

astagi commented 2 years ago

Direi perfetto come flusso @rawmain aggiungerei la reference del documento anche sul README.md principale di it-dgc-documentation, come la DRL. Grazie infinite!

rawmain commented 2 years ago

Ciao @DevTrevi

mancherebbe invece una descrizione riguardo la modifica ai certificati di guarigione "isRecoveryBis" Guardando l'implementazione mi sembra di capire che alcuni certificati di guarigione vengano firmati con una chiave diversa per permettere di identificarli e applicare una scadenza diversa, ma non ho ben capito qual'è il contesto. In questo caso una breve descrizione simile a quella per il booster aiuterebbe a inquadrare la modifica

Mi ero perso prima questo passaggio. Vedrò come inserire la parte relativa, sebbene non influenzi la gestione scanmode.

Quel PV che trovi indicato per i value start/end di ALT_Recovery corrisponde a post-vaccinazione. Tratto dalle FAQ DGC :

se si è contratta l’infezione Covid-19 oltre il quattordicesimo giorno dalla somministrazione della prima dose di vaccino oppure dopo il completamento del ciclo vaccinale primario oppure dopo la dose di richiamo (booster), la Certificazione è generata entro il giorno seguente l’emissione del certificato di guarigione.

Questa nuova Certificazione verde COVID-19 per guarigione post vaccinazione, valida per 9 mesi dalla data del certificato di guarigione, verrà emessa a partire dal 28 dicembre 2021.

Per quanto riguarda la validazione in funzione della modalità impostata per tipologia di verifica, sono quindi equivalenti ai certificati base di guarigione con durata 180gg.

Vengono semplicemente riconosciuti / distinti da quelli base, onde validarli correttamente in virtù della diversa scadenza, tramite il controllo delle entry extendedKeyUsage :

OID	DGC	Verificata da SDK per applicazione Validation Rules
1.3.6.1.4.1.1847.2021.1.1	Test (PCR/RAT)	NO
1.3.6.1.4.1.1847.2021.1.2	Vaccination (Partial / Cycle / Booster)	NO
1.3.6.1.4.1.1847.2021.1.3	Recovery 180gg	SI
1.3.6.1.4.1.0.1847.2021.1.3	Recovery PV 270gg	SI

DevTrevi commented 2 years ago

Grazie per la spiegazione @rawmain , immagino che questi OID non siano uno standard tra i paesi UE ma che siano specifici dei certificati di firma italiani, è corretto? Per i certificati di guarigione non rilasciati in Italia quindi vale sempre la regola dei 180gg?

rawmain commented 2 years ago

Ciao @DevTrevi

Grazie per la spiegazione @rawmain

Prego ;) .

, immagino che questi OID non siano uno standard tra i paesi UE ma che siano specifici dei certificati di firma italiani, è corretto?

In base alle specifiche tecniche DGC le entry extendedKey sono definite come non-critical per validazione DGC :

possono essere usate per applicare policy nazionali/specifiche di validazione
app/piattaforme di validazione devono poter gestire correttamente anche OID custom = l'eventuale presenza di entry extendedKey con OID nuovi/sconosciuti NON deve essere fattore di KO in validazioni DGC

I primi 3 OID li ritrovi indicati come standard/comuni nelle specifiche DGC Volume 5 - V1.1 (2021-11-17), mentre il 4° è anch'esso comunque un OID noto/usato precedentemente = lo ritrovi già nel set delle specifiche DGC Volume 1 - V1.0.5 (2021-04-21).

Per i certificati di guarigione non rilasciati in Italia quindi vale sempre la regola dei 180gg?

Corretto.

La funzione isRecoveryBis verifica infatti in prima battuta se il certificato di guarigione sia stato emesso in Italia o meno (ved. controllo countryOfVaccination) = se non è IT, restituisce direttamente false senza controllare entry extendedKey.

DevTrevi commented 2 years ago

Tutto chiarissimo, grazie ancora per le informazioni @rawmain 👍

rawmain commented 2 years ago

Ciao @astagi , @DevTrevi , @marcoserafini2 & @salmattia

Causa emergenze prioritarie, ho potuto sottoporre solo ora le PR per il caricamento del doc ScanMode - relativo alle tipologie di verifica DGC & per l'allineamento dei link risorse VerificaC19 .

PR 6 it-dgc-documentation
PR #18

Se volete dare un'occhiata al documento - anche in ottica obv di critiche e/o suggerimenti di aggiunte/modifiche - lo trovate anche QUI.

Ho evitato di renderlo troppo tecnico, considerato che potrebbe servire per spiegare perché il Ministero della Salute stia già procedendo all'emissione di DGC nuovi per coloro, che hanno ricevuto DGC richiamo eterologo post 1° dose Johnson con codifica ambigua dn/sd 2/2.

Per il resto, visto che ormai manca poco, Auguri di Buon Anno Nuovo ;) .

DevTrevi commented 2 years ago

Grazie @rawmain , auguri di buon anno a tutti 🥳

SickBoy84 commented 2 years ago

Ciao @rawmain e scusami per la domanda da principiante, ma ci sto sbattendo la testa da 3 ore senza venirne a capo, riguardo questo:

1.3.6.1.4.1.1847.2021.1.3 Recovery 180gg SI 1.3.6.1.4.1.0.1847.2021.1.3 Recovery PV 270gg SI

Dove è possibile recuperare l'OID per capire se si tratta di un certificato di guarigione post-vaccinazione (validità illimitata?!) oppure "normale"?

Grazie per l'aiuto!

rawmain commented 2 years ago

Ciao @SickBoy84

scusami per la domanda da principiante, ma ci sto sbattendo la testa da 3 ore senza venirne a capo

Figurati, non ti preoccupare ;) .

Dove è possibile recuperare l'OID per capire se si tratta di un certificato di guarigione post-vaccinazione (validità illimitata?!) oppure "normale"?

Verifichi/recuperi gli eventuali extension field dal certificato X509 della chiave pubblica (DSC - Document Signer Certificates). Esemplificando :

$> openssl x509 -noout -ext extendedKeyUsage < crt
X509v3 Extended Key Usage: 
     ...

\ Questo è proprio ciò, che fa il DGC-SDK Android/Kotlin (ved. CertificateModel.kt) quando verifica i soli DGC R (guarigione) emessi dall'Italia, onde rilevare se siano di tipo base guarigione, oppure R-PV guarigione post-vaccinazione.

enum class CertCode(val value: String) {
    OID_RECOVERY("1.3.6.1.4.1.1847.2021.1.3"),
    OID_ALT_RECOVERY("1.3.6.1.4.1.0.1847.2021.1.3"),
}

[...]

    fun isRecoveryBis(
        cert: Certificate?
    ): Boolean {
        takeIf { it.isFrom(Country.IT) }
            .let {
                cert?.let {
                    (cert as X509Certificate).extendedKeyUsage?.find { keyUsage -> CertCode.OID_RECOVERY.value == keyUsage || CertCode.OID_ALT_RECOVERY.value == keyUsage }
                        ?.let {
                            return true
                        }
                }
            } ?: return false
    }

Idem per gli altri SDK autorizzati = cambiano linguaggi/sintassi, ma la logica è la medesima.

\ Pertanto, il discorso R PV riguarda solo DGC R emessi dall'Italia (co = IT) & con chiave DSC CN=Italy DGC DSC 4, O=Ministero della Salute, C=IT.

Infatti, solo per tale chiave si è fatto ricorso in Italia a tali Extended Key Usage extension fields specifici. Inoltre, tale DSC è usata per i soli DGC R-PV emessi a partire dal 28/12.

\ Non vi è quindi distinguo tra i 2 OID & il controllo R-PV si riduce ai seguenti if check :

Se viene rilevato un extension field nel DSC & con valore 1.3.6.1.4.1.0.1847.2021.1.3 , allora il DGC R IT viene gestito come R P-V per quanto concerne start/end (e quindi la durata ai fini della validazione).
Se viene rilevato tale campo con valore 1.3.6.1.4.1.1847.2021.1.3, allora il DGC R IT viene ancora gestito come R P-V.
Se non viene rilevato tale campo con uno di quei 2 valori OID, allora il DGC R IT viene gestito come semplice/base R

Da cui la seguente tabella - allineata agli attuali valori start/end in Validation Rules :

Country	OID	DGC
IT	1.3.6.1.4.1.1847.2021.1.3	Recovery PV (540gg dal 07/02/2022)
IT	1.3.6.1.4.1.0.1847.2021.1.3	Recovery PV (540gg dal 07/02/2022)
IT	assente / diverso	Recovery IT (180gg)
NOT_IT	non viene controllato	Recovery NOT_IT (270gg dal 01/02/2022)

SickBoy84 commented 2 years ago

Grazie @rawmain , davvero gentilissimo!

ministero-salute / it-dgc-verificac19-sdk-onboarding

Proposta: segnalazione requisiti nuove versioni SDK #15