仕組み
ユーザーAがService Xでユーザー認証を完了し、現在パートナーであるService Yで登録手続きをしているとします。Service XがAに関する情報をService Yと共有することに同意した場合、次の手順で共有できます。
-
共有トークンの生成(
Service X):Service XはAPIを呼び出し、特定のユーザーの認証セッションに対して、安全で有効期間の短いshare_tokenを生成します。このトークンはService Yのみが使用できるように指定されます。APIリファレンス: Share Session APIを参照してください。 -
パートナーへのトークンの受け渡し(
Service X->Service Y):Service Xは、生成したshare_tokenを、事前に取り決めたバックエンドのチャネルを通じてService Yへ安全に送信します。 -
セッションのインポート(
Service Y):Service Yは受け取ったshare_tokenを使ってAPIを呼び出し、ユーザーのデータをインポートします。これにより、すべての書類とチェックを含む認証セッションの完全なコピーがService Y自身の環境内に作成されます。APIリファレンス: Import Shared Session APIを参照してください。
インポートオプション
セッションをインポートする際、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共有の違い
どちらの機能も本人情報の再利用を容易にしますが、目的は異なります。❗️ 重要: データ共有に関する制限
異なる組織間で個人のユーザーデータを共有することには、厳格な法的・規制上の要件が適用されます。この機能を使用する前に、欧州連合のGDPRや英国のUK GDPRなど、適用されるすべてのデータ保護法を完全に遵守していることを確認する責任はお客様の組織にあります。 次の対応が必要です。Diditはデータ共有のための技術的な機能を提供しますが、共有するデータに関するすべての法的義務とコンプライアンス上の義務は、お客様の組織とパートナーのみが負います。この機能を導入する前に、法律顧問に相談することを強くお勧めします。
- 法的根拠の確立: データを共有するための正当な法的根拠があることを確認してください。多くの場合、お客様とパートナー組織の間で明確なデータ共有契約を結ぶ必要があります。
- ユーザーの同意の確保: 利用規約とプライバシーポリシーに記載されているとおり、ユーザーが適切に説明を受け、パートナーとのデータ共有に同意していることを確認してください。
- 国際移転の適切な取り扱い: データが国境を越えて移転される場合(例: EUからEU域外の国へ)、法律の定めに従って適切な保護措置を講じる必要があります。