Firma con strong auth

E' possibile eseguire la firma con strong auth di n hashes sia con token API che con token OWNER.
Per questa tipologia di firma sono utilizzabili solo certificati di tipo FEQ e ONESHOT.
A differenza della firma massiva, la firma con strong auth prevede una serie di chiamate poichè richiede l'apertura di una sessione di firma, l'autenticazione tramite strong auth e poi la possibilità di firmare n hashes, anche con chiamate successive.

Il numero massimo di hashes che si possono firmare in una sessione è definito in configurazione.

Le chiamate per eseguire una firma con strong auth in caso di token API e token OWNER differiscono solo nella prima chiamata.

Apertura sessione di firma

Token API

L'apertura di una sessione con token API, quindi eseguita da un dato cliente, può essere eseguita tramite il servizio:

Apertura sessione

I dati da fornire sono:

• l'alias dell'owner per cui firmare in path param

{
  "certificateAlias": "123",
  "strongAuth": "type",
  "maxSignatures": n,
  "webhook": {
    "url": "url"
  }
}

dove:

• certificateAlias è il certificato da utilizzare (deve essere di tipo AUTO o SEAL).utilizzare. Il certificato DEVE essere un certificato che appartiene all'owner indicato E al customer relativo al token. Non è obbligatorio.
• certificate.pinstrongAuth è il tipo di strong authentication prevista. I valori possibili sono:
• SMS_OTP: strong auth tramite otp inviato per sms

PHONE_CALL: strong auth tramite chiamata telefonica maxSignatures è il numero di firme che si vogliono effettuare nella sessione webhookUrl è l'url, opzionale, del webhook su cui si possono ricevere i cambi stato della firma. Tale webhook verrà utilizzato in base al tipo di strong auth: es. l'SMS_OTP non lo prevede, PHONE_CALL sì.

In ritorno si ottiene la sessione appena aperta con le seguenti info:

{
    "id": "64a19ba4ba848a71caae31d8",
    "certificateAlias": "44040",
    "signatureTimeout": "PT10M",
    "strongAuthTimeout": "PT5M",
    "strongAuth": "SMS_OTP",
    "maxSignatures": 20,
    "completedSignatures": 0,
    "status": {
        "value": "OPENED",
        "step": null,
        "remaining": null
    },
    "createdAt": "2023-07-02T15:45:40.025663395",
    "lastModifiedAt": "2023-07-02T15:45:40.025663395"
}

Token OWNER

L'apertura di una sessione con token ONWER, quindi eseguita da un dato titolare, può essere eseguita tramite il servizio:

Apertura sessione

I dati da fornire sono:

{
  "certificateAlias": "123",
  "strongAuth": "type",
  "maxSignatures": n,
  "webhook": {
    "url": "url"
  }
}

dove:

certificateAlias è il certificato da utilizzare. Il certificato DEVE essere un certificato che appartiene all'owner indicato E al customer relativo al token. Non è obbligatorio. strongAuth è il tipo di strong authentication prevista. I valori possibili sono:

SMS_OTP: strong auth tramite otp inviato per sms PHONE_CALL: strong auth tramite chiamata telefonica maxSignatures è il numero di firme che si vogliono effettuare nella sessione webhookUrl è l'url, opzionale, del webhook su cui si possono ricevere i cambi stato della firma. Tale webhook verrà utilizzato in base al tipo di strong auth: es. l'SMS_OTP non lo prevede, PHONE_CALL sì.

In ritorno si ottiene la sessione appena aperta con le seguenti info:

{
    "id": "64a19ba4ba848a71caae31d8",
    "certificateAlias": "44040",
    "signatureTimeout": "PT10M",
    "strongAuthTimeout": "PT5M",
    "strongAuth": "SMS_OTP",
    "maxSignatures": 20,
    "completedSignatures": 0,
    "status": {
        "value": "OPENED",
        "step": null,
        "remaining": null
    },
    "createdAt": "2023-07-02T15:45:40.025663395",
    "lastModifiedAt": "2023-07-02T15:45:40.025663395"
}

A questo punto si procede in base alla tipologia di strong auth prevista dalla sessione.

Da questo momento in poi, è importante chiamare questo metodo con un token della stessa tipologia di quella usata per l'apertura e con lo stesso customerId in caso di API o owner in caso di OWNER.

1. SMS_OTP

Invio otp

Occorre inviare un OTP tramite il servizio

Invio OTP

fornendo in path param l'id di sessione ritornato al punto precedente.

Validazione otp

Occorre validare l'OTP

Validazione OTP

fornendo in path param l'id di sessione ritornato al punto precedente e l'otp inviato nel body.

2. PHONE_CALL

Avvio chiamata

Occorre avviare la chiamata tramite il servizio

Avvio chiamata

fornendo in path param l'id di sessione ritornato al punto precedente.

Dopo l'avvio della chiamata, i cambi di stato della sessione verranno comunicati all'integratore tramite webhook.

 

Firma hashes

Una volta completata la strong auth, la sessione si troverà in stato READY, cioè pronta per la firma.

Solo a questo punto sarò possibile chiamare il servizio:

Firma

con i seguenti valori:

id sessione in path param

{
  "certificatePin": "12345678",
  "hashes": [
    "myMXwslBoXkTDQ0olhq1QsiHRWWL4yj1V0IuoK+PYOg="
  ]
}

certificatePin è il pin del certificato da utilizzareutilizzare, sempre che il certificato ne preveda uno. hashes  è la collection di hashes in base64 da firmare. Gli hash devono essere in base64 e ottenuti con algoritmi consentiti dalla CA

La firma massiva con token OWNER, quindi eseguita da un dato titolare, può essere eseguita tramite il servizio: 

Firma massiva

I dati da fornire sono:

{
  "certificate": {
    "alias": "44039",
    "pin": "12345678"
  },
  "hashes": [
    "MGUifMonFmJHfa51PKL0jPxuP3bjwSQ13s42GMxQMwk="
  ]
}

dove:

certificate.alias è il certificato da utilizzare (deve essere di tipo AUTO o SEAL). Il certificato DEVE essere un certificato che appartiene all'owner relativo al token. certificate.pin è il pin del certificato da utilizzare hashes è la collection di hashes in base64 da firmare. Gli hash devono essere in base64 e ottenuti con algoritmi consentiti dalla CA

In ritorno si ottiene la lista degli hash firmati.