原著論文
Shibboleth IdP V5 におけるPasskeys の種別による認証可否の判定
キーワード:
Shibboleth IdP,
Passkeys,
Device-Bound Passkeys,
Synced Passkeys,
Authentication Assurance Level,
AAL2,
AAL3
2025 年 29 巻 1 号 p. 130-140
詳細
2025 年 29 巻 1 号 p. 130-140
パスワードレス認証方式の1つであるPasskeysは，デバイス間での同期が可能なSynced Passkeysとデバイスに紐づくDevice-Bound Passkeysの2つに分けられる．これらは当人認証の保証レベル（AAL）において，Synced PasskeysはAAL2，Device-Bound PasskeysはAAL3に分類されるためセキュリティ強度に差異がある．主に教育機関で利用されるShibboleth IdPではPasskeysの利用は可能であるものの，その種別を判定する機能はサポートされておらず，AAL3の要件を満たすことができない．本論文では，Shibboleth IdP V5の環境においてPasskeysの種別による認証可否の判定を可能にする機能を開発した．この機能により，Synced PasskeysとDevice-Bound Passkeysのセキュリティ強度の差異を考慮して認証ポリシを調整することができ，連携するサービスのAALに応じた適切な認証を実施可能となる．
近年，様々なWebサービスの発展やSNSの普及，政府によるGIGAスクール構想の推進などにより，インターネットが年齢を問わず身近なものとなっている．それに伴いオンラインによる本人確認における情報セキュリティの重要性が一層高まっている．特に当人認証については，運用者にとっての導入の容易さやユーザにとっての理解しやすさから，パスワードを用いた認証方式が広く一般に利用されてきた．しかしこの方式はユーザ1人あたりの利用サービスの増加に伴うパスワード管理の煩雑化や，ブルートフォース攻撃やアカウントリスト攻撃などに代表される数々の攻撃手法など，構成が単純であるがゆえに多くの脆弱性を抱えている．こうした問題に対処するため，2要素認証（2FA）や多要素認証（MFA）が様々なサービスで導入されている．これは認証の3要素である「知識情報」，「所有物情報」，「生体情報」の中から複数の要素を認証時に利用する方式である．知識情報だけの認証だったパスワード認証と比べ，追加の要素を組み合わせるため，より強固な認証が実現できる．しかし認証ステップの増加によるユーザビリティの低下や中間者攻撃（Man in the Middle）への耐性の低さなど，課題も多くなっている．こうした問題を解決するため，近年ではパスワードレス認証が注目されている．その中でも特に注目を集める方式がPasskeysである．
Passkeysは公開鍵暗号を利用した認証方式であり，鍵ペアの検証によりユーザ認証を行う．ユーザは対応する認証器（Authenticator）で鍵ペアを作成，サービス登録時に公開鍵の情報もあわせて登録する．認証時には対応する秘密鍵で電子署名を付与し，それを検証するというプロセスとなる．そのためインターネット上に秘密情報が流れず，パスワードを利用しない安全な認証を行うことができる．またユーザが行う操作はAuthenticatorに依存しており，例えばスマートフォンをAuthenticatorとして利用する場合，スマートフォンのロックを解除するのと同様の操作をするだけで認証を完了できるためユーザ利便性が高い．
PasskeysはAuthenticatorの種類によって，複数デバイスで利用できるSynced Passkeysとデバイスに紐づいたDevice-Bound Passkeysに分けられる．Synced Passkeysは，クラウドストレージに秘密鍵が保存され，複数デバイス間で同期が可能である．一方Device-Bound Passkeysは，秘密鍵がAuthenticatorとしてのハードウェアトークンに固定されるためデバイス間での同期ができない．利用にはハードウェアトークンが必須となり一般的なユーザにとっては利用の敷居が高くなるが，秘密情報をハードウェアの外部に取り出すことができないため，より堅牢であるという特徴がある．以上のように保存方式の違いにより堅牢性は異なるが，現状これらのPasskeysは同レベルの認証強度と設定されることが多い．
2022年5月にApple，Google，Microsoftの3社が共同でPasskeysへの対応を発表[1]して以降，様々なWebサービスでPasskeysへの対応が進んでいる．1Passwordが運営するPasskeys.directory[2]によれば，本論文執筆時点では，223のサービスで利用可能となっており，サービス利用開始時などにPasskeysの設定を促すサービスも見られる．しかし教育機関での本格的な活用は未だ始まっていない．国内の高等教育機関と国立情報学研究所（NII）が連携して構築および運用を行う学術認証フェデレーション（学認）では，Passkeysへの対応が進められているものの，導入状況は限定的となっている．学認の根幹技術となっているShibbolethにおいてさえ，2024年12月5日にShibboleth IdP V5のプラグインとしてPasskeysの機能を部分的にのみ可能にするWebAuthn version 1.0.0[3]が正式にリリースされただけで，フル実装までの課題は多い．
本論文では，Synced PasskeysとDevice-Bound Pass-keysのセキュリティの強度の違いに着目し，Passkeysの種別による認証可否の判定を可能にした認証システムの構築を行った．システムの根幹はShibboleth IdP V5を利用しており，既存のプラグインの機能を拡張することで実装した．これによりPasskeysを利用した認証の認証ポリシを柔軟に調整することができ，連携するサービスが要求する認証レベルに応じた適切な認証を実施可能となる．
認証方式としてPasskeysの利用を選択することは，従来のパスワード認証が抱えていたセキュリティリスクを大幅に軽減することにつながる．そのため今後，多くのWebサービスにおいてPasskeysが採用されることが予想できる．また学認をはじめ，教育機関での活用も大いに期待できる．しかしPasskeysの導入には考慮すべき問題点も存在する．本章ではそれらの問題点について述べる．
Passkeysは，FIDO2のコンポーネントのひとつであるWebAuthn（Web Authentication）[4]で生成・管理されるFIDO Credentials（FIDO認証資格情報）である．PasskeysにはSynced PasskeysとDevice-Bound Passkeysの2種類がある．Synced Passkeysは複数のデバイス間で同期可能なPasskeysである．同期にはクラウドが用いられ，クラウド上に保存されたPasskeysをデバイス間で共有する．Synced Passkeysは特定のプラットフォームのアカウントに紐づいたPasskeysであり，そのアカウントにログイン可能で，ユーザ認証機能を持つデバイスならば利用可能となる．典型的な例としてスマートフォンがあり，現在では一般的にiPhoneであればiCloud Keychain，Android端末であればGoogle Password Managerに保存され，当該アカウントにログインすることで使用できる．Device-Bound PasskeysはSynced Passkeysと異なり，Authenticatorとしてのハードウェアトークンに紐づけられたPasskeysである．Authenticator内で生成されたPasskeysは外部に流出せず，Authenticator内部でのみ保存される．登録や認証の際にはAuthenticatorをClient Deviceと接続して利用する．Device-Bound PasskeysのAuthenticatorの例として，YubicoのYubiKeyやGoogleのTitan Security Key等が該当する．ユーザの操作は使用するAuthenticatorのアクティベーション方法に依存し，PINでの認証や生体認証が利用可能である．Synced Passkeysはデバイス間で同期可能で利便性が高いという特徴があり，Device-Bound PasskeysはAuthenticatorに固定されており同期不可だがより堅牢であるという特徴がある[5]．Synced Passkeysは，Device-Bound Passkeysが持つ堅牢性を一部緩和することによって利便性を高めた仕様と言える．そのため攻撃者によるアカウントの不正利用やなりすまし，クラウドストレージそのものへの攻撃など，Device-Bound Passkeysが持たない脆弱性がある．
また当人認証の強度を表す指標としてAAL（Authentication Assurance Level）がある[6, 7]．AALでは，保証レベルが最も高いレベル3（AAL3）の要件の1つとして，耐タンパ性を持つハードウェアトークンの使用が求められる．利用可能なハードウェアトークンの例として，YubicoのYubiKeyやGoogleのTitan Security Key等のセキュリティキーがあり，これらで生成および管理できるPasskeysはDevice-Bound Passkeysである．AALの定義からSynced PasskeysはAAL2，Device-Bound PasskeysはAAL3にそれぞれ相当しており，Synced PasskeysはAAL3に対応していない．そのためAAL3を要求するほど高いセキュリティを求められるサービスでは，Synced Passkeysでは要件を満たさない．
NIST SP 800-63B[8]にあるようにAAL2とAAL3は明確に区別されておりPasskeysに関しても2種類の堅牢性の差異はあるが，文献[5]に示されているとおり異なる種類のPasskeys間の違いを考慮した研究は非常に少ない．少なくともPasskeysに関しては現状多くのサービスではこれらの差異は考慮されておらず，同レベルの認証強度として扱われることが多い．現状のShibboleth IdPにおいても，WebAuthnプラグインを導入することでPasskeysを用いた認証はできるものの，Passkeysの種別を判定する機能はサポートされておらず，それを利用した認証可否の判定はできない．高いセキュリティを求められる環境やSPとの連携では，Device-Bound Passkeysの利用をのみを許可すべきだが，現状すべてのPasskeysを同等の認証強度として扱ってしまうためAAL3の要件を満たせない可能性がある．
Passkeysはパスワードレス認証の実現に大きく貢献する技術だが，Synced PasskeysとDevice-Bound Passkeysの特性を考慮した適切な認証制御が求められる．本論文では，両者のセキュリティ強度の違いを考慮し，Passkeysの種別に応じた認証可否の判定をShibboleth IdP V5で実装したことを報告する．
桐明ら[9]は，NIIでShibboleth IdP V4向けに開発されたWebAuthnプラグインを拡張し，Shibboleth IdP V4にてFIDO2認証の実装を行った（2024）．この研究におけるシステムの動作環境について表1に示す．
| IdP version | Shibboleth IdP Version 4.3.1 |
| アプリケーションサーバ | Tomcat 9.0.84 |
| FIDO認証サーバ | webauthn.io |
この研究ではShibboleth IdPとして，現在はEOLとなっているShibboleth IdP V4を使用している．またFIDO認証サーバにはオープンソースであるwebauthn.io[10]を使用している．この研究で開発されたWebAuthnプラグインは，Authenticatorの登録は1つまでであり，Authenticatorを管理する機能を持たないといった制約がある．
本論文との相違点として動作環境が挙げられる．本論文においてShibboleth IdPは最新バージョンであるIdP V5を利用している．またWebAuthnプラグインについてはShibbolethの開発元が提供するWebAuthn version 1.0.0を利用しているため，WebAuthnプラグインそのものの開発は行っていない．桐明らが実現したものは登録が1つという制約があったが，その制約は無くしている．
3.2 学認のAAL2対応への取り組み学認では，次世代認証連携への取り組みを進めている．これまで個別に提供してきたスーパーコンピュータ，研究基盤等の各種サービスに対する認証強化や提供が躊躇されてきた認証強化を，セキュリティの観点からIdPでの認証連携を通して利用可能な環境を構築することを学認の取り組みは目的としている．現在では，これまでと比較し一段強い認証基準であるAAL2の運用を進めている[11]．
AAL2の基本方針として，「多要素認証器1個またはパスワード認証に所持要素に基づく認証器を組み合わせたもの」という要件を採用している．また業界標準等の外部認定を参照することとし，運用上の問題に注力することとしているため，様々なベンダから発表されているAuthenticatorを使用したFIDO認証についても利用可能となっている．Authenticatorの採用に関しては，学認認証器レジストリ[12]が構築されている．これは代表的なAuthenticatorに対してあらかじめ調査し，AAL2の認証が可能なものを認定しておくレジストリである．また参加機関の求めに応じてAuthenticatorの審査・認定を行った場合，その結果を登録し，定期的に更新することで他機関の認定にも適用できる．
本論文ではより強力な認証を要求するSP（service Provider）に対して適切なAALの認証方式を提供するために，IdPにてPasskeysの種別を判定し認証可否を判定する．
尚，Shibbolethを対象としている時にSPと呼ばれているサービス提供側は，より一般的にはRP（Relaying Party）と呼ばれる．以下，特にFIDO2を対象とした場合，RPと表現する．
WebAuthnの仕様にはPasskeysの種別を直接やりとりできるパラメータが含まれない．そのため本節では，Passkeysの種別を取得するために行ったAuthenticatorの情報の拡張について解説する．
本論文で使用したWebAuthnプラグインでは，Authenticatorに関するメタデータの2種類のソースをサポートしている．1つはFIDO AllianceのFIDOメタデータサービス（MDS, Meta Data Service）から提供されている公式FIDOメタデータであり，YubiKey等のAuthenticatorの情報が含まれる．もう1つはローカルに設定されたJSONファイルから，Authenticatorの基本的なメタデータを取得する方法である．本論文では後者の方法を採用し，メタデータソースとしてPasskeys Developerから提供されているaaguid.json[13]を使用した．このJSONファイルは，FIDOメタデータサービスに含まれないAuthenticatorの情報を補完する役割を持つ．実際，MDSにはサードパーティ製の特にSynced passkeysに対応したつまりAAL2の対象となるソフトウェアの認証器は未登録のものが多く，今回利用したGoogle Password Manager, Proton Pass等（表4）も掲載されていないが，aaguid.jsonには掲載されている．また，ローカルに設定されたファイルであるため，新規に作成された認証器であっても個々に割り当てられるIDであるAAGUID（Authenticator Attestation Global Unique IDentifier）が決まっていれば登録してPasskeyとして利用することが可能となっている．
aaguid.jsonに含まれる情報は，AAGUIDそのものとそれに対するAuthenticator名，アイコンのみである．本論文ではこの情報を拡張し，AAGUIDごとにAuthenticatorで保存可能なPasskeysの種別を表す「type」を追加した．「type」は「synced」と「device-bound」のいずれかを設定しており，それぞれSynced PasskeysとDevice-Bound Passkeysに対応する．修正後のaaguid.jsonに含まれるAuthenticatorのメタデータ例を図1に示す．またそれぞれのメタデータ構造について表2に示す．なおFIDOメタデータサービスから提供されるデータの形式はJWT（JSON Web Token）であり修正が困難であるため，FIDOメタデータサービスに含まれる一部のAuthenticatorの情報に関してもaaguid.jsonに追記した．
| Key Name | Data Type | Description |
|---|---|---|
| name | String | Authenticatorの名前 |
| icon_dark | String | アイコン（ダークテーマ） |
| icon_light | String | アイコン（ライトテーマ） |
| type | String | 保存可能なPasskeysの種別 |
認証可否の判定のため，WebAuthn全体の動作を設定するファイル「webauthn.properties」に表3に示す要素を追加した．この要素は「synced」，「device-bound」，「any」の3種類を任意に設定可能なプロパティである．FIDO認証時には，認証に使われたAuthenticatorのAAGUIDからaaguid.jsonのtypeに記載されたPasskeysの種別を取得する．そして取得したtypeとidp.authn.webauthn.allowedKeyTypesの値が一致する場合のみ認証を許可する．またidp.authn.webauthn.allowedKeyTypesの値がanyの時，Passkeysの種別がどちらであっても認証を許可する．
| Property | Values |
|---|---|
| idp.authn.webauthn.allowedKeyTypes | synced |
| device-bound | |
| any |
本論文で作成した認証可否の判定を含めた認証フローについて図2に示す．
1. ユーザはClient Deviceで起動したWebブラウザから，Shibboleth SPにアクセスしリソースを要求する．
2. SPはユーザのログインセッションを確認し，セッションが無効の場合Shibboleth IdPにリダイレクトする．
3. IdPはユーザ名をリクエストするため，Webブラウザにユーザ名入力ページを表示する．
4. ユーザは表示されたWebページにユーザ名を入力する．
5. IdPは送信されたユーザ名からユーザを特定し，WebブラウザにFIDO認証用ページを表示する．
6. ユーザはFIDO認証をリクエストする．
7. IdPはchallengeを生成し，RP情報とともにWebブラウザに送信する．
8. Webブラウザは，Authenticatorにユーザ認証をリクエストする．
9. Authenticatorでユーザ認証を行い秘密鍵を特定し，RP情報とchallengeに署名を施しAssertionを生成する．
10. Authenticatorの情報，AssertionをWebブラウザに送信する．
11. WebブラウザはWebAuthn APIを通じて情報をIdPに送信する．
12. IdPはAuthenticatorの情報に含まれるAAGUIDを取得する．
13. IdPは取得したAAGUIDをaaguid．jsonから探し，該当するAuthenticatorで生成可能なPasskeysの種別を取得する．
14. IdPは許可されたPasskeysの種別から，取得したPasskeysの種別が認証可能か検証する．またAssertionの検証も行う．
15. IdPは各検証に問題が無ければSAML Assertionを生成し，SAMLレスポンスとしてSPに送信する．
16. SPはSAMLレスポンスを検証し，ユーザにリソースを提供する．
本論文では，Shibbolethのデモ環境構築にDockerコンテナを使用した．全体の構成図を図3に示す．尚，動作が軽量で高速である点や再生成が容易であるという観点からDockerを採用したものであり，動作再生のためにDockerを利用しなかった場合に新たに制約が発生するものではない．
システムの主要なエンティティは，クライアント，リバースプロキシ，Shibboleth IdP，LDAP，Shibboleth SPである．このうち本論文で作成したエンティティは，リバースプロキシ，Shibboleth IdP，LDAP，Shibboleth SPの4つである．これらはすべてDockerコンテナとして実装されており，同一のDocker Networkに属する．次節以降では，それぞれのエンティティの役割を解説する．
5.1.1 クライアントクライアントはFIDO認証を行うユーザ環境全体を表す．クライアントの構成要素は，ユーザ，Authenticator，Client Deviceの3つである．それぞれについて以下で解説する．
ユーザユーザは，FIDO認証を行う主体である．Shibboleth SPにアクセス後，リダイレクト先のShibboleth IdPにてPasskeysの登録や認証などの操作を行う．
AuthenticatorAuthenticatorは，ユーザがFIDO認証に用いる認証器である．ユーザが操作することで，Passkeysの生成と管理を行う．Client Deviceに内蔵されているものはPlatform Authenticator，外部のものはRoaming Authenticatorとなり，Attachmentはそれぞれplatformとcross-platformである．本論文で使用したAuthenticatorについて表4に示す．
| Name | Provider | Key Type |
|---|---|---|
| YubiKey 5C | Yubico | Device-bound |
| Titan Security Key | Device-bound | |
| Windows Hello | Microsoft | Device-bound |
| Google Password Manager | Synced | |
| Proton Pass | Proton | Synced |
Client Deviceは，Webブラウザが動作するデバイスである．Webブラウザは，WebAuthn APIが動作するブラウザであり，WebAuthn RPからのリクエストに応じてAuthenticatorと接続する．そしてAuthenticatorから取得した情報を，WebAuthn APIを経由しWebAuthn RPに返信する役割を持つ．本論文で使用したClient Deviceの構成について表5に示す．このデバイスには，使用したAuthenticatorの1つであるWindows Helloが組み込まれている．
| 機種名 | ThinkPad Z13 Gen1 |
| OS | Windows 11 Pro 24H2 |
| TPM | TPM 2.0 |
| Webブラウザ | Vivaldi Version 7.1.3570.39 |
また使用したスマートフォンについて表6に示す．このデバイスは，使用したAuthenticatorの1つであるGoogle Password Managerを使用する．
| 機種名 | Xperia XZ3 SO-01L |
| OS | Android 10 |
| 生体認証機能 | 指紋認証 |
リバースプロキシは，Dockerコンテナで作成されたサーバであり，コンテナが属するDocker Network内への外部からのリクエストを中継する．リバースプロキシの構成について表7に示す．
| ディストリビューション | Debian GNU/Linux 12 |
| Webサーバ | Nginx 1.27.2 |
| ポート | 80，443 |
リバースプロキシに接続するコンテナは，Shibboleth IdPとShibboleth SPの2つである．本論文で作成したShibboleth環境のWebサーバ間の通信はHTTPSを利用する．HTTPSのポートは443を利用するが，Dockerの設定でコンテナの外向きのポートを自由に設定可能である．ここでShibboleth SPのホスト名が「sp.example.org」の時，外向きポート番号を「10443」と指定した場合を考える．ホスト名が「sp.example.org」であるため，Shibboleth IdPで設定するEntity IDは「https://sp.example.org/~」となる．しかしアクセスする際のURLは「https://sp.example.org:10443/~」となるため，IdP-SP間のリダイレクトにあたり，Entity IDと異なるホスト名からのアクセスと判断され正しく処理されない．この問題を解決するためリバースプロキシを導入し，IdP-SP間の通信をDockerネットワーク内で完結するように構成した．
リバースプロキシのコンテナはリクエストのドメイン名から送信先を判定し，それぞれのコンテナに振り分ける．振り分けの例について図4に示す．例では，IPアドレス「127.0.0.1」をドメイン名「idp.example.org」と「sp.example.org」の2つに解決している．
Shibboleth IdPはこのシステムのIdPであると同時に，WebAuthn RPとしての機能を持つエンティティである．このエンティティはIdPとしての基本的な機能をサポートし，登録されたShibboleth SPとの間で認証連携を可能にする．またユーザ情報を登録するデータベースとしてLDAPと接続する．Shibboleth IdPの構成について表8に示す．
| ディストリビューション | Rocky Linux 9.5 (Blue Onyx) |
| IdP Version | Shibboleth IdP Version 5.1.3 |
| Webサーバ | Apache HTTP Server 2.4.62 |
| アプリケーションサーバ | Jetty 11.0.22 |
本論文のShibboleth IdPには，WebAuthn RPとして運用するためにShibboleth IdP V5向けプラグインであるWebAuthn Version 1.0.0を導入した．プラグインの機能によりWebブラウザのWebAuthn APIを利用し，クライアントのAuthenticatorに対してPasskeysの生成や使用をリクエストする．
認証フローにおけるWebAuthnは，MFAのフローに組み込むことで利用可能となる．本論文における認証フローでは，WebAuthnを単一の認証要素として利用しておりPasskeysのみで認証完了とする．しかしユーザがPasskeysを登録していない場合，パスワード認証を利用して最初のPasskeysを登録することができる[14]．このフローについて図5に示す．
1. ClientはWebAuthn RPにFIDO認証をリクエストする．この際，認証の対象となるユーザ名を入力する．
2. RPは当該ユーザについてPasskeysが登録済みか確認し，未登録であればパスワード認証をリクエストする．
3. ユーザはユーザ名およびパスワードを入力し，RPへ認証情報を送信する．
4. RPは認証情報を検証後，問題なければPasskeys登録用ページを表示する．
5. 以降のPasskeys登録フローは，WebAuthnの仕様に従う．
5.4 LDAPLDAPはShibboleth IdPのデータベースとして動作する．本論文ではユーザ認証フローにおいて，IdPからリクエストされたユーザのデータを返す．LDAPの構成について表9に示す．
| ディストリビューション | Debian GNU/Linux 10 |
| LDAPサーバ | OpenLDAP 2.4.57 |
Shibboleth SPは，アクセスしてきたユーザをShibboleth IdPにリダイレクトし，認証完了後サービスを提供するWebサービスである．本論文でのShiboleth SPはデモサイトとして動作しており，IdPでの認証が成功したことを示すのみの役割となっている．Shibboleth SPの構成を表10に示す．
| ディストリビューション | Rocky Linux 9.4 (Blue Onyx) |
| SP Version | Shibboleth SP V3.4.1 |
| Webサーバ | Apache HTTP Server 2.4.57 |
AAL3となるハードウェアキーYubikey5Cを利用したPasskeyの登録の手順は以下の通りである．前提として，IdPではAAL3を利用するように設定してあるものとする．
1. ユーザがSP“https://sp.example.jp/secure”にアクセスするとIdPにリダイレクトされ図6のように表示される．
2. 左下の“Register new credential”を選択した後でユーザ名とパスワード入力する．
3. セキュリティキーの登録状況を示す画面となる．初期状態では図7のように登録が何もないことが分かり，追加のために“Add new security key”を押下する．
4. 図8のようにPasskeyの保存先の認証器を尋ねられるので，「セキュリティ キー」を選択する．
5. 図9のようにクライアントPCにセキュリティキーを挿入するように促されるので，指示に従い挿入する．
6. セキュリティキーを挿入した後，セキュリティキー用の認証コードを入力し利用可能とする．
7. 図10のように登録したPasskeyに名前を付与する．
8. 認証が完了し，図11のように登録されたことが明示されるようになる．
Passkeyを利用して認証をする様子を示す．ここでは，6.1.1においてPasskeysが登録されているものとする．
1. ユーザがSP“https://sp.example.jp/secure”’にアクセスするとIdPにリダイレクトされ図6のように表示される．
2. ユーザ名を入力すると図12のようなFIDO認証トップ頁に遷移するので，“Login with passkey or security key”を押下する．
3. 図13のように登録されている認証器への接続が要求されるので，指示に従いセキュリティーを挿入しセキュリティキー用の認証コードを入力するとセキュリティキーが利用可能となり，認証が完了する．
尚，認証器のPasskeysの種別が許可されていない場合，認証失敗となり図14のようにエラーが表示される．
ログの出力に含まれる主なものは次の4項目である．
aaguid，対象URL，公開鍵，webAthnの型（「create」等）
Titan Security Keyを登録した際のログの主要部分は図15に示したとおりであり，実際にTitan Security KeyのAAGUIDである“42b4fb4a286643b29bf76c6669c2e5d3”と対象となるWebサイトのURL及び公開鍵を確認できる．尚，斜体字で示したものは，省略して記載したものである．
4章で述べたWebAuthnの拡張を実証するために，5章において設計及び実装を行い，本章において実際にPasskeysの登録やそれによる認証の様子を示した．これにより，IdPへPassskeysを登録する際にAAL2かAAL3を見極めることが可能となり，ユーザがレベルを意識した登録が可能となった．また，認証の際にも，AAL2か3のいずれのレベルに見合った認証で認証することが可能となった．今回の実現では，AAL3が要求された際にはAAL3での認証が必須とされ，AAL2が要求された際にはAAL2が必須とされることはもちろん，よりレベルの高いAAL3での認証でも条件を満たすものとしている．また，よりレベルの高い認証はあえて要求しないAAL2のみを要求し，AAL3では要求を満たさない設定も可能としている．
以上により，Passkeysの種別によりAAL2とAAL3の認証の可否を柔軟に判定できるようになったと考えられる．
本論文では，Shibboleth IdP V5において，Passkeysの種別による認証可否の判定を可能にした認証システムを構築した．これによりShibboleth IdPで任意の種別のPasskeysのみを認証可能に設定することができ，Device-Bound Passkeysのみ利用可能とするAAL3の要件を満たすことが可能となった．
今後の課題として，今回構築したシステムでは認証可否の振り分けがShibboleth IdPの設定に依存するため，連携するShibboleth SPごとに認証ポリシを柔軟に変化させることができない点が挙げられる．Shibboleth SPから利用可能なPasskeysの種別あるいはサービスが対応するAALを取得し，それに応じた認証を行うように設計することで，それぞれのサービスに応じた認証ポリシを適用することができる．具体的には，昨年度行われたNIIによる実証実験が参考になると考えている．実証実験はAAL1とAAL2に関するものであるが，AAL3まで容易に拡張できるものと考えられる．これは，SAML requestへのAALの要求およびSAML responseへのAALの情報の埋め込み，更にSPとIdPのAAL対応状況の共有により実現することを考えている．
また本論文では，認証可否のみを判定したが，Passkeysの種別によってWebAuthn RPへの登録可否を判定できるように拡張することが考えられる．本論文の設計を登録処理に流用する場合，WebAuthn RPでの登録可否の判定自体は可能である．しかしPasskeysの種別を判定するタイミングの都合上，Authenticator側に登録処理が失敗したことを知らせることができない．そのため登録が失敗した場合，WebAuthn RPには登録されておらず認証に利用できないPasskeysがAuthenticatorに生成および保管されてしまうという課題がある．しかし登録処理への拡張が実装出来た場合，例えば大学で運用するIdPにおいて，学生が登録可能なPasskeysの種別をSynced Passkeysのみに限定したいという需要がある．これはDevice-Bound Passkeysのアカウントリカバリの困難さを考慮したものであり，Authenticatorの紛失や破損，買替時の窓口業務を削減することに繋がる．現状，多くの学生が登録するPasskeysはAuthenticatorとしてスマートフォンを利用することが予想できるため，ほとんどの場合Synced Passkeysの登録となる可能性が高い．しかし現在Android端末では既に，Android側とWebAuthn RP側の双方で設定が必要なものの，Device-Bound Passkeysの利用が可能である．またiPhoneにおいては現在，Device-Bound Passkeysの利用はサポートされていないものの，Face IDやTouch ID利用のためにSecure Enclaveが搭載されている[15]ため，今後対応する可能性は十分に考えられる．
以上から，今後の展望としては連携するShibboleth SPの開発による認証ポリシの柔軟な変化と，本論文の認証可否の判定を登録処理にも拡張することが考えられる．加えてWebAuthn RPにAAGUIDを送信するか否かを定義する要素「credentialCreationData.attestationConveyancePreferenceOption」がindirectである場合，情報を匿名化して送信することが可能である．これを利用してAAGUIDを匿名化しPasskeysの種別のみを送信できるような機能を実装することで，ユーザが使用したAuthenticatorをRPに知らせることなく認証可否の判定が可能となる．このようにユーザのプライバシを考慮した拡張も考えられる．
本論文では，Passkeysの認証器の情報としてMDSではなくaaguid.jsonを利用した．後者の方が最新の認証器にも対応しており，対応していなくても手動で追加することも可能と考えられる．しかし，当該ファイルに関しては信頼性，網羅性，保守性の観点からはMDSに比べて制約が多い．当該ファイルの管理，更新作業を学認に登録されたIdPそれぞれの管理者が行うことは現実的ではないと考えられるため，例えば学認を取りまとめているNIIが管理，更新作業を行い，その結果を他のメタデータと同様各IdPに配信するようにすることにより各IdP管理者の負担が軽減できるものと考えられる．
この研究は2025年度国立情報学研究所公募型共同研究（252S1-23665）の助成を受けています．
