> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.
# NFC認証API - eパスポート・eIDチップの読み取り
> DiditのNFC認証は、eパスポートやeIDのICチップを読み取り、暗号署名を検証します。改ざんを検知する最高水準の本人確認で、1回あたり$0.15です。
DiditのNFC認証では、最新のパスポートや身分証に内蔵されたセキュアチップをスマートフォンのNFC機能で読み取り、本人確認書類を検証できます。本人確認(ID Verification)で利用できる**最高水準のセキュリティ**を実現します。
NFC認証の連携プロンプト
Copy prompt to clipboard
\
\````# Goal
Integrate Didit NFC Verification — cryptographic ePassport / eID chip read — into your app.
\# Delivery mode
NFC is **session-only**. There is no standalone /v3/nfc/ endpoint. The chip is read by the Didit Web/Mobile SDK during a hosted session, which uses the device's NFC radio.
\# Steps
1\. Create a workflow that includes the NFC feature (Business Console or POST /v3/workflows/). NFC normally runs alongside ID Verification: the user first photographs the document so the SDK derives BAC/PACE keys from the MRZ, then taps the chip.
2\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. See /sessions-api/create-session.
3\. Open the returned session.url on a mobile device with NFC (iOS 13+/Android with NFC enabled), or mount the native SDK in your app.
4\. After completion fetch the decision — GET /v3/session/{sessionId}/decision/ (or subscribe to session.status.updated).
curl (create session):
\```bash
curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-123",
"callback": "https://yourapp.com/post-kyc"
}'
\```
\# Decision shape
The NFC result is returned under the plural array `nfc_verifications[]` on the decision payload.
\> Heads-up: the V3 schema deliberately keeps the **plural-array** name `nfc_verifications[]` even though early integrators occasionally hit a singular `nfc_verification` key. Always read from the plural array — it is the canonical, multi-instance shape and matches every other feature.
\# Status enum (per nfc_verifications[].status)
"Not Started" | "In Progress" | "Approved" | "In Review" | "Declined" | "Abandoned" | "Kyc Expired"
\# Warnings (LogWarningChoices.NFC)
The warnings[] array on each nfc_verification includes risk codes such as:
NFC_NOT_READ, NFC_DATA_INVALID, NFC_DATA_DOES_NOT_MATCH_OCR, NFC_BAC_FAILED, NFC_PASSIVE_AUTHENTICATION_FAILED, NFC_ACTIVE_AUTHENTICATION_FAILED, NFC_CHIP_CLONED, NFC_DOCUMENT_REVOKED.
Full catalogue: /core-technology/nfc-verification/warnings-nfc-verification.
\# Failure modes to handle
\- Device has no NFC chip or NFC is disabled — the SDK falls back to OCR + face match; nfc_verifications[] will be empty.
\- The user fails to hold the chip long enough — status="Declined" with NFC_NOT_READ or NFC_BAC_FAILED. Allow a retry.
\- nfc_verifications[].status="Declined" with NFC_DATA_DOES_NOT_MATCH_OCR — the chip and the printed data disagree (likely tampered document). Do not approve.
\- Passive Authentication failed — the chip's signing certificate did not chain back to a trusted CSCA. Stop the flow.
\# Japan My Number Card (JPKI)
\- The My Number Card is read through JPKI, not ICAO 9303: native SDKs only, and the person enters the card PIN. Its item has chip_protocol "jpki", its evidence under jpki (chain_valid, signature_valid, revocation_status good | revoked | unchecked, attributes, attributes_match_ocr), and null ICAO fields (chip_data, authenticity, certificate_summary).
\- iOS host apps add D392F000260100000001 to com.apple.developer.nfc.readersession.iso7816.select-identifiers.
\- Not enabled in production yet: until it is, a My Number Card in a native SDK on an NFC phone skips NFC with nfc_skip_reason JPKI_UNAVAILABLE.
\# See also
\- Canonical schema: /reference/data-models#nfc-verification
\- Per-feature report: /core-technology/nfc-verification/report-nfc-verification
\- Risk catalogue: /core-technology/nfc-verification/warnings-nfc-verification
\- Supported documents: /core-technology/nfc-verification/supported-documents-nfc-verification
\- Full integration playbook: /integration/integration-prompt````
\
Paste into
***## 主なメリット| メリット | 説明 |
| - | - |
| **最高水準のセキュリティ** | 政府発行機関の暗号署名を直接検証します |
| **使いやすい** | NFC対応のスマートフォンであれば自動的に動作します |
| **改ざん防止** | 人の目では見えない書類の改ざんを検知します |
| **豊富なデータ** | OCRだけでは取得できない追加データを抽出します |
| **柔軟なフォールバック** | NFCが使えない場合は、標準の本人確認に自動で切り替わります |***## NFC認証を有効にする方法### ネイティブSDKとの連携(推奨)NFC認証は、端末のNFC機能をフルに利用できる**ネイティブSDK**で提供されます。| プラットフォーム | NFC対応 | ドキュメント |
| - | - | - |
| **iOS** | ✅ 全面対応 | [iOS SDKドキュメント](https://docs.didit.me/integration/native-sdks/ios-sdk.md) |
| **Android** | ✅ 全面対応 | [Android SDKドキュメント](https://docs.didit.me/integration/native-sdks/android-sdk.md) |iOS SDKは、次のNFC関連の設定をすべて自動で処理します。- ePassport向けのISO7816アプリケーション識別子
- エンタイトルメントと機能(Capabilities)の設定
- 視覚的なフィードバック付きのリアルタイムのチップ読み取り### Webでの連携> ⚠️ **ブラウザーの制限**
>
> プラットフォームの制約により、NFC認証は**Webブラウザーでは利用できません**。
>
> | ブラウザー | NFC対応 |
> | - | - |
> | **Chrome(Android)** | 実験的なWeb NFC API - 不安定で、明示的な権限が必要です |
> | **Safari(iOS)** | Web NFC APIには非対応です |
> | **その他のブラウザー** | 非対応です |
>
> Webでの連携では、NFC認証は自動的にスキップされ、ユーザーは書類と自撮りによる標準の本人確認に進みます。***## 仕組み**1. セッションの開始**ユーザーは、お客様のアプリまたはプラットフォームから本人確認を開始します。- **ネイティブSDK**: アプリ内で本人確認フローを直接起動します
- **Web/モバイルWeb**: ユーザーはNFC対応の本人確認のためにDiditアプリへ案内されるか、標準の本人確認を続行します**2. 書類の撮影**ユーザーは本人確認書類を撮影し、次の情報を取得します。- **MRZ**(機械読み取りゾーン) — チップへのアクセスキーの導出に使用します
- **書類の表面と裏面の画像** — 目視で確認できるデータとセキュリティ機能
- **目視で確認できるセキュリティ機能** — ホログラム、透かし、マイクロ文字**3. NFC対応の検出**システムが端末と書類の対応状況を自動的に確認します。| チェック | 説明 |
| - | - |
| **書類の種類** | NFCチップを搭載したePassport/eIDですか? |
| **端末の機能** | スマートフォンはNFCの読み取りに対応していますか? |
| **権限** | 必要なNFCの権限が付与されていますか? |> [!NOTE]
>
> NFCが利用できない場合も、書類と生体認証による標準の本人確認がそのままスムーズに続行されます。**4. NFCチップの読み取り**対応する端末と書類の場合は、次の手順で進みます。1) ユーザーは書類をスマートフォンのNFCリーダーに近づけるよう案内されます
2) 視覚的なフィードバックで読み取りの進行状況がリアルタイムに表示されます
3) PACE/BACプロトコルを使用して、チップとの安全な通信が確立されます**5. データの抽出**システムは**ICAO 9303**規格に従い、チップから包括的なデータを抽出します。| データグループ | 内容 | 説明 |
| - | - | - |
| **SOD** | 書類セキュリティオブジェクト | すべてのデータグループのデジタル署名 |
| **DG1** | 個人データ | 氏名、ID番号、生年月日、有効期限 |
| **DG2** | 顔画像 | 所持者の高解像度のデジタル写真 |
| **DG7** | 署名 | 所持者の署名のデジタル表現 |
| **DG11-14** | 追加データ | 保存されている場合は指紋や虹彩スキャンを含むことがあります |**6. 暗号による検証**抽出したデータに対して、厳格な暗号検証を行います。> **デジタル署名の検証**
>
> 各データグループのハッシュをSODに保存された署名と照合し、データの完全性を確認します。> **証明書チェーンの検証**
>
> **書類証明書 → 発行国の署名CA → ICAO PKDルート**という信頼の連鎖を検証し、CSCAマスターリストとICAO公開鍵ディレクトリ(PKD)と照合します。> **証明書の失効確認**
>
> 証明書失効リスト(CRL)と照合し、証明書が失効しておらず、書類が盗難・漏えいとして届け出られていないことを確認します。> **クロス検証**
>
> NFCから抽出したデータを、書類写真のOCRデータ、顔の生体情報の比較、MRZのチェックサム検証と突き合わせて検証します。**7. 結果と信頼度スコア**最終的な検証結果には次の内容が含まれます。| 出力 | 説明 |
| - | - |
| **NFC認証ステータス** | 成功、失敗、またはスキップ |
| **データ整合性スコア** | NFCのデータと目視のデータがどれだけ一致しているか |
| **証明書の検証** | チェーン全体の検証ステータス |
| **信頼度の向上** | NFCにより、本人確認全体の信頼度が大きく高まります |***## 対応書類NFC認証は、NFCチップを搭載した**ePassport**と**eID**に対応しています。チップ搭載の書類には、通常、次のマークが付いています。2006年以降に発行されたパスポートの多くにはNFCチップが搭載されています。国民IDカードの対応状況は国によって異なります。[対応書類](https://docs.didit.me/core-technology/nfc-verification/supported-documents-nfc-verification.md)をすべてご確認ください。日本のマイナンバーカードのチップは種類が異なり、ICAO 9303ではなくJPKIで読み取ります。[日本のマイナンバーカード(JPKI)](#日本のマイナンバーカード-jpki)をご覧ください。***## 日本のマイナンバーカード(JPKI)日本のマイナンバーカード(英語名My Number Card)にもチップがありますが、ICAO 9303準拠のものではありません。日本の公開鍵基盤であるJPKIの下で発行された証明書と、カードのPINを入力した場合にのみ署名する秘密鍵が格納されています。DiditはこれをNFCの同じステップで、ICAO 9303ではなくJPKIを使って読み取ります。どのプロトコルを使ったかは、すべてのNFC結果の`chip_protocol`(`icao`または`jpki`)に記録されます。> [!WARNING]
>
> **まだ利用できません。** JPKIによるマイナンバーカードの読み取りは、本番環境ではまだ有効になっていません。有効になるまでは、ネイティブSDKで撮影したマイナンバーカードはスキップ理由`JPKI_UNAVAILABLE`でNFCステップをスキップし、これまでどおり書類の撮影と顔照合で検証されます。### 要件| 要件 | 詳細 |
| - | - |
| **書類** | 日本のマイナンバーカードのみ。日本のパスポートは、これまでどおりICAO 9303のチップ読み取りを使用します。 |
| **連携方式** | マイナンバーカードの読み取りに対応したネイティブSDKのリリース(iOS、Android、またはこれらを基盤とするReact NativeおよびFlutter SDK)。SDKがJPKIを読み取れることをDiditに伝えます。古いリリースでは`JPKI_UNAVAILABLE`でステップをスキップします。WebおよびWebViewでの連携では`INTEGRATION_WITHOUT_NFC_ACCESS`でスキップします。 |
| **端末** | NFCリーダーを搭載したスマートフォン。搭載していない場合、ステップは`DEVICE_WITHOUT_NFC`でスキップされます。 |
| **iOSのホストアプリ** | アプリのISO7816 select identifiersに`D392F000260100000001`を追加します。[iOSのNFC設定](https://docs.didit.me/integration/native-sdks/ios-sdk.md#nfc-configuration)をご覧ください。 |
| **利用者** | カードの4桁のPINを把握していること。ワークフローで所持者のデータを要求する場合は、署名用パスワードも必要です。 |### 利用者の操作**1. カードを撮影する**利用者は、他の書類と同様に、ID確認ステップでマイナンバーカードを撮影します。Diditがカードを認識し、パスポートのチップ読み取りではなくJPKIのNFCステップを送信します。**2. カードのPINを入力する**SDKがカードの4桁のPIN(利用者証明用電子証明書の暗証番号)を求めます。NFCノードの`jpki_request_attributes`設定がオン(デフォルト)の場合は、署名用パスワード(署名用PINとも呼ばれる、署名用電子証明書の暗証番号。英大文字と数字で6〜16文字)も求めます。**3. カードをスマートフォンにかざす**SDKがカードの証明書を読み取り、カードは自身の鍵でDiditからのワンタイムチャレンジに署名します。SDKは証明書と署名をアップロードします。PINはカードにのみ送られ、Diditには送信されません。> [!NOTE]
>
> カードは誤入力の回数を数えます。4桁のPINは連続3回、署名用パスワードは連続5回の誤入力でロックされ、ロックされた場合は所持者が住民登録のある市区町村の窓口で解除する必要があります。誤入力のあと、SDKは残りの試行回数を表示します。最後の1回は実行させません。残りが1回になった時点で入力を止め、解除方法を案内します。開始する前に、PINと署名用パスワードを手元に用意するよう利用者に案内してください。### Diditが確認する内容| チェック | Diditが検証する内容 | 失敗時の警告(デフォルトのアクション) |
| - | - | - |
| **証明書チェーン** | すべての証明書が、その種類のJPKI認証局にチェーンしていること、有効期間内であること、マイナンバーカードの証明書であること(`jpki.chain_valid`)。 | `JPKI_CERTIFICATE_INVALID`(拒否) |
| **カードとPIN** | ワンタイムチャレンジに対するカードの署名が、その証明書で検証できること(`jpki.signature_valid`)。カードはPINが入力された場合にのみ署名するため、利用者がカードを所持しPINを知っていることの証明になります。 | `JPKI_SIGNATURE_INVALID`(拒否) |
| **失効** | 失効した証明書がないこと(`jpki.revocation_status`)。 | `revoked`の場合は`JPKI_CERTIFICATE_REVOKED`(拒否)、`unchecked`の場合は`JPKI_REVOCATION_UNCHECKED`(レビュー) |
| **所持者データ** | 署名用証明書に含まれる氏名、生年月日、性別、住所が、同じカードの写真から読み取ったデータと一致すること(`jpki.attributes_match_ocr`、`jpki.mismatched_attributes`)。 | `JPKI_AND_OCR_DATA_NOT_SAME`(レビュー) |各アクションはNFCノードの設定で、**アクションなし**、**レビュー**、**拒否**に変更できます。[NFCの警告](https://docs.didit.me/core-technology/nfc-verification/warnings-nfc-verification.md#japan-my-number-card-jpki)と[NFC機能の設定](https://docs.didit.me/management-api/workflows/feature-configs.md#nfc-/-epassport)をご覧ください。### 失効ステータスが「unchecked」の意味`revocation_status: "unchecked"`は、Diditが証明書チェーンとカードの署名は検証できたものの、証明書が失効しているかどうかの回答を得られなかったことを意味します。証明書は、たとえばカードの紛失が届け出られた場合などに失効します。失効したカードである可能性を排除できないため、`unchecked`が`good`として扱われることはありません。`JPKI_REVOCATION_UNCHECKED`が発生し、デフォルトではNFCステップがレビューに回されます。別の結果にするには`jpki_revocation_unchecked_action`を設定します。証明書チェーンまたは署名が無効な場合、Diditは失効について確認しません。ステータスは`unchecked`のままで、チェーンまたは署名の警告のみが発生します。### 所持者データとプライバシー- `jpki_request_attributes`がオンの場合、判定には署名用証明書に含まれる所持者の氏名、生年月日、性別、住所が`jpki.attributes`として含まれます。オフの場合、利用者が入力するのは4桁のPINのみです。この場合もカードとPINは証明されますが、所持者データは含まれず、カードの写真との照合も行われません。
- NFCステップが、チップから12桁の個人番号(マイナンバー)を読み取ることはありません。
- 判定に含まれるのはカードが証明した内容のみで、証明書そのもの、そのシリアル番号、署名は含まれません。完全な結果は[NFC認証レポート](https://docs.didit.me/core-technology/nfc-verification/report-nfc-verification.md#japan-my-number-card-jpki)に記載されています。***## 連携例### iOS SDK(利用可能)```swift theme={null}
import DiditSdk
// NFC is automatically enabled when the document supports it
let config = DiditSdk.Configuration(
// NFC configuration is handled automatically
// Just ensure your app has the required entitlements
)
let result = try await DiditSdk.shared.startVerification(
with: sessionId,
configuration: config
)
```**[iOS SDKドキュメントの全文 →](https://docs.didit.me/integration/native-sdks/ios-sdk.md)**### Android SDK(近日公開)```kotlin theme={null}
// Coming soon - use WebView integration in the meantime
// See Android SDK documentation for WebView setup
```**[Android SDKドキュメント →](https://docs.didit.me/integration/native-sdks/android-sdk.md)*****## セキュリティアーキテクチャ```
┌─────────────────────────────────────────────────────────────┐
│ NFC Verification Flow │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ │ Document │───▶│ Phone │───▶│ Didit Backend │ │
│ │ NFC Chip │ │ NFC Read │ │ │ │
│ └──────────┘ └──────────┘ │ ┌────────────────┐ │ │
│ │ │ ICAO PKD │ │ │
│ │ │ Validation │ │ │
│ │ └────────────────┘ │ │
│ │ ┌────────────────┐ │ │
│ │ │ CSCA Master │ │ │
│ │ │ List Check │ │ │
│ │ └────────────────┘ │ │
│ │ ┌────────────────┐ │ │
│ │ │ CRL Revocation │ │ │
│ │ │ Check │ │ │
│ │ └────────────────┘ │ │
│ └──────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────┐ │
│ │ Verification Result │ │
│ │ + Confidence Score │ │
│ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```***## FAQ
**ユーザーのスマートフォンがNFCに対応していない場合は?**
本人確認フローがNFCの対応状況を自動的に検出します。利用できない場合、ユーザーは書類と自撮りによる標準の本人確認に進みます。本人確認の安全性は保たれますが、NFCによる追加の信頼度の向上は得られません。
**書類にNFCチップがない場合は?**
多くの書類(特に古いパスポートや一部の国民ID)にはNFCチップがありません。システムがこれを検出し、そのまま標準の本人確認に進みます。
**NFC認証で精度はどれくらい向上しますか?**
NFC認証は、発行元の政府による書類の真正性の暗号的な証明を提供します。これにより本人確認結果の信頼度が大きく高まり、目視検査をすり抜けかねない巧妙な偽造も検出できます。
**NFC認証は必須ですか?**
いいえ。NFCは必須ではなく、強化のための機能です。リスク許容度に応じて、ワークフローでNFCを必須にする、利用可能な場合に優先する、または完全にスキップするよう設定できます。
***
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.