JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-14

Abstract

JSON Web Signature (JWS)は, JavaScript Object Notation (JSON)をベースとしたデータ構造を用いて, デジタル署名やMessage Authentication Codes (MACs)により保護されたコンテンツを表現するための手段である. 本仕様で使用する暗号アルゴリズムと識別子はJSON Web Algorithms (JWA) で述べられている. 関連する暗号化の機能は, JSON Web Encryption (JWE) で述べられている.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on January 30, 2014.

Copyright Notice

Copyright (c) 2013 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.

Table of Contents

1.  Introduction
    1.1.  Notational Conventions
2.  Terminology
3.  JSON Web Signature (JWS) Overview
    3.1.  Example JWS
4.  JWS Header
    4.1.  Reserved Header Parameter Names
        4.1.1.  "alg" (Algorithm) Header Parameter
        4.1.2.  "jku" (JWK Set URL) Header Parameter
        4.1.3.  "jwk" (JSON Web Key) Header Parameter
        4.1.4.  "x5u" (X.509 URL) Header Parameter
        4.1.5.  "x5t" (X.509 Certificate Thumbprint) Header Parameter
        4.1.6.  "x5c" (X.509 Certificate Chain) Header Parameter
        4.1.7.  "kid" (Key ID) Header Parameter
        4.1.8.  "typ" (Type) Header Parameter
        4.1.9.  "cty" (Content Type) Header Parameter
        4.1.10.  "crit" (Critical) Header Parameter
    4.2.  Public Header Parameter Names
    4.3.  Private Header Parameter Names
5.  Producing and Consuming JWSs
    5.1.  Message Signing or MACing
    5.2.  Message Signature or MAC Validation
    5.3.  String Comparison Rules
6.  Key Identification
7.  Serializations
    7.1.  JWS Compact Serialization
    7.2.  JWS JSON Serialization
8.  IANA Considerations
    8.1.  JSON Web Signature and Encryption Header Parameters Registry
        8.1.1.  Registration Template
        8.1.2.  Initial Registry Contents
    8.2.  JSON Web Signature and Encryption Type Values Registry
        8.2.1.  Registration Template
        8.2.2.  Initial Registry Contents
    8.3.  Media Type Registration
        8.3.1.  Registry Contents
9.  Security Considerations
    9.1.  Cryptographic Security Considerations
    9.2.  JSON Security Considerations
    9.3.  Unicode Comparison Security Considerations
    9.4.  TLS Requirements
10.  References
    10.1.  Normative References
    10.2.  Informative References
    10.3.  翻訳プロジェクト
Appendix A.  JWS Examples
    A.1.  Example JWS using HMAC SHA-256
        A.1.1.  Encoding
        A.1.2.  Decoding
        A.1.3.  Validating
    A.2.  Example JWS using RSASSA-PKCS-v1_5 SHA-256
        A.2.1.  Encoding
        A.2.2.  Decoding
        A.2.3.  Validating
    A.3.  Example JWS using ECDSA P-256 SHA-256
        A.3.1.  Encoding
        A.3.2.  Decoding
        A.3.3.  Validating
    A.4.  Example JWS using ECDSA P-521 SHA-512
        A.4.1.  Encoding
        A.4.2.  Decoding
        A.4.3.  Validating
    A.5.  Example Plaintext JWS
    A.6.  Example JWS Using JWS JSON Serialization
        A.6.1.  JWS Per-Signature Protected Headers
        A.6.2.  JWS Per-Signature Unprotected Headers
        A.6.3.  Complete JWS Header Values
        A.6.4.  Complete JWS JSON Serialization Representation
Appendix B.  "x5c" (X.509 Certificate Chain) Example
Appendix C.  Notes on implementing base64url encoding without padding
Appendix D.  Negative Test Case for "crit" Header Parameter
Appendix E.  Acknowledgements
Appendix F.  Document History
Appendix G.  翻訳者
§  Authors' Addresses

1.  Introduction

JSON Web Signature (JWS)は, JavaScript Object Notation (JSON) [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) をベースとしたデータ構造を用いて, デジタル署名やMessage Authentication Codes (MACs)により保護されたコンテンツを表現するための手段である. JWSの暗号化メカニズムは任意のオクテット列に対して完全性保護を提供する.

JWSオブジェクトのために2つの密接に関連する表現が定義されている. JWS Compact Serializationはコンパクトであり, HTTP Authorization ヘッダやURIクエリパラメータのようなスペースが制約された環境を意図したURL-safeな表現である. JWS JSON SerializationはJSONオブジェクトとしてJWSオブジェクトを表現し, 同じコンテンツに対して複数の署名とMACsの両方, またはいずれかを適用することができる. 両方とも, 同じ暗号基盤を共有する.

本仕様で使用する暗号アルゴリズムと識別子はJSON Web Algorithms (JWA) [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.)で述べられている. 関連する暗号化の機能は, JSON Web Encryption (JWE) [JWE] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” July 2013.)で述べられている.

1.1.  Notational Conventions

本仕様で用いられる各キーワード「MUST (しなければならない)」, 「MUST NOT (してはならない)」, 「REQUIRED (必須である)」, 「SHALL (するものとする)」, 「SHALL NOT (しないものとする)」, 「SHOULD (すべきである)」, 「SHOULD NOT (すべきではない)」, 「RECOMMENDED (推奨される)」, 「MAY (してもよい)」, 「OPTIONAL (任意である)」は [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) で述べられている通りに解釈されるべきものである.

2.  Terminology

JSON Web Signature (JWS)

デジタル署名もしくはMAC化されたメッセージを表現するデータ構造. JWSは以下の3つの値より構成される: JWS ヘッダ, JWS ペイロード, JWS 署名

JSON Text Object (JSON テキストオブジェクト)

JSONオブジェクトを表現するUTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.)でエンコードされた文字列. JSONオブジェクトの構文は[RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.)のSection 2.2で定義されている.

JWS Header (JWS ヘッダ)

JWS 署名値を作成するために使用したデジタル署名やMACの操作を説明するJSONテキストオブジェクト(もしくはJWS JSON Serializationを用いたJSONテキストオブジェクト). JWS ヘッダオブジェクトのメンバは後述の "ヘッダパラメータ" である.

JWS Payload (JWS ペイロード)

保護対象となるオクテット列であり, メッセージとも呼ばれる. ペイロードは任意のオクテット列を含むことが出来る.

JWS Signature (JWS 署名)

JWS プロテクトヘッダとJWS ペイロードの完全性を保証する暗号論的情報からなるオクテット列. JWS 署名値はJWS ヘッダで指定されたパラメータを使いJWS署名入力から計算されたデジタル署名やMACの値である.

JWS Protected Header (JWS プロテクトヘッダ)

JWS ヘッダのうち完全性が保護された部分にあたる JSON テキストオブジェクト. JWS Compact Serialization では, JWS ヘッダ全体が JWS プロテクトヘッダとなる. JWS JSON Serialization では, JWS プロテクトヘッダは JWS ヘッダ全体のうちの一部である.

Header Parameter (ヘッダパラメータ)

JWSヘッダのメンバである名前と値のペア.

Header Parameter Name (ヘッダパラメータ名)

JWSヘッダのメンバの名前.

Header Parameter Value (ヘッダパラメータ値)

JWSヘッダのメンバの値.

Base64url Encoding

RFC 4648 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648]のSection 3.2で許可されているように, Section 5で述べられているURL-safeでない穴埋め文字'='を除いた, URL-safeかつfilename-safeであるBase64エンコーディング. (穴埋めなしのbase64urlエンコーディングの実装に関する注意事項についてはAppendix C (Notes on implementing base64url encoding without padding)を参照.)

Encoded JWS Header (エンコード済 JWS ヘッダ)

Base64urlでエンコードされたJWS プロテクトヘッダ.

Encoded JWS Payload (エンコード済 JWS ペイロード)

Base64urlでエンコードされたJWS ペイロード.

Encoded JWS Signature (エンコード済 JWS 署名)

Base64urlでエンコードされたJWS 署名.

JWS Signing Input (JWS署名入力)

エンコード済JWSヘッダ, ピリオド('.'), およびエンコード済JWSペイロードを連結したもの.

JWS Compact Serialization

エンコード済JWS ヘッダ, エンコード済JWS ペイロード, エンコード済JWS 署名を順番通りに, 3つの文字列を2つのピリオド('.')で区切り連結したJWSの表現. この表現はコンパクトでありURL-safeである.

JWS JSON Serialization

JWS ヘッダ, エンコード済 JWS ペイロード, エンコード済 JWS 署名値で構成される JSON 構造による JWS の表現. JWS Compact Serializationと異なり, JWS JSON Serializationは同じコンテンツに対して複数の署名とMACsの両方, またはいずれかを適用することができる. この表現はコンパクトでもなくURL-safeでもない.

Collision Resistant Namespace

他の名前と衝突することが極めて低くなるように名前を割り当てることを可能にする名前空間. 例えば, 衝突耐性は名前空間の部分の管理を委譲することで, または衝突耐性のある名前割り当て関数を利用することで実現できる. Collision Resistant Namespaceの例: ドメイン名, ITU-T X.660とX.670 Recommendation seriesで定義されたObject Identifiers (OIDs), Universally Unique IDentifiers (UUIDs) [RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.). 管理上委譲された名前空間を使用する場合, 名前を定義する際に, 名前を定義するために使用する名前空間の一部を制限していることを保証するために適切な注意を払う必要がある.

StringOrURI

以下の制約を設けたJSON文字列. 任意の文字列値を使用してよい(MAY)が, ":"を含む文字列はURI[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)でなければならない(MUST). StringOrURIの値は変換や正規化は適用されず, 比較時には大文字・小文字を区別する.

3.  JSON Web Signature (JWS) Overview

JWSはJSONデータ構造とbase64urlエンコーディングを用いてデジタル署名, もしくはMACを行ったコンテンツを表現する. JWSでは次の3つの値が表現される: JWSヘッダ, JWSペイロード, JWS署名. Compact Serializationでは3つの値はデータ転送のためにBase64urlでエンコードされ, またエンコードされた文字列を順番通りに, 3つの文字列を2つのピリオド('.')で区切って連結したものとして表現される. JSON Serializationの情報はSection 7.2 (JWS JSON Serialization)で定義されている.

JWSヘッダは採用した署名もしくはMACの手法とパラメータを記述する. JWSペイロードは保護対象となるメッセージコンテンツである. JWS署名はJWSプロテクトヘッダとJWSヘッダ両方の完全性を保証する.

3.1.  Example JWS

以下に示す例では, JWSヘッダはエンコードされたオブジェクトがJSON Web Token (JWT) [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2013.)であり, JWSヘッダとJWSペイロードがHMAC SHA-256アルゴリズムで保護されていることを示している:

  {"typ":"JWT",
   "alg":"HS256"}

JWSヘッダのUTF-8で表現されたオクテットをBase64urlエンコーディングすることで, 以下のエンコード済JWSヘッダの値が得られる:

  eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

