bitbucket 2022 (2) - (新) 檜山正幸のキマイラ飼育記 メモ編 から気付いたこと、考えたこと。
内容：
アプリパスワード
bitbucketは「アプリパスワード〈App password〉」という用語を使っているが、例によって、以下のような用語は、乱用・誤用・拡大解釈・オレオレ解釈・造語されて錯綜している。
- パスワード
- パスフレーズ
- アクセストークン
- アクセスキー
- APIキー
- APIトークン
- SSHキー
- アカウントキー
- アプリパスワード
- セキュリティトークン（ブロックチェーン）
- クレデンシャル
- クレデンシャルマネージャ
アクセストークンがクッキーで保存するデータであるとき、ID＋パスワード（識別子＋クレデンシャル）のユーザー代理データで初めに認証して、その後使う簡易的クレデンシャルが“アクセストークン”と考えられる。
bitbucketのアプリパスワードも、一種のアクセストークンなのだろう。クッキーの場合と違うのは：
- アクセストークン発行者が、サービスではなくて、bitbucketユーザー。
- 暗黙に自動的にアクセストークンの発行と管理が行われわけではなくて、ユーザーが明示的に行う。
- 発行したアクセストークン〈アプリパスワード〉の用途はユーザーが決める。
- アクセストークン〈アプリパスワード〉による認証を実行するのはbitbucket。
bitbucketが「アプリパスワード」と呼んでいるのは、いわゆる「APIキー」的なイメージだろう。Web APIプロバイダー（提供事業者）はAPIキーを発行するが、bitbucketからの git clone などはWeb APIと解釈できる。git clone の実行者が人間とは限らずソフトウェアかも知れない。利用主体（人間またはソフトウェア）の（広義の）クレデンシャルが「アプリパスワード」ということだろう。
となると、bitbucketアカウントのユーザーは、認証データ（広義のクレデンシャル）の発行権限を持つことになる。行動主体〈エージェント〉の役割や権限の構造がさらに複雑化する。bitbucketユーザーは次の権限を持つ。
- “認証を必要とするサービスの利用権限”の認証データ〈クレデンシャル〉を発行する権限
gitのクレデンシャルヘルパー
発行されたbitbucketアプリパスワードの、gitにおける利用法だが、通常のパスワードと同じで、「ユーザーID（僕なら m_hiyama）＋生成したアプリパスワード」でgitの認証がされる。Web APIの利用者側アクセス（↓ Parse.comとMailGunを普通のWebサイトのバックエンドとして使ってみる - 檜山正幸のキマイラ飼育記 (はてなBlog) より）と類似なのだろう。
#!/bin/sh # test-cloud-sendTestMailsh curl -v -X POST \ -H "X-Parse-Application-Id: ${PARSE_APPLICATION_ID}" \ -H "X-Parse-REST-API-Key: ${PARSE_REST_API_KEY}" \ -H "Content-Type: application/json" \ -d '{}' \ https://api.parse.com/1/functions/sendTestMail
問題は、40文字弱のランダム英数字文字列であるアプリパスワードをどうやって覚えるか？ -- この問題を考えると、クレデンシャルの分類にも疑問点が出てくる。
- What-You-Know方式と、What-You-Have方式の違いは何？ パスワードも紙やファイルに書けば所持物（I-Have XXX）になる。
- 公開キーやフィンガープリントをクレデンシャルと考えて、覚えている人がいたら、それは記憶物（I-Know XXX）となる。
- 生体認証（What-You-Are）は生物個体にしか通用しない。法人、組織、ソフトウェアには適用できない。
生物個体と抽象的エージェントの認証は区別して考えたほうがいいと思う。また、記憶と所持の境界線はとても曖昧。非生物個体が使えるクレデンシャルは、何らかのデジタルデータに限られる。
そのクレデンシャルであるデジタルデータの保存管理を行うのが git のクレデンシャルヘルパー。ここでややこしのが：
- 広義のクレデンシャルマネージャ ＝ クレデンシャルヘルパー ＝ ヘルパー
- 狭義のクレデンシャルマネージャ ＝ クレデンシャルマネージャ・ソフトウェア
クレデンシャルであるデジタルデータの保存管理方式は：
- ファイルシステム内の生のファイルに保存
- ソフトウェアが（背後に持つ何らかの）ストレージに保存、管理はソフトウェア
ソフトウェアのストレージもファイルだろうが、ユーザーから不可視と考えられる。git で利用可能な“クレデンシャルであるデジタルデータの保存管理方式”＝ヘルパー は：
- テキストファイル
- ソケットファイル（同一ホスト内でプロセス同士が通信に用いる特殊なファイル）
- キーチェーン
- 認証情報マネージャ（ソフトウェア）
認証情報マネージャの識別ラベル（Windowsの場合）は：
- wincred
- manager （固有名詞は Git Credential Manager for Windows）
- manager-core （固有名詞は Git Credential Manager (GCM)）
クレデンシャルマネージャと言った場合の解釈が：
- 認証情報マネージャ・ソフトウェアの総称
- テキストファイルなども含めたクレデンシャルヘルパー＝クレデンシャルであるデジタルデータの保存管理方式
- 特定固有のソフトウェアである Git Credential Manager for Windows や Git Credential Manager (GCM)
あー、ややこしい。
錯綜の要因
ダラダラ並べる。
- 認証と認可を区別してないことがある。
- 生物個体と抽象的エージェント（行動主体）を区別してないことがある。
- ひとつの自然人（生物個体）や法人に多数の抽象的エージェントが付随することがある。
- ひとつの抽象的エージェントに多数の自然人が付随することがある。
- 「パスワード」「キー」などの言葉の使い方が杜撰。キーが暗号鍵のときもあるし、キーバリュー・ストアのキーのときもあるし、単なる名前のことも。
- What-You-Know方式とWhat-You-Have方式の境界は極めて曖昧
- 認証を行う主体（認証局）とサービス提供主体（行動環境）が異なることがある。
- クレデンシャル（広義）の決定権限、発行権限と利用権限、認証実行者、それと管理責任者は区別すべき。
- 権限と責任（責務）の構造を明確化すべき。
- SSHの背景である公開鍵方式暗号は、暗号方式だが、鍵ペアの存在により認証構造とも関係する。
- よって、暗号方式と認証構造が混同されがち。
- 暗号は通信経路の安全性（気密性）や、ストレージの安全性（気密性）に関するテクノロジー、認証構造とは切り離せる。
- 保存と転送、要求と許可、権限と責任、状態遷移などの数学的構造があるといい。そうでないと、クリアな記述・コミュニケーション・議論ができない。
追記
APIのOAuthアクセストークンに関する説明：
タイトル通り分かりやすい。スライドでの説明を何度もした成果・賜物だろう。
Windowsのおける「資格情報マネージャー」は、「コントロールパネル→ユーザーアカウント→資格情報マネージャー」でアクセスできる。これが wincred の正体のようだ。
個人用アクセス トークン (PAT) については：
