Webでの本人確認書類の検証

こんにちは Wallet & Apple Payチームのエンジニア Erikです こんにちは WebKitチームの 標準開発担当エンジニアMarcosです 本日は デジタル本人確認書類を使用して オンライン本人確認フローを 効率化する方法をご紹介します 本日のセッションは 本人確認フローを強化したい Webサイトデベロッパや アプリで身分証明を提供できるようにしたい アプリデベロッパや 純粋にデジタルアイデンティティに 関心のある人 そんな皆さんのために用意しました デジタルID文書は 運転免許証のほか 政府が発行するIDなど 幅広いID文書に代わるものとして ますます一般的になりつつあります これらのデジタルID文書には 物理的な文書を超える 重要な利点があります その1つが オンラインでの使いやすさです 現在 オンラインで身分証明が必要になると 多くの場合は 本人確認書類を写した 写真のアップロードが必要です ユーザーにとっても IDの確認を求める側の 法人にとっても 優れた解決策ではないでしょう ユーザーにとっては 使い勝手が悪いものです まず 身分証明書を 探さなくてはなりません また 写真を撮るのに丁度よい背景を 探す必要があるほか 撮影した写真が読み取りやすいか ぶれていないかの確認も必要です 法人の側でも 複雑なソリューションを構築して これらの写真を処理して 本物であるかどうか判断する必要があります なかなかに解決が難しい問題です モバイルドキュメント 別名「mdocs」は この問題の解決を目的とした デジタルID文書形式の1つの例です mdocsには ユニークな特性があります 1つは ISO 18013-5規格で 定義されていること これにより 異なるプラットフォーム間での 相互運用が可能になります

また よりプライベートな ユーザー体験を提供します リクエスト送信者が 名前と年齢の確認だけを必要とする場合 共有が必要になるのは これらの情報だけです mdocsなら それができます さらに 物理的なIDよりも 優れたセキュリティ機能を提供できるため より信頼性が高まります たとえば mdoc内の情報は 発行者によって暗号化署名されており 企業は 受け取った情報の正当性を 信頼することができます AppleウォレットのIDは mdoc形式および 付随するISO 18013規格で構築された ドキュメントの1つの例です

現在 ユーザーは 米国内の一部の空港保安検査場や 一部の企業および施設や 米国全土のApple Store直営店で AppleウォレットのID書類を 対面で提示することができます 他にも Verify with Wallet APIを利用した 一部のアプリで IDを利用できます 皆さんのアプリで Verify with Wallet APIを採用して 本人確認を行う方法は WWDC 22のセッション 「What’s new in Wallet and Apple Pay」 をご覧ください 一部の地域では mdoc形式で ドキュメントプロバイダ アプリを構築しています これらアプリにより ユーザーは 本人確認書類を保存して対面で使用できます 地方道路交通当局を模して 運転免許証を管理する デモアプリを作成しました 「Local Driving Authority」と 命名しました 今年 このクラスの ドキュメントプロバイダアプリと ウォレットIDの分野における機能強化を ご報告できることを 大変嬉しく思います 今後のリリースからは W3Cの Digital Credentials APIもサポートして SafariおよびWebKitから mdocを要求できるようにします その仕組みを説明しましょう Spaceship Rentalsから 宇宙船をレンタルするとしましょう すでにSafariで Webサイトから 宇宙船と旅程の 選択を済ませてあります ここで 本人確認が必要になりました 先に進んで ボタンをタップします このボタンが JavaScript Digital Credentials APIをトリガします 運転免許証は 2つのアプリに保存してあります Local Driving Authorityと Appleウォレットです このアプリ選択UIで 本人確認に使用するアプリを 選択することができます

今回は Appleウォレットを使います

同意シートが表示され 確認を求められます IDの詳細閲覧を求めているのが誰かは ブランドアイコンと名前で確認できます どういう要素が要求されているのか また この情報を保存する 意図があるかないかも 確認できます Face IDでの承認により 本人確認の実行を承認します Spaceship Rentals社のWebサイトに 情報が提示されたことが 確認できますね すごいでしょう？

