You can follow these steps to integrate no-code identity link support to your application:

• Send identity link HTTP request to ADUCID Binder
• Process authentication on ADUCID Binder
• Read identity link JSON response

See chapters below for details.

At first, identity link must be prepared and sent to ADUCID Binder. ADUCID Binder accepts identity link HTTP requests at /aducid-binder/prepareIdentityLinkUpload. Before ADUCID Binder call, unique identifier (aka identityLinkId) must be generated. This identifier is neccessary to successfully pair identity link request and response. Let's see ADUCID Binder identity link interface parameters:

It is neccessary to add identityLinkId parameter to redirectUrl attribute to successfully pair identity link request and response. If errorPage is not defined, redirectUrl is used in case of error. Now we can send prepared request to /aducid-binder/prepareIdentityLinkUpload and check successful identity link upload (HTTP code 200).

We must also remember to provide generated identity link identifier to web view, e.g. Ajax JSON response or JSP expression language.

When identity link data are successfully uploaded, we can start identity link itself. It can be done with use of Client API for Web Integration. We only need to specify right ADUCID Binder methods to serve identity link:

aducid.setStartOperationUrl("/aducid-binder/identityLinkJson?identityLinkId=" + response.data);
aducid.setResultOperationUrl("/aducid-binder/identityLinkCheck");
aducid.setProxyUrl("/aducid-binder/proxy");

Expression response.data contains unique identity link identifier pushed from backend to view. After identity link run, user is redirected to redirectUrl value (or to errorPage if defined and error occurs).

User is now redirected to redirectUrl, where we must process identity link operation result. Operation result is saved in HTTP request attributes. We try to read attribute with prefix AAA_ULR_ with identity link identifier at the end. When value exists, we must invoke base64 decoding on value to get readable JSON response.

There is also saved used remote AIM in HTTP attributes. It can be accessed as an attribute with prefix AAA_ULR_RA_ with identity link identifier at the end. This value is saved as it is, it is not base64 encoded.

When identity link was successful (status = OK), JSON response will be:

{
  "status": "OK",
  "data": null,
  "redirect": null
}

When request value was used in identity link setup (e.g. {“eidProviderMethod”:“READ_EID_USER_DATA”,“data”:null}), data will be filled in service provider response. For example:

{
  "status": "OK",
  "data": {
    "firstName": "John",
    "firstNameApproved": true,
    "lastName": "Green",
    "lastNameApproved": true,
    "permanentAddress": "Castle Road 54, Green Town, CF72 2YD",
    "permanentAddressApproved": true,
    "identityCardNumber": "ID97967588",
    "identityCardNumberApproved": true,
    "identityCardValidTo": "2023-05-10",
    "identityCardValidToApproved": true,
    "birthDate": "1971-10-09",
    "birthDateApproved": true,
    "deliveryAddress": "Castle Road 54, Green Town, CF72 2YD",
    "deliveryAddressApproved": true,
    "telephoneNumber": "+44 654 987 987",
    "telephoneNumberApproved": true,
    "voter": true,
    "voterApproved": true,
    "creditCardNumber": "4485 5057 0701 1520",
    "creditCardNumberApproved": true,
    "creditCardValidTo": "09/2022",
    "creditCardValidToApproved": true,
    "creditCardOwner": "John Green",
    "creditCardOwnerApproved": true,
    "gender": "male",
    "genderApproved": true,
    "email": "john.green@test.com",
    "emailApproved": true,
    "approvedLF": true,
    "proofingStatus": "APPROVED"
  },
  "redirect": null
}

See Transaction support, Negative response chapter.