CIBA-Initiate process | InGroupe Doc

Please read on CIBA process and eIdent here: https://doc.ingroupe.com/developer/openid-connect#CIBA-flow

↔️ CIBA Flow for TrustID

Call the /ciba endpoint in eIdent with the appropriate parameters

curl -kiSs \
https://www.ident-preprod1.nets.eu/oidc/ciba \
-H Authorization: Basic <<Base64Enocoded username:password>> \
-d scope=openid profile \
-d amr_values=trustid:pin \
-d binding_message=ICB7CiAgInJlcX…..Cg==  (see description below)

Parameter	Description
Authorization	This is basic http authentication. Base64Enocoded of <<username:password>> for the connection to eIdent
scope	This determines the information you will be getting in the idToken and the UserInfo end point when authentication is completed. TrustId supports scopes: • openid • profile The “openid” scope will provide you with the user’s TrustID ( “pid”) upon successful authentication. If “pid” parameter is notr present then the authentication has failed. The “profile” scope will provide you with many more info9rmation on the transaction, including device info, transaction info etc. Tose information will be made available in the “user info” endpoint We recommend that you initiate the CIBA flow with scope=”openid profile”
amr_values	It denotes to eIdent • which identification method you want to use for this call (in this case TrustId) • and your authentication preferences for this method. For TrustId you can choose “pin”, “biometric”, “pin_and_biometric” or just leave it empty (in which case we will define the value of this) You can add multiple values, space separated and in the order of your preference. We would process that list, choosing to use your most preferred method. The actual used authentication method will be returned in the amr claim/attribute of the ID Token Examples: • amr_values=trustid • amr_values=trustid:pin • amr_values= trustid:pin trustid:biometric • amr_values= trustid:pin_and_biometric trustid:biometric trustid:pin
binding_message	It is a base64 encoded json. Please see description in the table below

memo Binding Message

The binding message payload looks like this:
 
{
  "action_context": "authentication"  
  "appId": "0001",
  "bindingMessage": "Approve transaction of 100 Euro to Amazon.com with cardnr:xxxx.xxxx.xxxx.1234?"  
  "userStatus":"active"
}

Parameter		Description
action_context	obligatory	It can be either "authentication” or “provisioning”. Provisioning is used ONLY in the initial set up of the sdk in the app. If the SDK within the app is already configured, a call with "action_context=provisioning" will fail
appId	Obligatory when "action_context” = provisioning", otherwise optional	This is a configurable parameter which you will be getting from us upon configuration on our side of your app that will be using the SDK. You can use this parameter to indicate the app you expect the user to use for this process. It is useful if you have implemented the SDK in multiple apps on your side. In an authentication, if you do not specify the app to be used for this process, any app that has been configured for your client can be used in this process.
bindingMessage	Obligatory only for a consent	This is a text that will be presented directly to the user. It provides the context for the authentication (or validation). It will be presented “As Is” so you chose the language and the text. It is an obligatory parameter. It is also a required element according to PSD2 regulation
userStatus	optional when "action_context= provisioning" Not allowed on action_context=authentication	This is relevant ONLY when "action_context=provisioning". Values “active” or “locked” By default, the new user on our servers will be created with status= “active”. That means that this user can use your app for authentication immediately after the provisioning process is finished. But you can use this parameter to instruct us to create the user with a status = “locked”. In which case, the user is created, the SDK in your app is provisioned but the app cannot be used in any authentication process until you decide to change the status of this user to “active”. You can change the status of tis user at any time by using the relevant admin API. This functionality can be useful when your security department wants to run some extra checks before activating the user. For example, upon provision, you will get from us information on the user’s device, location, and other input useful to your risk management process.

The binding message JSON, should be base64 encoded and passed on as “binding_message” parameter in the call. When encoded, the result is:

ICB7CiAgInJlcXVlc3RUeXBlIjogImF1dGhlbnRpY2F0aW9uIiAKICAiYXBwSWQiOiAiMDAwMSIsCiAgImJpbmRpbmdNZXNzYWdlIjogIkFwcHJvdmUgdHJhbnNhY3Rpb24gb2YgMTAwIEV1cm8gdG8gQW1hem9uLmNvbSB3aXRoIGNhcmRucjp4eHh4Lnh4eHgueHh4eC4xMjM0PyIsIAogICJ1c2VyU3RhdHVzIjoiYWN0aXZlIgp9Cg==

This is what will be posted to the CIBA endpoint using the following command:

curl --location --request POST 'https://www-ident-test.nets.no/oidc/ciba?amr_values=trustid&scope=openid profile&binding_message=ICB7CiAgInJlcXVlc3RUeXBlIjogImF1dGhlbnRpY2F0aW9uIiAKICAiYXBwSWQiOiAiMDAwMSIsCiAgImJpbmRpbmdNZXNzYWdlIjogIkFwcHJvdmUgdHJhbnNhY3Rpb24gb2YgMTAwIEV1cm8gdG8gQW1hem9uLmNvbSB3aXRoIGNhcmRucjp4eHh4Lnh4eHgueHh4eC4xMjM0PyIsIAogICJ1c2VyU3RhdHVzIjoiYWN0aXZlIgp9Cg==' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic encodedcredentials'

↔️ Response of the /ciba end point

The server response expected will look like this:
 {
"auth_req_id":"7d080d66b23e4ec1ad9ea1a238e741ef",
"interval":2,
"expires_in":600
}

Parameter	Description
auth_req_id	An identifier for this process.
interval	Polling interval as “seconds”
expires_in	Number of seconds