Interactions

An app can support different interaction types and a relying party can demand a particular interaction with or without a fallback possibility. Different interactions can support different amount of data to display information to user.

Available interactions are listed in the following table. Availability depends on what type of flow is used. Each interaction is defined by an object that has 2 parameters: type and either displayText60 or displayText200. All possible type value and extra parameter combinations are also listed in the following table.

Parameters used for dynamic link generation
Interaction type & extra parameter	Description	Dynamic link flows	Notification based flows
`displayTextAndPIN with displayText60`	The simplest interaction with max 60 chars of text and PIN entry on a single screen.	Yes	No
`confirmationMessage with displayText200`	First screen is for text only (max 200 chars) and has Confirm and Cancel buttons. Second screen is for PIN.	Yes	No
`verificationCodeChoice with displayText60`	Verification Code Choice interaction. First screen is for code choice and second screen is with max 60 chars text and PIN like `displayTextAndPIN` is.	No	Yes
`confirmationMessageAndVerificationCodeChoice with displayText200`	First screen combines text and Verification Code choice. Second screen is for PIN.	No	Yes

RP uses allowedInteractionsOrder array to list interactions it allows for the current session. Not all app versions may support all interactions though. The Smart-ID server is aware of which app installations support which interactions.

RP is not allowed to list interaction types not meant for the flow (dynamic link flow or notification based flow). Listing an inappropriate interaction in the allowedInteractionsOrder will result in an error (HTTP 400 Bad Request).

When processing an RP request the first interaction supported by the app is taken from allowedInteractionsOrder array and sent to the app.

The interaction that was actually used is reported back to RP with interactionFlowUsed response parameter to the session request. If an app cannot support any interaction requested then the session is cancelled with reason code REQUIRED_INTERACTION_NOT_SUPPORTED_BY_APP.

Example allowedInteractionsOrder elements

RP first choice is confirmationMessage, if not available then fall back to displayTextAndPIN.

{
  "allowedInteractionsOrder": [
    {
      "type": "confirmationMessage",
      "displayText200": "Longer description of the transaction context"
    },
    {
      "type": "displayTextAndPIN",
      "displayText60": "Short description of the transaction context"
    }
  ]
}

RP first choice is confirmationMessageAndVerificationCodeChoice, if not available then verificationCodeChoice should be used.

{
  "allowedInteractionsOrder": [
    {
      "type": "confirmationMessageAndVerificationCodeChoice",
      "displayText200": "Longer description of the transaction context"
    },
    {
      "type": "verificationCodeChoice",
      "displayText60": "Short description of the transaction context"
    }
  ]
}

displayTextAndPIN only.

{
  "allowedInteractionsOrder": [
    {
      "type": "displayTextAndPIN",
      "displayText60": "Short description of the transaction context"
    }
  ]
}

Insists on confirmationMessage, if not available then fail.

{
  "allowedInteractionsOrder": [
    {
      "type": "confirmationMessage",
      "displayText200": "Longer description of the transaction context"
    }
  ]
}