以下はJWSペイロードとして用いることの出来るJSONオブジェクトの例である. (ペイロードは任意のコンテンツになり得るため, JSONオブジェクト表現である必要はないことに注意する.)

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

上記のJSONオブジェクトのUTF-8表現である以下のオクテット列が, JWSペイロードである:

[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125]

JWSペイロードをBase64urlエンコーディングすることで, 以下のエンコード済JWSペイロードが得られる (改行は掲載上の都合による):

  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

JWS署名入力 (エンコード済JWSヘッダ, ピリオド('.'), エンコード済JWSペイロードを連結したもの) の ASCII [USASCII] (American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.) オクテットの HMAC を, Appendix A.1 (Example JWS using HMAC SHA-256)で指定されたキーを用いてHMAC SHA-256アルゴリズムで計算し, 結果をbase64urlエンコードすることで, 以下のエンコード済JWS署名値が得られる:

  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

これらの値を "ヘッダ.ペイロード.署名" の順番で, パーツの間をピリオド('.')で連結することで, JWS Compact Serializationを用いたこの完全なJWS表現が得られる (改行は掲載上の都合による):

  eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

この計算はAppendix A.1 (Example JWS using HMAC SHA-256)で更に詳細に示されている. その他の例についてはAppendix A (JWS Examples)を参照すること.

4.  JWS Header

JWSヘッダを構成するJSONオブジェクトのメンバは, エンコードJWSヘッダおよびエンコード済JWSペイロード適用されたデジタル署名ないしMACについて記述する. また, それ以外のJWSプロパティーについて記述することもある. JWSヘッダ内のヘッダパラメータ名はユニークでなければならない (MUST). 受信者は重複したヘッダパラメータ名を持つJWSを, 拒否するか, または以下の動作をするJSONパーサーを使用しなければならない (MUST). すなわち, 重複したメンバ名に対して字面上で最後の(lexically last)もののみを返すようなJSONパーサーである(この動作はECMAScript 5.1 [ECMAScript] (Ecma International, “ECMAScript Language Specification, 5.1 Edition,” June 2011.) Section 15.12 (The JSON Object)で定義されている).

実装は本仕様において「理解しなければならない (MUST)」と定義されているヘッダパラメータを理解し, 本仕様に定義されている方法で処理することが要求される. 本仕様で定義されており, かつMUSTでないヘッダパラメータは, 理解できなかった場合にはすべて無視しなければならない (MUST). Section 4.1.10 ("crit" (Critical) Header Parameter)によってクリティカルヘッダパラメータとして列挙されている場合を除き, 本仕様で定義されていないヘッダパラメータは, 理解できなかった場合にはすべて無視しなければならない (MUST).

ヘッダパラメータ名には3つのクラスがある. すなわち, 予約済ヘッダパラメータ名, パブリックヘッダパラメータ名, およびプライベートヘッダパラメータ名である.

4.1.  Reserved Header Parameter Names

以下に示すヘッダパラメータ名は予約済とし, その意味を以下で定義する. これらのパラメータ名は短いが, それは本仕様の主目的として, JWS Compact Serialization方式による生成結果を小さくするためである.

追加の予約済ヘッダパラメータ名が定義される場合は, IANAによって JSON Web Signature and Encryption Header Parameters レジストリ Section 8.1 (JSON Web Signature and Encryption Header Parameters Registry)に追加される. レジストリが共通であることから示されるとおり, JWSとJWEはヘッダパラメータ空間を共有する. あるパラメータが両方の仕様で使われる場合, その使い方は2つの仕様の間で互換でなればならない.

4.1.1.  "alg" (Algorithm) Header Parameter

alg (algorithm) ヘッダパラメータはJWSの署名に使われる暗号アルゴリズムを識別する. 受信者は以下の場合にはJWSを拒否しなければならない (MUST): algで示されるアルゴリズムをサポートしていない場合, またはデジタル署名ないしMACを行ったパーティーの有効な鍵がない場合. algの値はIANA JSON Web Signature and Encryption Algorithms レジストリ [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.) に登録されているか, またはCollision Resistant Namespaceを含んでいるべきである (SHOULD). algの値はStringOrURIを表現する文字列であり, 大文字・小文字は区別される. このヘッダパラメータの利用は必須である (REQUIRED). 実装はこのヘッダパラメータを理解しなければならない (MUST).

定義済のalg値は IANA JSON Web Signature and Encryption Algorithms レジストリ [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.)に一覧されている. このレジストリの初期の内容はJSON Web Algorithms (JWA) [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.)仕様のSection 3.1で定義されている.

4.1.2.  "jku" (JWK Set URL) Header Parameter

jku (JWK Set URL)ヘッダパラメータはURI[RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.)であり, JSONでエンコードされた公開鍵セットのリソースを参照する. そのうちのひとつがJWSにデジタル署名をするときに用いる秘密鍵と対応する. 鍵は JSON Web Key Set (JWK Set) [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.)にしたがってエンコードされていなければならない (MUST). リソースを取得するために使用するプロトコルは完全性を保証しなければならない (MUST). HTTP GETリクエストによってJWK Setを取得する場合にはTLS[RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.)を使用しなければならない (MUST). サーバーのアイデンティティーはHTTP Over TLS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.)のSection 3.1で定義されるとおりに検証されなければならない (MUST) このヘッダパラメータの利用は任意 (OPTIONAL) である.

4.1.3.  "jwk" (JSON Web Key) Header Parameter

jwk (JSON Web Key)ヘッダパラメータはJWSにデジタル署名をするときに用いる秘密鍵と対応する公開鍵である. 鍵は JSON Web Key [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.)形式で表現される. このヘッダパラメータの利用は任意 (OPTIONAL) である.

4.1.4.  "x5u" (X.509 URL) Header Parameter

x5u (X.509 URL)ヘッダパラメータはURIであり, JWSにデジタル署名するために用いる鍵に対応するX.509公開鍵証明書もしくは証明書チェーン [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) リソースを参照する. リソースは証明書または証明書チェーンを表現し, RFC 5280 (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) [RFC5280]仕様を満たすPEMフォーマット[RFC1421] (Linn, J., “Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures,” February 1993.)でなければならない (MUST). JWSのデジタル署名に使用する鍵に対応する公開鍵の証明書は先頭の証明書でなければならない (MUST). これの後にさらなる証明書が続いても良く(MAY), それぞれの証明書は直前のものを証明する. リソースを取得するために使用するプロトコルは完全性を保証しなければならない (MUST). HTTP GETリクエストによってJWK Setを取得する場合にはTLS[RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.)を使用しなければならない (MUST). サーバーのアイデンティティーはHTTP Over TLS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.)のSection 3.1で定義されるとおりに検証されなければならない (MUST) このヘッダパラメータの利用は任意 (OPTIONAL) である.

4.1.5.  "x5t" (X.509 Certificate Thumbprint) Header Parameter

x5t (X.509証明書フィンガープリント)ヘッダパラメータは, JWSにデジタル署名するために用いる鍵に対応するX.509証明書[RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.)をDER形式で表現し, そのSHA-1フィンガープリント(ダイジェスト)をBase64 URLエンコードしたものである. このヘッダパラメータの利用は任意 (OPTIONAL) である.

将来, 証明書フィンガープリントをSHA-1以外のハッシュ関数によって計算する必要が発生した場合, その目的のために追加のヘッダパラメータを定義することが推奨される. 例えば, 新しいx5t#S256 (SHA-256によるX.509証明書フィンガープリント)というヘッダパラメータをIANA JSON Web Signature and Encryption Header Parameters レジストリに Section 8.1 (JSON Web Signature and Encryption Header Parameters Registry)登録することが推奨される.

4.1.6.  "x5c" (X.509 Certificate Chain) Header Parameter

x5c (X.509証明書チェーン) ヘッダパラメータは, JWSにデジタル署名するために用いる鍵に対応するX.509公開鍵証明書もしくは証明書チェーン [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) を含む. 証明書や証明書チェーンは, 証明書の文字列のJSON配列として表される. 配列中のそれぞれの文字列はBase64エンコード([RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) 4節 -- Base64 URLエンコードではない)されているDER [ITU.X690.1994] (International Telecommunications Union, “Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” 1994.) PKIX証明書の値である. JWSにデジタル署名するために用いる鍵に対応する公開鍵の証明書は先頭の証明書でなければならない (MUST). これの後にさらなる証明書が続いても良く(MAY), それぞれの証明書は直前のものを証明する. 受信者は証明書チェーンを [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) に従って確認する. 検証エラーが発生した場合には, そのJWSを拒否しなければならない (MUST). このヘッダパラメータの利用は任意 (OPTIONAL) である.

x5c の例については Appendix B ("x5c" (X.509 Certificate Chain) Example) を参照.

4.1.7.  "kid" (Key ID) Header Parameter

kid (key ID)ヘッダパラメータはJWSを保護するためにどの鍵が使用されたかを示しているヒントである. このパラメータは発信者が鍵の変更を受信者に明確に示すことを許す. 受信者が kid の値に一致する鍵を見つけることができないならば, その状態をエラーとして扱うべきである (SHOULD). kid の値の説明は記載しない. その値は文字列でなければならない (MUST). このヘッダパラメータの利用は任意 (OPTIONAL) である.

JWKを利用する場合, kid の値はJWK kid パラメータの値と一致するように利用できる.

4.1.8.  "typ" (Type) Header Parameter

typ (type) ヘッダパラメータは, これがアプリケーションにとって有用な文脈の中で, アプリケーションに特化した方法で, この完全なJWSオブジェクトの種類を表すために用いられてもよい (MAY). このパラメータはJWSの処理に影響を及ぼさない. JOSE という値はアプリケーションによりこのオブジェクトがJWS Compact Serializationを用いたJWSもしくはJWE Compact Serializationを用いたJWEであることを示すために用いられてもよい (MAY). JOSE+JSON という値はアプリケーションによりこのオブジェクトがJWS JSON Serialiationを用いたJWSもしくはJWE JSON Serializationを用いたJWEであることを示すために用いられてもよい (MAY). その他の値も用いられても良く(MAY), もし理解されなかった場合は無視されるべきである (SHOULD). typ の値は文字列であり, 大文字・小文字を区別する. このヘッダパラメータの利用は任意 (OPTIONAL) である.

MIME Media Type [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) の値は typ の値として用いられてもよい (MAY).

typ の値は IANA JSON Web Signature and Encryption Type Values レジストリ Section 8.2 (JSON Web Signature and Encryption Type Values Registry) に登録されるか衝突耐性を持つ名前空間を含む値であるべきである (SHOULD).

4.1.9.  "cty" (Content Type) Header Parameter

cty (content type) ヘッダパラメータは, これがアプリケーションにとって有用な文脈の中で, アプリケーションに特化した方法で, 保護されているコンテント(ペイロード)の種類を表すために用いられてもよい (MAY). このパラメータはJWSの処理に影響を及ぼさない. コンテントタイプの値が理解されなかった場合は無視されるべきである (SHOULD). cty の値は文字列であり, 大文字・小文字を区別する. このヘッダパラメータの利用は任意 (OPTIONAL) である.