Erikさん iPhoneでも上手くいきましたね じゃあ Macからは？ いい質問ですね やってみましょう

再びSafariを表示していますが こちらは私のMacです 先ほどと同じ Spaceship Rentals社のWebサイトです

先に進んで ボタンをクリックします 手元のiPhoneで続けるように 促されます iPhoneに通知が表示され 本人確認を実行できる状態になります タップすると 先ほどと同じオプションで 使用アプリの選択を求められます 今回も Appleウォレットを使います さきほどと同じ同意シートが表示され 誰がリクエストしているのか どの要素を要求しているのか この情報を保存する意図があるかどうかを 確認できます 問題ないので Face IDで確認を実行します

素晴らしいですね これで ドキュメント情報が Mac上のSpaceship Rentalsに 返されたことがわかります Mac上のSafariのサポートを 実装したほかにも 他のOSやブラウザを交えた クロスプラットフォームでの ID検証用に標準化されたサポートを 導入しました 他のプラットフォームやブラウザから 宇宙船を借りるとしても iPhoneのIDは引き続き使用できます ブラウザに表示されるQRコードを スキャンすればよいのです ご紹介したフローは 一連の規格に基づいて 構築されています W3CのDigital Credentials API 特にISO 18013-7の附属書Cと ISO 18013-5で定義された リクエストプロファイルで使用します FIDO CTAPプロトコルは クロスプラットフォームフローに使われます Appleプラットフォームとの統合用に Webサイトが記述したコードは 同じ規格を採用している他のブラウザや アプリでも動作するというわけです

この体験は クロスプラットフォームを 実現するために ゼロから構築されました iPhone、iPad、Macに加え 他のブラウザやOSまで サポートするよう 構築されています ユーザーがインターネット上の どこで閲覧していても iPhoneにあるドキュメントを使用して 本人確認を行うことができます 最後に Appleプラットフォーム用に一連の Document Provider APIを構築しました これらのAPIを使用すると Local Driving Authorityなどのアプリを 本人確認フロー中に オプションとして表示させることができます 先ほどご覧になったデモをもとに その仕組みを詳しく説明します Webでのmdoc認証は ブラウザでの Webサイトへのアクセスから始まります Webサイトはサーバに接続し mdocリクエストを作成して署名します Webサイトがリクエストを受け取れば Digital Credentials APIは使用可能です 本人確認を開始するアクションを ユーザーが実行すると Webサイトはリクエストを使用して Digital Credentials APIを呼び出します

その後 ブラウザは基盤となるOSに リクエストを転送します OSは リクエストとユーザー操作の 組み合わせをもとに リクエストに応答するための ドキュメントソースを特定します これは ローカルにインストールされた ドキュメントプロバイダアプリであったり まったく別のデバイスであったりする 可能性もあります

特定が済むと 処理のため リクエストが 適切なドキュメントソースに渡されます ユーザーはドキュメントの引渡しを 承認します ドキュメントのソースから リクエスト元のWebサイトまで さかのぼる形で 暗号化された応答が返されます 最後に 復号化と検証のため Webサイトがこの応答を サーバに送信します

一歩引いて全体を見渡すと Appleプラットフォームでの オンラインmdoc検証のさまざまな 構成要素を より明確にイメージできます このフローを実行する場合 エントリポイントは2種類あります iOSドキュメントプロバイダアプリの デベロッパの皆さんは Document Provider APIに 興味を持たれるかもしれません このAPIを使用すると iOSアプリを オンラインmdoc検証実行用の オプションとして表示できます

オンラインでの本人確認実施に 関心のあるWebサイトとしては W3CのDigital Credentials APIと 関連する リクエストと応答の 処理ロジックの実装に 注目したいところでしょう このフローについて 詳しく紹介します

