2024年3月14日木曜日

OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が開始されています

こんにちは、富士榮です。

先日ポストした、OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が始まっています。

Notice of Vote for Proposed Implementer’s Draft of OpenID for Verifiable Credential Issuance

https://openid.net/notice-of-vote-for-proposed-implementers-draft-of-openid-for-verifiable-credential-issuance/


個人でもOpenID Foundationのメンバになれますので(50ドルかかりますが)、ぜひ登録して投票してください。

2024年3月13日水曜日

OpenID Foundatioon Hybrid Workshop@Googleオフィス(マウンテンビュー)

こんにちは、富士榮です。

次回のIIW(Internet Identity Workshop)の前日(4月15日)に開催されるOpenID Foundation Hybrid Workshopのレジストレーションが始まっているので忘れずに登録しましょう。(2月後半にレジストサイトがオープンしたので速攻申し込みました)

先日日本でもOpenID Summitの前日に開催されたワークショップですね。
その時の様子はこちらです。

今回はマウンテンビューにあるGoogleのオフィスで開催されます。

こちらは2022年の4月に同じくIIWの前にOIDF WorkshopがGoogleで開催された際の写真です。このチャリ欲しいなぁ。。と思った記憶があります。

今回は私も現地参加の予定なので様子をリポートしたいと思います。


2024年3月12日火曜日

パスキーの実験に使ったコードをgithubにあげました

こんにちは、富士榮です。

そういえばパスキーの実験をしていた頃のコードを公開するのを忘れていた気がするので公開しておこうと思います。

これまでのパスとでやったことはこちらです。


あくまで実験的に実装した内容ですので参考までに、です。

そろそろ忙しくなってきたのでOpenID Providerのログインにパスキーを組み込むのは少し先になりそうです。。。

2024年3月11日月曜日

自己主権型アイデンティティは本当か?情報銀行からの学びはあるのか?

こんにちは、富士榮です。

ちょっと前に情報銀行の認定事業の最後の一つだったDataSignさんのPaspitがサービス停止をしたことで通常認定がゼロになった、というニュースが界隈で出ていました。
DataSignさんのニュースリリース

情報銀行「paspit」サービス終了のお知らせ 

https://datasign.jp/blog/paspit-announce/ 

結果、IT連盟の通常認定がゼロになっています。

https://tpdms.jp/certified/


ちなみにP認定はまだありますが、そもそもP認定は「「情報銀行」サービス開始に先立って立案した計画、運営・実行体制が認定基準に適合しているサービスであることを認定するものです。サービス開始後において運営・実行、改善を図り、『通常認定』の取得が条件となります(P認定の更新は不可)。」という定義なのでサービスが開始されていない(もしくはサービスを開始する前の検討段階)のものなので、実質サービスとして提供されているものではありません。なので本当にゼロ件です。

この分野はそれほど詳しいわけではありませんが、そもそもの情報銀行の意義は利用者が自分の情報を適切に扱ってくれるサービスに適切に渡すために情報銀行サービス事業者に情報を信託することで安心してサービスを利用できるようにしましょう、という取り組みだったはずです。つまり、前提として情報銀行サービスが情報を提供する先の審査を行い、適切に情報を扱うことが確認できている場合に情報を提供することでリテラシーのあまり高くない利用者を保護しましょう、という話です。これは正に信託銀行が利用者の代わりに株式や資産の運用を行うことで利用者個人が過剰に責任を負うことなく安全に資産運用ができるようにしましょう、という話と同様のもので、その意味で情報(信託)銀行だったわけです。
しかしながら、実態として情報銀行においては、この信託銀行や銀行の本来の価値である利用者に変わって比較的安全に運用を行いましょう、という部分が私たちの頭から抜け落ちていたように感じます。結果、単に個人情報をサービス事業者に預けると利子(ポイントなどのリワード)がつく、雑に言うと「個人情報を売っている」感覚に近くなっていき敬遠されていく、というサイクルだったのかな?と思ったりしています。

ちなみにこの話は本日のコラムのテーマでもある「自己主権」についても隣接する話題だと思っています。今日はそんな話です。

自己主権とユーザの責任

これまでも自己主権型IDの責任モデルについてあちこちでお話してきました。
(2019年ごろによく使っていたスライド)


