[10] JOSEヘッダーJOSE Headerは、 使用する RFC 4949 デジタル署名や RFC 4949 MAC の演算や引数を記述する JSONオブジェクトです。 >>8, >>47 更に追加の情報も含めることが出来ます。 >>47

仕様書

データモデル

[13] ヘッダー引数Header Parameterは、 JOSEヘッダーのメンバーたる名前nameと値valueの組です。 >>8

[48] ヘッダー引数の名前は、JOSEヘッダー内で固有でなければなりません。 JWS 構文解析器は、 JWS がヘッダー引数の重複を含む時、 これを拒絶するか、 または重複するメンバー名について字句的に最後のもののみ採用する JavaScript JSON.parse と同じ挙動の JSON 構文解析器を使うかしなければなりません。 >>47, >>148

[5] JWE でもヘッダー引数の名前は固有でなければなりません。 >>33, >>14 各受信者に対するJWE被保護ヘッダー、 JWE被共有非被保護ヘッダー、 JWE受信者毎非被保護ヘッダーの組み合わせにおいてヘッダー引数の名前が互いに素でなければなりません >>16。

[49] JSONオブジェクトは、 {"name": "value1", "name": "value2"} のごとく同名のメンバーを複数含めることが出来ます。 JWS はこれを拒絶するか、最後の value2 のみ採用することを求めています。 挙動に曖昧性が認められるのは、 相互運用性の火種であり、 とりわけセキュリティー技術には好ましからざる性質です。 どちらとも実装し得る JSON 仕様側の問題といえなくもないですが。 JSON の標準的な実装である JSON.parse の挙動、すなわちエラーとせず最後のもののみを採用するのが好ましいと考えられます。[17] 重複メンバーの扱いはJWKやJWK集合と同等の規定です。

[1] ヘッダー引数群にまたがってのヘッダー引数の重複も禁止されています。 JWS

JWS におけるヘッダー引数

[2] JWS では JOSEヘッダーにおけるJWS被保護ヘッダーやJWS非被保護ヘッダーで使用できます。

JWE におけるヘッダー引数

[4] JWE では JOSEヘッダーにおけるJWE被保護ヘッダー, JWE共有非被保護ヘッダー, JWE受信者毎非被保護ヘッダーで使用できます。

ヘッダー引数の処理

[50] JWS および JWE の実装は、理解しなければならないと規定されたヘッダー引数を、 理解し処理しなければなりません。 >>47, >>33

[51] JWS および JWE の実装は、 それ以外のヘッダー引数は、理解できない場合無視しなければなりません。 ただし、 crit が適用されるものを除きます。 >>47, >>33

crit ヘッダー引数

[70] ヘッダー引数 crit (critical) は、 JWS や JWE や JWA の仕様書に対する拡張拡張性が使われていて、 これを理解して処理しなければならないことを示すものです。 >>69, >>33

[71] 値は、 当該拡張拡張性を使う JOSEヘッダーのヘッダー引数名の配列JSON配列です。 >>69

[73] 生成器は、 JWS や JWA の仕様書で定められたヘッダー引数名を指定してはなりません。 >>69

[74] 生成器は、 ヘッダー引数名を重複して指定したり、 JOSEヘッダー内に出現しないヘッダー引数名を指定したりしてはなりません。 >>69

[79] crit の使用は任意です。 >>69

[75] 生成器は、 空の配列JSON配列を指定してはなりません。 >>69

[78] crit を使う場合、 JWS保護ヘッダーに含めなければなりません。 >>69 JWS非保護ヘッダーでは使えません。

[80] 実装は、ヘッダー引数 crit を理解し処理しなければなりません。 >>69

[76] 受信者は、 crit の値が制約 (>>73, >>74, >>75) 違反のとき、 当該 JWS を非妥当とみなして構いません。 >>69

[77] なぜ必須でないのか不明です。 これでは相互運用性の罠です。

[72] 受信者が指定されたヘッダー引数のいずれかを理解対応していない場合には、 当該 JWS は非妥当です。 >>69

ヘッダー引数の一覧

[3] JWS のヘッダー引数は、 JWS被保護ヘッダーで使えるもの、 JWS非被保護ヘッダーで使えるもの、 どちらでも使えるものがあります。

[56] JWS ヘッダー引数