ざっくり言うと mdocのリクエストに際して Webサイトが取るべきステップは 3つあります

1. 本人確認のためユーザーが Webサイトにアクセスしたとき 文書リクエストの作成と署名を サーバに要求する必要があります 2. ユーザー側でID確認のための 準備ができたら W3CのDigital Credentials APIを介して ブラウザにリクエストを渡す必要があります

3. 応答を受信したら Webサイトは 復号化と検証のため 暗号化された応答を サーバに送信する必要があります Marcosさんは 熱心な Full Stackデベロッパですが Spaceship RentalsのWebサイトで チェックアウトフローに 本人確認ステップを組み込む方法を 説明してもらえますか？ 喜んで まず W3CのDigital Credentials APIを 使用して リクエストを作成し 署名する方法を紹介します ISO 18013-7附属書Cで標準化された内容に 準拠したリクエストを作成します リクエストは2つの部分に分けられます Device Requestと Encryption Informationです 1つずつ詳しく見ていきましょう Device Requestには 2つの重要な情報が含まれています まず Document Requestのリスト ユーザーに要求するドキュメントは ここで宣言できます Spaceship Rentalsは 運転免許証の確認を望んでいるので モバイル運転免許証のdocType文字列を 構造体に入力します 次に リクエスト対象である 運転免許証の 特定のプロパティを追加します これは 名前空間と要素識別子の 標準化されたセットを介して実行します この場合は 氏名を要求します 本人が21歳以上の場合は ポートレート写真と 運転免許内容を要求します

デバイスリクエストの もう1つの重要なパラメータとは 「Reader Authentication All」リストと 呼ばれているもので Webサイトはここで リクエストに署名します このプロパティは後ほど使用するので 今は空のままにしておきます リクエストの2つ目の部分が 暗号化情報です 応答を暗号化するために ドキュメントプロバイダが使用する パラメータを ここに配置できます

暗号化で使用するnonceを 生成する必要があります nonceとは リプレイ攻撃の防御に役立つ 重要なセキュリティ機能です 他に 受信者の 暗号化キーペアも生成します このキーペアは ドキュメント応答の 暗号化に使われます 暗号化情報構造体に 受信者の公開鍵を配置して 後で使うため 受信者の秘密鍵を保持します 最終的に ドキュメントの応答を 復号化するために使うので サーバ上で安全に保管することが 重要になります 以上で 完全なリクエストが構成されます

リクエストが作成できたら 署名に進みましょう ドキュメントプロバイダアプリが違えば リクエストに署名するための条件も 違ってきます Spaceship RentalsにAppleウォレットの IDを受け付けてもらいたいので まずは ウォレットのリクエストに 署名することから始めます

リクエストに署名する前に Apple Business Connectから署名証明書を 取得する必要があります 署名キーペアを生成して Apple Business Connectに 証明書署名リクエストを 送信することで 取得できます 証明書を手元に揃えたら 手続きに進む準備は完了です ここで 2つの情報を使用して セッショントランスクリプトを 生成する必要があります WebサイトのURLと 先に生成しておいた 暗号化情報の構造体です セッショントランスクリプトは 後の操作でも使用します セッショントランスクリプトができたら 署名の準備は完了です 署名には 署名キーペアと Apple Business Connectから受け取った 署名証明書を使用します これで 署名付き認証構造体ができました

こちらの ウォレット用の 署名付き認証構造体を Reader Authentication Allリストに入れます この仕組みは ISO 18013-5の定義によるものです 他のドキュメントプロバイダアプリでは リクエストへの署名に関する要件が 若干異なる場合がある点に 注意してください Local Driving Authorityアプリ内の 書類を受け付けたくても 当局では 先に発行された まったく別の証明書を使って リクエストに署名するよう 要求する場合もあります

幸い Reader Authentication Allは リストなので リクエストには 何度でも署名できます そこで Local Driving Authorityからの 認証を使用して 新しい署名付き認証構造体を 作成しました ウォレットの署名付き認証構造体と 一緒に挿入できます