cty ヘッダパラメータに用いられる値は typ ヘッダパラメータと同じ値空間となり, 同じ規則が適用される.

4.1.10.  "crit" (Critical) Header Parameter

crit (critical) ヘッダパラメータは, 本仕様の拡張が利用されていること, およびその拡張仕様が必ず理解されなければならない (MUST) ことを示す. その値はJWSヘッダ内で用いられるこれらの拡張仕様によって定義されたヘッダパラメータ名が記載された配列である. もし記載された拡張ヘッダパラメータが受信者により理解されずサポートされない場合, そのJWSは拒否されなければならない (MUST). 送信者はこの仕様もしくはJWS利用のために [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.) により定義されているヘッダパラメータ, 重複した名前, JWSヘッダに現れないヘッダパラメータ名を crit リストに含めてはならない (MUST NOT). 送信者は crit の値に空のリスト [] を用いてはならない (MUST NOT). もしcriticalリストがこの仕様もしくはJWS利用のために [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.) で定義されているヘッダパラメータを含む場合, 受信者はそのJWSを拒否してもよい (MAY). 同様に, critヘッダを利用する上でのなんらかの制約条件に違反する場合にも, 受信者はそのJWSを拒否してもよい (MAY). このヘッダパラメータは完全に保護されなければならず (MUST), 従って利用されるときは必ずJWSプロテクトヘッダのみに現れなければならない (MUST). このヘッダパラメータの利用は任意 (OPTIONAL) である. 実装はこのヘッダパラメータを理解しなければならない (MUST).

exp (expiration-time)フィールドを加えたと仮定した使用例 :

  {"alg":"ES256",
   "crit":["exp"],
   "exp":1363284000
  }

4.2.  Public Header Parameter Names

JWS利用者により, 追加のヘッダパラメータ名を定義することができる. しかしながら, 衝突を防ぐために, 新しいヘッダパラメータ名は IANA JSON Web Signature and Encryption Header Parameters レジストリ Section 8.1 (JSON Web Signature and Encryption Header Parameters Registry) に登録されるか, またはパブリックな名前(衝突耐性を持つ名前空間を含む)となるべきである (SHOULD). それぞれのケースにおいて, 名前もしくは値の定義者は, ヘッダパラメータ名定義に用いる名前空間の一部を制御可能なことを保証するために, 適切な注意を払う必要がある.

新しいヘッダパラメータは非互換なJWSの発生原因となりうるため, 慎重に導入されるべきである.

4.3.  Private Header Parameter Names

JWSの生成者と消費者は, 予約済パラメータ名 Section 4.1 (Reserved Header Parameter Names) やパブリックパラメータ名 Section 4.2 (Public Header Parameter Names) ではないプライベートパラメータ名であるヘッダパラメータを用いることに同意してもよい. パブリックな名前とは異なり, プライベートな名前は衝突しやすく注意して利用すべきである.

5.  Producing and Consuming JWSs

5.1.  Message Signing or MACing

JWSを作成するためには, 以下の手順を踏まなければならない (MUST). 手順の順序は, それぞれの手順の入力と出力の間に依存関係がない場合には重要ではない.

1. JWSペイロードとして利用されるコンテンツを作成する.
2. JWSペイロードのオクテット列をbase64urlエンコードする. このエンコード結果がエンコード済みJWSペイロードとなる.
3. 希望のヘッダパラメータのセットを含んだJWSヘッダを作成する. 空白がその表現の中に存在することが明示的に許可されること, そしてエンコード前に正規化が必要ないことに注意する.
4. JWSプロテクトヘッダのUTF-8表現のオクテット列をbase64urlエンコードし, エンコード済みJWSヘッダを作成する. JWSプロテクトヘッダが存在しない場合(JWS JSON Serializationを利用していて, protected 要素が存在しない場合のみに発生する), エンコード済みJWSヘッダは空文字列にする.
5. JWS署名入力(エンコード済みJWSヘッダ, ピリオド ('.'), そしてエンコード済みJWSペイロードの連結文字列)に対して適用される特定のアルゴリズムで定義されている方法でJWS署名を算出する. alg (アルゴリズム)ヘッダパラメータは, JWSヘッダに存在し, JWS署名を生成するために利用されるアルゴリズムを正確に表すアルゴリズム名を値としなければならない (MUST).
6. JWS署名をbase64urlエンコードし, エンコード済みJWS署名を作成する.
7. これらの３つのエンコード部分がJWS Compact Serialization表現とJWS JSON Serialization表現の双方で利用される結果値となる.
8. JWS JSON Serializationが利用される場合には, 適用対象となる各デジタル署名, もしくはMAC値毎にこのプロセスを繰り返す.
9. 希望の形式のシリアライズ結果を作成する. 結果のJWS Compact Serializationは, エンコード済みJWSヘッダとエンコード済みJWSペイロード, そしてエンコード済みJWS署名をこの順で連結したもので, この３つの文字列は２つのピリオド('.')で分けられる. JWS JSON Serializationについては Section 7.2 (JWS JSON Serialization)で述べられる.

5.2.  Message Signature or MAC Validation

JWSの正当性を評価する時には, 以下の手順を踏まなければならない (MUST). 手順の順序は, それぞれの手順の入力と出力に依存関係がない場合には重要ではない. 列挙されている手順のいずれかで異常が発生した場合には, JWSは拒否されなければならない (MUST).

1. シリアライズされた入力をパーズしJWSヘッダ, エンコード済みJWSペイロード, そしてエンコード済みJWS署名の値を確定する. JWS Compact Serializationを利用している場合には, エンコード済みJWSヘッダ, エンコード済みJWSペイロード, そしてエンコード済みJWS署名が, この順で二つのピリオド('.')によって分けられた文字列として表される. JWS JSON Serializationについては Section 7.2 (JWS JSON Serialization)で述べられる.
2. エンコード済みJWSヘッダは, 穴埋め文字は利用されないというこの仕様の制約に従ってbase64urlデコードされなければならない (MUST).
3. エンコード済みJWSヘッダをbase64urlでデコードした結果を, JWSプロテクトヘッダ値とする.
4. 結果として得られたJWSプロテクトヘッダは, RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]に従った完全に有効なJSONオブジェクトでなければならない (MUST).
5. JWS Compact Serializationを利用している場合, JWSプロテクトヘッダをJWSヘッダとする; さもなければ, JWS JSON Serializationを利用して, JWSヘッダを, 対応する protectedヘッダパラメータの値と headerヘッダパラメータの値の和集合とし, すべてを完全に有効なJSONオブジェクトとしなければならない.
6. 結果のJWSヘッダは重複したヘッダパラメータ名を含んではならない (MUST NOT). JWS JSON Serializationを利用する場合は, この制約は, 共にJWSヘッダを含んだ, それぞれ別個のJSON Textオブジェクトの中に同じヘッダパラメータ名は存在してはならないことも含む (MUST NOT).
7. 結果のJWSヘッダは, シンタックスやセマンティックスが理解され, かつサポートされている, もしくは理解されない場合には無視するよう指定されたパラメータやその値のみ含んでいることを確認されなければならない (MUST).
8. エンコード済みJWSペイロードは穴埋め文字は利用されないというこの仕様の制約に従ってbase64urlデコードされなければならない (MUST).
9. エンコード済みJWS署名は穴埋め文字は利用されないというこの仕様の制約に従ってbase64urlデコードされなければならない (MUST).
10. JWS署名は, JWS署名入力(エンコード済みJWSヘッダ, ピリオド ('.'), そしてエンコード済みJWSペイロードの連結文字列)に対して適用されているアルゴリズムで定義された方法で検証されなければならない (MUST). アルゴリズムは alg(アルゴリズム)ヘッダパラメータの値として正確に示されなければならない (MUST). このヘッダパラメータは存在していなければならない (MUST).
11. JWS JSON Serializationが利用されている場合には, 含まれている各デジタル署名, もしくはMAC値毎にこのプロセスを繰り返す.

5.3.  String Comparison Rules

JWSの処理は必然的に既知の文字列とJSONオブジェクトの値を比較することを要求する. 例えばアルゴリズムが何であるかをチェックする場合, algをエンコードしたUnicode文字列がJWSヘッダの要素名と照合され, マッチするヘッダパラメータ名があるかどうかを確かめる. 同様のプロセスが algヘッダパラメータの値がサポートされているアルゴリズムであるかどうか判定するときにも発生する.

JSON文字列とその他のUnicode文字列の比較は以下の手順で実施されなければならない (MUST):

1. JSONのエスケープを入力JSON文字列から取り除き, その文字列をUnicodeのコードポイント列に変換する.
2. 同様に比較対象文字列をUnicodeのコードポイント列に変換する.
3. Unicode正規化 [USA15] (Davis, M., Whistler, K., and M. Deurst, “Unicode Normalization Forms,” 09 2009.)はJSON文字列, もしくはそれと比較される文字列について, いかなる時点においても適用されるべきではない (MUST NOT).
4. 二つの文字列の比較はUnicodeのコードポイントどうしの等価比較として実行されなければならない (MUST). (もともと異なるUnicodeのエンコード方式(UTF-8, UTF-16, など.)を利用していた値どうしはそれぞれ同じコードポイントになる可能性があることに注意する.)

JSONのセキュリティ考慮事項 Section 9.2 (JSON Security Considerations)とUnicodeのセキュリティ考慮事項 Section 9.3 (Unicode Comparison Security Considerations)も参照すること.

6.  Key Identification

JWSの受信者は, デジタル署名またはMAC処理に使用された鍵を決定できる必要がある. 適用された鍵はSection 4.1 (Reserved Header Parameter Names)で説明されているヘッダパラメータによって, まには本仕様のスコープ外の方法で識別することができる. 特に, ヘッダパラメータ jku, jwk, x5u, x5t, x5c, および kid は鍵の識別のために用意されている. 送信者は鍵を識別するために十分な情報をヘッダパラメータに含めるべきである(SHOULD). ただし, アプリケーションが他の手段やコンベンションによって使用する鍵を識別する場合にはこの限りではない. 受信者は, 指定されたアルゴリズムが鍵を必要とする場合であり(実際, none以外のすべてのアルゴリズムは鍵を必要とする), 使用する鍵が識別できない場合には, 入力を拒否しなければならない(MUST).

7.  Serializations

JWSオブジェクトは2通りのシリアライズ形式を使用する. JWS Compact Serialization および JWS JSON Serializationである. JWS Compact Serializationの実装は必須である. JWS JSON Serializationの実装はオプショナルである(OPTIONAL).

7.1.  JWS Compact Serialization

JWS Compact Serializationはデジタル署名された, またはMACを行ったコンテンツをコンパクトなURL-safe文字列として表現したものである. この文字列は, エンコード済JWSヘッダ, エンコード済JWSペイロード, およびエンコード済JWS署名を, この順序で2つのピリオド('.')文字を区切り文字として連結したものである. JWS Compact Serializationでサポートされる署名ないしMACはひとつだけである.

