---
title: Note per progetto OTP via SMS con PIN
tags: Mercury
---

## TODO Progetto

* Minos: verificare come si comporta ora dopo modifica il giro OTS (business con OTP SMS). Mostra il PIN? Funziona correttamente?
*(incredibile ma vero) Funziona correttamente!

* Minos / 3DS2: Verificare cosa succede se i servizi banca non rispondono o danno errore: viene concesso un altro tentativo? si va in fallback? fallisce l'autenticazione?

* capire con Monica/Orazio scenario "Utenza bloccata per troppi PIN errati"
* è uno scenario `UNSOLVABLE ERROR`, che comporta il terminare la transazione e mostrare la faccina triste

* chiedere a Orazio/Monica: quale è la card associata allo userId `05057361`

* se utente sbaglia PIN o SMS
* se sbaglia PIN, fa comunque auth SMS, poi mostra schermata PIN di retry con la scritta "Credenziali errate"
* se inserisce PIN corretto, e sbaglia SMS, mostra schermata PIN di retry con la scritta "Credenziali errate"

* in caso di errore tecnico (es. servizio non raggiungibile) sia in fase PIN che SMS, si comporta come in caso di errore utente. Mostra quindi sia schermata PIN che SMS, poi mostra nuovamente schermata PIN con scritta "Errore tecnico - riprovare" (o messaggio simile, chiarire messaggio con Orazio e Monica)

- [ ] scrivere UAT per scenari PIN with SMS

### Note tecniche e domande

* quando inseriamo PIN/SMS errati restituiamo response che ha sempre attempt #0

Response body: <400 BAD_REQUEST Bad Request,Failure(errorCode=INCORRECT_OTP, errorDescription=INCORRECT_OTP for two  actor authentication code 'qwerty2' for attempt #0, userMessage=, challengeInfo=[ChallengeStep(authenticationType=OTP, choiceCode=NONE, step=1), ChallengeStep(authenticationType=OTP, choiceCode=NONE, step=2)], userInterfaceInformation=[]),[]>

se usiamo autenticazione solo SMS attemptCount è corretto

**Nota** ci viene inviato da Nets, nella request della `checkOTP`

* che scenari testano i nostri AT di Issuer? SMS con o senza PIN?
* SMS senza PIN. Funzionano solo se flag `pinWithOTPSms` è disattivato in `application-development.yaml`
* gli UAT dovrebbero impostare la property `pinWithOTPSms` a true/false prima di partire

* come gestiamo ora in Issuer le utenze bloccate?
* errore `AUKO_41` => utenza bloccata, restituisce `UNSOLVABLE_ERROR` e fallisce transazione

## Errore invio SMS utenze business da Minos

Su Minos quando si utilizza una carta business con utenza private abilitata a SMS, dopo la `/checkstatus` viene inviato un SMS all'utente della private (`/generateotpviasms`).

Questo comportamento c'è da un po' di tempo, almeno dal 17/04/2020.

Una traccia è nel file `b1 -2020-04-17.minos-application.log`, parte del file `2020-04-17.zip` inviato da Orazio su #minos.

Cercare nel log l'accountId `zWQrMiEFLftF0000000057983339`

## call con N&TS

Nella risposta della RISK noi torniamo `challengeInfo`.

Nel darmi errore nel messaggio di errore, nel tag UserInterfaceInfo possiamo mettere OTP / PIN
nel 412 + corpo dell'error message per decidere cosa fare ...

nuovo tipo "PIN" nello step per la GUI

qui dipende dalla banca: possiamo dire Y al primo step e andare avanti lo stesso, altrimenti dobbiamo tornare alla wrong.jsp

Step:
  type: object
  required:
    - authenticationType
  properties:
    authenticationType:
      type: string
      description: >-
        Indicates whether a transaction qualifies as an authenticated
        transaction or account verification.
      example: >-
        OTP(One Time Password authentication)
        OOB(Out of band authentication)
        NONE(No authentication type to provide. Used only for FRICTIONLESS, DENIED and REJECTED status)
        CHOICE(A choice is required from the user to complete the authentication)
        PIN (nuovo tipo)
    choiceCode:
      type: string
      description: >-
        Describe the choice to be made (set to "NONE" if "authenticationType" is not "CHOICE").
        QUI METTIAMO PIN, per la GUI mostrare le label giuste (la pagina sarà la stessa )
        viene traghettato fino alla GUI 
    step:
      type: integer
      description: >-
        Describe the current step number in the actual authentication flow.
        In case of a multi-factor authentication, indicates the execution order of the authentication system.
        Initial value is 1.

{
  "authenticationId": "17b9946c-3a81-11e9-b210-d663bd873d93",
  "authenticationStatus": "Y(Authentication/ Account Verification Successful) N(Not Authenticated /Account Not Verified; Transaction denied) C(Challenge Required; Additional authentication is required using the CReq/CRes) R(Account Verification Rejected; Issuer is rejecting authentication/verification and request that authorisation not be attempted) U(Authentication/ Account Verification Could Not Be Performed; Technical or other problem, as indicated in ARes or RReq)",
  "challengeInfo": [
    {
      "authenticationType": "OTP",
      "choiceCode": "NONE"
      "step": 2
    },
    {
      "authenticationType": "OTP",
      "choiceCode": "PIN",
      "step": 1
    }
  ],
  "authenticationStatusReasonCode": "CARDHOLDER_NOT_ENROLLED,PAN_NOT_FOUND,EXPIRED_CARD,INVALID_CARD_NUMBER,STOLEN_CARD",
  "authenticationStatusReasonDescription": "The given PAN was not found"
}