また、主権?という話についても正直疑問に思っている、という話も何度もしてきました。
(昨年のOpenID TechNight、分散型ID勉強会の資料より)


この辺りを踏まえて少し自己主権型アイデンティティについて考えてみましょう。
簡単にまとめると、自己主権アイデンティティのモデルにはユーザの責任が重くなりすぎると言う点で以下の通り課題があると思っています。
  • 自己主権の一番の難しさは結果的にユーザに責任を押し付けることになること
  • つまり、ユーザは誰に情報を提示して良いのかを自身の責任で判断しないといけない
従来のID連携のモデルでは多くの場合RPとIdPの間で事前の信頼関係構築が前提となっていました。具体的にはIdPとRPはトラストフレームワークなどで表現されるID連携のために必要なルール(例えばRPは受け取ったID情報を適切に扱うこと、など)に基づき事前に合意している前提がありました。
そのため、IdPにアカウントを登録するユーザはIdPが連携できるRPをある程度審査していることを含めある程度納得した上でRPを使っているという建て付けになっている(利用規約とかポリシーに記載されている)わけです。

ただし、あくまでIdPがある程度担保してくれるためにはユーザが使うRPの情報などをIdPが知ることができてしまう、という点においてプライバシーリスクが指摘され、Walletを使うことでIssuer/Verifierの間にWalletが入り、ユーザ自身の意思を反映した形でID情報のやり取りが行われる=自己主権でありプライバシー上の問題がなくなる、という話になってきたわけです。

ところが、このことによりIssuerは、Verifierを事前に審査することができなくなるわけで、Verifierが適切なのかどうかを判断できず、あくまでユーザが自身の責任でVerifierに情報を提供しなければならない、ということになってきてしまいました。

果たしてユーザは責任をとれるのか

「自己責任」の一言で済ませられるのであればそれで議論は終了なわけですが、人類はそれほど賢いわけではありません。いつまで経っても秘密鍵やパスワードの管理を人類はできるようになっていないわけで、VCがWalletに入っていても正しく管理できるようになるとは思えません。
暗号資産についても結局は事業者に管理を委託しちゃってますよね。本来はあれもBitcoinのアドレスを自分で管理することもできるはずですが、結局はカストディアンに頼るのが自然な状態になっているわけです。

と言うことでどんな対応ができるのか考えてみる

結局はWalletをIssuerが管理化に置き、VCを提示できるVerifierを制限する、などが必要になるのかもしれません。しかしIssuerが管理をするモデルになると、従来のID連携モデルでIdPが利用者が使っているRPを知れてしまう、という問題の解決にならず、Walletモデルの意味がなくなってしまいます。
となると、もう選択肢になり得るのはWalletプロバイダが提示できるVerifierを制限するという形が良いのかも知れないな、と最近は思っています。
もちろん、Verifier毎に専用Walletを使う、などの対応をしないと今度はWalletプロバイダがユーザが使っているVerifierを知れてしまうという問題が出てくる可能性もあるのですが、このモデルだと結局自己責任モデルにしかなりませんし、Verifier毎にWalletが大量にインストールされているスマホを持ちたいとは思いません。(それこそカスタムURLスキーム問題で技術的にもややこしいことになりますし)

結局はユーザが安心してVerifierにID情報を提示することができる状態を作る必要があるわけなので、ユーザが誰かを信頼して委託する(つまり信託する)必要があるわけです。Walletプロバイダのモデルだと、ユーザは従来のID連携モデルでIdPを信頼したのと同様にWalletプロバイダを信頼することになります。
こうなると、Walletプロバイダに情報が集約することは諦めるしかないわけなのですが、
  • ID連携に比較してIdPへのCall home問題はなくなるのでIdPの可用性を含む全集中度合いは下げられる(別の切り口だが)
  • Walletプロバイダが本当に認定済みVerifierに対してVCを提示したかどうかはわからないようにWalletを作ることはできるはず
ということは考えられるわけで、ID連携のモデルとの差別化はできそうです。

これを実現するためには、Walletプロバイダが審査済みのVerifierのみにVCを提示可能にするなどの機能を実装し、VC提示の際に許可・不許可のリストをローカルで参照する仕組みになっていればWalletプロバイダは審査済みのVerifierのうち、実際にユーザがどこに対してVC提示を行ったかは検知できないようにはできるのではないかと思います。(本当にそんな実装になっているかどうかは信頼するしかないとは思いますが)