7.2.  JWS JSON Serialization

JWS JSON Serializationははデジタル署名された, またはMACを行ったコンテンツをJSONオブジェクトとして表現したものである. JWS Compact Serializationとは違い, JWS JSON Serializationを使用したコンテンツは複数のデジタル署名および/またはMAC値で保護することができる.

JWS JSON Serializationの表現はJWS Compact Serializationで使われる表現と強く関連しており, 以下の点に違いがある:

• JWS JSON Serializationの中にある値は, ピリオド('.')文字を区切りとしたbase64url文字列としてではなく, JSONオブジェクトのメンバとして表現される. (ただし, バイナリ値および完全性を保護された値はbase64urlエンコードされる.)
• エンコード済JWSペイロード値はpayloadメンバに格納される.
• 署名および/またはMAC値は, ひとつに限らず, 複数存在してもよい. signaturesメンバはJSON配列であり, 特定の署名またはMAC算出に使われる値を格納するために使われる. 配列の1要素が署名/MACひとつに対応する. これらの要素はそれぞれJSONオブジェクトである.
• 各エンコード済JWS署名値は, 空でない限り, signatures配列の要素であるJSONオブジェクトのsignatureメンバに格納される.
• 各エンコード済JWSヘッダ値は, 署名/MAC算出に用いるヘッダパラメータ値の集合をbase64urlエンコードしたものであり, 空でない限り, signatures配列の対応する要素オブジェクトのprotectedメンバに格納される.
• JWS Compact Serializationとは違い, JWS JSON Serializationは署名/MAC算出に用いられないヘッダパラメータ値を含むこともできる. これらの保護されないヘッダパラメータ値は, 存在すれば, エンコードされないJSONテキストオブジェクトとして, signatures配列の対応する要素オブジェクトのheaderメンバに格納される.
• それぞれの署名またはMAC値の算出ないし検証に使用されるヘッダパラメータ値は, 以下の2つのヘッダパラメータ値の和集合である: (1)完全性を保護された署名/MACごとの値であり, 署名/MACに対応する配列要素のprotectedメンバに格納されている, (2)完全な保護のなされていない署名/MACごとの値であり, 署名/MACに対応する配列要素のheaderメンバに格納されている, これらのヘッダパラメータ値の和集合がJWSヘッダとなる. 2つの場所にあるヘッダパラメータ名は共通するものがあってはならない(MUST be disjoint).

JWS JSON Serializationを用いたJWSの形式は以下の通りである:

  {
   "payload":"<ペイロードコンテンツ>"
   "signatures":[
    {"protected":<完全性を保護されたヘッダ 1 のコンテンツ>",
     "header":"<完全性を保護されないヘッダ 1 のコンテンツ>",
     "signature":"<署名 1 のコンテンツ>"},
    ...
    {"protected":<完全性を保護されたヘッダ N のコンテンツ>",
     "header":"<完全性を保護されないヘッダ N のコンテンツ>",
     "signature":"<署名 N のコンテンツ>"}],
  }

これらのメンバのうち, payload, signatures, およびsignatureは存在しなければならない(MUST). protectedおよび headerの少なくとも一方は存在しなければならず(MUST), 各署名/MAC算出に対応するalgヘッダパラメータ値を含むものとする.

エンコード済JWSペイロード値およびエンコード済JWS署名値のコンテンツは, 正確に本仕様の他の部分で定義されるとおりである. これらの値は, 対応するエンコード済JWS署名およびヘッダパラメータ値の集合が生成・検証される場合と同じ方法で解釈・検証される. 使用されるJWSヘッダ値は, 上述のとおり, 対応するprotectedおよび headerメンバの和集合である.

各JWS署名値はJWS署名入力に対し, 対応するJWSヘッダ値をJWS Compact Serializationの場合と同様の方法で適用して算出する. これにより, signatures配列内のエンコード済JWS署名値が, JWS Compact Serializationにおいて同一のパラメータを用いた場合に得られるであろう値と一致するという望ましい特性が得られる. これはその署名/MACの算出に用いられるエンコード済JWSヘッダ値(つまり完全性を保護されたヘッダパラメータ値を表現したもの)が, JWS Compact Serializationで用いられるものと一致する限りにおいて正しい.

JWS JSON Serializationを用いたJWSの算出例については Appendix A.6 (Example JWS Using JWS JSON Serialization) を参照.

8.  IANA Considerations

以下の登録手順は, この仕様によって定められる全てのレジストリで利用される.

値は1名以上の Designated Experts の勧告に従い, [TBD]@ietf.orgのメーリングリストで2週間のレビュー期間の後にSpecification Required [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) な状態で登録される. しかしながら, 発行に先立ちそれらの値を割り当てることができるように Designated Expert(s) はそれらの値が公開できる状態になった時点で登録を許可することもありうる.

登録要請は, 適切な件名 (例: "Request for access token type: example") で [TBD]@ietf.org のメーリングリストに通知しなければならず, そこでレビューとコメントが行われる. [[ RFC-EDITORへの注意: メーリングリストの名前は, IESGとIANAと協議の上, 決定されるべきである. 提案される名前: jose-reg-review ]]

Designated Expert(s) はレビュー期間内に登録申請を承認または拒否し, レビューが行われるメーリングリストおよび IANA へその決定を告げる. 要請が拒否された場合は, その理由が通知され, 可能な場合は申請の成功に向けた提案が行われるべきである.

IANA は Designated Expert(s) からのレジストリ更新のみを受け付けなければならず, 登録のために全ての申請をレビューが行われるメーリングリストに送られるべきである.

8.1.  JSON Web Signature and Encryption Header Parameters Registry

この仕様は, JWSとJWEのヘッダパラメータ名の予約ために IANA JSON Web Signature and Encryption Header Parameters レジストリを定める. レジストリは, 予約されるヘッダパラメータ名とそれを定める仕様への参照を登録する. パラメータの利用が仕様間で互換性を持つならば, 同じヘッダパラメータ名は複数回登録されても良い (MAY). 同じヘッダパラメータ名の異なる登録は, 利用箇所が異なるのが一般的である.

8.1.1.  Registration Template

Header Parameter Name:

申請される名前 (例: "example"). この名前は大文字・小文字を区別する. 大文字・小文字を同一視すると, 他に登録されている名前と一致するものは受け入れられるべきではない (SHOULD NOT).

Header Parameter Usage Location(s):

ヘッダパラメータの使用箇所は JWS もしくは JWE のうちの1つ以上であるべき.

Change Controller:

標準化過程のRFCについては, "IETF"とする. その他については, 責任を追う団体の名前を与える. その他の詳細情報 (例: 郵便番号, メールアドレス, ホームページURI) も含まれても良い.

Specification Document(s):

パラメータを規定するドキュメントの参照であり, そのドキュメントの複製を取得するために利用可能なURIを含むことが望ましい. 関連する節の表示も含まれて良いが, 必須ではない.

8.1.2.  Initial Registry Contents

本仕様はこのレジストリに Section 4.1 (Reserved Header Parameter Names) にて定義されているヘッダパラメータ名を登録する.

• Header Parameter Name: alg
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.1 ("alg" (Algorithm) Header Parameter) of [[ this document ]]

• Header Parameter Name: jku
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.2 ("jku" (JWK Set URL) Header Parameter) of [[ this document ]]

• Header Parameter Name: jwk
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification document(s): Section 4.1.3 ("jwk" (JSON Web Key) Header Parameter) of [[ this document ]]

• Header Parameter Name: x5u
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.4 ("x5u" (X.509 URL) Header Parameter) of [[ this document ]]

• Header Parameter Name: x5t
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.5 ("x5t" (X.509 Certificate Thumbprint) Header Parameter) of [[ this document ]]

• Header Parameter Name: x5c
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.6 ("x5c" (X.509 Certificate Chain) Header Parameter) of [[ this document ]]

• Header Parameter Name: kid
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.7 ("kid" (Key ID) Header Parameter) of [[ this document ]]

• Header Parameter Name: typ
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.8 ("typ" (Type) Header Parameter) of [[ this document ]]

• Header Parameter Name: cty
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.9 ("cty" (Content Type) Header Parameter) of [[ this document ]]

• Header Parameter Name: crit
• Header Parameter Usage Location(s): JWS
• Change Controller: IETF
• Specification Document(s): Section 4.1.10 ("crit" (Critical) Header Parameter) of [[ this document ]]

8.2.  JSON Web Signature and Encryption Type Values Registry

この仕様は, JWSとJWEの typ (type) ヘッダパラメータ値の予約ために IANA JSON Web Signature and Encryption Type Values レジストリを定める. 全ての登録される typ の値は, それが短い名前として表すMIME Media Type [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) の値を含むことを推奨する (RECOMMENDED). レジストリは, typ の値, それが省略形となる(ものがあれば) MIME type の値とそれを定める仕様への参照を登録する.

MIME Media Type [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) の値は新しい typ の値としてそのまま登録されてはならない (MUST NOT); むしろ, 新しい typ の値は MIME Typesを短縮した名前として登録されても良い (MAY).

8.2.1.  Registration Template

"typ" Header Parameter Value:

申請される名前 (例: "example"). この名前は大文字・小文字を区別する. 大文字・小文字を同一視すると, 他に登録されている名前と一致するものは受け入れられるべきではない (SHOULD NOT).

Abbreviation for MIME Type:

この名前が省略形となるMIME Type (例: "application/example").

Change Controller:

標準化過程のRFCについては, "IETF"とする. その他については, 責任を追う団体の名前を与える. その他の詳細情報 (例: 郵便番号, メールアドレス, ホームページURI) も含まれても良い.

Specification Document(s):

パラメータを規定するドキュメントの参照であり, そのドキュメントの複製を取得するために利用可能なURIを含むことが望ましい. 関連する節の表示も含まれて良いが, 必須ではない.

8.2.2.  Initial Registry Contents

本仕様はこのレジストリで JOSE と JOSE+JSON というtype値を登録する.

• "typ" Header Parameter Value: JOSE
• Abbreviation for MIME type: application/jose
• Change Controller: IETF
• Specification Document(s): Section 4.1.8 ("typ" (Type) Header Parameter) of [[ this document ]]

• "typ" Header Parameter Value: JOSE+JSON
• Abbreviation for MIME type: application/jose+json
• Change Controller: IETF
• Specification Document(s): Section 4.1.8 ("typ" (Type) Header Parameter) of [[ this document ]]

8.3.  Media Type Registration

8.3.1.  Registry Contents

本仕様は, コンテンツがJWS Compact Serializationを利用するJWS もしくはJWE Compact Serializationを利用するJWEであることを示すために用いられる application/jose というMedia Type [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) をMIME Media Typeレジストリ [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.) に登録し, コンテンツがJWS JSON Serializationを利用するJWSもしくはJWE JSON Serializationを利用するJWEであることを示すために用いられる application/jose+json というMedia TypeをMIME Media Typeレジストリに登録する.

