publicKey
ドキュメント
JSONLD
スキーマ
code:example.json
{
"publicKey": {
"publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvXc4vkECU2/CeuSo1wtn\nFoim94Ne1jBMYxTZ9wm2YTdJq1oiZKif06I2fOqDzY/4q/S9uccrE9Bkajv1dnkO\nVm31QjWlhVpSKynVxEWjVBO5Ienue8gND0xvHIuXf87o61poqjEoepvsQFElA5ym\novljWGSA/jpj7ozygUZhCXtaS2W5AD5tnBQUpcO0lhItYPYTjnmzcc4y2NbJV8hz\n2s2G8qKv8fyimE23gY1XrPJg+cRF+g4PqFXujjlJ7MihD9oqtLGxbu7o1cifTn3x\nBfIdPythWu5b4cujNsB3m3awJjVmx+MHQ9SugkSIYXV0Ina77cTNS0M2PYiH1PFR\nTwIDAQAB\n-----END PUBLIC KEY-----\n"
}
}
id: 鍵自体のID。Federation上でユニーク
HTTP Signaturesのヘッダに含まれる key-id はそのリクエストを検証するための公開鍵のURLということになっている
lacolaco.icon これはActivityPub界隈での慣例?
レスポンスに { publicKey: {...} } プロパティを持つJSONを返すのが習わし
そのため、key-id と一致するように、 publicKey.id もURLになっている必要がある
多くの実装では Actor.id#main-key のように、Actorと同じエンドポイントにしてあり、Actorのオブジェクトに publicKey プロパティが常に含められている。なので key-id へのリクエストで公開鍵を返却できる
lacolaco.icon 言い換えれば、公開鍵情報だけを返すエンドポイントを作ってそのURLを id に指定してもよいはず?(誰もやっていないが)
owner : 鍵の持ち主であるActorのID
lacolaco.icon 察するに、ひとりのActorが複数の鍵を持っていてもよい(リクエストごとに署名する鍵ペアを変えてもよい)はず
publicKeyPem: 公開鍵の文字列
/icons/hr.icon
windymelt.icon idはhttps://example.com/path/to/actorである場合とhttps://example.com/path/to/actor#main-keyみたいにフラグメントを持つ場合があるけど、何が違うのかな〜
フラグメントを付けると鍵の取得がうまく動作しない対向サーバがあった(Key fetch failedといったメッセージを返されてINBOXへのPOSTが拒絶されるなど)
nyarla.icon GoToSocial だと publicKey の URL は https://example.com/users/username/main-key ですね 通信する相手のソフトウェア名を調べて対応するためには
https://example.com/.well-known/nodeinfo を取得して JSON-LD の href の値を調べる
href に入っている URL へアクセスして software.name と software.version を調べる
ここで nodeinfo の version も見る必要ある?
それぞれの値から必要な workaround などの対応をする
と言う流れみたい (?)
nyarla.icon 正直非常につらそう
mushus.icon publicKeyPemとなってるけど、PEM形式の公開鍵ならばなんでも良いわけではないかもしれない?それとも実装依存?
GoToSocial0.9時点では鍵の開始ヘッダーがBEGIN PUBLIC KEY以外では駄目そう(有効なのはPKIX?)
どうやら実装依存っぽい。GoToSocialも最新だと↑の部分に対応しているみたい
JSONLD的に正しく書くなら{ @context: "https://w3id.org/security/v1" } を書くとよさそう