Identity Use Case

Identity Use Case

This page describes how identity data can be shared using MiTrust as a specific use case of the generic data sharing platform.

Identity is not a dedicated product or core concept of MiTrust. It is one of many datasets that can be shared through the platform, alongside other types of data (administrative, financial, health, etc.). However, identity presents specific characteristics that require dedicated documentation.

Overview

The Identity use case allows an End-User to share a proof of identity with a relying party through MiTrust. This proof can originate from hybrid sources:

• Document-based identity verification
• Electronic identity (eID)

Each source produces different outputs and may be consumed differently by integrators.

Identity Sources

1. Document-based Identity Verification

In this flow, the End-User provides an identity document (for example, an ID card or passport). The verification process produces:

• A verification decision
• Optional risk indicators
• Document evidence (front/back images)

This verification decision is a core concept of document verification and does not apply to eID flows.

Verification Decision

The verification decision represents the outcome of the verification process. Possible values are:

• Approved
• Declined
• Inconclusive

The decision is exposed through the claim: identity.document.verification.decision

2. Electronic Identity (eID)

In an eID flow, the End-User authenticates using a digital identity provider. The result of the flow is:

• A digital identity token
• No verification decision

Unlike document verification:

• There is no concept of approved/declined/inconclusive
• The proof is a cryptographic assertion, not a document check

Backward Compatibility: PDF Attestation

To preserve backward compatibility with existing integrations:

• MiTrust generates a PDF attestation of the eID token
• This PDF is exposed using the same data point as the document front image

As a result:

• For document verification: document.front → image of the document
• For eID: document.front → PDF attestation of the digital identity token

Integrators must rely on metadata (content type, source) to distinguish between the two.

Express Identity Flow

In the specific case of identity:

• The second consent screen is skipped
• This avoids unnecessary friction
• The End-User is already fully aware of the shared data (from the first consent, and because his own identity data is very well-known from the End-User)

This behavior applies only to identity datasets and does not affect other use cases.

Claims Structure

Identity Document Verification Claims

Normalized Risk Indicators

For security reasons, it is not recommended to expose exact verification failure reasons to end users. Detailed rejection signals may help fraudsters understand detection mechanisms and adapt their behaviour to bypass controls.

Instead, only high-level or generic error messages should be displayed to users, while detailed risk signals remain restricted to internal systems and customer support analysts.

That being said, below is the exhaustive list of all available risk indicators:

• document_back_image_missing — No image of the back side of the identity document was provided during verification.
• document_back_not_visible — The back side of the identity document was expected but was not sufficiently visible in the submitted images.
• document_expired — The submitted identity document is no longer valid because its expiration date has passed.
• document_front_image_missing — No image of the front side of the identity document was submitted.
• document_front_not_visible — The front side of the identity document was not clearly visible or readable in the submitted image.
• document_image_quality_low — The document image quality was insufficient for reliable verification due to blur, glare, low resolution, cropping, poor lighting, or obstruction.
• document_invalid_appearance — The identity document showed visual inconsistencies or abnormalities that do not match expected security features or official document standards.
• document_not_physical — The submitted identity document appears to be a digital screen capture, photocopy, screenshot, or otherwise non-physical document instead of an original physical ID.
• document_not_recognised — The document type, issuing authority, or format could not be identified or is unsupported by the verification system.
• document_rejected — The identity document could not be accepted due to validation failure, integrity concerns, unsupported format, or other compliance issues.
• document_tempering — Evidence suggests that the identity document may have been altered, manipulated, forged, or tampered with.
• duplicated_device — The same device has been reused across multiple verification attempts in a manner associated with suspicious or fraudulent activity.
• duplicated_end_user — The same end user appears to have attempted multiple verifications beyond acceptable duplication thresholds.
• duplicated_id — The same identity document has been used in multiple verification attempts, potentially indicating identity reuse or fraud.
• face_image_missing — No selfie or face image was provided as part of the identity verification flow.
• face_image_quality_low — The submitted selfie or facial image quality was too poor for accurate biometric analysis due to blur, lighting issues, obstruction, or low resolution.
• face_in_blocklist — The detected face matches an identity or biometric record included in a fraud, sanctions, or internal blocklist database.
• face_liveness_failed — The liveness detection process failed, indicating that the system could not confirm the presence of a real live person during verification.
• face_not_similar_to_portrait — Facial comparison between the submitted selfie and the portrait on the identity document failed or produced insufficient similarity.
• identity_farming — The verification activity indicates systematic creation, collection, or exploitation of multiple identities, often associated with organised fraud operations.
• known_fraud — The verification session matched previously identified fraudulent identities, devices, documents, or behaviours already associated with confirmed fraud cases.
• other — A generic or uncategorised verification issue that does not match a predefined risk or rejection category.
• restricted_ip_location — The verification attempt originated from an IP address or geographic location associated with restricted, sanctioned, or high-risk regions.
• suspicious_behaviour — The verification session exhibited behaviour patterns considered abnormal or potentially fraudulent, such as inconsistent actions, unusual interaction flow, or risk indicators detected during the identity verification process.
• unexpected_traffic_behaviour — Traffic patterns related to the verification session were flagged as abnormal, potentially indicating automation, proxy usage, bot activity, or coordinated fraudulent behaviour.

