自己主権型IDってなんなのか
全然いまさらのトピックだとは思うけど
ちゃんと自分の言葉で理解するためのメモ。
僕の頭の中ではIDといえばフェデレーションモデル というところで
止まっているので、アップデートのための勉強です。
自己主権型IDとはなんなのか
答えはここにだいたい書いてあったので引用
自己主権型アイデンティティ（Self Soverreign Identity /SSI）とは
「個人は、管理主体が介在することなく、自身のアイデンティティを所有しコントロールできるべきである」とするデジタル・ムーブメントを表す言葉。
そうか、SSIはムーブメントのことを指すのか
この図がめちゃくちゃわかりやすい
フェデレーションモデルだと、お買いものしたいAくんがお店でレジに行くと
お店がIdPに問い合わせ → IdPはAくんに「本当にAくんだよね？」と確認 → Aくんと確認できたらお店にその旨を連絡 → お店はAくんにサービスを提供
という感じだったのが
SSIモデルだと、お買いものしたいAくんがお店でレジに行き免許証を見せるだけで
お店はその免許証（の発行元である警察）を信頼し、Aくんにサービスを提供する
ということらしい
フェデレーションの何がだめで、SSIは何を解決するのか
IdPが認証を一元的に取り扱い、サービス（RP）がIdPに問い合わせるモデルだと以下のような問題がある
- IdPがシングルポイントとなる
シンプルに、IdPに認証の問い合わせが集中するのでボトルネックになり得る
構成変更などでサービス停止したいと思っても影響が大きすぎたり、IdP側ではもはやRPが被る影響の判断ができないのはあり得ると思う
- プライバシーの課題
IdP側や、あるいはRP側が結託すると行動把握ができてしまう
確かにある主体がいつどのデバイスからどのRPにアクセスしたか、それを繋げることで行動をうっすら追うことはできてしまいそう
- IdPとRPの情報が非同期
IdP側でステータスの変化があっても、RPはユーザがログインした契機でした情報取得ができない
IdP側でアカウント侵害があった際、緊急的にRPに伝達することを目的にSharedSignalsFrameworkというフレームワークが現在整備されているので
こういう仕組みがあれば課題は少しずつ解決するかもしれない
- ユーザから見てIdP運営事業者が信用できない
これはあるんだろうか？でもユーザはRPの提供するサービスを使いたいのであってIdPを自分で選んだわけではない
得体の知れないIdPに本人確認に必要な個人情報を渡すのは嫌かもしれない
登録時のKYCをIdPに任せることにもなるので、IdPのテキトウな本人確認により悪意のある第三者にアカウントを侵害され、なりすまされるリスクもあり得るかもしれない
なんとなくここまでは理解
では、SSIだと何が良いのか？
SSIは免許証、具体的には生成した識別子や認証のための鍵を自分のお財布で管理し、必要に応じてサービス側に提供できる、という考え方。
以下２つの特徴がある
- ID情報の利用可否が特定事業者（旧来のIdP事業者のような）に依存しない
IdPの場合だと、IdPが急にサービスを打ち切ると該当IDが使えなくなるリスクはあった
しかし、SSIだと自分でIDを管理しているのでそういうリスクはない。
例えば自国を追われた難民の人が有効な身分証明書をもっていない場合に、国に依存せず自身でアンデンティティを証明できるとして活用が期待されているもの
- ID情報の管理権限が個人にある
IdPの場合だと、個人の情報がどのように扱われているかはブラックボックスだが、SSIなら自分の意思で制御ができる
２つの特徴はこちらから引用
www.nri-digital.jp
これらを実現する実装としてDID（Decentralized Identity）といって、分散型台帳技術などを用いてIDを管理する仕様が整備されているそう。
W3Cにより検討されているDIDsという仕様だと、識別子をブロックチェーンなどの分散型システムで管理する
いろいろ疑問がわく
①そもそも生成した識別子や認証のための鍵は誰が発行するのか？
②それを個人でどう管理するのか？
②なんらか識別子や鍵を管理したとして、それを提示されたRPはどうやってそのIDが正しいか検証するのか？
ちょっと理解が追いつかないのでユースケースで確認してみる
今検討が進んでいるテーマが「学位・履修履歴証明」である
上述はDIDで実現されている
- 大学はDIDと関連付けられた証明書を個人に発行する
- 個人はその証明書をユーザエージェント（DIDに対応した証明書管理アプリ。いわゆるwalletかな？）で管理する
- 証明書は暗号化されたパーソナルデータストアであるIdentityHubで管理され、必要になったときにユーザエージェントを用いて第三者に必要な証明事項の提出を行う
うむ、、疑問①はこの場合大学、疑問②はDID対応証明書管理アプリで管理すると理解。
疑問③はどうなるんだろう？
例えば転職したとき、卒業証明としてDIDがついた証明書を提出したとして、会社はその証明事項が正しいかどう検証するんだろう？
図をよく見たら少し書いてあった
証明書要求者は提示された証明書の発行者及び内容を独自に検証可能
ちょうと同じ例で解説してくれているブログがあった
就職活動を例にとって説明しましょう。 学生 (Holder) は大学 (Issuer) から成績証明書 (VC) を発行してもらい、 就職したい企業 (Verifier) むけに成績証明書 (VC を加工した VP) を提示します。 VP を提示された企業はこの VP を見て、学生 (Subject) の成績と出身校 (Issuer) を 確認することができます。 VP の内容は、大学 (Issuer) が発行した内容であると数学的に証明されており、 詐称されていない情報として信用できるので、雇用するかどうかの判断材料になります。 本当に正しい情報かどうか、大学に問い合わせて確認する必要はありません。
うむ、、大学に問い合わせずしてこの証明書が正しいと検証する方法はVC（検証可能な資格情報 /Verifiable Credentials ）の勉強がいりそう、、、
ということで次回はDIDについて勉強します、、
VMwareはどうなるのか
Broadcomに買収されてからサービスやライセンスに変更がある（あった）らしい
使い続けるとどう影響があるのか、整理してみます
そもそもBroadcomってどんな会社か
Broadcomってシマンテックも買収してて名前は聞くけど実態をよく知らない会社である（個人の意見です）
- 1991年にロスで創業したBroadcom Corporationというファブレス半導体会社と、1961年にHPの半導体部門を起源として設立されたAvago TechnologiesがAvago側の買収という形で2016年に今のBroadcom Ltd.となる（なのでNADAQのティッカーシンボルはAVGO）
- 豊富な知的財産権ポートフォリオを有しており、無線通信、有線インフラストラクチャー、エンタープライズストレージ、産業用エレクトロニクスの4つが主要なターゲット市場。上述がカバーする代表製品は、携帯電話端末、基地局、データネットワーク、ストレージ／テレコム危機、工業用オートメーション、発電および再生可能エネルギーシステム、ディスプレイなど（出典：マクニカのページ）
- 今の本社はカリフォルニア州パロアルト、従業員は約2万人
ファブレスというのは、工場を持たないという意味で、製品の企画・設計・マーケ・販売などの機能に特化して、生産は他社に委託する業態だそう。
Broadcomも実際の半導体の製造は台湾や中国などアジアを中心としたファウンドリに任せている。
VMwareってどんな会社か
BroadcomによるVMware買収後の公式情報
とりあえず何がどう変わるのか、公式情報を拾います
2023年12月11日 VMwareニュース記事
1 . 製品ポートフォリオを大幅に簡素化する
- VMware Cloud Foundation（以降VCF）について、サブスクリプションの定価を半額にし、より高いサポートサービスレベルを追加
- VMware vSphere Foundation（以降VVF）について、中〜小規模顧客向けにより簡素なプラットフォームを提供
2 . サブスクリプションライセンスに移行する
- 本日より永久ライセンスの販売を終了
- 有効なサポート契約による永久ライセンスは使える
- 新しいサブスク製品と引き換えに永久製品の「下取り」を支援
2024年1月22日 VMware Cloud Foundationブログ
- VMwareのソリューションはVCFまたはVVFの一部としてのみ提供される
- 具体的にこのページでリストアップされている製品はスタンロアドンオファーとしては提供終了になった。VCF /VVFの一部としては利用できる可能性がある
※VMware vSphere ハイパーバイザー (無償版)などはNになっているので、VCF/VVFなどにも含まれず今後利用できない
なおVMwareの上述発表を受け、競合のNutanixが以下記事を出している
2024年1月16日 VMware ユーザーに対する Broadcom の予期せぬ結果に関する 9 つの予測
- 多くの顧客がより多くの料金を払うことになる
- 仮想化したからストレージ安くなる予定だったのが帳消し
- VMware代理店のマージンが削減されるのでサポートリソース減るかも
- Dellなど大手がVMware投資削減するかも
- EUC製品はさらにオープンになる可能性がある
- VMCが顧客あるいはプロバイダー管理サービスになる可能性がある
- DellがVxRailの焦点をScaleIOに移す可能性がある
- DPUの導入が遅れる可能性がある
- カスタマサポートが変更される可能性がある
2024年4月25日 旧VMwareエンドユーザコンピューティングビジネスであるOmnissaの紹介
よくわからん、、、
こんな記事もあったのだけど、いまいちよくわからず、、、
こちらに製品体系についてまとまった記事があったので引用します。ありがたや
VMware vSphereは
①小規模向けのVMware vSphere Essentials Plus
②小〜中規模向けのVMware vSphere Standard
③中〜大規模向けのVVF
と
④VCF
の４つのエディションに簡素化され、全てサブスクリプション型のライセンスに統一。
使い続けたい人はどうなるのか
- いま永続ライセンス持っている人は、サポート有効期限内はつかえる
- 更新のタイミングで、新たなエディションとサブスク型ライセンスに切り替え
- 要件によるが、使いたい機能がどのエディション、あるいはどのアドオンに含まれるかで現行より費用が高くなる可能性がある
- サポートなども今後手薄になる可能性がある？
とりあえず今わかるのはこんなところでしょうか
ガバメントクラウドとはなにか
とうとうこのテーマに向き合う時が来た
これまで横目で「大変そうだなぁ〜」と思っていたけどちゃんと勉強していく
なおここで取り扱う情報はすべて無料の公表情報のみ、です
ガバメントクラウドとはなんなのか
令和3年にデジタル社会形成基本法が施行された。
これによりデジタル社会形成のための基本理念や方針が定められることとなった。（あわせてデジタル庁設置法など関連法案が整備された）
また上記を根拠に制定されたデジタル社会の実現に向けた重点計画の中で
重点的な取り組みとして
3. 国や地方公共団体を通じてデジタル変革を推進する
＞ 7. 国・地方公共団体のガバメントクラウド移行
が定められている
（７）国・地方公共団体のガバメントクラウド移行
2023 年度（令和５年度）は、2022 年度（令和４年度）に引き続き、地方公共団体による先行事業等の整備を実施するともに、各府省庁や地方公共団体の情報システムについて、業務の見直し及び費用削減の努力を徹底した上でのガバメントクラウドへの移行を進めるほか、ガバメントクラウドテンプレートや各府省庁向け利用ガイド等の整備、クラウド移行支援体制の整備等を実施する。
そして、、、ガバメントクラウドの最新情報やドキュメントマスタのある場所がわからない
ここはなんか情報少ないよな、、、
利用の手続きやドキュメントを一元的なツールにした「GCAS（Government Cloud Assistant Service）」なるサービスがリリースされているのでそこにドキュメント類があると思われるが外部には公開されていない模様。
前述の法や計画によると地方公共団体だけでなく各府省庁もガバクラ活用対象だと思うのだがガバクラ単体の公表資料があまりないので、地方公共団体の標準化の文脈で公表されている資料から見てみる
地方公共団体情報システムのガバメントクラウドの利用について【第2.0版】
図７の説明がなく、、（文句ばっかですみません）でもイメージを掴むのにわかりやすいと思ったので引用
まずガバメントクラウド管理領域として
- ガバナンス
- 共通セキュリティ
- ログ収集
がデジタル庁より提供される
その上のガバメントクラウド個別領域は、利用権限を有する者が自由に構成できる領域のよう。
もう少しレイヤーで整理したもの？が下図
先ほどの3つの機能が具体的には
- ガードレール
- テンプレート
- 環境（払い出し）
- ガバメントクラウドとしてのセキュリティ設定
に分類され、さらに運用面として
が提供されるように読み取れる。
テンプレートについては一覧があった
詳細はAWSさんで公開されていた以下コンテンツに説明があった
自治体がガバメントクラウド利用に向けておさえておきたい 10 のこと
（閲覧にあたりメールアドレス等の登録が必要です）
aws.amazon.com
なおかつそれをレポートくださっているこちらの技術記事が見やすい
dev.classmethod.jp
ガバメントクラウドの利用は必須なのか
地方公共団体については地方公共団体情報システム標準化基本方針で定められているが
- 標準化基準（標準化法第６条第１項及び第７条第１項に規定する標準化のために必要な基準）に適合する基幹業務システム利用は、義務
- 標準準拠システムについてガバメントクラウド（デジタル社会形成基本法（令和３年法律第 35 号）第 29 条に規定する「全ての地方公共団体が官民データ活用推進基本法第二条第四項に規定するクラウド・コンピューティング・サービス関連技術に係るサービスを利用することができるようにするための国による環境の整備」としてデジタル庁が 4.3.1 に規定するとおり整備するもの）を利用することは、努力義務
となっている。標準化は2025年度までにという期限が切られており、現在標準化対応やガバクラ活用について作業が急ピッチで進められている理解である
一方で国は、デジタル庁が定める情報システムの整備及び管理の基本的な方針と冒頭の重点計画を受ける形で各府省庁が中長期的な計画を策定している
www.digital.go.jp
基本方針では以下のように4つの重点注力分野が定められており
ガバメントクラウドは２の共通機能に含まれる
また政府情報システムの整備にあたっては、関係する分野の「標準」「共通機能」の利用を原則とする とされている
それを受け、例えば総務省の中長期計画には
(2) デジタル庁が整備する共通機能の活用の徹底
各情報システムについて、品質・コスト・スピードを兼ね備えた行政サービスに向けて、デジタル庁が検討しているアーキテクチャに基づき、整備されるガバメント・クラウド、GSS、ベースレジストリ等の共通機能の活用を徹底する。
とされている
PassKeyとはなにか
しばらく認証関係の仕事から離れていたうちに、いよいよパスワードレスが現実的となりNISTもSP800を更新しちゃうような仕組みが確立されつつあった。
PassKeyである。自分なりに整理してみる。
PassKeyとは
パスワード認証に変わる認証手段としてウェブサイトやアプリへのログインを簡単かつ安全に行うことを可能とするもの。
この2022年5月5月の#WorldPasswordDayにAppleから出た文書で初めてパスキーという言葉が使われたそう
（ていうか昨日ワールドパスワードデーだったんすね）
ここでは「FIDOサインインの認証情報」をパスキーと呼んでいる。
むむ、、FIDOサインインの認証情報、、FIDO2となにが違うのか、、？
FIDO2はWebAuthnとCTAPのことであり
WebAuthn→ WebブラウザーがJavaScriptを用いて秘密鍵にアクセスするためのAPI
CTAP→ クライアントと外部認証器間の通信をサポートする認証プロトコル
こちらの図がわかりやすかったので引用
FIDOのキモは、ユーザの「認証」はローカルで行うので、ユーザの識別情報がネットワーク上に流れないということ。
FIDO2まででは、認証器として想定されているものは
例えばYubiKeyのようなUSB/NFC/Bluetoothなどで接続可能な外部認証機器、
あるいはWindowsHelloのようなプラットフォーム内蔵の認証器
だったはず。
しかし、この方式では、デバイスの紛失やスマートフォンの機種変更など、認証器が使えなくなると認証不可能となり、新しいデバイスの再登録が必要となり、パスワード認証と比較して利便性が低下しました。この問題を解決するため、図右のように秘密鍵とそのメタデータに相当する「FIDO認証資格情報（FIDOクレデンシャル）」をクラウド経由で同期し、複数のデバイスで利用できるようにする仕組みが考案されました。（上述の大和総研資料より引用）
つまり、認証行為自体ローカルで行うという考え方は維持したまま
FIDO認証資格情報（＝パスキー）をクラウド経由で同期し利便性を高めたもの ということのよう。
googleであればGooglepasswordマネージャー、iOS/iPadOS/macOSではiCloud キーチェーンによってパスキーを同期するようです。
なお2022年段階ではパスキーの同期は同じエコシステム内のみ、つまりスマホをAndroidからiPhoneに乗り換えたとき、パスキーの同期はできなかったようですが、
現時点では例えばchromeのパスキーを使えばiCloud キーチェーンと同期ができるようです。
安全性は大丈夫なんだろうか？
もともと認証はローカルで行うのでネットワーク上に流れず、攻撃に強いというのがFIDOの利点だったはず。パスキーをネットワーク越しにクラウドと同期して大丈夫なんだろうか。
その答えとしては
複数デバイスでパスキーが同期される際はエンドツーエンドで暗号化されているので、そのためサーバ側での不正アクセスから保護されるようになっているとのこと。
そうなの？（そうなの？）
こちらの技術ブログが参考になった
パスキーでNIST SP800-63B で定義されている AAL3 (Authenticator Assurance Level 3) から外れてしまうという懸念はあるので、
パスワードを使い続けるのは論外として、利便性も悪くフィッシングに弱い認証方法を残さざるをえない従来の FIDO クレデンシャルと、利便性は高いがリスクが若干増してしまうパスキーと、どちらを選ぶべきかという話になります。ここはニーズで使い分けるのがベストではないかと思います。
ある程度リスクが許容できるユースケースであれば、利便性が向上した新しい選択肢が増えた、ということですね。
むむ、、ちょっと待てよ、、？
上述のNIST SP800-63Bは最近、同期可能なクレデンシャルの取り扱いに関する補足文書なるものが公表されている
一回読んだ時はなんかわかったようなわからなかったような感じだったけど
もしかしてここにパスキーの課題に対する見解があるのでは！
NIST SP800-63Bの補足文書
長いのでとりあえず結論を訳してみる（DeepLによる翻訳）
8. 結論
同期可能な認証子は、認証の状況、特に多要素暗号認証子の使用における実質的な技 術的変化を示 すものである。暗号鍵の複製とクラウド・インフラへの保存を許可する ことに関連するトレードオフの 評価は、必然的に行われることになる。このことは、 明確なリスク(認証鍵に対する企業の管理能力の喪失など)をもたらすが、同時に、一般市民や企業にとっての主要な脅威ベクトルを排除する、便利でフィッシングに強 い認証機能への道筋を提供する。同期可能な認証機能はすべてのユースケースに適しているわけではない。しかし、本補足文書に含まれるガイドラインに沿った方法で導入される場合、AAL2 リスク軽減策との整合性を達成し、フィッシング耐性認証の採用をより広範に促進することができる。
つまり・・？
ということですかね
この文書は腰を据えて後程ちゃんと読むとして、、気になったところをかいつまむと
- これまでのSP800-63Bでは「多要素暗号ソフトウェア認証機能は、複数のデバイスへの秘密鍵 のクローニングを抑制すべきであり、 また促進すべきではない (SHALL NOT)。」としていた。
- しかし今回以下要件満たせばAAL2 で想定される脅威から保護するために十分であるとみなされるものとする。
- その要件とは、例えば「承認された暗号技術を用いて生成する」など6項目（＋連邦企業向けに追加4項目）
どういうシーンで利用できるのか
すでにAmazonなどコンシューマ向けサービスでパスキーは実装されているし、ひさびさにこのブログ（はてな）にログインしたところパスキーを設定するかと言われた。このあたりはパスワードの代替として置き換わっていくのだろうと思った
自分の仕事の領域は行政DXなのだが、行政だと例えばGビズID（法人共通認証基盤）というIdPがある。OpenIDConnectのAuthorization Code Flowで実装されており、
gBizプライム/メンバーは当人認証保証レベルAAL2を保証する。現状では当人認証方法としてパスワード認証＋所有物認証方式（スマホアプリあるいはワンタイムパスワード）が実装されているが、パスキーだと
ローカル認証とサーバーでの署名検証で、合計二回認証していることにお気付きでしょうか？つまり、パスキーは単体で生体認証 (もしくは知識認証) と所有認証の二要素認証を行っている（上述の技術ブログより引用）
つまりパスキーだけで認証が完結し、ユーザの操作もかなりシンプルになり便利になるのではと思う
ただ一方で、パスキーを使う場合のAuthorization Code Flowがどんなフローになるのかまだイメージが沸いておらず、、今後考えてみます
（追記）
Xにて尊敬するIDプロフェッショナルな方々に反応をいただいたのでありがたくメモ
> ただ一方で、パスキーを使う場合のAuthorization Code Flowがどんなフローになるのかまだイメージが沸いておらず
— 👹秋田の猫🐱 (@ritou) 2024年5月6日
ユーザー認証部分だけパスキーに置き換わるのでOIDCのフロー自体には変更がありません。 https://t.co/d4fEWhIcnl
なるほどー。「OpenID Connect は認証手段独立なので、任意の認証手段（含むパスキー）と組み合わせられます。それによってフローは影響を受けません」というところから説明が必要なんですね。 OpenID Connect （OIDC ）とパスキー（ Passkeys ）の組み合わせ。 https://t.co/OQ2iff9AjG
— Nat Sakimura/崎村夏彦 (@_nat) 2024年5月6日
そうか、、認証リクエスト出した後IdP（OP）がユーザに認証求める時の手段が変わるだけでOIDCのフローは同じですね。確かに認証の方式は定めていないですね
（5/6）新規作成
（5/6）追記
国・自治体のDNS水責め攻撃のまとめ
いっときnoteに書き散らした記事をリンク
自治体コンビニ交付で証明書が誤発行されてしまう障害のまとめ
いっときnoteに書き散らした記事をリンク
GWに勉強しようと思っていた文献
完全に自分用メモであるが、インターネットで公開されている動画や文献でこれは！と思ったもの。すでにGWが半分終わっているなんて信じられない。
データ研修
デジタル庁準備室新規メンバーに向け、平本CIO補佐官が講義したもの。これを公開してくれるのは素晴らしいと思う。これは優先度最上位（早く見ろ
安宅さんの「データ・ドリブン社会の創発と戦略」講義動画
言わずもがな、シン・ニホンやイシューからはじめよで有名な安宅さんの慶應での講義動画。サイトや動画再生がすごく重いが（見てる人が多いんだろうか）これもざっと見たい。
データ分析のための統計学入門
本一冊分をまるまる公開してくれている。良書ぽいが流して読むには多い、、目次だけしっかり読んで、気になるところは読む、あとは必要なときに思い出せるようにしておくか。
AWS入門
これも東大の教材。読み物というよりは調べ物するときにも便利そう。
なお東大のよさげな教材はここを参照にした。人工知能の動画も見たいとは思っている。
digitaldigital.hatenablog.com
デジタルガバメントの海外事例
前にも読んだけど、おさらい