このことで、
  • ID連携におけるIdP万能という状態からは少し前進できている気はする
  • 多分、次のVC関連のビジネスはWalletプロバイダが本当の意味での情報銀行(提示先の審査による安心の提供)としての機能を提供することなのかも知れない(どこまで利用者からお金を取れるかは未知数だけど)
と思えます。
この辺は引き続き皆さんと意見公開をしつつモデルを考えていけるといいですね。

2024年3月10日日曜日

EUのDigital Identity Walletのリファレンス実装が公開されています

こんにちは、富士榮です。

各国でデジタル・アイデンティティ・ウォレット(DIW)の検討や実装が進んでいますが、先行して検討が進んでいるEUの実装やアーキテクチャ・リファレンス・フレームワーク(ARF)を参考にすることが多いと思います。

ARFはこちら

The European Digital Identity Wallet Architecture and Reference Framework

https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework


今回はドキュメントではなく、Digital Identity Wallet並びに関連するモジュールがgithubで公開されている、という話です。ビルドすればWalletが作れるのでみなさんも試してみると面白いと思います。

こんな感じで動くようです。

レポジトリより

こちらで公開されています。

https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md

公開されているのは、以下のモジュール群です。

  • Wallet Core(Android) and Wallet Kit(iOS) Coordinator Libraries
    • Wallet Core(Android)
    • Wallet Kit(iOS)
  • Proximity Sharing iOS Libraries
    • mDoc Security(iOS)
    • mDoc Data Transfer(iOS)
    • mDoc Data Model(iOS)
  • Proximity Sharing Android Libraries
    • mDoc Data Transfer(Android)
  • Remote Presentation iOS Libraries
    • Presentation Exchange(iOS)
    • SIOPv2 and OpenID4VP protocols(iOS)
    • SD-JWT(iOS)
  • Remote Presentation Android Libraries
    • Presentation Exchange(Android)
    • SIOPv2 and OpenID4VP protocols(Android)
    • SD-JWT(Android)
  • Issuing iOS Libraries
    • OpenId4VCI(iOS)
  • Issuing Android Libraries
    • OpenId4VCI(Android)
  • Wallet Data Storage and Cryptographic Management iOS Libraries
    • mDoc Document Storage (iOS)
  • Wallet Data Storage and Cryptographic Management Android Libraries
    • mDoc Document Storage (Android)
  • Wallet UI App and demo App for Android and iOS
    • UI / Demo App (Android)
    • UI / Demo App (iOS)
  • Verifier Apps and Services
    • Web Verifier
    • Restful API (web-services)
  • Issuing Apps and Services
    • OpenId4VCI issuer (Python)
    • OpenId4VCI issuer (Kotlin)

結構膨大ですね。

日本でもDataSignさんが進めているOWND ProjectなどオープンソースでWalletなどの実装を公開する動きが出てきていますし、開発者のみなさんには良いことだと思います。

OWND Project

https://github.com/OWND-Project


2024年3月9日土曜日

OpenID Foundationの提供するテストスイートの開発者(Javaプログラマ)の募集が出ています

こんにちは、富士榮です。

OpenID Foundationは同団体が開発している各種仕様やプロファイルに関する認定プログラムを提供しています。

みなさんが開発しているOpenID Providerなどがこのプログラムに認定されると上記のページに掲載され、安全に使えるソリューションであることが認められた形になります。
最近ではOpenID Connectのコア仕様だけではなく、FAPIやOpenID for Verifiable Presentationに関するテストも開発されています。

今回は認定プログラムに適合することを確認するためのテストスイート自体の開発をするためのJavaプログラマを募集している、という話です。



我こそは!という方は応募してみてはいかがでしょうか?
プロトコルやプロファイルにとっても詳しくなれると思います。

2024年3月8日金曜日

統合認証シンポジウム(佐賀)に参加しています

こんにちは、富士榮です。

毎年3月に佐賀大学で開催されている統合認証シンポジウムに参加するために4〜5年ぶり?に佐賀大学に来ています。大学や研究機関でID基盤の企画や運用をしている方々がたくさん参加される歴史あるシンポジウムです。
佐賀大学ホームページより

