[MS-1346] Identification response now contains scanned external credential data

[alexandr-simprints]

JIRA ticket
Will be released in: 2025.4.1

Notable changes

Identification responses now include a scannedCredential object that contains information on the credential scanned during the ID workflow: value and type.

Response example:

  "identifications": [],
  "sessionId": "9943a6e1-86bb-47ec-af57-2f6f34c2f380",
  "scannedCredential": {
    "type": “NHIS”,
    "value": “12345678”
  }
}

Testing guidance

• Start and Identification process using the Custom Intent page in the Intent Launcher app
• Scan both biometrics and ID
• Verify that the scannedCredential field is present in the response

Additional work checklist

• Effect on other features and security has been considered
• Design document marked as "In development" (if applicable)
• External (Gitbook) and internal (Confluence) Documentation is up to date (or ticket created)
• Test cases in Testiny are up to date (or ticket created)
• Other teams notified about the changes (if applicable)

[Copilot]

Pull request overview

This pull request adds scannedCredential information to identification responses, enabling calling applications to receive data about external credentials (such as NHIS cards) that were scanned during the identification workflow. The change extends the identification response to include the credential type and value.

Changes:

• Added scannedCredential field to identification response data models (AppIdentifyResponse and ActionResponse.IdentifyActionResponse)
• Implemented credential extraction and mapping logic in CreateIdentifyResponseUseCase
• Updated response mappers to serialize scannedCredential to JSON in client API responses

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
infra/orchestrator-data/src/main/java/com/simprints/infra/orchestration/data/responses/AppIdentifyResponse.kt	Added nullable scannedCredential field to AppIdentifyResponse data class
infra/orchestrator-data/src/main/java/com/simprints/infra/orchestration/data/ActionResponse.kt	Added nullable scannedCredential field to IdentifyActionResponse data class
feature/orchestrator/src/main/java/com/simprints/feature/orchestrator/usecases/response/CreateIdentifyResponseUseCase.kt	Implemented logic to extract ExternalCredentialSearchResult and map scannedCredential to AppExternalCredential
feature/orchestrator/src/main/java/com/simprints/feature/orchestrator/usecases/MapRefusalOrErrorResultUseCase.kt	Updated error response creation to include null scannedCredential
feature/client-api/src/main/java/com/simprints/feature/clientapi/mappers/response/LibSimprintsResponseMapper.kt	Added conditional serialization of scannedCredential (only when multi-factor ID is enabled)
feature/client-api/src/main/java/com/simprints/feature/clientapi/ClientApiViewModel.kt	Updated to pass scannedCredential from identifyResponse to ActionResponse

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[luhmirin-s]

Isn't the takeIf kinda redundant here?

[alexandr-simprints]

I thought about it as well, but this approach seems less error-prone if we ever want to change the logic of the returned credential