> ## 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.

# APIでKYCを共有：再利用可能な本人確認

> Diditでは、有効期間の短い共有トークンを使い、信頼できるパートナー間でAPI経由で検証データを安全に共有できます。連携サービス間で繰り返し行うKYCが不要になります。

## 仕組み

ユーザー`A`が`Service X`でユーザー認証を完了し、現在パートナーである`Service Y`で登録手続きをしているとします。`Service X`が`A`に関する情報を`Service Y`と共有することに同意した場合、次の手順で共有できます。

1. **共有トークンの生成（`Service X`）**: `Service X`はAPIを呼び出し、特定のユーザーの認証セッションに対して、安全で有効期間の短い`share_token`を生成します。このトークンは`Service Y`のみが使用できるように指定されます。APIリファレンス: [Share Session API](https://docs.didit.me/ja/sessions-api/share-session/share.md)を参照してください。

2. **パートナーへのトークンの受け渡し（`Service X` -> `Service Y`）**: `Service X`は、生成した`share_token`を、事前に取り決めたバックエンドのチャネルを通じて`Service Y`へ安全に送信します。

3. **セッションのインポート（`Service Y`）**: `Service Y`は受け取った`share_token`を使ってAPIを呼び出し、ユーザーのデータをインポートします。これにより、すべての書類とチェックを含む認証セッションの完全なコピーが`Service Y`自身の環境内に作成されます。APIリファレンス: [Import Shared Session API](https://docs.didit.me/ja/sessions-api/share-session/import.md)を参照してください。

### インポートオプション

セッションをインポートする際、`Service Y`は結果の扱い方を制御できます。

* **`trust_review`**: このブール型パラメーターは、`Service Y`が`Service X`によるレビューと最終ステータス（`Approved`/`Declined`）を信頼するかどうかを決定します。
  * `true`: セッションは元のステータスのままコピーされます。ユーザーは`Service Y`で即座にオンボーディングされます（または拒否されます）。
  * `false`: セッションのデータはコピーされますが、ステータスは自動的に`In Review`に設定されます。これにより、`Service Y`は収集済みの書類とデータを利用しつつ、独自の社内レビュープロセスを実施して最終判定を下せます。
* **`workflow_id`**: `Service Y`は、インポートしたセッションに紐づける自社の認証ワークフローを指定する必要があります。
* **`vendor_data`**: `Service Y`は、インポートしたセッションに独自の社内ユーザー識別子を割り当てることができます。

### 重要な注意事項

* **完了したセッションのみ**: 共有トークンは、完了ステータス（`Approved`、`Declined`、`In Review`）のセッションに対してのみ生成できます。
* **重複不可**: 特定のセッションは、特定のパートナーアプリケーションに1回のみインポートできます。2回目以降の試行は拒否されます。

***

## 再利用可能なKYCとAPIによるKYC共有の違い

どちらの機能も本人情報の再利用を容易にしますが、目的は異なります。

| 機能 | ユーザー主導の再利用可能なKYC | APIによるKYC共有（B2B共有） |
| - | - | - |
| **開始するのは誰か** | エンドユーザーが、オンボーディング中に開始します。 | 企業が、サーバー間のAPI呼び出しによって開始します。 |
| **同意** | ユーザーは再利用のたびに、データの共有に明示的に同意します。 | 同意は通常、最初の企業との利用規約の中で取得されます。パートナー企業間で明確なデータ共有契約を結ぶ必要があります。 |
| **データの流れ** | ユーザーのDidit IDが、新しいアプリとのデータ共有を直接仲介します。 | `Service X`が安全なトークンを介して`Service Y`とデータを共有します。 |
| **ユースケース** | 互いに関係のない複数のサービスにすばやく登録したいユーザー。 | パートナーエコシステム、金融サービスグループ、コングロマリットなど、関連するプラットフォーム間でユーザーの本人情報を持ち運べる必要がある場合。 |

***

> ## ❗️ 重要: データ共有に関する制限
>
> 異なる組織間で個人のユーザーデータを共有することには、厳格な法的・規制上の要件が適用されます。この機能を使用する前に、欧州連合のGDPRや英国のUK GDPRなど、適用されるすべてのデータ保護法を完全に遵守していることを確認する責任はお客様の組織にあります。
>
> 次の対応が必要です。
>
> 1. **法的根拠の確立**: データを共有するための正当な法的根拠があることを確認してください。多くの場合、お客様とパートナー組織の間で明確なデータ共有契約を結ぶ必要があります。
> 2. **ユーザーの同意の確保**: 利用規約とプライバシーポリシーに記載されているとおり、ユーザーが適切に説明を受け、パートナーとのデータ共有に同意していることを確認してください。
> 3. **国際移転の適切な取り扱い**: データが国境を越えて移転される場合（例: EUからEU域外の国へ）、法律の定めに従って適切な保護措置を講じる必要があります。
>
> Diditはデータ共有のための技術的な機能を提供しますが、共有するデータに関するすべての法的義務とコンプライアンス上の義務は、お客様の組織とパートナーのみが負います。この機能を導入する前に、法律顧問に相談することを強くお勧めします。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.