IAL2/AAL2のロードマップを作ろう:学認のサポート:佐藤先生(東京大学・学認)

大学や研究機関におけるID保証の必要性の話です。
文科省としてもオープンアクセスを推進しているのが大きな理由ですね。
オープンアクセスとは・・

このような状況への対処とインターネットの普及を受けて学術情報をインターネットから無料で入手でき、誰でも制約なくアクセスできるようにするというオープンアクセスの発想が1990年代に生まれた 


組織が研究者のアイデンティティを保証した上で、研究者がそれらのアイデンティティを使って研究活動を行う、というのが基本的な考え方です。すでにNIIではGRDM、Jairo Cloudという基盤を運用していて、各機関のIdPを使ってログインして利用するのが基本的な使い方です。

この枠組みがいわゆる「学認」、学術認証フェデレーションなわけですが、まだ全大学が参加しているわけではない、という課題があります。
これはオンプレミスでShibboleth IdPを建てて運用していく、というのは負荷も高いのでMSやGoogleのアカウント管理(要するにGoogle WorkspaceやMicrosoft 365ですね)や、IDaaSサービスを使っていく必要があるので、学認としてもサポートしていこうとしている、ということです。

その一つの取り組みとして、ここ3年ほど「次世代学認」という旗印のもの、質の高いIdPの運用を可能にするにはどうするのがいいのかを模索してきたわけです。その取り組みに加えて新たなミッションとしてより多くの大学がサービスを享受するにはどうすればいいのか?を考え始めており、そのために学認の求めるIAL/AALを定義してIDaaSやIdPの構築をする際のガイドラインとして提供しよう、という話になっている、ということですね。(こちらの作業部会には私も参加しておりましてサポートさせていただいております)

この辺りをNIST SP800-63をベースに設計をして行っているのはデジタル庁がやっていることと似ていますね。
こちらの会議にも私は参加していまして、先日の会議の議事録が最近公開されていますのでご参考までに。

本気でこれを推進していこうとするとなかなか難しい話も多く、ポリシー策定等の文書を作り、リスク評価、実現可能性の評価、予算・人員の確保、構築、としっかりと計画を立てて進めていかないといけないですね。
現在、そのために「中規模実験」として意見交換〜文書化を進めています。来年度はシステムに関する技術的なところ(プロトコルやIdPの構成など)も進めていく予定なので参加機関募集!というアナウンスもありました。

他にもAALにも触れられています。Google AuthenticatorやMicrosoft Authenticatorやパスキー(Face IDやWindows Helloなど)などの新しい認証器がたくさん出てきていますが、しっかりリスク評価をした上で認証器レジストへ登録して公開する、という動きもあります。FIDO Metadataの学認版って感じですね。


学認対応IdPホスティングサービス実証実験とそこから得られた課題と対応:清水先生(NII)

学認参加機関を増やしていかないと先のオープンアクセス・オープンサイエンスが実現しないわけなのですが、そのためには各大学や機関がIdPを構築する必要があるわけです。このあたりはそれなりにハードルも高いので、学認対応IdPホスティングサービスをNIIが中心に提供していくことを検討している、という話です。
本格提供に先んじて2023年3月〜実証実験を行い、参加機関と協力して課題のあり出しなどを進めてきたそうです。

加えて自組織に所属していない学認未参加機関に所属している研究者と共同でSPを利用する際の扱いをどうするか?についても大きなテーマでNIIが提供している認証プロキシ(Orthros)を利用することも検討されてます。このあたりは実証実験から出てきた課題ですね。


京都大学におけるOrthrosの活用に向けて:中村先生(京都大学)

京都大学で進めている研究DXの取り組みの推進においては「サービス主導型選択的多要素認証システム」がテーマになっているということです。
すでに教員・学生には多要素認証システムを導入しているということですが、学外研究者に関するID保証強度をどのように高めていくか?というのが次の取り組みとなっているわけですね。これはこれまでのセッションでも出てきたオープンアクセスの話題そのものっていうことです。しかし外部ユーザとして名誉教授も入ってくるんですね・・・大学のID種別多すぎです。

ここで登場してくるのがOrthrosってことです。
外部の機関の提供するサービスを使ってIALやAALを補強していくためのHubのような役割となるシステム(認証プロキシ)として利用するイメージです。

