Traccia in accordo alle nuove specifiche di interoperabilità

[andreapoli]

Obiettivo

Far evolvere la traccia SPCoop in accordo alle nuove specifiche di interoperabilità, con l'obiettivo di:

• soddisfare i requisiti di tracciamento delle Linee Guida di Interoperabilità
• rendere possibile l'uso di JWT per la firma della traccia emessa dal gateway, anche a fini di non ripudio
• proporre lo schema come base di proposta di standardizzazione per l'interscambio di tracce firmate tra fruitori ed erogatori dei servizi applicativi

Saranno realizzate due versioni della traccia:

1. una prima traccia che certifichi l'avvenuto scambio applicativo, senza far riferimento ai contenuti scambiati (esempio).
2. una seconda traccia che estenda la prima con tutti i contenuti applicativi scambiati (header, body e url parameters) , in modo da poter essere utilizzata anche per il non ripudio delle comunicazioni (esempio).

Considerazioni sul non ripudio

1. Se la richiesta è stata firmata dal mittente (tramite http-signature, jws, xml-signature o altri modi ...), la traccia estesa rappresenterà un Token NRO (Non Repudiation of Origin) che accerta l’integrità e l’originalità dei dati contenuti in associazione al mittente. La conservazione dei contenuti firmati all'interno della traccia da parte del soggetto ricevente rappresenta infatti una prova dell’avvenuto invio dei dati contenuti, da parte del soggetto mittente.

2. Se la risposta viene firmata dal destinatario (tramite http-signature, jws, xml-signature o altri modi ...) la traccia estesa rappresenta un Token NRO a parti invertite.

3. La firma della traccia estesa da parte del soggetto ricevente rappresenta un Token NRR (Non Repudiation of Receipt) che riporta le evidenze del messaggio ricevuto con firma del destinatario (sarà possibile per il mittente richiedere la traccia tramite un servizio push o pull, possibilmente da standardizzare in ambito specifiche di interoperabilità.

4. Le medesime considerazioni per il recupero della traccia valgono a parti invertite per rappresentare un Token NRR della risposta.

[andreapoli]

Altro materiale:

• schema in formato yaml
• esempio di traccia che riporta un'autorizzazione negata
• esempio di traccia che riporta un errore interno del gateway
• esempio di traccia firmata
• esempio di tracce previste in SPCoop

[andreapoli]

Una proposta di standardizzazione per l'interscambio di tracce firmate tra fruitori ed erogatori dei servizi applicativi deve anche definire quali sono le modalità in cui è recuperabile il certificato pubblico dell'emittente della traccia al fine di poter effettuare la verifica del jwt firmato.

Possibili soluzioni possono essere:

• Certificato X.509 inserito nell'header del JWT tramite il claim standard x5c
• Certificato X.509 riferito dalla uri indicata nel claim standard x5u
• JSON Web Key inserito nell'header del JWT tramite il claim standard jwk
• JSON Web Key Set + Riferimento della chiave inserite nell'header del JWT tramite i claim standard jku e kid.
• Certificato 'offline' posseduto da chi effettua la validazione della traccia

La soluzione di inserire il certificato x509 o la url nell'header 'x5c' o 'x5u' consente al soggetto che deve validare la traccia di ottenere facilmente il certificato con cui tale traccia è stata firmata. Prima di utilizzare il certifcato deve verificarlo (rispetto alla CA pubblica che lo ha emesso).

[andreapoli]

Ogni traccia deve essere identificabile univocamente attraverso un id.
Si cerca di proporre una standardizzazione anche per l'interscambio di tale identificativo univoco che deve essere recuperato da un Gateway e poi utilizzato successivamente per recuperare la traccia emessa dalla controparte (traccia che rappresenterà il Token NRR).

• In una erogazione, l'identificativo deve arrivare insieme alla richiesta. Possibili modalità sono una parametro della url o un header http.
• In una fruizione, l'identificativo deve arrivare nella risposta come header http.

GovWay attualmente invia tale identificativo, rappresentato dall'id di transazione, nell'header http 'GovWay-Transaction-ID' sia nella richiesta che nella risposta.

Un gateway dovrebbe poi mettere a disposizione un servizio che consente di recuperare la traccia attraverso tale identificatvo. Di seguito una proposta di interfaccia openapi di tale servizio.

[ioggstream]

@andreapoli molto interessante! Potrebbe essere una proposta da portare ad un tavolo più largo - magari con qualche modifica.

I punti:

• definire il subset minimo di dati da tracciare;
• lasciare il formato come estendibile;
• valutare i nomi dei campi;
• valutare una serializzazione non compact dei jws;

[andreapoli]

Per poter discutere su un'istanza e non sullo schema ecco un esempio di traccia convertita nel formato yaml e commentata in ogni campo con l'indicazione anche sull'obbligatorietà.

• definire il subset minimo di dati da tracciare;
• lasciare il formato come estendibile;

Di seguito un esempio di traccia contenente solamente i campi obbligatori. I benefici della strutturazione delle informazioni della richiesta e della risposta (oltre a api e mittente) a loro volta in oggetti non emergono esaminando la traccia con il subset minimo. La strutturazione permette di evitare fastidiosi prefissi 'richiesta_' o 'risposta_' e anche una estensione di tali informazioni risulta più semplice poichè ben localizzata alla struttura dati interessata.

[andreapoli]

• valutare una serializzazione non compact dei jws;

Tutte le possibili modalità utilizzabili per firmare la traccia in JSON Web Signature (JWS) sono:

• esempio di traccia firmata in JSON Compact
• esempio di traccia firmata in JSON Serialization
• esempio di traccia firmata in JSON Serialization - Unencoded Payload Option
• esempio di traccia firmata in JSON Serialization - Detached
• esempio di traccia firmata in JSON Compact - Detached

La modalità JSON Serialization con 'Unencoded Payload Option' consente di avere una traccia firmata 'in chiaro' (non codificata tramite base64 etc...). I caratteri utilizzati all'interno traccia devono soddisfare le restrizioni indicate nel RFC 7797.

Le modalità 'detached', citate anche all'interno della specifica JWS - Unencoded Payload Option, permettono di non doversi preoccupare delle restrizioni.

[andreapoli]

@ioggstream nei precedenti commenti trovi qualche riflessione sui punti da te sollevati.