Draft: OAuth 2.0 Multiple Response Type Encoding Practices - draft 05

「OAuth 2.0 Multiple Response Type Encoding Practices - draft 05」も和訳してみました。原文は http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html です。

Draft	B. de Medeiros, Ed.
	M. Scurtescu
	Google
	P. Tarjan
	Facebook
	May 25, 2012

OAuth 2.0 Multiple Response Type Encoding Practices - draft 05

概要

当仕様は、応答タイプパラメータに空白文字を含むOAuth 2.0の認可要求に対する応答の適切なエンコーディングについてのガイダンスを提供することを目的としている。

当仕様は、OAuthパラメータレジストリの規定に従い、いくつかの固有の新たな応答タイプに関する登録文書としての役目も果たす。

1. はじめに
1.1. 要求記法および規則
1.2. 用語
2. 多値応答タイプのエンコーディング
3. IDトークン応答タイプ
4. 無応答タイプ
5. いくつかの多値応答タイプ組合せの登録
6. IANAに関する考慮事項
7. 規定文献
Appendix A. 謝辞
Appendix B. 通知
Appendix C. 文書履歴
§ 著者のアドレス

TOC

1. はじめに

TOC

1.1. 要求記法および規則

本文書で用いられる各キーワード「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.) で述べられている通りに解釈されるべきものである。

本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (MUST NOT)。

TOC

1.2. 用語

当仕様は、OAuth 2.0 (Hammer, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2012.) [OAuth2.0]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語を用いる。また当仕様では、以下の用語についても定義する。

クライアントおよびサーバ (Client and Server)

伝統的なクライアントサーバ認証モデルでは、クライアントは、リソース所有者のクレデンシャルを用いてサーバで認証を行い、サーバ上のアクセス制限のかけられたリソース（保護リソース）を要求する。

認可エンドポイント (Authorization Endpoint)

サーバによって維持されているウェブリソースであり、ユーザエージェントによるリダイレクションを介して、リソース所有者から認可（グラント）を取得するために用いられる。

応答タイプ (Response Type)

クライアントは、パラメータresponse_typeを用いて、認可サーバに希望する認可処理フローを通知する。

認可エンドポイント応答タイプレジストリ (Authorization Endpoint Response Type Registry)

新規のresponse_typeパラメータの登録のためにOAuth 2.0仕様で確立されたプロセス。

多値応答タイプ (Multiple-Valued Response Types)

OAuth 2.0仕様では、スペース区切りのresponse_type値の登録を許可する。応答タイプに一つ以上の空白文字 (%20) が含まれている場合、値のスペース区切りのリストとして比較される。また、それらの値の順序は重要ではない。

TOC

2. 多値応答タイプのエンコーディング

部分的にはクエリストリング、部分的にはフラグメントでエンコードしたデータを返すようにサーバに要求する値をresponse_typeに含める場合のガイダンスについては、当仕様では提供しない。

多値応答タイプが定義された場合、以下のエンコーディングルールを発行される応答に適用することを推奨する (RECOMMENDED)。

クエリストリングで全体をエンコードしたデータを返すように要求する値だけがresponse_typeに含まれている場合、この多値response_typeに対する応答で返されるデータは、クエリストリングで全体をエンコードしなければならない (MUST)。この推奨は、成功とエラー応答の両方に適用される。

フラグメントで全体をエンコードしたデータを返すように要求する値が一つでもresponse_typeに含まれている場合、この多値response_typeに対する応答で返されるデータは、フラグメントで全体をエンコードしなければならない (MUST)。この推奨は、成功とエラー応答の両方に適用される。

論拠: response_type値にフラグメントエンコードが必要な部分を含む場合、ユーザエージェントクライアントは応答の処理の完了に関与しなければならない。新たなクエリパラメータがクライアントURIに追加された場合、ユーザエージェントベースのクライアントコンポーネントの操作の不連続性を引き起こす、クライアントURIの再取得をユーザエージェントに引き起こすだろう。フラグメントエンコーディングのみが使用された場合、ユーザエージェントは、クライアントコンポーネントを単純に再活性化するだけですむだろう。このクライアントコンポーネントは、フラグメントを処理し、例えばXmlHttpRequestを介するなどで、必要に応じてクライアントホストに任意のパラメータを伝達することができる。したがって、全体をフラグメントエンコーディングすることは、応答の処理の低遅延化に繋がる。

TOC

3. IDトークン応答タイプ

当節では、OAuth 2.0の8.4節の規定に従い、新たな応答タイプ id_token を登録する。id_tokenの用途は、サーバによって把握されたリソース所有者のアイデンティティのアサーションを提供しなければならない (MUST) ことである。アサーションは、例えば要求クライアントのような、ターゲットとする聴衆を指定しなければならない (MUST)。しかし、アサーションの具体的な意味と検証方法については当文書では規定しない。