• Type name: application
• Subtype name: jose
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: application/joseの値は, ピリオド('.')文字により分割された(空の文字列であることもありうる)Base64 URLエンコードされた一連の文字列としてエンコードされる.
• Security considerations: See the Security Considerations section of [[ this document ]]
• Interoperability considerations: n/a
• Published specification: [[ this document ]]
• Applications that use this media type: OpenID Connect, Mozilla Persona, Salesforce, Google, numerous others that use signed JWTs
• Additional information: Magic number(s): n/a, File extension(s): n/a, Macintosh file type code(s): n/a
• Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Michael B. Jones, mbj@microsoft.com
• Change Controller: IETF

• Type name: application
• Subtype name: jose+json
• Required parameters: n/a
• Optional parameters: n/a
• Encoding considerations: application/jose+jsonの値は, JSONオブジェクトとして表現される; そのJSONオブジェクトのためにUTF-8エンコードが用いられるべき (SHOULD).
• Security considerations: See the Security Considerations section of [[ this document ]]
• Interoperability considerations: n/a
• Published specification: [[ this document ]]
• Applications that use this media type: TBD
• Additional information: Magic number(s): n/a, File extension(s): n/a, Macintosh file type code(s): n/a
• Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com
• Intended usage: COMMON
• Restrictions on usage: none
• Author: Michael B. Jones, mbj@microsoft.com
• Change Controller: IETF

9.  Security Considerations

9.1.  Cryptographic Security Considerations

どんな暗号化アプリケーションも直面するセキュリティ上の課題すべてに, JWS/JWE/JWKエージェントも立ち向かわなければならない. なかでもユーザの秘密鍵と共通鍵を保護すること, さまざま攻撃を阻止すること, そして不注意で間違った受信者へのメッセージを暗号化するような誤操作を避ける手助けをすることが課題である. セキュティ上の考慮事項の完全なリスト化は本ドキュメントの範囲外がであるが, ここにいくつかの重要な事項を列挙する.

XML DSIG 2.0 (Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Hirsch, F., Cantor, S., and T. Roessler, “XML Signature Syntax and Processing Version 2.0,” January 2012.) [W3C.CR‑xmldsig‑core2‑20120124]にあるすべてのセキュリティ上考慮すべき事項は, XMLに特化したもの以外はすべて本仕様にも当てはまる. 同様にXML Signature Best Practices (Datta, P. and F. Hirsch, “XML Signature Best Practices,” August 2011.) [W3C.WD‑xmldsig‑bestpractices‑20110809]に記載されているベストプラクティスの多くも, XMLに特化したもの以外は本仕様に適用できる.

鍵は生成するために使われるエントロピー量と同じ強度にしかならない. 最低128ビットのエントロピーがすべての鍵に利用されるべきである. アプリケーションコンテクストによってはもっと多くのエントロピーが必要になるかもしれない. 特にいくつかのブラウザやアプリケーション環境では十分ランダムな数値を生成するのが難しいかもしれない.

JWSの作成者は, 第三者によって制御されないエントロピーを追加することをせずに第三者が任意のコンテンツをメッセージに挿入することを許すべきではない.

情報取得のためにTLSを利用する場合には, リソースを提供する機関は本物であることを証明されなければならない(MUST). そして取得される情報は改変不能でなければならない(MUST).

暗号化アルゴリズムが成功時と失敗時で処理時間に差があるように実装されている場合, 攻撃者は処理時間の差を利用して利用されている鍵についての情報を取得することができかもしれない. 故にそのような処理時間の差は避けなければならない.

互換性の理由からSHA-1ハッシュが x5t (x.509証明書のフィンガープリント) の値を算出するのに利用される. SHA-1ハッシュ値の衝突を引き起こす効率的な方法が開発され, 攻撃者が任意のシステムの既知の証明書の利用を妨害したい場合, SHA-1ハッシュの値が同じ証明書をもう一つ作成し, それを狙われた被害者の証明書ストアに加えることで妨害は実現される可能性がある. この攻撃の前提は攻撃者が狙われた被害者の証明書ストアへの書き込み権限をもつことである.

将来, 証明書のフィンガープリントをSHA-1以外のハッシュ関数で算出する必要が出てきた場合, そのために追加の関連ヘッダパラメータを定義することが推奨される. 例えば, 新しい x5t#S256 (SHA-256を使ったX.509証明書のフィンガープリント)というヘッダパラメータを定義して利用することが推奨される.

9.2.  JSON Security Considerations

厳密なJSONの検証はセキュリティ上必要である. 不正な形式のJSONを受け取った場合, 送信者の意図を確実に識別することは不可能である. 使用されるJSONパーサーが不正な構文のJSONを拒否しない場合, 不明瞭かつ潜在的に悪用可能な状況が起こりうる.

本仕様では"オブジェクト内のヘッダパラメータ名はユニークでなければならない(MUST). つまり, 受信者はヘッダパラメータ名が重複したJWSを拒否するか, ECMAScript 5.1 [ECMAScript] (Ecma International, “ECMAScript Language Specification, 5.1 Edition,” June 2011.)のSection 15.12で規定されているように, 重複したメンバ名から字面上で最後のもののみを返すJSONパーサーを使うかのどちらかをしなければならない(MUST)"と述べているのに対し, JavaScript Object Notation (JSON) 仕様書 [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.)のSection 2.2では"オブジェクト内の名前はユニークであるべき (SHOULD)"と述べられている. したがって, 本仕様では, Section 2.2内の"SHOULD"は送信者により"MUST"として扱われ, 受信者により"MUST"として扱われるか, もしくはECMAScript 5.1で規定されている方法で扱われることを必要としている. 使用されるJSONパーサーがメンバ名のユニーク性を強制しない, もしくは重複したメンバ名から予測不可能な値を返す場合, 不明瞭かつ潜在的に悪用可能な状況が起こりうる.

一部のJSONパーサーは有効な入力の後に意味のある文字が余分に含まれている入力を拒否しないかもしれない. 例えば, {"tag":"value"}ABCDという入力は有効なJSONオブジェクトの後に余分な文字であるABCDを含んでいる. このような入力は全体が拒否されないければならない(MUST).

9.3.  Unicode Comparison Security Considerations

ヘッダパラメータ名とアルゴリズム名はUnicode文字列である. セキュリティ上の理由から, これらの名前の表現は任意のエスケープ処理(RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]のSection 2.5に従う)を行った後, そのまま比較されなければならない. つまり, 例えばJSON文字列("sig", "\u0073ig")は等しいものとして比較されなければならない一方, ("SIG", "Sig", "si\u0047")は前述のセットと, またお互いにも等しくないものとして比較されなければならない.

JSON文字列はUnicodeの基本多言語面外の文字を含むことが出来る. 例えば, ト音記号 (U+1D11E)はJSON文字列中に"\uD834\uDD1E"として表すことが出来る. 理想的には, JWSの実装は基本多言語面外の文字が正確に保存され比較されることを保証するべき(SHOULD)である. しかし一方で, これらの文字のせいで基礎となるJSONの実装に存在する制限を実行出来ない場合は, これらの文字を含む入力は拒否されなければならない(MUST).

9.4.  TLS Requirements

実装はTLSをサポートしなければならない(MUST). 実装されるべきバージョンは導入の普及状況や, 実装時点で既知のセキュリティの脆弱性に依存し, 時間とともに変化する. TLS version 1.0 [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.)はもっとも広く導入されているバージョンであり, 広範な相互運用性を提供する.

情報取得や改ざんから保護するために, 機密保護にはTLSを使用して機密性と完全性保護を提供するciphersuiteが適用されなければならない(MUST).

TLSが使用されるときは常にRFC 6125 (Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),” March 2011.) [RFC6125]に従いTLSサーバー証明書のチェックが実行されなければならない(MUST).

10.  References

10.1. Normative References

10.2. Informative References

10.3. 翻訳プロジェクト

Appendix A.  JWS Examples

本節では, いくつかのJWSの例を提供する. はじめの3例はJSON Web Token (JWT) [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2013.) を表しているが, Appendix A.4 (Example JWS using ECDSA P-521 SHA-512) に見られるように, ペイロードは任意のオクテット列を含むことが出来る.

A.1.  Example JWS using HMAC SHA-256

A.1.1.  Encoding

以下に示すJWSヘッダの例では, データ構造がJSON Web Token (JWT) [JWT] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” July 2013.) であり, JWS署名入力はHMAC SHA-256アルゴリズムにより保護されていることを示している.

  {"typ":"JWT",
   "alg":"HS256"}

以下に示すオクテット列は, JWSヘッダのUTF-8表現を含む:

[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]

これらのオクテット列をBase64 URLエンコードすることで, エンコード済JWSヘッダの値が生成される:

  eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

この例で使用されるJWSペイロードは以下のJSONオブジェクトでUTF-8で表現したオクテット列である. (このペイロードはBase64 URL エンコードされたJSONオブジェクトである必要はなく, 任意のBase64URLエンコードされたオクテット列でもよいことに注意)

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

以下に示すオクテット列は上記のJSONオブジェクトのUTF-8表現であり, これがJWSペイロードである:

[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125]

JWSペイロードをBase64 URLエンコードすることで, エンコード済JWSペイロードの値が生成される (改行は掲載上の都合による):

  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

エンコード済JWSヘッダとエンコード済JWSペイロードをピリオド('.')文字で連結することで, JWS 署名入力値が生成される (改行は掲載上の都合による):

  eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

JWS署名入力のASCII表現が以下に示すオクテット列となる:

[101, 121, 74, 48, 101, 88, 65, 105, 79, 105, 74, 75, 86, 49, 81, 105, 76, 65, 48, 75, 73, 67, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]

HMACは鍵を用いて生成される. この例では次のようなJSON Web Key [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.) フォーマットで表現される対象鍵を用いる (改行は掲載上の都合による):

  {"kty":"oct",
   "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
        aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
  }

JWS署名入力のASCII表現であるオクテット列にこの鍵を用いてHMAC SHA-256アルゴリズムを実行することで, オクテット列が生成される.

[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]

上記のオクテット列をBase64 URLエンコードすることで, エンコード済JWS署名の値が生成される.

  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

ピリオド('.')文字をパーツ間の区切りとしてこれらの値をヘッダ.ペイロード.署名の順番で連結することで, JSON Compact Serialiation形式の完全なJWS表現が生成される. (改行は掲載上の都合による):

  eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

A.1.2.  Decoding

JWSのデコードは, JWSヘッダ, JWSペイロード, JWS署名のオクテット列を生成するためにエンコード済JWSヘッダ, エンコード済JWSペイロード, エンコード済JWS署名のBase64 URLデコードを必要とする. JWSヘッダのUTF-8表現を含むオクテット列がJWSヘッダ文字列にデコードされる.

A.1.3.  Validating

次にデコード結果を検証する. ヘッダ中の alg パラメータが"HS256"であるため, JWS署名に含まれるHMAC SHA-256の値を検証する. 検証に失敗した場合, このJWSは拒否されなければならない (MUST).