[12] JWE のヘッダー引数は、 JWE被保護ヘッダー, JWE共有非被保護ヘッダー, JWE受信者毎非被保護ヘッダーで使用できますが、 どこで使用できるか制限されているものもあります。

[11] JWE ヘッダー引数
[15] その他のヘッダー引数

ヘッダー引数名の登録

[52] ヘッダー引数名には、 登録ヘッダー引数名、 公開ヘッダー引数名、 私的ヘッダー引数名の3種類classがあります。 >>47, >>33 この「class」は互いに素のようにも感じられますが、 仕様書の定義が曖昧で意図を掴みかねます。

[53] 登録ヘッダー引数名Registered Header Parameter nameは、 IANA登録簿に登録されたものです >>47。 IANA登録簿は JWS と JWE で共通で、一方または両方で使用するかを指定できます >>142。 JWS と JWE の両方で使うものを定める場合、用法が一貫していなければなりません >>47, >>33。

[143] 登録するヘッダー引数名は、 短く、原則として8文字以下であるべきとされています。 >>142

[144] 一般にヘッダー引数名は大文字・小文字区別ありですが、 登録時に指定専門家が必要と認めた場合を除き、 大文字・小文字不区別で既存の名称と一致するものは登録できません。 >>142

[54] 公開ヘッダー引数名Public Header Parameter name >>47 が何であるか仕様書はなぜか明確に述べていませんが、 登録ヘッダー引数名でも私的ヘッダー引数名でもないものとみられます。

[57] 公開ヘッダー引数名に関する仕様書の節には、 次のようにあります。 JWS / JWE の利用者は、 RFC 7515 / RFC 7516 にない追加のヘッダー引数名を定義できますが、 IANA登録簿に登録するか、 または Public Name (耐衝突名が含まれる値) であるかとするべきshouldです。 いずれにせよ、 定義者は、 名前を定義するため使う名前空間の部分に関して、 制御下に置かれるべく十分に注意を払う必要があります。 >>47, >>33 (この Public Name が公開ヘッダー引数名を指しているとも解せます。 主語の利用者が誰を指すか明らかではありませんが (私的ヘッダー引数名との違いに注意)、 JWS を利用する技術の仕様策定者とみるべきでしょうか。)

[58] 新しいヘッダー引数の追加は、相互運用性の低下を招き得るため、 慎重にするべきshouldです。 >>47, >>33

[55] 私的ヘッダー引数名Private Header Parameter name >>47 が何であるか仕様書はなぜか不明瞭にしていますが、 仕様書の私的ヘッダー引数名の節には、 JWS / JWE の生成者と消費者は Private Names (登録ヘッダー引数名でない名前) や公開ヘッダー引数名を使う私用ことに合意情報交換の当事者間の合意して構わない >>47, >>33 とあります。 この Private Names が私的ヘッダー引数名とも解し得ますが、 「登録ヘッダー引数名でない」 ならそれは公開ヘッダー引数名を含むとも考えられ、 だとすると敢えて公開ヘッダー引数名に言及しているのが不審です。 公開ヘッダー引数名と違って私的ヘッダー引数名は衝突の恐れがあり、 注意して使うべきである >>47, >>33 とされており、だとすると両者は互いに素であるとも思われます。

[59] この通りヘッダー引数名には3つの分類がありますが、 仕様書は注意せよと言っているだけで、 利用の制限も特になく、 定義も曖昧で、 実質的な違いはないといって良いでしょう。

[60] 相互運用性を考慮すると、 JWS や JWE を使う応用は、 それぞれどれを実装しなければならないか定め、 それ以外は実装してはならないと定める必要がありそうです。 JWS や JWE の実装は、 その適用対象の応用に合わせ、 不要なものを生成せず、 対応が求められていないものを無視することを徹底するべきでしょう。

メモ

[6] JWE は JWS に同じ、と丸投げしています。その委任の仕方が雑なので、 仕様書の厳密な解釈spec lawyerに基づくと JWE の規定する処が若干曖昧ではあります。

[9] JOSE は JWE, JWS 等の仕様の共通化できる部分を共通化し、 JWA のように仕様書としても共通部分を括りだしているところがあるのに、 なぜか JWE が依存する JWS との共通部分が JWS の仕様書に JWS 用の規定として含まれています。 なぜこのような技術的に美しくない仕様書の構成にしたのでしょう。