リクエストが用意できたら JavaScriptで書かれたW3Cの Digital Credentials APIを使用して これをブラウザに渡します これで サーバで構築した リクエストデータを取得して リクエストディクショナリに 入れられるようになりました 標準化された「org-iso-mdoc」文字列を 使用して 「protocol」プロパティを介した 「mdoc」リクエストとしても定義した点に 注意してください これで navigator.credentials.get メソッドを呼び出して 応答を待つ準備ができました このメソッド呼び出しにより ブラウザがシステムUIを表示するので ユーザーはここで デジタル認証情報を選択できます ちなみに getメソッドの呼び出しには マウスのクリックやボタンの押下など ユーザーのジェスチャが必要になります 応答を受信したら 復号化サーバに 送り返すことができます 応答はJSON形式でシリアル化できるため Fetch APIやXHRを使用して 簡単にサーバに送り返すことができます 最後に 何か問題が発生した場合 W3CのDigital Credentials APIが プログラムの回復に役立つ 例外セットを豊富に提供しています または IDのスキャン画像を HTMLフォームを介してアップロードするなど 既存の本人確認方法に フォールバックすることもできます すごいですね コードをテストして 動作を確認しましょう 上出来です ボタンを押すと システムUIが表示されますね リクエストが機能している証拠です ウォレットとLocal Driving Authority アプリの両方が 選択可能なオプションとして 表示されています どうですか Erikさん？ 素晴らしいですね Marcosさん 次のステップに進む前に このフローの セキュリティについて説明します IDデータと同等レベルの 機密性の高い情報を扱う場合 適切なセキュリティ保護の実施を 徹底することが重要です たとえば こんな疑問が 浮かんでくることもあるでしょう 誰がIDデータをリクエストしているのか？ IDデータの保護は大丈夫か？ いったい本物なのか？ コピーではないか？ こうした疑問に答えるため 標準装備のセキュリティ保護について 1つずつ説明します

リクエストの認証については これまでに説明しました この仕組みを通じて リクエスト側の Webサイトの正当性を保証したり ドキュメントプロバイダアプリを通じて ユーザーがリクエスト側の情報を 把握するための支援を行います こちらは リクエストの署名に使用する 証明書を介して行われます

次は 応答の暗号化です 応答は リクエスト側のWebサイト サーバにより生成されたキーを使用して エンドツーエンドで暗号化されます これにより ブラウザやOSなども含めた 第三者による IDデータの読み取りが不可能になります 発行者認証は IDデータの信頼性証明に使われます これにより リクエスト側のWebサイトは 誰がデータを発行したか 信頼できる相手なのかを特定できます また 返されたデータの変更も防止します 最後に mdoc認証により データの重複を防ぎます これで リクエスト元のWebサイトは 受信したmdocが 発行元と同じデバイスによるものであると 確認できます この仕組みにより mdocが複数のデバイスで 重複する可能性を防ぎます

Marcosさん 応答処理の際に セキュリティプロパティが機能する仕組みを 紹介してもらえますか？ もちろん 説明しますね

最後に Spaceship Rentalsでの 実装を完了するため ドキュメントプロバイダから返される 応答の処理が必要になります リクエストの場合と同様に JavaScriptの応答形式が ISO 18013-7附属書Cで 定義されています 応答にも 2つのプロパティが 含まれています 1つは 解読が必要な暗号文です もう1つは ドキュメントプロバイダアプリが 暗号化プロセスの一環として 生成した鍵です 暗号文は RFC-9180で定義されている ハイブリッド公開鍵暗号化 略してHPKEにより 暗号化されます