初めに, JWSヘッダ文字列が正しいJSONであることを検証する.

HMAC値を検証するために, 正しい鍵を用いてJWS署名入力のASCII表現をHMAC SHA-256アルゴリズムの入力として上記のプロセスを繰りかえし, 出力されたものがJWS署名と一致するかが決定される. もしそれが正確に一致していた場合, HMACの検証は完了する.

A.2.  Example JWS using RSASSA-PKCS-v1_5 SHA-256

A.2.1.  Encoding

この例のJWSヘッダは2つの点で前述の例と異なっている: まず, 異なるアルゴリズムが使われているため, algの値が異なっている. 次に, 例示の都合により, 任意の"typ"パラメータは使用されていない(この違いは用いられるアルゴリズムに関連するものではない). 使用されるJWSヘッダは以下の通り:

  {"alg":"RS256"}

以下のオクテット列はJWSヘッダのUTF-8表現である:

[123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 50, 53, 54, 34, 125]

これらのオクテット列をBase64urlエンコードすることで, エンコード済JWS署名の値が生成される:

  eyJhbGciOiJSUzI1NiJ9

以下の, この例で使用されるJWSペイロードは前述の例と同じである. エンコード済JWSペイロードは同じになるので, 計算はここで繰り返し行わない.

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

エンコード済JWSヘッダとエンコード済JWSペイロードをピリオド('.')文字で連結することで, JWS署名入力値が生成される (改行は掲載上の都合による):

  eyJhbGciOiJSUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

JWS署名入力のASCII表現が以下のオクテット列となる:

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]

この例では次のようなJSON Web Key [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.) フォーマットで表現されるRSA鍵を用いる (改行は掲載上の都合による):

  {"kty":"RSA",
   "n":"ofgWCuLjybRlzo0tZWJjNiuSfb4p4fAkd_wWJcyQoTbji9k0l8W26mPddx
        HmfHQp-Vaw-4qPCJrcS2mJPMEzP1Pt0Bm4d4QlL-yRT-SFd2lZS-pCgNMs
        D1W_YpRPEwOWvG6b32690r2jZ47soMZo9wGzjb_7OMg0LOL-bSf63kpaSH
        SXndS5z5rexMdbBYUsLA9e-KXBdQOS-UTo7WTBEMa2R2CapHg665xsmtdV
        MTBQY4uDZlxvb3qCo5ZwKh9kG4LT6_I5IhlJH7aGhyxXFvUK-DWNmoudF8
        NAco9_h9iaGNj8q2ethFkMLs91kzk2PAcDTW9gb54h4FRWyuXpoQ",
   "e":"AQAB",
   "d":"Eq5xpGnNCivDflJsRQBXHx1hdR1k6Ulwe2JZD50LpXyWPEAeP88vLNO97I
        jlA7_GQ5sLKMgvfTeXZx9SE-7YwVol2NXOoAJe46sui395IW_GO-pWJ1O0
        BkTGoVEn2bKVRUCgu-GjBVaYLU6f3l9kJfFNS3E0QbVdxzubSu3Mkqzjkn
        439X0M_V51gfpRLI9JYanrC4D4qAdGcopV_0ZHHzQlBjudU2QvXt4ehNYT
        CBr6XCLQUShb1juUO1ZdiYoFaFQT5Tw8bGUl_x_jTj3ccPDVZFD9pIuhLh
        BOneufuBiB4cS98l2SR_RQyGWSeWjnczT0QU91p1DhOVRuOopznQ"
  }

RSAの秘密鍵, ハッシュタイプ SHA-256, およびJWS署名入力のASCII表現であるオクテット列が入力としてRSAの署名関数に渡される. デジタル署名の結果はビッグエンディアン整数として表現されるオクテット列である. 以下がこの例である:

[112, 46, 33, 137, 67, 232, 143, 209, 30, 181, 216, 45, 191, 120, 69, 243, 65, 6, 174, 27, 129, 255, 247, 115, 17, 22, 173, 209, 113, 125, 131, 101, 109, 66, 10, 253, 60, 150, 238, 221, 115, 162, 102, 62, 81, 102, 104, 123, 0, 11, 135, 34, 110, 1, 135, 237, 16, 115, 249, 69, 229, 130, 173, 252, 239, 22, 216, 90, 121, 142, 232, 198, 109, 219, 61, 184, 151, 91, 23, 208, 148, 2, 190, 237, 213, 217, 217, 112, 7, 16, 141, 178, 129, 96, 213, 248, 4, 12, 167, 68, 87, 98, 184, 31, 190, 127, 249, 217, 46, 10, 231, 111, 36, 242, 91, 51, 187, 230, 244, 74, 230, 30, 177, 4, 10, 203, 32, 4, 77, 62, 249, 18, 142, 212, 1, 48, 121, 91, 212, 189, 59, 65, 238, 202, 208, 102, 171, 101, 25, 129, 253, 228, 141, 247, 127, 55, 45, 195, 139, 159, 175, 221, 59, 239, 177, 139, 93, 163, 204, 60, 46, 176, 47, 158, 58, 65, 214, 18, 202, 173, 21, 145, 18, 115, 160, 95, 35, 185, 232, 56, 250, 175, 132, 157, 105, 132, 41, 239, 90, 30, 136, 121, 130, 54, 195, 212, 14, 96, 69, 34, 165, 68, 200, 242, 122, 122, 45, 184, 6, 99, 209, 108, 247, 202, 234, 86, 222, 64, 92, 178, 33, 90, 69, 178, 194, 85, 102, 181, 90, 193, 167, 72, 160, 112, 223, 200, 163, 42, 70, 149, 67, 208, 25, 238, 251, 71]

デジタル署名をbase64urlでエンコードすることで以下のエンコード済JWS署名が生成される. (改行は掲載上の都合による):

  cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
  AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
  BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
  0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
  hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
  p0igcN_IoypGlUPQGe77Rw

これらの値をヘッダ.ペイロード.署名の順番で, パーツの間をピリオド('.')で連結することでJWS Compact Serializationを用いた完全なJWS表現が生成される. (改行は掲載上の都合による):

  eyJhbGciOiJSUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZmh7
  AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjbKBYNX4
  BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHlb1L07Qe7K
  0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZESc6BfI7noOPqv
  hJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AXLIhWkWywlVmtVrB
  p0igcN_IoypGlUPQGe77Rw

A.2.2.  Decoding

JWSのデコードはJWSヘッダ, JWSペイロード, およびJWS署名のオクテット列を生成するために, エンコード済JWSヘッダ, エンコード済JWSペイロード, エンコード済JWS署名をBase64urlデコードする必要がある. JWSヘッダのUTF-8表現を含むオクテット列はJWSヘッダ文字列にデコードされる.

A.2.3.  Validating

ヘッダ中のalgパラメータが"RS256"であるため, JWS署名に含まれるRSASSA-PKCS-v1_5 SHA-256のデジタル署名を検証する. いずれかの検証ステップに失敗した場合, JWSは拒否されなければならない.

まず, JWSヘッダ文字列が正しいJSONであるか検証する.

JWS署名の検証は直前の例と少し異なる. まず, デジタル署名 Sを生成してチェックするためにエンコード済JWS署名をbase64urlデコードする. (n, e), S, 及びJWS署名入力のASCII表現であるオクテット列をSHA-256ハッシュ関数を使うよう設定されたRSASSA-PKCS-v1_5 署名検証器に渡す.

A.3.  Example JWS using ECDSA P-256 SHA-256

A.3.1.  Encoding

異なるアルゴリズムが利用されているため, この例のJWSヘッダは前の例と異なる. 利用されるJWSヘッダ:

  {"alg":"ES256"}

以下に示すオクテット列はJWSヘッダのUTF-8表現である:

[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 50, 53, 54, 34, 125]

これらのオクテット列をBase64 URLエンコードするとこのようなエンコード済JWSヘッダの値が生成される.

  eyJhbGciOiJFUzI1NiJ9

以下に示す, この例で用いられるJWSペイロードは前の例のものと同一である. したがって, エンコード済JWSペイロードもまた同一であるため, ここではその計算を繰りかえさない.

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

エンコード済JWSヘッダとエンコード済JWSペイロードをピリオド('.')文字で連結することで, JWS 署名入力値が生成される (改行は掲載上の都合による):

  eyJhbGciOiJFUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

JWS署名入力のASCII表現が以下に示すオクテット列となる:

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 73, 49, 78, 105, 74, 57, 46, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81]

この例は以下のJSON Web Key [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.) フォーマットで表現された楕円曲線鍵を用いる:

  {"kty":"EC",
   "crv":"P-256",
   "x":"f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
   "y":"x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
   "d":"jpsQnnGQmL-YBIffH1136cspYG6-0iY7X1fCE9-E9LI"
  }

ECDSA秘密部 d, 曲線タイプ P-521, ハッシュタイプ SHA-512, およびJWS署名入力のASCII表現のオクテット列が, 入力としてECDSA署名関数に渡される. デジタル署名結果はEC点 (R, S)であり, ここで R および S は符号なし整数である. この例では, R と S の値をビッグエンディアン整数として表現するオクテット列となる:

S配列をR配列の末尾に連結し, Base64 URLエンコーディングを施すことで, 以下のエンコード済JWS署名が生成される (改行は掲載上の都合による):

  DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
  pmWQxfKTUJqPP3-Kg6NU1Q

ピリオド('.')文字をパーツ間の区切りとしてこれらの値をヘッダ.ペイロード.署名の順番で連結することで, JSON Compact Serialiation形式の完全なJWS表現が生成される. (改行は掲載上の都合による):

  eyJhbGciOiJFUzI1NiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSA
  pmWQxfKTUJqPP3-Kg6NU1Q

A.3.2.  Decoding

JWSのデコードはJWSヘッダ, JWSペイロード, およびJWS署名のオクテット列を生成するために, エンコード済JWSヘッダ, エンコード済JWSペイロード, エンコード済JWS署名をBase64urlデコードする必要がある. JWSヘッダのUTF-8表現を含むオクテット列はJWSヘッダ文字列にデコードされる.

A.3.3.  Validating

ヘッダ中の alg パラメータが"ES256"であるため, JWS署名に含まれるECDSA P-256 SHA-256デジタル署名を検証する. もし検証に失敗した場合, このJWSは拒否されなければならない (MUST).

まず, JWSヘッダ文字列が正しいJSONであるか検証する.

JWS署名の検証は最初の例と少し異なる. 初めにエンコード済JWS署名を前の例のようにBase64 URLデコード, それから長さ64のオクテット列を長さ32の2つのオクテット列に分割し, はじめがR, 次がSとなる. そして, (x, y), (R, S)およびJWS署名入力のASCII表現であるオクテットを, P-256 曲線とSHA-256ハッシュ関数が設定されたECDSA署名検証器に入力として与える.