id_token

OAuth 2.0認可要求のresponse_typeパラメータで指定された場合、成功応答の応答URIのフラグメント内にエンコードされたパラメータid_tokenが含まれるべきである。

フラグメント内でid_tokenを返すことは、通信中にid_tokenが漏洩する可能性を減少させ、ユーザ（リソース所有者）のプライバシーに関連するリスクを低減させる。

TOC

4. 無応答タイプ

当節では、OAuth 2.0の8.4節の規定に従い、応答タイプ none を登録する。ある当事者が、サーバに対しクライアントの代理で保護リソースへのアクセス付与の登録をするが、この時点ではクライアントに返されるアクセスクレデンシャルは要求しないというユースケースを可能とすることを目的としている。クライアントが最終的にアクセスクレデンシャルを取得する手段については、ここでは規定しない。

ユーザが、マーケットからのアプリケーションの購入と、アプリケーションのインストールの認可と、アプリケーションの保護リソースへのアクセスの許可を、一回のステップで行いたいというシナリオがある。しかし、ユーザはその時点で（まだアクティブになっていない）アプリケーションと対話できないため、認可のステップと同時にアクセスクレデンシャルを返すことは適切ではない。

none

OAuth 2.0認可要求のresponse_typeパラメータで指定された場合、認可サーバは、許可要求の成功応答でOAuth 2.0のcodeもtokenも返すべきではない (SHOULD NOT)。redirect_uriが指定された場合、ユーザエージェントは、アクセスの許可または拒否の後にそこへリダイレクトされるべきである (SHOULD)。要求はstateパラメータを含むかもしれない (MAY)。その場合、サーバは成功応答を発行する際に、redirect_uriにその値をそのまま追加しなければならない (MUST)。redirect_uriに追加されるあらゆるパラメータは、クエリエンコードされるべきである。これは、成功応答とエラー応答の両方に適用される。

応答タイプnoneは他の応答タイプと組み合わせるべきではない (SHOULD NOT)。

TOC

5. いくつかの多値応答タイプ組合せの登録

当節では、各々個別に登録された応答タイプである値codeとtokenとid_tokenの組み合わせを登録する。

code token

response_typeパラメータの値として指定された場合、成功応答にはOAuth 2.0仕様で定義されている認可コードとアクセストークンの両方が含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。

code id_token

response_typeパラメータの値として指定された場合、成功応答には認可コードとIDトークンの両方が含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。

id_token token

response_typeパラメータの値として指定された場合、成功応答にはIDトークンとアクセストークンの両方が含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。

code id_token token

response_typeパラメータの値として指定された場合、成功応答には認可コードとIDトークンとアクセストークンが含まれなければならない (MUST)。成功応答、エラー応答共に、フラグメントエンコーディングされるべきである (SHOULD)。

ユーザエージェントによって発行／受信される、要求／応答の参考例:

GET https://server.example.com/authorize?
response_type=token%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&state=af0ifjsldkj HTTP/1.1

HTTP/1.1 302 Found
Location: https://client.example.org/cb#
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&expires_in=3600
&state=af0ifjsldkj

TOC

6. IANAに関する考慮事項

この文書ではIANAへの要求はない。

TOC

7. 規定文献

[OAuth2.0]	Hammer, E., Ed., Recordon, D., and D. Hardt, “OAuth 2.0 Authorization Protocol,” May 2012.
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).

TOC

Appendix A.謝辞

The OpenID Community would like to thank the following people for the work they've done in the drafting and editing of this specification.

Naveen Agarwal (naa@google.com), Google

John Bradley (ve7jtb@ve7jtb.com), Ping Identity

Michael B. Jones (mbj@microsoft.com), Microsoft

Breno de Medeiros (breno@google.com), Google

Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.

David Recordon (dr@fb.com), Facebook

Marius Scurtescu (mscurtescu@google.com), Google

Paul Tarjan (pt@fb.com), Facebook

TOC

Appendix B. 通知

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

TOC

Appendix C. 文書履歴

[[ To be removed from the final specification ]]

-05

Changed client.example.com to client.example.org, per issue #251

-04

Updated Notices

-03

Use same section number structure as the OpenID Connect specs

-02

Editorial corrections

-01

Initial draft

TOC

著者アドレス

	Breno (editor)
	Google, Inc.
Email:	breno@google.com

	Marius
	Google, Inc.
Email:	mscurtescu@google.com

	Paul
	Facebook
Email:	pt@fb.com

sat's memo

2012年8月21日火曜日