復号化のための入力には 暗号文と 送信者の応答からの公開鍵の 両方が含まれます また 先ほどリクエストをビルドした際に サーバで生成した 受信者の秘密鍵も含まれます 最終的に入力するのは 先ほど リクエストの署名時に生成したものと同じ セッショントランスクリプトです この操作によって 復号化された デバイス応答が得られます 応答のドキュメントはそれぞれ モバイル セキュリティオブジェクトを含みます このオブジェクトは不変のもので 発行者による署名付きです 返されたデータの 正当性を検証するにあたって 不可欠な情報も含んでいます モバイルセキュリティオブジェクトの認証は 発行者認証構造体を介して行われます この構造体は 文書署名者証明書を含んでおり これを最初に 検証する必要があります 発行者が公開した 信頼された認証機関の ルート証明書と連鎖させることにより 検証を行います Spaceship Rentalsのサーバは 信頼された認証機関のルート証明書の 一覧を保持しており これをもとに mdocの受け入れを判断します 文書署名者証明書が 信頼を得られない場合 その応答は破棄することになります 証明書の確認ができたら 署名を検証する必要があります 発行者の認証構造体を 検証できたら モバイルセキュリティオブジェクトの 検証に進みます ここで実行するべき検証は いくつかありますが 最も重要なのは 返されてきた要素の 正当性の検証です 返された要素は 「発行者の名前空間」内にあります たとえば この例では 「Kelly」という名前が返されています ですが 使用する前に この要素が 改変されていないという証明が必要です そのためには 要素情報構造体全体の ハッシュダイジェストを計算します 次に このダイジェストを モバイルセキュリティオブジェクト内にある 特定のダイジェストと比較します 比較するべきダイジェストは 要素の構造体で提供されている ダイジェスト識別子をもとに特定します ダイジェストの比較で 問題がなければ データが本物であるという 確信が得られます 最後に mdocの認証について 検証が必要です モバイルセキュリティオブジェクトは デバイスの公開鍵を含んでいます この鍵は ドキュメント発行先のデバイスに 一意に与えられるものです このキーを使用して デバイス認証構造体を検証します これで ドキュメントが発行先の デバイス由来であると確認できます 応答の処理は これで終わりです これまでに 応答の検証に必要な作業の 概要を紹介しました 実行するべき 正確な検証手順の詳細については ISO 18013-5規格をご覧ください ここから フローの残りの部分を テストします Spaceship Rentalsのリクエストに応じて ウォレットを選択して

認証を行います フローが正常に機能して Spaceship Rentalsによる 情報の復号化と検証が完了しました これでようやく レンタルした宇宙船で出航できます Erikさん どうでしょう？ お疲れさまでした！ 実装中に注目してきた 重要なポイントを ここでおさらいしましょう 1. Digital Credentials APIは Webでの本人確認を必要とするユーザーに クラス最高の体験を提供します APIと統合することは Webサイトが クロスデバイスフローなど 使いやすいプラットフォーム機能に アクセスできるようになることを意味します 2. mdocsを要求するWebサイトは 一連の規格を標準実装しています つまり 記述したコードは 同じ規格に対応している すべてのブラウザで機能するため 幅広い相互運用性を実現できます 3. APIそのものが 安全性を向上させます これまで紹介してきた保護機能に加えて ドキュメントプロバイダアプリはこのAPIにより リクエスト元のWebサイトで ドメイン検証を実行できるようになります これにより フィッシング攻撃の実行が さらに困難になります

W3CのDigital Credentials APIとの 統合で必要となる 実装については以上です リクエストを作成して署名し Digital Credentials APIを介して送信し 暗号化された応答を処理しました Webサイトでmdocをリクエストするために 必要な作業から 話は変わって アプリでのオンラインmdoc検証を 実現するためにAppleが構築した Document Provider APIに注目しましょう 先ほど Spaceship Rentalsで 本人確認を行った際に 2つ目のアプリ Local Driving Authorityアプリを 使用するというオプションがありました これは 私たちが作成した 運転免許証を保存できるサンプルアプリです

先に進んで Local Driving Authorityアプリを選ぶと このような認証UIが表示されます このUIは アプリが実装する UI App Extensionにより提供されます ドキュメントを提供するiOSアプリを すでに構築している場合は この拡張機能を アプリに追加するだけで オンラインID検証を有効にできます

