署名者が ID 確認チェックを完了すると、ID 確認済みデータを使用して重要なフォームフィールドに自動入力し、ロックすることができます。データ入力エラーは減り、信頼できるソースから特定の値が取得されたことを示す明確で監査可能な証拠が提供されます。
「確認済みフォーム」を使用すると、ID プロバイダーから返される確認済み ID 情報をフォームフィールドに関連付けることができます。署名者が「デジタルアイデンティティゲートウェイ」を介して接続されたプロバイダーで ID 確認を正常に完了すると、Adobe Acrobat Sign は署名中に ID クレームからの値をタグ付きフィールドに挿入し、信頼できるソースから重要なデータが直接取得されることを保証します。
この機能は、金融サービスや政府機関など、規制対象で機密性の高い環境での高信頼ワークフロー向けに設計されています。
ID 確認済みデータの仕組み
ID 確認済みデータは、オーサリング UI、テキストタグまたは API のフィールド名規則によってのみトリガーされます。
以下のようになっています。
- ID 確認済みフィールドを設定する UI コントロールはありません。
- 文書がアップロードまたは送信される際の検証はありません。
- 設定が正しくない場合のエラーメッセージはありません。
フィールド名が必要な構文と正確に一致しない場合、フィールドは通常のフォームフィールドのように動作するか、完全に無視されます。
必須フィールド命名構文
フォームフィールドを本人確認プロバイダーからの本人確認済みデータにバインドするには、フィールド名が次の正確なパターンに従う必要があります:
VF_DIG_{claimName}*
このシンタックスでは:
- VF_ フィールドを確認済みフォームフィールドとして識別します。
- DIG_ はデジタル ID ゲートウェイ認証方法を指定します。
- {claimName} は、スペルと大文字小文字を含む、設定された ID プロバイダーから返される正確な OpenID Connect(OIDC)クレーム名で、中括弧で囲まれています。
- * は、フィールド名を一意にするために使用するオプションのテキストです。
例:
- VF_DIG_{birthdate}
- VF_DIG_{address}_page2
- VF_DIG_{zipcode}1
複数のフィールドが同じ ID クレームを参照する場合でも、各フィールドは一意のフィールド名を持つ必要があります。
サポートされている ID クレーム
設定された ID プロバイダーから返される ID クレームのみが認識されます。
クレーム名:
- Acrobat Sign ではなく、ID プロバイダーによって定義されます。送信者がベンダーからクレーム名のリストを取得する責任があります。
- 大文字/小文字が区別されます。
- 完全に一致する必要があります。
- エイリアスはサポートされていません。
- 正しくない場合や欠落している場合は、警告なしで無視されます。
ID 検証中に ID プロバイダーからクレーム名が返されない場合、フィールドには検証済みデータが入力されません。
データ取り込みに対する送信者の責任
送信者は、ID 確認済みデータを使用するとき、どの ID 属性がフォームフィールドにマップされるかを決定する責任があります。確認済みフォームフィールドを設定することで、送信者は、契約書にどの確認済みプロバイダーデータフィールドが入力されるかを制御します。
送信者は、確認済みフォームフィールドを通じて取り込まれるあらゆるデータが、Acrobat Sign を使用して処理および保存することを許可されているデータであり、そのような使用が、適用されるすべての法律、規制、契約上の義務に準拠していることを確認する必要があります。
送信者は、Acrobat Sign 製品固有使用許諾条件(PSLT)の下で顧客が収集、処理または保存することを禁止されているデータを取り込むように確認済みフォームフィールドを設定しないでください。例えば、Acrobat Sign は(PCI DSS で定義されている)決済カードデータや機密認証データの保存に使用できず、顧客は、アドビとの業務提携契約を締結していない限り、保護された医療情報を処理できません。
アドビは、確認済みフォームフィールドを通じた取り込みのために送信者によって選択されたデータをレビュー、検証または制限しません。
署名中のフィールドの動作
確認済みフォームフィールドは、ID 対応のオーバーライドを使用して、既存の Acrobat Sign フィールドの動作に従います。
読み取り専用フィールド
- クレームが存在する場合、確認済みデータが入力されます。
- 署名者が編集することはできません。
- 事前定義された値をオーバーライドします。
- クレームが欠落している場合は、事前定義された値が使用されます。
編集可能なフィールド
- クレームが存在する場合、確認済みデータが入力されます。
- 署名者が編集可能な状態を維持します。
- 署名者が値を変更することができます。
必須フィールド
- 編集可能なフィールドのように動作します
- クレームが欠落している、空である、または null の場合は、署名者の入力が必要です
サイレント障害条件
ID 検証済みデータは、以下のすべてのケースでサイレントに失敗します:
- フィールド名が必須の構文に従っていません。
- クレーム名のスペルが間違っているか、大文字と小文字の使い方が正しくありません。
- ID プロバイダーからクレームが返されません。
- この機能はアカウントまたはグループレベルで無効になっています。
契約書または web フォームは正常に送信されます。
契約書または web フォームを配布する前に、オーサリング環境でフィールドの動作を必ず検証してください。
署名者 ID レポートの動作
契約書に 1 つ以上の検証済みフォームフィールドが含まれている場合、署名者 ID レポート(送信者のアカウントまたはグループレベルで有効になっている場合)には、これらのフィールドをリストした専用セクションが含まれます。
検証済みフォームフィールドごとに、署名者 ID レポートには以下の情報が含まれます:
- フィールド名
- 最終値
- 単一の状態インジケーター
署名者 ID レポートで可能な状態
状態は契約書の完了後に決定されます。これらは最終値のソースを反映し、オーサリングまたは署名中の設定を検証するものではありません。
各検証済みフォームフィールドには、以下の優先順位に基づいて 1 つの状態のみが割り当てられます。
- 編集済み - 署名者が署名中にフィールド値を変更しました。
- 条件:
- フィールドが編集可能で、かつ
- 最終値が署名者によって変更された
- 条件:
- 検証済み - フィールド値は ID 検証済みデータから取得され、意味のある変更は行われていません。
- 述語:
- 一致する ID クレームが返され、かつ
- 最終値が検証済みクレーム値と一致する
- 対象製品
- 検証済みデータから取得された読み取り専用フィールド
- 編集可能フィールドが未変更のまま
- 検証済みデータから入力されたフィールドが編集されましたが、値は同一のままでした。
- 述語:
- 事前定義 - フィールドは作成者によって設定されたデフォルト値を保持しています。
- 述語:
- ID 確認済みデータが適用されておらず、かつ
- より高い優先度の状態は適用されません。
- 述語:
- クレームが存在しません - 参照されたアイデンティティクレームは、アイデンティティプロバイダーから返されませんでした。
- 述語:
- フォームフィールドで指定されたクレーム名が ID プロバイダーの応答に存在しません。
- 述語:
- 空または Null 値 - 参照されたアイデンティティクレームは、使用可能な値なしで返されました。
- 述語:
- クレームは存在しますが、空または null です。
- 空とは、空の文字列またはオブジェクトを意味します。
- Null とは、値が明示的に null であることを意味します。
- 述語:
メモ
- フィールドごとに 1 つの状態のみが割り当てられます。
- 状態は警告やエラーを生成しません。
- レポートは設定エラーではなく、結果を反映します。