管理画面¶
管理画面は操作の形をしている。テーブルの行編集は無い。
これは意図的な拒否である。行を直接編集できると、ドメインが禁じていることが画面から
できてしまう——retired の shoulder を戻す、ark の主キーを書き換える、名前空間を消す。
モデルから CRUD を自動生成する方式（sqladmin など）は要するに気の利いた DB ブラウザで、
「やらないこと」に価値がある台帳には向かない。
どのページも domain.admin_ops か domain.minting を呼ぶ。CLI と同じ関数なので、
画面から不変条件を迂回する道は無い。
何を見せるか¶
組織管理 — 台帳そのものを入れ子で見せる。組織番号（NAAN）→ 組織 → 名前空間。 ARK は名前空間を受け渡す体系なので、渡した形がそのまま中身である。
画面の言葉は「委譲の構造」ではなく「組織管理」にしてある。台帳を初めて見る人が 最初に開く画面なので、その人がまだ持っていない語を見出しにしない。
ただし用語は捨てず、括弧で残す——「名前空間（shoulder）」「組織番号（NAAN）」 「永続・内容は変わりうる（permanent-dynamic）」のように、平易な言い方を先に置いて 用語を添える。初めての人はそのまま読め、用語を知っている人は 仕様・CLI・API との対応が取れる。用語を消すと、この画面 だけが他と違う言葉を話すことになる。
ARK を採番 — 手作業で 1 本要るとき用（移行時の個別対応、物理オブジェクト、動作確認）。 組織は通常 API から採番する。
利用者と鍵 — 誰が、どの鍵で、どこまで届くか。ここに並ぶのは組織そのもの ではなく、組織のシステムと、その組織に属する人である。
画面の「利用者」＝ API と CLI の「主体（principal）」
読み手が違うので、呼び方も分けてある。 画面を読むのは運用の担当者で、 API と CLI を読むのは開発者である。
| 画面 | API・CLI・データモデル |
|---|---|
| 利用者 | 主体 / principal（Client） |
| 鍵 | 資格情報 / credential |
「主体」はアクセス制御で subject を訳した語で（対になる object は「客体」）、
Subject（machine / person）という列名もここから来ている。クラウド事業者の
文書では「プリンシパル」とカタカナで書かれることが多い。
保留中の転送 — 今どの識別子・名前空間で転送を止めているか。期限つきの措置だが、 目に見えないと恒久化する——掛けた人が忘れても、一覧に残っていれば誰かが気づく。 止めているのは転送だけで、解決は続いている（壊さないもの）。
監査ログ — NAAN 単位以上にしか見せない。誰が何をしたかはその名前空間を預かる側の 情報で、組織の担当者が他組織の履歴を読む筋合いは無い。
到達範囲が画面を決める¶
画面の出し分けと実際の認可に、同じ判定を使う。 別々にすると「ボタンは出ないが URL を直接叩けば通る」穴ができる。
| ログインした人 | 見えるもの | 監査ログ |
|---|---|---|
| システム管理者 | 全 NAAN | ○ |
| NAAN 管理者 | 1 NAAN 配下の全組織 | ○ |
| 組織管理者 | 1 組織 | 403 |
誰が何をできるか¶
縛りは 3 つあり、互いに独立している。 どれか 1 つを通っても、残りは免除されない:
- 到達範囲——上の 3 段。クライアント登録の属性から来るもので、要求本文や トークンの中身からは決して来ない。トークンは範囲を狭めることしかできない。
- scope——その種類の操作の鍵（
ark:mint、ark:unpublishほか）。 - 儀式——一度でも公開した名前に触るときの、理由と ARK の打ち直し。 これは主体の位ではなく、名前の履歴に従う。
ARK そのもの——3 者とも、それぞれの範囲で¶
以下はすべて同じ到達範囲の判定を通る。だから 3 段の違いはどこまで届くかだけで、 何ができるかは違わない。
| 操作 | scope | システム | NAAN | 組織 |
|---|---|---|---|---|
| 採番・一括採番・修飾子の登録 | ark:mint |
全 NAAN | 自 NAAN | 自組織の shoulder |
| 外で採番された名前の取り込み | ark:import |
〃 | 〃 | 〃 |
| 更新・一括更新 | ark:update |
〃 | 〃 | 〃 |
読み取り（/api/query） |
ark:read |
〃 | 〃 | 〃 |
| 公開・再公開 | ark:mint |
〃 | 〃 | 〃 |
| 公開の取り下げ | ark:unpublish |
〃 | 〃 | 〃 |
| 削除（公開していないもの） | ark:delete |
〃 | 〃 | 〃 |
| 破棄（取り下げと削除を一手で） | ark:purge |
〃 | 〃 | 〃 |
| tombstone | ark:tombstone |
〃 | 〃 | 〃 |
| ARK 1 本の転送保留 | ark:hold |
〃 | 〃 | 〃 |
儀式が要るのは、一度でも公開した名前の取り下げ・削除・破棄である ——壊さないものを参照。
クライアントは段ではなく、組み合わせである¶
3 段は軸の 1 つにすぎない。クライアントが実際に何であるかは 3 つの組で決まり、 実運用でいちばん多いものは、どの段でもない:
| 軸 | 何を決めるか |
|---|---|
authority |
どこまで届くか——上の 3 段 |
scopes |
何ができるか。段とは独立 |
shoulder_id |
組織の主体を 1 shoulder に固定する |
発行だけのクライアント——識別子をもらうだけのリポジトリ——は
authority=manager、shoulder_id で固定、scopes は ark:mint 1 つ、という組である。
この鍵が開ける口はちょうど 4 つ:
ここから 2 つ導かれる。どちらも意図したものである:
- 名前を世に出せるが、1 本も引っ込められない。 取り下げ・削除・破棄はそれぞれ
ark:unpublish/ark:delete/ark:purgeの向こうにあり、この主体はどれも 持たない。採番の鍵を配ることは、名前を止める力を配ることではない。 - 自分が採った ARK を読み返せない（
/api/queryはark:read）。解決は認証を 要さないので識別子そのものは引ける——効くのは台帳のほうだけである。
公開が ark:mint に入っているのは、それが採番の後半だからである。予約した主体が
そのまま出せないと、下書きのたびに別の鍵が要る。
ゲスト——クライアントを持たないすべての人¶
解決は認証を要さない。そこが肝心である——鍵が無いと引けない識別子は、 永続識別子ではない。無認証の呼び出し側が届くのは:
| 誰でも叩ける | 何が得られるか |
|---|---|
GET /ark:/…、GET /ark:… |
解決と、インフレクション ? ?? ?info ?json |
GET /.well-known/ark |
このサービスがどの名前空間を預かっているか |
GET /healthz、GET /readyz |
生死と、受け入れ可能か |
POST /oauth/token |
上のアクターになるための入口（資格情報は要る） |
これ以外はすべてクライアントが要る。
公開前と公開後を分けている理由は、このアクターである。 ?info と ?? は鍵無しで
答えるので、公開のリゾルバが公開前の ARK を返すと、まだ公開していない対象の存在・
題名・行き先が、名前を当てた人にそのまま出る。だから既定は返さない側にしてあり、
返すかどうかは ARK の性質ではなくリゾルバがどこに置かれているかの性質にしてある
（閉域のリゾルバ向けの ARKHE_RESOLVE_UNPUBLISHED）。
ゲストから見れば、公開前の ARK と一度も採番されていない名前は同じ 404 である。 取り下げたものも同じで、しかも永久に 404 のまま——その名前が別のものに 割り当てられることは無いからである。
名前空間——NAAN 管理者以上¶
| 操作 | システム | NAAN | 組織 |
|---|---|---|---|
| shoulder の追加・状態変更・解決の委譲 | ○ | ○ | × |
| shoulder ／ NAAN 単位の転送保留 | ○ | ○ | × |
| 名前空間の決まり・quota・永続性の宣言 | ○ | ○ | × |
| 組織のオンボード | ○ | ○ | × |
| NAAN の登録 | ○ | × | × |
shoulder や NAAN の保留は名前空間そのものを止めるので、組織より上に置いてある ——1 組織の判断で、他組織の識別子まで巻き込めてはいけない。
主体と組織——自組織の内側なら、組織管理者も¶
| 操作 | システム | NAAN | 組織 |
|---|---|---|---|
| クライアントの登録 | ○ | 自 NAAN | 自組織のみ |
└ authority=system の主体を作る |
○ | × | × |
└ authority=naan の主体を作る |
○ | ○ | × |
| 資格情報の発行・失効、パスワード、停止／再開 | ○ | 自 NAAN | 自組織のみ |
| 承継先の設定・承継の実行 | ○ | 自 NAAN | 自組織のみ |
離脱（arkhe depart） |
○ | ○ | × |
CLI は常にシステム管理者として動く。 サーバのシェルに入れる時点で DB には届くので、 権限で絞っても意味の在る防御にならない——代わりに操作は必ず監査に残る。
入り方¶
ARKHE_ADMIN_LOGIN で決める。認証を参照。bearer では
ログイン画面そのものが無い——「ブラウザからは入れない」という選択である。
引き返せない操作は、見た目でそう分かるようにしてある。 実際に引き返せないから ——ただし公開はその 1 つではない（取り下げて、出し直せる）。引き返せないのは 行を消すことと、名前空間を引退させることである。どちらの道を通っても、 一度使われた名前が別のものに割り当てられることは無い。
設定を変える¶
画面から変えられるのは、宣言と運用の設定だけ。 ARK の行も shoulder の綴りも
画面からは変えられない——変えられると、NR を宣言しているはずの体系で名前が
振り直せることになる。
| 何を | 誰が |
|---|---|
| NAA ポリシー（NAAN の宣言） | NAAN 単位以上 |
採番の案内先（/.well-known/ark） |
システム管理者 |
| 約束の水準（組織の宣言） | その組織自身と、それ以上 |
| 1 日あたりの採番上限 | NAAN 単位以上 |
| shoulder の状態・委譲先 | NAAN 単位以上 |
この分かれ方は権限表ではなく、ARK の委譲の構造がそのまま出たものである。 NAA ポリシーは名前空間を配る側の宣言で、配下の全組織にかかる——だから 1 組織の 管理者には変えられない。約束の水準は配られた側が自分について述べるもので、 述べる主体が述べられなければ意味がない——だから組織管理者が変えられる。
採番上限だけは組織自身では変えられない。上限は配った側が課すものなので、 課された側が外せては意味がない。
判定は domain.admin_ops にしかない。画面は同じ関数を呼ぶので、ボタンが
出ないのに URL を直接叩けば通る、ということが起きない。
国際化¶
日本語と英語。ヘッダーの地球儀から切り替える。言語は ?lang= → cookie →
Accept-Language の順で決まる。
カタログは gettext ではなく素の辞書なので、言語の追加はモジュール 1 つで済み、 ビルド手順も増えない。翻訳の抜けは起動時に落ちるので、片方のカタログにだけ 足したことに気づける。