このエクスペリエンスは ID文書を 中心とした新しいフレームワークの 追加によって強化されています それが IdentityDocumentServicesです 仕組みをご紹介しましょう 最初のステップは App Extensionの外部で行われます 提示可能なID書類を アプリがプロビジョニングするたびに この文書をiOSに登録します これにより 選択UIに 文書が表示されるようになります ドキュメントを登録する際は そのドキュメントの種類と 要求Webサイトを承認するにあたり どの認証局を信頼するかを指定します iOSは このドキュメント登録情報を デバイス上でローカルに保持します

次は本人確認フローです ユーザーがこのフローをトリガします iOSは 保存されている ドキュメント登録情報を使用して リクエストに応答できるアプリを 特定します 次に 先ほども見た 選択UIが表示されます

ユーザーはここで 使用するアプリを選択します iOSは ドキュメントプロバイダアプリに 部分的なリクエストを送信します 「部分的なリクエストとは何か？」と 思われるかもしれません 受信したISO 18013デバイスリクエストには 未加工の解析可能なデータBLOBを含む いくつかのプロパティが収容されています これらは ドキュメントプロバイダが 署名を正確に計算して検証できるよう エンコードされています ただし 保証されたユーザー操作なしで Webサイトからの 未処理のデータBLOBを解析することは ユーザーデータを扱うOSコンポーネントの 脅威となる可能性があります こうした危険性を軽減するため システムはこのリクエストの一部を 安全なSandbox内から解析します リクエストを解析する前に OSはまず リクエストの署名を検証します その結果作成されるのが 文書リクエストや認証証明書など UIのビルドに必要な情報を収容する 部分的なリクエストというわけです

アプリは 部分的なリクエストを受け取り App Extensionで表示するUIの ビルドに使用できます

ユーザーがドキュメントの公開を許可したら 完全なISO 18013デバイス要求が ドキュメントプロバイダアプリに公開され 使用可能になります ここで ドキュメントプロバイダアプリは 2つのリクエストを比較して それらが一貫しているか確認し 続いて ISO 18013デバイスリクエストの 署名を検証します

検証が完了したら アプリはドキュメントの応答を構築して リクエスト元のWebサイトに向けて 暗号化します

応答がiOSに送り返され さらに iOSからWebサイトへ転送されます Marcosさん Swiftには詳しいですか？ 危険なことは十分知っています 素晴らしい 地方道路交通当局が 助けを必要としているようです Document Provider APIの統合を 手伝ってもらえますか？ もちろん お願いします OK まず実装する必要があるのは 登録手順です このステップはLocal Driving Authority アプリによるmdocの作成後に 行う必要があります すべての登録アクションは IdentityDocumentProviderRegistrationStore型を 介して行われるため まずはストアを初期化します 次に MobileDocumentRegistration オブジェクトをインスタンス化します このオブジェクトには mdoc登録用の 情報が収容されています 地方道路交通当局が 運転免許証を発行し こちらは モバイル運転免許証用に 標準化された ドキュメント型文字列を入れます 「mDL」というmobileDocumentType 文字列で これを確認できるでしょう 次は 信頼する認証局の キー識別子を指定します これにより 適切なタイミングで アプリを表示できます これら認証局のいずれからも署名のない リクエストが届いた場合 私たちのアプリは 選択シートでは非表示になります 次は ドキュメント識別子を 指定します この識別子は アプリ内にある mdoc用ストレージに簡単にリンクできます 登録オブジェクトが作成できたら addRegistration()メソッドを呼び出して iOSに登録します