🗒️

The suspicious_behaviour and document_not_physical indicators are the most commonly observed in real-world integrations.
They usually indicate that the submitted document is a photocopy or a photo, not a physical document.

Annex — JSON Examples

A. Document Verification — Approved

{
  "identity": {
    "given_name": "Alexandre",
    "family_name": "Martin",
    "name": "Alexandre Martin",
    "birthdate": "1992-04-17",
    "gender": "male",
    "nationality": "FR",
    "document": {
      "verification": {
        "decision": "approved"
      },
      "type": {
        "normalized": "id_card",
        "raw": "ID_CARD"
      },
      "issuing_country": "FR",
      "number": "ID-FR-123456789",
      "date_of_issue": "2022-06-30",
      "date_of_expiry": "2032-06-30",
      "front": {
        "file_wrapper": {
          "base64": "<BASE64_DOCUMENT_FRONT_IMAGE>"
        }
      },
      "back": {
        "file_wrapper": {
          "base64": "<BASE64_DOCUMENT_BACK_IMAGE>"
        }
      }
    }
  }
}

B. Document Verification — Declined with Risk Indicators

{
  "identity": {
    "given_name": "Camille",
    "family_name": "Durand",
    "name": "Camille Durand",
    "birthdate": "1987-11-03",
    "gender": "female",
    "nationality": "FR",
    "document": {
      "verification": {
        "decision": "declined",
        "risk_indicators": [
          {
            "normalized": "suspicious_behaviour",
            "raw": "suspicious_behaviour"
          },
          {
            "normalized": "document_not_physical",
            "raw": "112"
          }
        ]
      },
      "type": {
        "normalized": "passport",
        "raw": "PASSPORT"
      },
      "issuing_country": "FR",
      "number": "P-FR-987654321",
      "date_of_issue": "2016-02-15",
      "date_of_expiry": "2026-02-15",
      "front": {
        "file_wrapper": {
          "base64": "<BASE64_DOCUMENT_FRONT_IMAGE>"
        }
      },
      "back": {
        "file_wrapper": {
          "base64": "<BASE64_DOCUMENT_BACK_IMAGE>"
        }
      }
    }
  }
}

D. Electronic Identity (eID)

{
  "identity": {
    "document": {
      "front": {
        "file_wrapper": {
          "base64": "<BASE64_PDF_ATTESTATION_ANONYMIZED>",
          "filename": "oidc_front.pdf"
        }
      },
      "date_of_issue": "2025-12-22",
      "issuing_country": "FRA",
      "type": {
        "normalized": "jwt",
        "raw": "id_token"
      },
      "number": "e7c94b21-8f42-4d2a-9c3e-5b91f6c2a8de"
    },
    "nationality": "FRA",
    "given_name": "Julien André",
    "family_name": "Morel-Dupont",
    "gender": "male",
    "name": "Julien André Morel-Dupont",
    "birthdate": "1978-01-29"
  }
}