JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
JSON Web Signature（JWS）は、JWSのペイロードをbase64urlエンコードされた値として表現し、この値をJWS署名計算に使用します。これにより、任意のペイロードを整合性で保護することが可能になりますが、ペイロードが大きい場合や分離されている場合など、base64urlエンコードが不要であるか、または採用を妨げる場合があると説明されることがあります。この仕様では、JWS署名入力計算でペイロードをbase64urlエンコードしないように変更するオプションを定義して、これらの使用例に対応する手段を定義しています。このオプションは、JWSの使用が適している使用例のセットを広げることを目的としています。
This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.
この仕様は、RFC 7519を更新して、JSON Web Token (JWT) がこの仕様で定義されている非符号化ペイロードオプションを使用してはならないことを述べています。
This is an Internet Standards Track document.
これは、インターネット標準トラックのドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
この文書は、インターネット・エンジニアリング・タスク・フォース（IETF）の成果です。これは、IETFコミュニティの合意を表しています。公開レビューを受け、インターネット・エンジニアリング・ステアリング・グループ（IESG）によって公開が承認されました。インターネット標準に関する詳細な情報は、RFC 5741のセクション2にあります。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7797.
このドキュメントの現在の状況、誤り情報、およびフィードバックの提供方法に関する情報については、http://www.rfc-editor.org/info/rfc7797 で入手できます。
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETFドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）にしたがう必要があります。これらの文書をよく確認し、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
The "JSON Web Signature (JWS)" [JWS] specification defines the JWS Signing Input as the input to the digital signature or Message Authentication Code (MAC) computation, with the value ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)). While this works well in practice for many use cases, including those accommodating arbitrary payload values, other use cases have been described in which base64url-encoding the payload is unnecessary and/or an impediment to adoption, particularly when the payload is large and/or detached.
「JSON Web Signature（JWS）」[JWS] 仕様では、JWS署名入力をデジタル署名またはメッセージ認証コード（MAC）計算の入力として定義しています。値はASCII（BASE64URL（UTF8（JWS保護ヘッダー））|| '.' || BASE64URL（JWSペイロード））です。これは、多くのユースケースにおいて、特に任意のペイロード値を受け入れるユースケースを含めて、実際にはうまく動作します。しかし、ペイロードをbase64urlエンコードすることが不要であるか、または採用の妨げとなる場合があり、特にペイロードが大きい場合や分離される場合など、他のユースケースが説明されています。
This specification introduces a new JWS Header Parameter value that generalizes the JWS Signing Input computation in a manner that makes base64url-encoding the payload selectable and optional. The primary set of use cases where this enhancement may be helpful are those in which the payload may be very large and where means are already in place to enable the payload to be communicated between the parties without modifications. Appendix F of [JWS] describes how to represent JWSs with detached content, which would typically be used for these use cases.
この仕様では、ペイロードのbase64urlエンコードを選択可能およびオプションとする方法で、JWS署名入力の計算を一般化するための新しいJWSヘッダーパラメーターの値を導入しています。この改良が有用となる主なユースケースは、ペイロードが非常に大きく、既に構造変更せずにパーティ間でペイロードを通信できる手段がある場合です。付録Fの[JWS]では、切り離されたコンテンツを持つJWSの表現方法について説明しており、通常はこれらのユースケースに使用されます。
The advantages of not having to base64url-encode a large payload are that allocation of the additional storage to hold the base64url- encoded form is avoided and the base64url-encoding computation never has to be performed. In summary, this option can help avoid unnecessary copying and transformations of the potentially large payload, resulting in sometimes significant space and time improvements for deployments.
大きなペイロードをbase64urlエンコードする必要がない利点は、base64urlエンコード形式の追加のストレージの割り当てが回避され、base64urlエンコーディングの計算を行う必要がなくなることです。要約すると、このオプションは、潜在的に大きなペイロードの不要なコピーと変換を回避し、展開において時には著しいスペースと時間の改善がもたらされることがあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.
キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、 「要求されています（REQUIRED）」、 「することになります（SHALL）」、「することはありません（SHALL NOT）」、 「すべきです（SHOULD）」、「すべきではありません（SHOULD NOT）」、 「推奨されます（RECOMMENDED）」、「推奨されません（NOT RECOMMENDED）」、 「してもよいです（MAY）」、「選択できます（OPTIONAL）」は、 BCP 14 [RFC2119] RFC8174に記載されているとおりに解釈されるものとします。 ただし、ここに示すようにすべて大文字で表示される場合に限ります。
BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2 of [JWS].
BASE64URL（OCTETS）は、[JWS]のセクション2に従ったOCTETSのbase64urlエンコーディングを示しています。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.
ASCII(STRING)は、STRINGのASCII文字のオクテットを示します。STRINGは0以上のASCII文字のシーケンスです。[RFC20]の表現形式です。
The concatenation of two values A and B is denoted as A || B.
２つの値AとBの連結は、A || Bと表されます。
This Header Parameter modifies the JWS Payload representation and the JWS Signing Input computation in the following way:
このヘッダーパラメーターは、以下の方法でJWSペイロードの表現およびJWS署名入力の計算を変更します。
b64 The "b64" (base64url-encode payload) Header Parameter determines whether the payload is represented in the JWS and the JWS Signing Input as ASCII(BASE64URL(JWS Payload)) or as the JWS Payload value itself with no encoding performed. When the "b64" value is "false", the payload is represented simply as the JWS Payload value; otherwise, it is represented as ASCII(BASE64URL(JWS Payload)). The "b64" value is a JSON boolean, with a default value of "true". When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWS Protected Header. Use of this Header Parameter is OPTIONAL. If the JWS has multiple signatures and/or MACs, the "b64" Header Parameter value MUST be the same for all of them. Note that unless the payload is detached, many payload values would cause errors parsing the resulting JWSs, as described in Section 5.
b64 ヘッダーパラメーターは、ペイロードがJWSおよびJWS署名入力でASCII(BASE64URL(JWSペイロード))として表されるか、エンコードを行わずにJWSペイロードの値そのものとして表されるかを決定します。 "b64"の値が「false」の場合、ペイロードは単にJWSペイロードの値として表されます。それ以外の場合は、ASCII(BASE64URL(JWSペイロード))として表されます。 "b64"の値はJSONの真偽値であり、デフォルト値は「true」です。このヘッダーパラメーターを使用する場合、整合性が保護される必要があります（MUST）。したがって、これはJWS Protected Header内にのみ存在しなければなりません（MUST）。このヘッダーパラメーターの使用は選択できます（OPTIONAL）。 JWSに複数の署名および/またはMACがある場合、"b64"ヘッダーパラメーターの値はすべて同じである必要があります（MUST）。ペイロードが切り離されていない限り、多くのペイロード値は結果のJWSを解析する際にエラーが発生する可能性があることに注意してください（セクション5を参照）。
The following table shows the JWS Signing Input computation, depending upon the value of this parameter:
以下の表は、このパラメーターの値に応じたJWS署名入力の計算を示しています。
| "b64" | JWS Signing Input Formula | ||
| true | ASCII(BASE64URL(UTF8(JWS Protected Header)) BASE64URL(JWS Payload)) | '.' | |
| false | ASCII(BASE64URL(UTF8(JWS Protected Header)) JWS Payload | '.') |
| "b64" | JWS 署名入力フォーミュラ | ||
| true | ASCII(BASE64URL(UTF8(JWS 保護ヘッダー)) BASE64URL(JWS ペイロード)) | '.' | |
| false | ASCII(BASE64URL(UTF8(JWS 保護ヘッダー)) JWS ペイロード) | '.') |
This section gives examples of JWSs showing the difference that using the "b64" Header Parameter makes. The examples all use the JWS Payload value [36, 46, 48, 50]. This octet sequence represents the ASCII characters "$.02"; its base64url-encoded representation is "JC4wMg".
このセクションでは、「b64」ヘッダーパラメーターの使用による違いを示すJWSの例を示します。すべての例は、JWSペイロード値[36, 46, 48, 50]を使用します。このオクテットシーケンスはASCII文字「$.02」を表し、そのbase64urlエンコードされた表現は「JC4wMg」です。
The following table shows a set of Header Parameter values without using a false "b64" Header Parameter value and a set using it, with the resulting JWS Signing Input values represented as ASCII characters:
以下の表は、誤った「b64」ヘッダーパラメーター値を使用しない一連のヘッダーパラメーター値と、それを使用した場合のJWS署名入力値をASCII文字で表したものです。
| JWS Protected Header | JWS Signing Input Value |
| {"alg":"HS256"} | eyJhbGciOiJIUzI1NiJ9.JC4wMg |
| {"alg":"HS256","b64":false, | eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2U |
| "crit":["b64"]} | sImNyaXQiOlsiYjY0Il19.$.02 |
| JWS保護ヘッダー | JWS署名入力値 |
| {"alg":"HS256"} | eyJhbGciOiJIUzI1NiJ9.JC4wMg |
| {"alg":"HS256","b64":false, | eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2U |
| "crit":["b64"]} | sImNyaXQiOlsiYjY0Il19.$.02 |
{
"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
{
"kty":"oct",
"k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
}
The rest of this section shows complete representations for the two JWSs above.
このセクションの残りの部分では、上記の2つのJWSの完全な表現が示されています。
The complete JWS representation for this example using the JWS Compact Serialization and a non-detached payload (with line breaks for display purposes only) is:
この例では、JWSコンパクトシリアライゼーションおよび非切り離しペイロードを使用したJWSの完全な表現は、次のようになります（表示目的の改行あり）:
eyJhbGciOiJIUzI1NiJ9 . JC4wMg . 5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ
eyJhbGciOiJIUzI1NiJ9 . JC4wMg . 5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ
Note that this JWS uses only features defined by [JWS] and does not use the new "b64" Header Parameter. It is the "control" so that differences when it is used can be easily seen.
このJWSは、[JWS] によって定義された機能のみを使用し、新しい「b64」ヘッダーパラメーターは使用しません。これは、使用する際の差異を容易に確認するための「制御」です。
The equivalent representation for this example using the flattened JWS JSON Serialization is:
この例の等価な表現は、フラット化されたJWS JSONシリアライゼーションを使用しています。
{
"protected":
"eyJhbGciOiJIUzI1NiJ9",
"payload":
"JC4wMg",
"signature":
"5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ"
}
{
"protected":
"eyJhbGciOiJIUzI1NiJ9",
"payload":
"JC4wMg",
"signature":
"5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ"
}
The complete JWS representation for this example using the JWS Compact Serialization and a detached payload (with line breaks for display purposes only) is:
この例でのJWSの完全な表現は、JWSコンパクトシリアル化と切り離されたペイロードを使用しています（表示目的の改行を含む）：
eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19 . . A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY
eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19 . . A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY
Note that the payload "$.02" cannot be represented in this JWS in its unencoded form because it contains a period ('.') character, which would cause parsing problems. This JWS is therefore shown with a detached payload.
このJWSでは、ペイロード "$.02" はエンコードされていない形式で表現することはできません。なぜなら、ピリオド（'.'）の文字が含まれており、解析の問題を引き起こす可能性があるためです。そのため、このJWSはデタッチされたペイロードとして表示されます。
The complete JWS representation for this example using the flattened JWS JSON Serialization and a non-detached payload is:
この例では、フラット化されたJWS JSONシリアライゼーションおよび非分離ペイロードを使用した完全なJWS表現は次のようになります。
{
"protected":
"eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19",
"payload":
"$.02",
"signature":
"A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY"
}
{
"protected":
"eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19",
"payload":
"$.02",
"signature":
"A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY"
}
If using a detached payload with the JWS JSON Serialization, the "payload" element would be omitted.
JWS JSON Serializationを使用して切り離しペイロードを使用する場合、「payload」要素は省略されます。
When the "b64" value is "false", different restrictions on the payload contents apply, depending upon the circumstances, as described in this section. The restrictions prevent the use of payload values that would cause errors parsing the resulting JWSs.
「b64」値が「false」の場合、このセクションで説明されているように、状況に応じてペイロードの内容に異なる制限が適用されます。これらの制限により、結果のJWSの解析エラーを引き起こす可能性のあるペイロード値の使用が防止されます。
Note that because the character sets that can be used for unencoded non-detached payloads differ between the two serializations, some JWSs using a "b64" value of "false" cannot be syntactically converted between the JWS JSON Serialization and the JWS Compact Serialization. See Section 8 for security considerations on using unencoded payloads.
次の点に留意してください。JWSのJSONシリアル化とJWSコンパクトシリアル化の間で、エンコードされていない非デタッチド・ペイロードに使用できる文字セットが異なるため、"b64"の値が "false" の一部のJWSは構文的に変換できません。非エンコードされたペイロードの使用に関するセキュリティーについては、セクション8を参照してください。
Appendix F of [JWS] describes how to represent JWSs with detached content. A detached payload can contain any octet sequence representable by the application. The payload value will not cause problems parsing the JWS, since it is not represented as part of the JWS. If an application uses a content encoding when representing the payload, then it MUST specify whether the signature or MAC is performed over the content-encoded representation or over the unencoded content.
[JWS]の付録Fでは、切り離しコンテンツを使用してJWSを表現する方法について説明しています。切り離しペイロードには、アプリケーションで表現可能な任意のオクテットシーケンスを含めることができます。ペイロードの値は、JWSの一部として表現されないため、JWSの解析に問題を引き起こしません。アプリケーションがペイロードを表現する際にコンテンツエンコーディングを使用する場合、署名またはMACがコンテンツエンコードされた表現またはエンコードされていないコンテンツ上で実行されるかどうかを明示しなければなりません（MUST）。
When using the JWS Compact Serialization, unencoded non-detached payloads using period ('.') characters would cause parsing errors; such payloads MUST NOT be used with the JWS Compact Serialization. Similarly, if a JWS using the JWS Compact Serialization and a non-detached payload is to be transmitted in a context that requires URL-safe characters, then the application MUST ensure that the payload contains only the URL-safe characters 'a'-'z', 'A'-'Z', '0'-'9', dash ('-'), underscore ('_'), and tilde ('~'). The payload value is the ASCII representation of the characters in the payload string. The ASCII space character and all printable ASCII characters other than period ('.') (those characters in the ranges %x20-2D and %x2F-7E) MAY be included in a non-detached payload using the JWS Compact Serialization, provided that the application can transmit the resulting JWS without modification.
JWSコンパクトシリアライズを使用する場合、ピリオド（'.'）文字を使用しない非エンコードの非分離ペイロードは解析エラーを引き起こすことがあります。このようなペイロードはJWSコンパクトシリアライズと一緒に使用してはなりません（MUST NOT）。同様に、JWSコンパクトシリアライズを使用したJWSと非分離ペイロードをURLセーフな文字が必要なコンテキストで転送する場合、アプリケーションはペイロードに'a'-'z'、'A'-'Z'、'0'-'9'、ダッシュ（'-'）、アンダースコア（'_'）、チルダ（'~'）のURLセーフな文字だけが含まれていることを要求されています（MUST）。ペイロード値はペイロード文字列のASCII表現です。ASCIIスペース文字と期間（'.'）以外の印刷可能なASCII文字（範囲%x20-2Dおよび%x2F-7E内の文字）は、アプリケーションが変更せずに生成されたJWSを転送できる場合、JWSコンパクトシリアライズを使用した非分離ペイロードに含まれることができます（MAY）。
No meaning or special semantics are attached to any characters in the payload. For instance, the percent ('%') character represents itself and is not used by JWS objects for percent-encoding [RFC3986]. Applications, of course, are free to utilize content-encoding rules of their choosing, provided that the encoded representations utilize only allowed payload characters.
ペイロード内の任意の文字には特別な意味や特別な意味付けはありません。たとえば、パーセント（「%」）文字はそのまま自身を表しますが、JWSオブジェクトではパーセントエンコーディング [RFC3986] に使用されません。アプリケーションは、エンコードされた表現が許可されたペイロード文字のみを使用している限り、任意のコンテンツエンコーディングルールを利用することができます。
When using the JWS JSON Serialization, unencoded non-detached payloads must consist of the octets of the UTF-8 encoding of a sequence of Unicode code points that are representable in a JSON string. The payload value is determined after performing any JSON string escape processing, per Section 8.3 of RFC 7159 [RFC7159], and then UTF-8-encoding the resulting Unicode code points. This means, for instance, that these payloads represented as JSON strings are equivalent ("$.02", "\u0024.02"). Unassigned Unicode code point values MUST NOT be used to represent the payload.
JWS JSONシリアライゼーションを使用する場合、エンコードされていない非分離ペイロードは、JSON文字列で表現可能なUnicode符号ポイントのUTF-8エンコーディングのオクテットで構成されなければなりません。これは、例えば以下のようなJSON文字列で表現されるペイロードが同等であることを意味します（"$.02"、"\u0024.02"）。ペイロードは、RFC 7159 [RFC7159]のセクション8.3に従って、JSON文字列のエスケープ処理を適用した後に決定され、それから結果のUnicode符号ポイントをUTF-8エンコードします。また、未割り当てのUnicode符号ポイント値は使用してはなりません（MUST NOT）、ペイロードを表現するためには使えません。
The "crit" Header Parameter MUST be included with "b64" in its set of values when using the "b64" Header Parameter to cause implementations not implementing "b64" to reject the JWS (instead of it being misinterpreted).
「b64」ヘッダーパラメーターを使うときは、「crit」ヘッダーパラメーターに「b64」を含む必要があります（MUST）。これにより「b64」を解釈しない実装がJWSを（誤って解釈してしまう代わりに）拒否することができます。
Application profiles should specify whether "b64" with a "false" value is to be used by the application in each application context or not, with it then being consistently applied in each application context. For instance, an application that uses detached payloads might specify that "b64" with a "false" value always be used. It is NOT RECOMMENDED that this parameter value be dynamically varied with different payloads in the same application context.
アプリケーションプロファイルでは、各アプリケーションコンテキストごとに「b64」が「false」の値で使用されるかどうかが指定されるべきであり、それが各アプリケーションコンテキストで一貫して適用されるべきです。「b64」を使用するアプリケーションでは、分離したペイロードを使用する場合、常に「b64」を「false」と指定することがあります。同じアプリケーションコンテキスト内で、このパラメーターの値を異なるペイロードで動的に変化させることは推奨されません（NOT RECOMMENDED）。
[JWS] base64url-encodes the JWS Payload to restrict the set of characters used to represent it so that the representation does not contain characters used for delimiters in JWS representations. Those delimiters are the period ('.') character for the JWS Compact Serialization and the double-quote ('"') character for the JWS JSON Serialization. When the "b64" (base64url-encode payload) value is "false", these properties are lost. It then becomes the responsibility of the application to ensure that payloads only contain characters that will not cause parsing problems for the serialization used, as described in Section 5. The application also incurs the responsibility to ensure that the payload will not be modified during transmission.
[JWS] は、JWS表現で区切り文字として使用される文字を含まないように、JWSペイロードをbase64urlエンコードして表現を制限します。これらの区切り文字は、JWSコンパクトシリアル化においてピリオド（'.'）文字、JWS JSONシリアル化においてダブルクォート（'"'）文字です。"b64"（ペイロードをbase64urlエンコードする）値が"false"の場合、これらのプロパティは失われます。その後、セクション5で説明されているように、シリアル化に使用される解析の問題を引き起こさない文字だけがペイロードに含まれるように、アプリケーションが保証する責任が発生します。アプリケーションはまた、ペイロードが送信中に変更されないようにする責任も負います。
Note that if a JWS were to be created with a "b64" value of "false" without including the "crit" Header Parameter with "b64" in its set of values and it were to be received by an implementation not supporting the "b64" Header Parameter, then the signature or MAC would still verify but the recipient would believe that the intended JWS Payload value is the base64url decoding of the payload value received, rather than the payload value received itself. For example, if the payload value received were "NDA1", an implementation not supporting this extension would interpret the intended payload as being the base64url decoding of this value, which is "405". Requiring the use of the "crit" Header Parameter with "b64" in the set of values prevents this misinterpretation.
注：もしJWSが「b64」の値を「false」に設定して、「b64」を含まないヘッダーパラメーターの「crit」を持っている場合、そして「b64」ヘッダーパラメーターをサポートしていない実装によって受信された場合、署名またはMACは正しく検証されますが、受信者は意図したJWSペイロードの値が受信したペイロードの値のbase64urlデコードであると信じることになります。例えば、もし受信したペイロードの値が「NDA1」であり、この拡張機能をサポートしていない実装がある場合、意図したペイロードをこの値のbase64urlデコードと解釈します（「405」です）。この誤解を防ぐために、「b64」を値のセットに含む「crit」ヘッダーパラメーターの使用が必要です。
Anders Rundgren, Richard Barnes, Phillip Hallam-Baker, Jim Schaad, Matt Miller, Martin Thomson, and others have all made the case for being able to use a representation of the payload that is not base64url encoded in contexts in which it safe to do so.
アンダース・ルングレン氏、リチャード・バーンズ氏、フィリップ・ハラム＝ベイカー氏、ジム・シャード氏、マット・ミラー氏、マーティン・トムソン氏他は、安全である場合には、ペイロードの表現にbase64urlエンコードされていないものを使用することができるよう主張しています。
Thanks to Sergey Beryozkin, Stephen Farrell, Benjamin Kaduk, James Manger, Kathleen Moriarty, Axel Nennker, Anders Rundgren, Nat Sakimura, Jim Schaad, Robert Sparks, and Matias Woloski for their reviews of the specification, and thanks to Vladimir Dzhuvinov for verifying the examples.
「本仕様書のレビューを行っていただいた Sergey Beryozkin、Stephen Farrell、Benjamin Kaduk、James Manger、Kathleen Moriarty、Axel Nennker、Anders Rundgren、Nat Sakimura、Jim Schaad、Robert Sparks、Matias Woloski に感謝いたします。また、例の検証を行っていただいた Vladimir Dzhuvinov にも感謝いたします。」