アプリのユーザーには 運転免許証を 削除する権限を与えてあります ユーザーが運転免許証を削除した場合は 以降 アプリのオプションとしては 表示されないようにしたいですね 削除した運転免許証に対応する 登録を削除すれば これを実現できます この処理は removeRegistration()メソッドを 介して行われます 先に作成してあったmdocの 登録内容と一致する ドキュメント識別子を渡します 現時点でシステムに保存されている アプリ登録の照会が 必要になる場合があります その場合は 登録のプロパティを使用します 返された登録の一覧で処理を反復して 検査を実行できます 次は UI App Extensionを アプリに追加します

実行するには 新しいターゲットを Xcodeプロジェクトに追加して 「ID文書プロバイダ」テンプレートを 選択します

これにより 実装用Extensionが 生成されます コードを入力できる場所は 2つあります performRegistrationUpdates() メソッドは ユーザーがLocal Driving Authorityによる オンラインでの本人確認を承認すると 呼び出されます このメソッドは アプリのストレージに 保存されたmdocsをすべてチェックして iOSに登録されているかどうかを 確認します これ以外の実装先は 「ISO 18013 Mobile Document Request Scene」コンテンツです ユーザーがアプリを選択した際に 表示される承認UIは ここで構築できます UIを実装するため RequestAuthorizationViewを定義して 受け取ったコンテキストを渡します この新しいビューの実装結果を 見てみましょう ISO18013MobileDocumentRequestContext を取り込みます これは App Extensionによって提供されます この型には 応答を送る際に要求される リクエスト情報と コールバックメソッドが収容されます

このビューのbodyを実装するにあたり UIには3つの主要な部分があります リクエスト実行者とリクエスト対象に関する 情報を含むビューを 構築する必要があります このために コンテキストオブジェクトから 受信したリクエストを受け取る RequestInfoViewを定義します これは Erikさんが先ほど話していた 部分的なリクエストです 次に実装が必要になるのが ユーザーが本人確認を「承認」するための ボタンです これには ビューで定義した acceptVerification()メソッドの 呼び出しが含まれます 実装しましょう 検証を受け入れる 準備ができたら リクエストコンテキストオブジェクトで sendResponse()メソッドを呼び出します このメソッドはクロージャを受け入れます クロージャは rawRequestパラメータを受け取ります ここでISO 18013デバイスリクエストの 出番です デバイスリクエストを受け取ったら これを リクエストコンテキストオブジェクトからの 部分リクエストに照らして 比較する必要があります ここで 未処理のリクエストの署名を 検証する必要があります アプリがWebサイトを信頼しているか 確認の手がかりにするためです

リクエストに問題がなければ ドキュメントの応答を構築して暗号化します 最後に クロージャからの 応答データを返します 返された応答は リクエスト元の Webサイトに送り返されます

acceptVerification() メソッドの実装は これで終わりです

UIを完成させるための最後のピースが ボタンです 実装の手順は リクエストコンテキストの cancelメソッドを呼び出すだけです

以上が Local Driving Authorityアプリの 基本的な実装方法です Erikさん ありがとう Marcosさん

オンラインmdoc検証フローの 紹介ツアーは これにて終了です 紹介した2つのAPIは 柔軟性に優れており Webサイトでの 幅広い本人確認体験の 実現を可能にします Webでの本人確認には ベストなソリューションだと自負しています 締めくくる前に Digital Credentials APIの統合に 着手するにあたって 必要となるステップを いくつか紹介します 皆さんがWebサイトデベロッパで ウォレットにあるIDからの 本人確認情報リクエストに 関心がおありなら Apple Business Connectによる 登録と証明書の受け取りを 検討してはいかがでしょう 自治外のアプリなど 別のアプリから ID情報をリクエストしたい場合は 追加のオンボーディング要件について アプリ発行元に確認しましょう ID文書の提出に関心のある アプリデベロッパの皆さんは ID文書プロバイダApp Extensionを アプリ内に実装しましょう 使用しているAPIにとらわれず このセッションに登場した さまざまな規格をチェックしましょう 皆さんにとって 本当に頼れる情報源となり 実装プロセスの本質を理解する上で きっと役立つでしょう

ご視聴ありがとうございました WWDCをお楽しみください