JSON Web Algorithms (JWA) [JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.) 仕様の3.4節で説明されているように, ECDSAのKの値の利用は, HMACの妥当性確認と同じ方法でデジタル署名の妥当性を検証することができないことを意味する. その代わり, 実装はデジタル署名を検証するためにECDSA検証機を利用しなければならない (MUST).

A.4.  Example JWS using ECDSA P-521 SHA-512

A.4.1.  Encoding

この例のJWSヘッダは直前の例と異なり, ECDSA曲線とハッシュ関数を使っている. 使用されるJWSヘッダは以下の通り:

  {"alg":"ES512"}

以下のオクテット列はJWSヘッダのUTF-8表現である:

[123, 34, 97, 108, 103, 34, 58, 34, 69, 83, 53, 49, 50, 34, 125]

これらのオクテットをbase64urlエンコードすると, 以下のエンコード済JWSヘッダ値を得る:

  eyJhbGciOiJFUzUxMiJ9

この例のJWSペイロードは, ASCII文字列の "Payload" である. この文字列の表現は以下のオクテット列である:

[80, 97, 121, 108, 111, 97, 100]

これらのオクテットをbase64urlエンコードすると, 以下のエンコード済JWSペイロード値を得る:

  UGF5bG9hZA

エンコード済JWSヘッダ, ピリオド文字('.'), エンコード済JWSペイロードを連結することにより, 以下のJWS署名入力値を得る:

  eyJhbGciOiJFUzUxMiJ9.UGF5bG9hZA

このJWS署名入力値のASCII表現は以下のオクテット列である:

[101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 70, 85, 122, 85, 120, 77, 105, 74, 57, 46, 85, 71, 70, 53, 98, 71, 57, 104, 90, 65]

この例では, 以下のJSON Web Key [JWK] (Jones, M., “JSON Web Key (JWK),” July 2013.)フォーマットで表現された楕円曲線を使う(改行は掲載上の都合による):

  {"kty":"EC",
   "crv":"P-521",
   "x":"AekpBQ8ST8a8VcfVOTNl353vSrDCLLJXmPk06wTjxrrjcBpXp5EOnYG_
        NjFZ6OvLFV1jSfS9tsz4qUxcWceqwQGk",
   "y":"ADSmRA43Z1DSNx_RvcLI87cdL07l6jQyyBXMoxVg_l2Th-x3S1WDhjDl
        y79ajL4Kkd0AZMaZmh9ubmf63e3kyMj2",
   "d":"AY5pb7A0UFiB3RELSD64fTLOSV_jazdF7fLYyuTw8lOfRhWg6Y6rUrPA
        xerEzgdRhajnu0ferB0d53vM9mE15j2C"
  }

ECDSA秘密部 d , 曲線タイプ P-521, ハッシュタイプ SHA-512, およびJWS署名入力のASCII表現オクテット列が, 入力としてECDSA署名関数に渡される. デジタル署名結果はEC点 (R, S)であり, ここで R および S は符号なし整数である. この例では, R と S の値をビッグエンディアン整数として表現するオクテット列となる:

S配列をR配列の末尾に連結し base64urlエンコーディングを施すとと以下のエンコード済JWS署名を得る(改行は掲載上の都合による):

  AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
  wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
  EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn

これらの値を ヘッダ, ペイロード, 署名 の順でピリオド文字 ('.') を区切りとして連結することで, 以下のJWS Compact Serialization形式を用いた完全なJWS表現を得る(改行は掲載上の都合による):

  eyJhbGciOiJFUzUxMiJ9
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .
  AdwMgeerwtHoh-l192l60hp9wAHZFVJbLfD_UxMi70cwnZOYaRI1bKPWROc-mZZq
  wqT2SI-KGDKB34XO0aw_7XdtAG8GaSwFKdCAPZgoXD2YBJZCPEX3xKpRwcdOO8Kp
  EHwJjyqOgzDO7iKvU8vcnwNrmxYbSW9ERBXukOXolLzeO_Jn

A.4.2.  Decoding

JWSのデコードは, エンコード済JWSヘッダ, エンコード済JWSペイロード, エンコード済JWS署名をbase64urlデコードし, JWSヘッダ, JWSペイロード, およびJWS署名のオクテット列を得る必要がある. JWSヘッダのUTF-8表現を含むオクテット列をデコードし, JWSヘッダ文字列を得る.

A.4.3.  Validating

ヘッダのalgパラメータが "ES512" であることから, JWS署名に格納されている ECDSA P-521 SHA-512 デジタル署名を検証する. いずれかの検証ステップに失敗した場合は, JWSは拒否されなければならない (MUST).

最初に, JWSヘッダ文字列が正しいJSONであるか検証する.

JWS署名の検証は直前の例と同様である. まず, 直前の例と同じく, エンコード済JWS署名をbase64urlデコードする. 次に132オクテットある列を2つの長さ66オクテットの列に分割する必要がある. 最初がRであり次がSである. そして, (x, y), (R, S)およびJWS署名入力のASCII表現オクテットを, ECDSA署名検証器に入力として与える. この検証器はP-521曲線およびSHA-512ハッシュ関数として設定されたものである.

JSON Web Algorithms (JWA)[JWA] (Jones, M., “JSON Web Algorithms (JWA),” July 2013.)仕様の3.4節で説明されているとおり, ECDSAにおいてK値を用いるということは, HMACの正当性検証と同じ方法ではデジタル署名の正しさを検証できないことを意味する. 実装はECDSA検証器を使ってデジタル署名を検証しなければならない(MUST).

A.5.  Example Plaintext JWS

以下のJWSヘッダの例はエンコード済みのオブジェクトが平文のJWSである例を示している:

  {"alg":"none"}

このJWSヘッダのUTF-8表現のオクテット列をbase64urlエンコーディングすると以下のエンコード済みJWSヘッダが生成される:

  eyJhbGciOiJub25lIn0

以下に示されるこの例の中で使われているJWSペイロードは, 前の例のものと同じである. それゆえエンコード済みJWSペイロードは同じであるため, ここでは再度算出は行わない.

  {"iss":"joe",
   "exp":1300819380,
   "http://example.com/is_root":true}

エンコード済みJWS署名は空文字となる.

ヘッダ.ペイロードPayload.署名の順でそれぞれの部分をピリオド('.')で連結すると完全なJWSが生成される(改行は掲載上の都合による):

  eyJhbGciOiJub25lIn0
  .
  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
  .

A.6.  Example JWS Using JWS JSON Serialization

このセクションはJWS JSON Serializationを利用した場合の例を含む. この例では同一のペイロードについて複数の電子署名, および/またはMAC値を伝送できることを示す.

この例で利用されているエンコード済みJWSペイロードは Appendix A.2 (Example JWS using RSASSA-PKCS-v1_5 SHA-256)と Appendix A.3 (Example JWS using ECDSA P-256 SHA-256)の例で利用されているものと同じである(改行は掲載上の都合による):

  eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
  cGxlLmNvbS9pc19yb290Ijp0cnVlfQ

この例では二つの電子署名が使用される: 1つ目ではRSASSA-PKCS-v1_5 SHA-256を2つ目ではECDSA P-256 SHA-256を利用する. 1つ目のJWSプロテクトヘッダと鍵は Appendix A.2 (Example JWS using RSASSA-PKCS-v1_5 SHA-256)のものと同じになり, 結果として得られるJWS署名が同じ値になる; それゆえここでは再度算出は行わない. 2つ目のJWSプロテクトヘッダと鍵は Appendix A.3 (Example JWS using ECDSA P-256 SHA-256)のものと同じになり, 結果として得られるJWS署名が同じ値になる; それゆえここでは再度算出は行わない.

A.6.1.  JWS Per-Signature Protected Headers

1つ目の署名に利用されるJWSプロテクトヘッダ値は以下となる:

  {"alg":"RS256"}

これらのオクテット列をbase64urlエンコーディングすると以下のエンコード済みJWSヘッダ値が生成される:

  eyJhbGciOiJSUzI1NiJ9

2つ目の署名に利用されるJWSプロテクトヘッダ値は以下となる:

  {"alg":"ES256"}

これらのオクテット列をbase64urlエンコーディングすると以下のエンコード済みJWSヘッダ値が生成される:

  eyJhbGciOiJFUzI1NiJ9

A.6.2.  JWS Per-Signature Unprotected Headers

Key ID の値は, 署名毎のヘッダパラメータを利用して両方の鍵に対して与えられる. これらのKey IDを表す2つの値は以下となる:

  {"kid":"2010-12-29"}

と:

  {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}

A.6.3.  Complete JWS Header Values

与えられたプロテクトヘッダとプロテクトされていないヘッダの値を合わせて, 1つ目の署名と2つ目の署名それぞれに利用されるJWSヘッダ値は以下のようになる:

  {"alg":"RS256",
   "kid":"2010-12-29"}

と:

  {"alg":"ES256",
   "kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"}

A.6.4.  Complete JWS JSON Serialization Representation

