E-signature
署名の前に行う、電子署名のための本人確認
署名の価値は、その背後にある本人確認で決まります。ShieldIDの署名者本人確認APIは、ご自身の政府発行IDを持つ実在の人物が文書を完了させていることを確認し、その確認結果を署名そのものと並べて記録します。
課題
「リンクをクリックした」は「署名した」ではありません
多くの電子署名プラットフォームが確認しているのは、誰かがメールを開いて名前を入力したことだけです。これは受信箱の認証であり、人物の本人確認ではありません。
メールのリンクが証明するのは受信箱であり、人物ではありません
共有の受信箱、転送されたメッセージ、不正アクセスされたアカウントなど、メールを開ける人であれば誰でも、リンクをクリックして署名欄に名前を入力できてしまいます。
高額な文書にはチェックボックス以上のものが必要です
賃貸借契約、融資契約、和解書、委任状などは、重大な結果を伴います。本人確認が行われていない相手が入力した「同意します」は、それほど重要な文書の土台としては脆弱です。
後で争いになったとき、示せるものが何もないことがよくあります
署名者が後になって、別の人が代理で署名したと主張した場合、多くの電子署名の監査証跡に残っているのはIPアドレスとタイムスタンプであり、ライブの顔と照合された政府発行IDではありません。
具体例
2名の署名を待つ商業賃貸借契約
フローの流れをお見せするための架空の例です。実在のテナント、貸主、賃貸借契約は一切関係ありません。
文書が送信されます
不動産管理者が、電子署名プラットフォームを通じて商業賃貸借契約を署名用に送信します。署名画面が表示される前に、プラットフォームはテナントを、その文書に紐づいたShieldIDの本人確認セッションへリダイレクトします。署名者のスマートフォンで撮影
入居者は運転免許証の表裏を撮影し、ガイドに従った短いライブネスチェックを完了します。バーコードと印字された項目が照合され、ライブの顔は証明書の顔写真と照合されます。不正の兆候チェックはすべてのセッションで実行されます
なりすまし防止、ディープフェイク、マスク、文書改ざんの各チェックが自動的に実行されます。高額な文書だからといって、電子署名プラットフォーム側で有効にし忘れないように気を配る必要のある設定ではありません。確認済みの状態で文書に戻ります
ShieldIDは、結果を付けてテナントをプラットフォームの戻り先URLに戻し、同じ結果を署名付きwebhookでも通知します。署名ステップが進められるのは、この時点からです。2つの記録を並べて確認
電子署名プラットフォーム自身の監査証跡には、署名イベントが記録されます。ShieldIDのアクティビティ台帳には、その前に行われた本人確認、つまり誰が確認されたか、エンジンが何を報告したか、いつ行われたかが記録されます。これはデータベースによって追記専用が保証された記録です。
署名の前に最も重要なこと
受信箱だけでなく、本人を確認します
以下のチェックはすべて、文書の種類を問わず、すべての本人確認で実行されます。
顔照合とライブネス
不正の兆候
アクティビティ台帳
署名付きwebhookと戻り先URL
ウォッチリストスクリーニング
紛争や監査に備えて
署名が争われたときも、本人確認は記録に残っています
署名者が後になって文書に異議を唱えます。訴訟担当の弁護士が、実際に誰が署名したのかの証拠を求めます。規制当局が顧客確認のファイルを審査します。署名の背後にある本人確認は、そうした場面で議論の出発点となります。
データベースによって強制される追記専用の仕組み
エントリの追加はできますが、編集や削除はできません。お客様にも、ShieldIDにもできません。これはデータベース自体の特性です。
署名イベントとは別に残る本人確認
ShieldIDの台帳は、署名前に実行された本人確認(誰が確認されたか、エンジンが何を報告したか、いつ行われたか)を、電子署名プラットフォーム自身によるクリックの記録とは別の、独立したエントリとして記録します。
アクター、アクション、結果、日付で検索可能
2つの異なるシステムから手作業でタイムラインを再構築する代わりに、紛争やファイル審査に必要なエントリだけを正確に取り出せます。
現在、台帳には、成功および失敗した本人確認の結果、サインイン、APIキーのアクティビティ、監査エクスポートが記録されます。ID画像ごとの閲覧・ダウンロードイベント、専用の判定イベント、パージ受領記録、チーム向けのセルフサービスCSVエクスポートは、近日公開予定です。
連携オプション
署名の前に行う、ひとつの本人確認ステップ
ホスト型認証ページ
署名付きwebhook
ひとつのREST API
Sandbox、課金は一切なし
すでに本番稼働中
Trust Ledgerの裏側で動いているのが、この仕組みです
ShieldIDの署名者本人確認は、Crown Stack Systems自社の電子署名プロダクトであるTrust Ledgerを支えています。このページで説明している文書チェック、顔照合、ライブネス、アクティビティ台帳は、計画段階ではなく、すでに実際の署名フローで稼働しています。
プライバシーについて
署名者のIDは、署名する文書と同じ細心の注意をもって取り扱います
署名する価値のある文書は、その背後にある本人の情報も同じように慎重に守る価値があることが少なくありません。
- 自社サーバーでホスティング
- ID画像、抽出されたフィールド、結果は、パブリッククラウドではなく、当社が管理するインフラで処理・保存されます。
- 短いタイマーでパージ
- ID画像は自動的にパージされます。デフォルトは7日間で、設定変更も可能です。本人確認の記録は、画像より長く保持されます。
- 暗号化
- 生年月日は暗号化して保存され、ID画像は保存時に暗号化されます。
- PIPEDAに沿うよう設計
- 必要最小限の収集、短い保持期間、検索可能なアクセス記録。これらの管理策によって、「署名者を確認しました」という記述が、規約内の一文にとどまらないものになります。
手作業との比較
クリックして署名する前にID確認が加えるもの
カテゴリ間の比較であり、特定のベンダーに関する主張ではありません。
| 機能 | ShieldID | 一般的なエンタープライズ向けIDV | 手動チェック |
|---|---|---|---|
| 受信箱だけでなく、実在する人物を確認 | はい | 通常は対応 | いいえ |
| 静止画やチェックボックスではなく、ライブネスチャレンジ | はい | 通常は対応 | いいえ |
| 政府発行の身分証明書を読み取り、照合 | はい | 通常は対応 | いいえ |
| 本人確認を検索可能な記録に登録 | はい | お客様には提供されない | IPアドレスとタイムスタンプのみ |
| 特定の書類やエンベロープに紐付け | はい | 通常は対応 | n/a |
| 請求が発生しないsandbox | はい | 場合による | n/a |
よくある懸念
プラットフォームチームがこのステップの追加前に尋ねること
「当社の電子署名ツールはすでに本人確認をしているのでは?」
多くのツールは、メールのリンク、SMSコード、入力した氏名に頼っています。これらは受信箱や電話番号を管理していることの証明にすぎず、本人が誰であるかの証明ではありません。ShieldIDは、実際の政府発行IDとライブの顔の確認を加えます。
「ステップが増えると署名が遅くなりませんか?」
署名者ご自身のスマートフォンで行うホスト型の1ステップで、署名画面の前に1回だけ置かれます。再訪の署名者に対してどのくらいの頻度で繰り返すかは、ShieldIDがすべての書類に強制するものではなく、貴社のプラットフォームが定めるポリシーです。
「IDに裏付けられた署名は法的に義務付けられていますか?」
それは管轄、書類の種類、顧問弁護士の助言によって異なります。当社は法的助言を行いません。ShieldIDが加えるのは、署名の相手側にいたのが誰かを示すより強力な証拠であり、義務付けられているかどうかにかかわらず有用です。
「より価値の高い書類だけに使うことはできますか?」
はい。必要な書類にはShieldIDを呼び出し、不要な書類では省略できます。これは特定の署名フローに追加するステップであり、プラットフォーム全体に対するオール・オア・ナッシングの切り替えではありません。
確認できる内容
誰が署名したかを把握し、その根拠を示せます。
署名者は署名の前に本人確認を行います。結果はエンベロープに紐づき、身分証から読み取ったすべてのフィールドと各チェックを個別に確認できます。
ご質問
e-signatureプラットフォーム向けの率直なQ&A。
はじめる
次の署名の前に、本人確認を追加しましょう
sandboxセッションを作成し、ご自身のスマートフォンで本人確認を実行して、実際の署名者が操作する前に、記録される内容をご確認ください。
Sandboxのセッションに課金されることはありません。