これは重要な示唆ですが、大学におけるID管理がますます重要になってきている、ということが挙げられています。やはり研究データは非常に重要なもので国家レベルの機密情報に当たるものもあるわけなので、研究者の本人確認〜ID保証(IAL/AAL)が非常に重要になってきているということです。

この辺りを学内認証基盤と学外の利用者を対象としたOrthrosをうまく活用して安全な世界を作っていけると良いですね。

公開鍵暗号方式に基づく認証機能の分離:大神さん(LINEヤフー)

パスワードレスの話です。先日発表されていたPKaaSの話ですね。
参考)PKaaSデモ

まずはパスキーの説明です。

次にLINEヤフーさんのパスワードレス認証の取り組みについて紹介がありました。SMS認証も合わせると2017年からパスワードレス認証の仕組みを提供しているので、かなり早いうちから対応を進めていました。さすがです。

すごい数のユーザがすでにFIDO認証を、そしてパスワードレス認証をしているんですね。

一方でパスワードレス認証の課題にも触れられています。
  • IdPがFIDOに関する機能を実装すること
  • IdPを運用する上で必要なこと
が結構あるので、この辺りを共通化してコンポーネント・サービスとして提供しよう、というのがPKaaSってことですね。要するに機関のIdPはID管理に注力して認証に関する情報管理(特にFIDOだと公開鍵の管理などが該当)はクラウド(PKaaS)に任せるのはどうだろうか?という提案です。

実装方式は2つあるそうです。リダイレクトするかバックエンドでAPIを呼び出す方法です。

リダイレクトの場合のoriginはPKaaSになるんでしょうか。そうなるtお大学IdP側のフィッシング対策にはならなさそうですので、どちらの方式で実装するかは考えたほうがよさそうですねぇ。

そういえば東大とヤフーさん共同でTrusted Webの実証をしていましたね。


ハイブリッドクラウド環境における認証基盤とクライアント端末の運用:石丸さん(名古屋工業大学)


NPS経由でAzure MFAを使っているんですね。Radiusを使う場合は確かにこういう構成になります。
そういえば昔AD FSとOpenAMの連携をやったなぁ、、という記憶が蘇ってきました。

しかし、この辺りはあるある過ぎて・・・私は過去に3日間同期完了まで待っていたことがあります。。。


検証可能な資格情報によるデジタル学生証・職員証の検討:伊東先生(九州大学)

ジェイズコミュニケーションズさんとの共同プロジェクトなんですね。

JWSの話かと思ったらVCの話でした。

どんな機能をデジタル学生証に載せるか、は結構考え所ですね。個人的な意見としては色々な機能を搭載していけばいくほど標準スキーマから離れていく気がするので難しいところだと思っています。

管理方針についても話がありました。大学で発行・失効などを集中管理するということでしたので、VCである必要性はどこまであるのかな?というのはちょっとした疑問でした。
VCサンプルというかJWTも見せていただけました。。。。

発行・提示のプロトコルは独自っぽいですね。
検証時にもIssuerに問い合わせに行くようです。

ユースケースはまだ想像がついていないと言うことでしたが、最後にデジタル名刺なんじゃないかな?とういこともおっしゃっていました。同意です。

質疑応答でも出てきましたが、学生証のユースケースで難しいのは試験のときに持ち込めない、という点なんじゃないでしょうか。


Shibboleth IdPにおけるFIDO2認証対応 事例報告:大谷先生(佐賀大学)

ワンタイムパスワードをメインで使ってこられていたということです。

Shibboleth IdPをFIDO2対応させました、とうことです。
ベースはNIIが公開しているFIDO2プラグインを使ったそうです。
当時はShibboleth公式版が出ていなかったからですね。
ちょうど最近オフィシャルからもアルファ版が出ていますので、今後はこちらも検討されていくのかな?と思います。ただShibboleth v5以降でしか使えないみたいなのでほとんどの大学では厳しそうです。

まだ管理型機能などはないと言うことで実環境で使うにはまだまだ手を入れないといけなさそうですね。
いずれにしても大学がリテラシーもバラバラな人たちがたくさん集まる場所でもあるのでパスキーをうまく使えるようになると良いと思います。

こんなところです。
来年も参加できるといいなぁ、と思いました。