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

Possible values include (non-exhaustive):

• Suspicious behaviour
• Document not physical
• Restricted IP location
• Unexpected traffic behaviour
• Document rejected
• Document back not visible
• Document back image missing
• Document front not visible
• Document front image missing
• Document image quality low
• Document expired
• Document not recognised
• Document invalid appearance
• Face image missing
• Face image quality low
• Face liveness failed
• Face in blocklist
• Face not similar to portrait
• Document tempering
• Known fraud
• Duplicated end user
• Duplicated device
• Duplicated ID
• Identity farming
• Other

🗒️

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"
  }
}