これらの値の完全なJSON Web Signature JSON Serializationは以下のようになる(改行は掲載上の都合による):

  {"payload":
    "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGF
     tcGxlLmNvbS9pc19yb290Ijp0cnVlfQ",
   "signatures":[
    {"protected":"eyJhbGciOiJSUzI1NiJ9",
     "header":
      {"kid":"2010-12-29"},
     "signature":
      "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5RZ
       mh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcAcQjb
       KBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSjtQBMHl
       b1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHWEsqtFZES
       c6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9Fs98rqVt5AX
       LIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"},
    {"protected":"eyJhbGciOiJFUzI1NiJ9",
     "header":
      {"kid":"e9bc097a-ce51-4036-9562-d2ade882db0d"},
     "signature":
      "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS
       lSApmWQxfKTUJqPP3-Kg6NU1Q"}]
  }

Appendix B.  "x5c" (X.509 Certificate Chain) Example

以下の JSON array は, Section 4.1.6 ("x5c" (X.509 Certificate Chain) Header Parameter) にあるように, x5c ヘッダパラメータとして指定される証明書チェーンの例である. ここでは Base64URL エンコードではなく Base64 エンコードが用いられるため, 空白と改行が許可されていることに注意すること.

  ["MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
    xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
    8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
    TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
    CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
    keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
    RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
    nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ
    KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt
    wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV
    Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL
    GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo
    7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW
    JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw
    EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH
    SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA
    MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR
    keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2
    RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH
    SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
    b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE
    BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI
    UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL
    5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9
    p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx
    uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ
    EjYx8WnM25sgVjOuH0aBsXBTWVU+4=",
   "MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z
    hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE
    luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb
    24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x
    IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY
    yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS
    BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM
    iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
    ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC
    APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux
    6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO
    tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo
    riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ
    Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
    4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
    zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
    Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
    pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
    FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
    QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
    F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
    6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
    BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
    mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
    BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
    Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
    QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
    09VZw==",
   "MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
    0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
    AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
    G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
    hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
    5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
    V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
    XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
    ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
    AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
    vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
    N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
    P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
    AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
    C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
    j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"]

Appendix C.  Notes on implementing base64url encoding without padding

ここではパディング無し Base64URL エンコード/デコードを, 標準のパディング付き Base64 エンコード/デコードを元に実装する方法について述べる.

具体例として, 以下に C# での実装例を挙げる. 他の言語でも実装方法は同様である.

  static string base64urlencode(byte [] arg)
  {
    string s = Convert.ToBase64String(arg); // Regular base64 encoder
    s = s.Split('=')[0]; // Remove any trailing '='s
    s = s.Replace('+', '-'); // 62nd char of encoding
    s = s.Replace('/', '_'); // 63rd char of encoding
    return s;
  }

  static byte [] base64urldecode(string arg)
  {
    string s = arg;
    s = s.Replace('-', '+'); // 62nd char of encoding
    s = s.Replace('_', '/'); // 63rd char of encoding
    switch (s.Length % 4) // Pad with trailing '='s
    {
      case 0: break; // No pad chars in this case
      case 2: s += "=="; break; // Two pad chars
      case 3: s += "="; break; // One pad char
      default: throw new System.Exception(
        "Illegal base64url string!");
    }
    return Convert.FromBase64String(s); // Standard base64 decoder
  }

上記コードの通り, パディング無しBase64URL エンコード文字列をパディング付きに変換する為に付与すべきパディング "=" の文字数は, エンコード文字列長から求められる. "length mod 4 = 0" の時, パディングは必要なく, "length mod 4 = 2" の時は2つの "=" を追加, "length mod 4 = 3" の時は1つ, "length mod 4 = 1" の時はその入力が不正である.

エンコードあり/なしの値の対応例を以下に示す. 以下のオクテット列はその下の文字列にエンコードされ, デコードすると元のオクテット列が導出される.

3 236 255 224 193

A-z_4ME

Appendix D.  Negative Test Case for "crit" Header Parameter

適切な実装は, 理解不能もしくは処理不能なクリティカル拡張を含む入力を拒否しなければならない. 以下に示す JWS は, http://example.invalid/UNDEFINED という理解不能な拡張ヘッダパラメータを利用しているため, いかなる実装もこの JWS を拒否しなければならない. http://example.invalid/UNDEFINED に変わるなんらかの理解不能なヘッダパラメータが含まれる場合にも, 同様に実装はそれらを拒否しなければならない.

JWS ヘッダ

  {"alg":"none",
   "crit":["http://example.invalid/UNDEFINED"],
   "http://example.invalid/UNDEFINED":true
  }

JWS 全体 (改行は表示の都合による)

  eyJhbGciOiJub25lIiwNCiAiY3JpdCI6WyJodHRwOi8vZXhhbXBsZS5jb20vVU5ERU
  ZJTkVEIl0sDQogImh0dHA6Ly9leGFtcGxlLmNvbS9VTkRFRklORUQiOnRydWUNCn0.
  RkFJTA.

Appendix E.  Acknowledgements

Solutions for signing JSON content were previously explored by Magic Signatures (Panzer (editor), J., Laurie, B., and D. Balfanz, “Magic Signatures,” January 2011.) [MagicSignatures], JSON Simple Sign (Bradley, J. and N. Sakimura (editor), “JSON Simple Sign,” September 2010.) [JSS], and Canvas Applications (Facebook, “Canvas Applications,” 2010.) [CanvasApp], all of which influenced this draft.

Thanks to Axel Nennker for his early implementation and feedback on the JWS and JWE specifications.

This specification is the work of the JOSE Working Group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:

Dirk Balfanz, Richard Barnes, Brian Campbell, Breno de Medeiros, Dick Hardt, Joe Hildebrand, Jeff Hodges, Edmund Jay, Yaron Y. Goland, Ben Laurie, James Manger, Matt Miller, Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig, and Sean Turner.

Jim Schaad and Karen O'Donoghue chaired the JOSE working group and Sean Turner and Stephen Farrell served as Security area directors during the creation of this specification.

Appendix F.  Document History

[[ to be removed by the RFC editor before publication as an RFC ]]

-14

• Stated that the signature parameter is to be omitted in the JWS JSON Serialization when its value would be empty (which is only the case for a Plaintext JWS).

-13

• Made all header parameter values be per-signature/MAC, addressing issue #24.

-12

• Clarified that the typ and cty header parameters are used in an application-specific manner and have no effect upon the JWS processing.
• Replaced the MIME types application/jws+json and application/jws with application/jose+json and application/jose.
• Stated that recipients MUST either reject JWSs with duplicate Header Parameter Names or use a JSON parser that returns only the lexically last duplicate member name.
• Added a Serializations section with parallel treatment of the JWS Compact Serialization and the JWS JSON Serialization and also moved the former Implementation Considerations content there.

-11

• Added Key Identification section.
• For the JWS JSON Serialization, enable header parameter values to be specified in any of three parameters: the protected member that is integrity protected and shared among all recipients, the unprotected member that is not integrity protected and shared among all recipients, and the header member that is not integrity protected and specific to a particular recipient. (This does not affect the JWS Compact Serialization, in which all header parameter values are in a single integrity protected JWE Header value.)
• Removed suggested compact serialization for multiple digital signatures and/or MACs.
• Changed the MIME type name application/jws-js to application/jws+json, addressing issue #22.
• Tightened the description of the crit (critical) header parameter.
• Added a negative test case for the crit header parameter

-10

• Added an appendix suggesting a possible compact serialization for JWSs with multiple digital signatures and/or MACs.

-09

• Added JWS JSON Serialization, as specified by draft-jones-jose-jws-json-serialization-04.
• Registered application/jws-js MIME type and JWS-JS typ header parameter value.
• Defined that the default action for header parameters that are not understood is to ignore them unless specifically designated as "MUST be understood" or included in the new crit (critical) header parameter list. This addressed issue #6.
• Changed term "JWS Secured Input" to "JWS Signing Input".
• Changed from using the term "byte" to "octet" when referring to 8 bit values.
• Changed member name from recipients to signatures in the JWS JSON Serialization.
• Added complete values using the JWS Compact Serialization for all examples.

-08

• Applied editorial improvements suggested by Jeff Hodges and Hannes Tschofenig. Many of these simplified the terminology used.
• Clarified statements of the form "This header parameter is OPTIONAL" to "Use of this header parameter is OPTIONAL".
• Added a Header Parameter Usage Location(s) field to the IANA JSON Web Signature and Encryption Header Parameters registry.
• Added seriesInfo information to Internet Draft references.

-07

• Updated references.

-06

• Changed x5c (X.509 Certificate Chain) representation from being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the certificate chain.
• Applied changes made by the RFC Editor to RFC 6749's registry language to this specification.

-05

• Added statement that "StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied".
• Indented artwork elements to better distinguish them from the body text.

-04

• Completed JSON Security Considerations section, including considerations about rejecting input with duplicate member names.
• Completed security considerations on the use of a SHA-1 hash when computing x5t (x.509 certificate thumbprint) values.
• Refer to the registries as the primary sources of defined values and then secondarily reference the sections defining the initial contents of the registries.
• Normatively reference XML DSIG 2.0 (Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Hirsch, F., Cantor, S., and T. Roessler, “XML Signature Syntax and Processing Version 2.0,” January 2012.) [W3C.CR‑xmldsig‑core2‑20120124] for its security considerations.
• Added this language to Registration Templates: "This name is case sensitive. Names that match other registered names in a case insensitive manner SHOULD NOT be accepted."
• Reference draft-jones-jose-jws-json-serialization instead of draft-jones-json-web-signature-json-serialization.
• Described additional open issues.
• Applied editorial suggestions.

-03

• Added the cty (content type) header parameter for declaring type information about the secured content, as opposed to the typ (type) header parameter, which declares type information about this object.
• Added "Collision Resistant Namespace" to the terminology section.
• Reference ITU.X690.1994 for DER encoding.
• Added an example JWS using ECDSA P-521 SHA-512. This has particular illustrative value because of the use of the 521 bit integers in the key and signature values. This is also an example in which the payload is not a base64url encoded JSON object.
• Added an example x5c value.
• No longer say "the UTF-8 representation of the JWS Secured Input (which is the same as the ASCII representation)". Just call it "the ASCII representation of the JWS Secured Input".
• Added Registration Template sections for defined registries.
• Added Registry Contents sections to populate registry values.
• Changed name of the JSON Web Signature and Encryption "typ" Values registry to be the JSON Web Signature and Encryption Type Values registry, since it is used for more than just values of the typ parameter.
• Moved registries JSON Web Signature and Encryption Header Parameters and JSON Web Signature and Encryption Type Values to the JWS specification.
• Numerous editorial improvements.

-02

• Clarified that it is an error when a kid value is included and no matching key is found.
• Removed assumption that kid (key ID) can only refer to an asymmetric key.
• Clarified that JWSs with duplicate Header Parameter Names MUST be rejected.
• Clarified the relationship between typ header parameter values and MIME types.
• Registered application/jws MIME type and "JWS" typ header parameter value.
• Simplified JWK terminology to get replace the "JWK Key Object" and "JWK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusion between single keys and sets of keys. As part of this change, the Header Parameter Name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
• Added suggestion on defining additional header parameters such as x5t#S256 in the future for certificate thumbprints using hash algorithms other than SHA-1.
• Specify RFC 2818 server identity validation, rather than RFC 6125 (paralleling the same decision in the OAuth specs).
• Generalized language to refer to Message Authentication Codes (MACs) rather than Hash-based Message Authentication Codes (HMACs) unless in a context specific to HMAC algorithms.
• Reformatted to give each header parameter its own section heading.

-01

• Moved definition of Plaintext JWSs (using "alg":"none") here from the JWT specification since this functionality is likely to be useful in more contexts that just for JWTs.
• Added jpk and x5c header parameters for including JWK public keys and X.509 certificate chains directly in the header.
• Clarified that this specification is defining the JWS Compact Serialization. Referenced the new JWS-JS spec, which defines the JWS JSON Serialization.
• Added text "New header parameters should be introduced sparingly since an implementation that does not understand a parameter MUST reject the JWS".
• Clarified that the order of the creation and validation steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
• Changed "no canonicalization is performed" to "no canonicalization need be performed".
• Corrected the Magic Signatures reference.
• Made other editorial improvements suggested by JOSE working group participants.

-00

• Created the initial IETF draft based upon draft-jones-json-web-signature-04 with no normative changes.
• Changed terminology to no longer call both digital signatures and HMACs "signatures".

Appendix G.  翻訳者

本仕様の翻訳は, OpenIDファウンデーションジャパン (OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン,” .) [oidfj] 翻訳・教育ワーキンググループ (OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ,” .) [oidfj‑trans]を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー (OpenIDファウンデーションジャパン, “Githubレポジトリー,” .) [oidfj‑github] にご連絡ください.

• Kaoru Maeda
• Ryo Ito (mixi, Inc.)
• Yutaka Obuchi (Hitachi Solutions)
• Yuya Ito

Authors' Addresses