RFC7235-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 7235 — HTTP/1.1: Authentication （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">
<script src="common0.js"></script>
<script src="RFC723X.js"></script>
<script src="common1.js" async></script>

<script type="text/plain" id="_source_data">


●●options

spec_title:RFC 7235 — HTTP/1.1: Authentication
trans_update:2016-07-26
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc7235.html
spec_status:IETFPR
no_original_dfn:true
abbr_url:7235
trans_1st_pub:2014-12-07

●●mdn_urls
header.authorization:HTTP/Headers/Authorization
header.proxy-authorization:HTTP/Headers/Proxy-Authorization
header.www-authenticate:HTTP/Headers/WWW-Authenticate
header.proxy-authenticate:HTTP/Headers/Proxy-Authenticate

status.401:HTTP/Status/401
status.407:HTTP/Status/407

●●link_map

qdir.no-store:~7234#cache-request-directive.no-store
sdir.private:~7234#cache-response-directive.private

base64:~4648#section-4
base64url:~4648#section-5
base32:~4648#section-7
base16:~4648#section-8
	~realm:#realm
c.realm:#realm
var.名前:#auth-param-name
var.値:#auth-param-value

正準的~root~URI:#canonical-root-URI
認証~scheme:#authentication-scheme
認証~parameter:#authentication-parameter
保護~空間:#protection-space
~challenge:#challenge


●●section_map


1:introduction
1.1:conformance
1.2:notation
2:access.authentication.framework
2.1:challenge.and.response
2.2:protection.space
3:status.code.definitions
3.1:status.401
3.2:status.407
4:header.field.definitions
4.1:header.www-authenticate
4.2:header.authorization
4.3:header.proxy-authenticate
4.4:header.proxy-authorization
5:IANA.considerations
5.1:authentication.scheme.registry
5.1.1:authentication.scheme.registry.procedure
5.1.2:considerations.for.new.authentication.schemes
5.2:status.code.registration
5.3:header.field.registration
6:security.considerations
6.1:confidentiality.of.credentials
6.2:auth.credentials.and.idle.clients
6.3:protection.spaces
7:acks
8:rfc.references
A:changes.from.rfc.2616
B:imported.abnf
C:collected.abnf


●●words_table1

●●words_table

root::::ルート
	realm:
alphabet::::アルファベット
放置:inactivity:~
管轄:administrative domain:~
請求:demand:~
協力的:cooperative:~
logout::::ログアウト
commit::::承諾
	必要とされてはいないが通例的には:usually, but not necessarily
獲得-:gain:~
罠:pitfall:落とし穴
反射攻撃:replay attack::~
論題:topic:~
採取-:harvest:~
延長-:extend:~
時事的:topical:~
事実調査:research:~
制限時間:timeout::~
企業:corporate:~

●●
要請-中にある:being requested
更には，:furthermore
必要十分でない:inadequate
該当する:pertain
適宜:as appropriate
非~予約-済み:unreserved
広く~supportされた:well-supported
長年にわたり:for a long time
束縛される:bound to
一例:for instance
部署 office and regional
取って代わる:take s over
~~見做される／~~前提にする:presume
課す:put
何でも:everything
期間は不定indefinitely
関知しない:no awareness
re-prompt
~~簡単に:readily
並び:sequence
受ける:achieve
難しく:hard
新たに:newly
通過-:passed through


●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により PROPOSED STANDARD として公表された，
RFC 7235
<a href="~SPEC_URL">Hypertext Transfer Protocol (HTTP/1.1): Authentication</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

公表者
	Internet Engineering Task Force (IETF)
RFC
	7235
廃用
	<a href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> を廃用にする
	<a href="https://www.rfc-editor.org/rfc/rfc9110">RFC 9110</a> により廃用にされた
更新
	<a href="https://www.rfc-editor.org/rfc/rfc2617">RFC 2617</a> を更新する
分類
	Standards Track
ISSN
	2070-1721
編集
	R. Fielding, Adobe
	J. Reschke, greenbytes
日付
	2014 年 6 月
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc7235
</script>

</head>
<body>

<header>
	<hgroup>
<h1>HTTP/1.1 — 認証</h1>
<p>RFC 7235 — Authentication</p>
	</hgroup>
</header>

<div id="MAIN" hidden>

<p class="trans-note">【
この~RFCは、
今や，`現在の~HTTP中核~仕様＠~HTTPcommon#core-specifications$（ ~RFC 9110 ）により廃用にされた。
】</p>

	<section>
◎要約

<p>
~HTTP（ Hypertext Transfer Protocol ）は、分散型の協調的な~hypertext情報~system用の、`~stateless$な~app~levelの~protocolである。
この文書は、~HTTP認証（ HTTP Authentication ）~frameworkを定義する。
◎
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.
</p>
	</section>
	<section id="rfc.status">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status$に移譲。
】</p>

	</section>
	<section id="rfc.copyrightnotice">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright © 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">
	<section id="section-1">
<h2 title="Introduction">1. 序論</h2>

<p>
~HTTPは、~access制御と認証~用の 一般的~frameworkを，拡張-可能な［
［`~challenge$応答］ `認証~scheme$の集合
］を介して，供する
— それは、`~server$により~client要請を~challengeするために, および
`~client$により認証~情報を供するために利用できる。
この文書は、`~HTTP11$認証を，
<span title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">`7230$R</span>
により定義される~architectureを通して定義する。
この~architectureには、［
以前に
<span title="HTTP Authentication: Basic and Digest Access Authentication">`2617$R</span>
にて述べられた，一般的~framework
］, および［
以前に
<span title="Hypertext Transfer Protocol -- HTTP/1.1">`2616$R</span>
にて定義された，関係する 各種~headerおよび状態s~code
］も含まれる。
◎
HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" [RFC7230], including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617] and the related fields and status codes previously defined in "Hypertext Transfer Protocol -- HTTP/1.1" [RFC2616].
</p>

<p>
IANA Authentication Scheme Registry（ `5.1$sec ）に，登録-済みな`認証~scheme$, および
それらに対応ng仕様を挙げる
— 以前に `2617$R にて定義された認証~scheme
"`basic^c", "`digest^c" も含めて。
◎
The IANA Authentication Scheme Registry (Section 5.1) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by RFC 2617.
</p>

		<section id="section-1.1">
<h3 title="Conformance and Error Handling">1.1. 適合性, ~errorの取扱い</h3>

<p>
この文書~内の~keyword "MUST" …
【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】
◎
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
</p>

<p>
適合性の判定基準, および
~errorの取扱いに関する考慮点は、
`7230-2.5$rfc にて定義される。
◎
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
</p>

		</section>
		<section id="section-1.2">
<h3 title="Syntax Notation">1.2. 構文の表記法</h3>

<p class="trans-note">【
この節の他の内容は、
`~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$に移譲。
】</p>

<p>
`総集的~ABNF＠~723Xabnf#abnf-7235$
にて、他の文書から取込まれた規則, および
すべての`~list演算子$を標準な~ABNF表記法に展開した，総集的な文法を示す。
◎
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.
</p>

		</section>
	</section>
	<section id="section-2">
<h2 title="Access Authentication Framework">2. ~access認証~framework</h2>

		<section id="section-2.1">
<h3 title="Challenge and Response">2.1. ~challengeと応答</h3>

<div class="p">
<p>
~HTTPは、単純な，`~challenge$応答による認証~frameworkを供する
— それは、次の 2 つの目的に利用できる：
◎
HTTP provides a simple challenge-response authentication framework that can be used＼
</p>

<ul>
	<li>
`~server$が~client要請を~challengeする。
◎
by a server to challenge a client request and＼
</li>
	<li>
`~client$が認証~情報を供する。
◎
by a client to provide authentication information.＼
</li>
</ul>

<p>
各
`~challenge@（ `challenge$p ）
は、順に，次の情報からなる：
◎
＼</p>

<ol>
	<li>
`認証~scheme@
（ `auth-scheme$p ）
を識別する，文字大小無視 `token$p 。
◎
It uses a case-insensitive token as a means to identify the authentication scheme, followed by＼
</li>
	<li>
<p>
前項の~schemeの下で認証を受けるために必要yな，追加的な情報
— 次のいずれかをとり得る：
◎
additional information necessary for achieving authentication via that scheme. The latter can be either＼
</p>
		<ul>
			<li>
いくつかの`認証~parameter$からなる，~commaで分離された~list。
◎
a comma-separated list of parameters or＼
</li>
			<li>
base64 符号化された情報を保持できる，単独の［
文字~並び
］（ `token68$p ）。
◎
a single sequence of characters capable of holding base64-encoded information.
</li>
		</ul>
	</li>
</ol>
</div>

<div class="p">
<p>
各
`認証~parameter@
（ `auth-param$p ）は、
"`=^c" で~~区切られた
`名前@var
と
`値@var
の~pairであり：
◎
Authentication parameters are name=value pairs, where＼
</p>

<ul>
	<li>
`名前$var
は、文字大小無視で照合される `token$p である。
◎
the name token is matched case-insensitively, and＼
</li>
	<li>
同じ `名前$var が生じるのは、 `challenge$p ごとに 1 個まででなければナラナイ。
◎
each parameter name MUST only occur once per challenge.
</li>
</ul>
</div>

<pre class="bnf">
`auth-scheme@p
	= `token$p

`auth-param@p
	= `token$p `BWS$p "=" `BWS$p ( `token$p / `quoted-string$p )

`token68@p
	= 1*( `ALPHA$P / `DIGIT$P /
	      "-" / "." / "_" / "~" / "+" / "/" ) *"="
</pre>

<p>
`token68$p 構文は、 66 個の非~予約-済み~URI文字（ `3986-2.3$rfc ）に加えて，空白~以外の少数の文字も許容する
— 次に挙げる符号化法 `4648$R を，~paddingの有無も込みで保持できるようにするための
⇒＃
`base64$,
`base64url$ （ URL や~filenameに用いても安全な~alphabet）,
`base32$,
`base16$ （ 16 進）
◎
The token68 syntax allows the 66 unreserved URI characters ([RFC3986]), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace ([RFC4648]).
</p>

<p>
`401$st 応答~messageは、`~UA$への権限付与を~challengeするために，`生成元~server$により利用され、［
要請された資源に適用-可能な， 1 個~以上の `challenge$p
］を包含する， `WWW-Authenticate$h ~headerを含む。
◎
A 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent, including a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
</p>

<p>
`407$st 応答~messageは、`~client$への権限付与を~challengeするために，`~proxy$により利用され、［
要請された資源~用に~proxyに適用-可能な， 1 個~以上の `challenge$p
］を包含する， `Proxy-Authenticate$h ~headerを含む。
◎
A 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client, including a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
</p>

<pre class="bnf">
`challenge@p
	= `auth-scheme$p [ 1*`SP$P ( `token68$p / #`auth-param$p ) ]
</pre>

<p class="note">注記：
多くの`~client$は、［
未知な~schemeを包含するような `challenge$p
］の構文解析-に失敗する。
この問題~用の対処法は、広く~supportされている~schemeたち（ "`basic^c" など）を，~~最初の方に挙げることである。
◎
Note: Many clients fail to parse a challenge that contains an unknown scheme. A workaround for this problem is to list well-supported schemes (such as "basic") first.
</p>

<p>
`~UA$は、
— 必要とされてはいないが通例的には， `401$st を受信した後に —
［
要請に `Authorization$h ~headerを内包する
］ことにより，［
自身を`生成元~server$から認証してもらう
］ことができる。
◎
A user agent that wishes to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) -- can do so by including an Authorization header field with the request.
</p>

<p>
`~client$は、
— 必要とされてはいないが通例的には， `407$st を受信した後に —
［
要請に `Proxy-Authorization$h ~headerを内包する
］ことにより，［
自身を`~proxy$から認証してもらう
］ことができる。
◎
A client that wishes to authenticate itself with a proxy -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) -- can do so by including a Proxy-Authorization header field with the request.
</p>

<div class="p">
<p>
［
`Authorization$h, `Proxy-Authorization$h
］両`~header値$とも，［
要請-中にある`資源$が属する `realm$c
］用の［
`~client$の
`資格証@（ `credentials$p ）
］を包含する。
`~UA$は、それらの値を［
応答~内に（場合によっては過去のある時点で）受信された `challenge$p
］に基づいて，次のように作成する~OUGHT：
◎
Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by＼
</p>

<ul>
	<li>
受信した `challenge$p たちのうち，［
自身が解する かつ最も~secureと見なすような， `auth-scheme$p
］を伴うものを選定する。
◎
selecting the challenge with what it considers to be the most secure auth-scheme that it understands,＼
</li>
	<li>
利用者から適宜 `資格証$を得する。
◎
obtaining credentials from the user as appropriate.＼
</li>
</ul>

<p>
`資格証$を`~header値$の中に伝送することは、下層~接続の機密性に関する，有意な~securityの考慮点も含意する
— `6.1$sec を見よ。
◎
Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in Section 6.1.
</p>
</div>

<pre class="bnf">
`credentials@p
	= `auth-scheme$p [ 1*`SP$P ( `token68$p / #`auth-param$p ) ]
</pre>

<div class="p">
<p>
`生成元~server$は、保護される資源~用の`資格証$が［
省略されている ／
無効である（例： 不良~password） ／
部分的である（例：`認証~scheme$が複数~回の往復を要求する）
］ような要請の受領~時には，次のような `401$st 応答を送信するベキである：
◎
Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server SHOULD send a 401 (Unauthorized) response that＼
</p>

<ul>
	<li>
`WWW-Authenticate$h ~headerを包含する。
◎
contains a WWW-Authenticate header field＼
</li>
	<li>
この~headerには、 1 個~以上の［
要請された資源に適用-可能な `challenge$p
］を伴わせる（場合によっては 新たなそれも含ませる）。
◎
with at least one (possibly new) challenge applicable to the requested resource.
</li>
</ul>

</div>

<div class="p">
<p>
同様に，認証を要求する`~proxy$は、~proxy`資格証$が［
省略されている／無効である／部分的である
］ような要請の受領~時には，次のような `407$st 応答を`生成する$ベキである：
◎
Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy that requires authentication SHOULD generate a 407 (Proxy Authentication Required) response that＼
</p>

<ul>
	<li>
`Proxy-Authenticate$h ~headerを包含する。
◎
contains a Proxy-Authenticate header field＼
</li>
	<li>
この~headerには、 1 個~以上の［
その`~proxy$に適用-可能な `challenge$p
］を伴わせる（場合によっては 新たなそれも含ませる）。
◎
with at least one (possibly new) challenge applicable to the proxy.
</li>
</ul>

</div>

<p>
`~server$は、妥当ではあるが ~accessを獲得するには必要十分でない`資格証$を受信したときは，状態s~code `403$st で応答する~OUGHT。
◎
A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code (Section 6.5.3 of [RFC7231]).
</p>

<p>
~HTTPは、この単純な ［`~challenge$応答］ ~frameworkによる応用を，~access認証のみに制約しない。
追加的な仕組みにも利用し得る
— ［
~transport~levelの認証として, あるいは
~messageによる~capsule化を介して
］, および認証~情報を指定する追加的な~headerを伴わせるような。
しかしながら、そのような追加的な仕組みは，この仕様では定義されない。
◎
HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.
</p>

		</section>
		<section id="section-2.2">
<h3 title="Protection Space (Realm)">2.2. 保護~空間（ `realm^c ）</h3>

<p>
`名前$var
`realm@c
の`認証~parameter$は、`認証~scheme$における保護の視野
— `保護~空間$ —
を指示する利用が望まれるときのために，予約されている。
◎
The "realm" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.
</p>

<p>
`保護~空間@
は、~accessされている`~server$の
`正準的~root~URI@
— `実効~要請~URI$の［
`scheme$p, `authority$p
］成分の組 —
と, この `realm$c 値（もし在れば）との組合nにより定義される。
`realm$c により、`~server$上の保護される資源たちを，いくつかの`保護~空間$に区分できるようになる
— それぞれが自前の［
`認証~scheme$や, 権限付与~database
］を伴うような。
`realm$c 値は、一般に，`生成元~server$によりアテガわれる文字列であり、`認証~scheme$に特有な追加的な意味論を持ち得る。
応答は、［
同じ `auth-scheme$p を伴いつつ, 異なる `realm$c 値を伴う
］ような，複数の `challenge$p を持ち得ることに注意。
◎
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI; see Section 5.5 of [RFC7230]) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different realms.
</p>

<p>
`保護~空間$は、`資格証$を自動的に適用できるような~domainを決定する。
先立つ要請に権限付与されていた場合、`~UA$は、その`保護~空間$に属する他のすべての要請に対し，同じ`資格証$を ある期間までは再利用してヨイ
— その期間は、［
`認証~scheme$, `認証~parameter$たち, 利用者-選好（環境設定できるような放置 制限時間など）
］のうち いくつかから決定される。
`認証~scheme$により特に許容されない限り、単独の`保護~空間$は，その`~server$の視野から外へは拡張できない。
◎
The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a configurable inactivity timeout). Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server.
</p>

<p>
歴史的な理由から、`送信者$は， `quoted-string$p 構文のみを`生成し$なければナラナイ。
長年にわたり両 表記法を受容してきた既存の`~client$との相互運用能を最大にするため、
`受信者$は， `token$p, `quoted-string$p 両~構文の~supportを要し得る。
◎
For historical reasons, a sender MUST only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability with existing clients that have been accepting both notations for a long time.
</p>

		</section>
	</section>
	<section id="section-3">
<h2 title="Status Code Definitions">3. 状態s~code定義</h2>

		<section id="section-3.1">
<h3 title="401 Unauthorized">3.1. `401^st</h3>

<p>
状態s~code `401^st は、［
要請は、`~target資源$用の妥当な認証 `資格証$を欠如するために，まだ適用されていない
］ことを指示する。
`~server$が `401^st0 応答を`生成する$ときは、［
~target資源に適用-可能な `challenge$p を， 1 個~以上は包含する
］ような， `WWW-Authenticate$h ~headerを送信しなければナラナイ。
◎
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
</p>

<div class="p">
<p>
要請が認証 `資格証$を内包していた場合、 `401^st0 応答は，［
その`資格証$に対する権限付与は，拒否された
］ことを指示する。
`~UA$は，その応答に対し：
◎
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials.＼
</p>

<ul>
	<li>
［
新たな, または他の値に置換された `Authorization$h ~header
］を伴わせた上で，要請を繰返してヨイ。
◎
The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2).＼
</li>
	<li>
［
その `401^st0 応答が，それに先立つ応答と同じ `challenge$p を包含する
］, かつ［
~UAは，認証をすでに 1 回は試みていた
］場合、同封された表現を利用者に呈示するベキである
— それは、通例的に，関連な診断~情報を包含するので。
◎
If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
</li>
</ul>
</div>

		</section>
		<section id="section-3.2">
<h3 title="407 Proxy Authentication Required">3.2. `407^st</h3>

<div class="p">
<p>
状態s~code `407^st は、 `401$stに類似するが，［
`~client$は、`~proxy$を利用するためには，認証が必要である
］ことを指示する：
◎
The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy.＼
</p>

<ul>
	<li>
~proxyは、［［
自身に適用-可能な, `~target資源$用の `challenge$p
］を包含する， `Proxy-Authenticate$h ~header
］を送信しなければナラナイ。
◎
The proxy MUST send a Proxy-Authenticate header field (Section 4.3) containing a challenge applicable to that proxy for the target resource.＼
</li>
	<li>
`~client$は、［
新たな, または他の値に置換された， `Proxy-Authorization$h ~header
］を伴わせた上で，要請を繰返してヨイ。
◎
The client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 4.4).
</li>
</ul>
</div>


		</section>
	</section>
	<section id="section-4">
<h2 title="Header Field Definitions">4. ~header定義</h2>

<p>
この節では、~HTTP認証~frameworkに関係する各種~headerの構文と意味論を定義する。
◎
This section defines the syntax and semantics of header fields related to the HTTP authentication framework.
</p>

		<section id="section-4.1">
<h3 title="WWW-Authenticate">4.1. `WWW-Authenticate^h</h3>

<p>
`WWW-Authenticate^h ~headerは、`~target資源$に適用-可能な［
`認証~scheme$たち, および
`認証~parameter$たち
］を指示する。
◎
The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.
</p>

<pre class="bnf">
`WWW-Authenticate@p
	= 1#`challenge$p
</pre>

<p>
`401$st 応答を`生成する$`~server$は、［
 1 個~以上の `challenge$p を包含する，
`WWW-Authenticate$h ~header
］を送信しなければナラナイ。
~serverは、他の応答~message内にも，
`WWW-Authenticate$h ~headerを`生成し$てヨイ
— 【後の要請に】 `資格証$（または異なる`資格証$）を給することが，対する応答に影響し得ることを指示するために。
◎
A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.
</p>

<p>
応答を回送している`~proxy$は、その応答~内のどの
`WWW-Authenticate$h ~headerも，改変してはナラナイ。
◎
A proxy forwarding a response MUST NOT modify any WWW-Authenticate fields in that response.
</p>

<p>
`~UA$には、`~header値$を構文解析するときに，特別に~careすることを勧める
— それは，複数の `challenge$p を包含することがあり、また，各 `challenge$p も，いくつかの`認証~parameter$からなる~commaで分離された~listを包含し得るので。
更には、~header自体も複数~回 生じ得る。
◎
User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.
</p>

<div class="example">
<p>
一例：
◎
For instance:
</p>

<pre class="lang-http">
WWW-Authenticate: Newauth `realm^c="apps", type=1, title="Login to \"apps\"", Basic `realm^c="simple"
</pre>

<div class="p">
<p>
この~headerは、 2 個の `challenge$p を包含する：
◎
This header field contains two challenges;＼
</p>

<ul>
	<li>
`Newauth^c ~scheme用の `realm$c 値 "`apps^c" を伴い，追加的な~parameter `type^c, `title^c も伴うもの。
◎
one for the "Newauth" scheme with a realm value of "apps", and two additional parameters "type" and "title", and＼
</li>
	<li>
`Basic^c ~scheme用の `realm$c 値 "`simple^c" を伴うもの。
◎
another one for the "Basic" scheme with a realm value of "simple".
</li>
</ul>
</div>

</div>

<p class="note">注記：
`challenge$p 文法~生成規則も~list構文を利用する。
したがって、［
~comma, 空白, ~comma
］の並びは、［
先行している `challenge$p に適用するもの
］としても, あるいは［
`challenge$p の~listにおける，空~entry
］にも，見なし得る。
この多義性は、実施においては `~header値$の意味論に影響しないので，無害である。
◎
Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value and thus is harmless.
</p>

		</section>
		<section id="section-4.2">
<h3 title="Authorization">4.2. `Authorization^h</h3>

<p>
`Authorization^h ~headerにより、
`~UA$は，自身を`生成元~server$から認証してもらうことが可能になる
— 必要とされてはいないが通例的には， `401$st 応答を受信した後に。
その値は、［
要請-中にある資源が属する `realm$c 用の，`~UA$の認証~情報
］を包含する`資格証$からなる。
◎
The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
</p>

<pre class="bnf">
`Authorization@p
	= `credentials$p
</pre>

<p>
要請が認証され, かつ `realm$c も指定されている場合、同じ`資格証$は，［
この `realm$c に属する 他のすべての要請に対しても，妥当である
］と~~見做されるようになる（`認証~scheme$自体が，他のもの
— `challenge$p 値に則って, あるいは同期された`時計$を利用して様々になるような，`資格証$など —
を要求しない限りにおいて）。
◎
If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
</p>

<p>
要請を回送している`~proxy$は、その要請~内のどの `Authorization$h ~headerも，
改変してはナラナイ。
~HTTP~cacheによる `Authorization$h ~headerの取扱い［
の詳細／に課される要件
］については、 `7234-3.2$rfc を見よ。
◎
A proxy forwarding a request MUST NOT modify any Authorization fields in that request. See Section 3.2 of [RFC7234] for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
</p>

		</section>
		<section id="section-4.3">
<h3 title="Proxy-Authenticate">4.3. `Proxy-Authenticate^h</h3>

<p>
`Proxy-Authenticate^h ~headerは， 1 個~以上の `challenge$p からなり、そのそれぞれは，［
この`実効~要請~URI$に対し，`~proxy$に適用-可能な［
`認証~scheme$, `認証~parameter$たち
］］を指示する。
`~proxy$は、自身が`生成する$各 `407$st 応答~内に， 1 個~以上の `Proxy-Authenticate$h ~headerを送信しなければナラナイ。
◎
The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this effective request URI (Section 5.5 of [RFC7230]). A proxy MUST send at least one Proxy-Authenticate header field in each 407 (Proxy Authentication Required) response that it generates.
</p>

<pre class="bnf">
`Proxy-Authenticate@p
	= 1#`challenge$p
</pre>

<p>
`WWW-Authenticate$h とは違って，
`Proxy-Authenticate$h ~headerは、［
応答`連鎖$の`外方$にある次の`~client$
］のみに適用される
— 当の`~proxy$を選択した`~client$のみが，認証に必要yな`資格証$を持つ見込みが高いので。
しかしながら、同じ管轄の中で複数の`~proxy$が利用されるとき
— 巨大~企業~networkの中の，各~部署の~caching~proxyなど —
`~UA$により`生成され$た`資格証$が，消費されるまで階層を通過することは、共通的にある。
よって，そのような環境設定では、各`~proxy$は同じ `challenge$p 集合を送信することになり， `Proxy-Authenticate$h が回送されているかのように出現することになる。
◎
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authenticate is being forwarded because each proxy will send the same challenge set.
</p>

<p>注記：
`WWW-Authenticate$p の構文解析に際しての考慮点は、この~headerにも適用される。
詳細は`4.1$sec を見よ。
◎
Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see Section 4.1 for details.
</p>

		</section>
		<section id="section-4.4">
<h3 title="Proxy-Authorization">4.4. `Proxy-Authorization^h</h3>

<p>
`Proxy-Authorization^h ~headerは、
`~client$が，認証を要求する`~proxy$に対し，自身を（または その利用者を）識別してもらうことを可能にする。
その値は、［［
当の~proxyや, 要請-中にある資源が属する `realm$c
］用の，`~client$の認証~情報
］を包含する，`資格証$からなる。
◎
The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication. Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the resource being requested.
</p>

<pre class="bnf">
`Proxy-Authorization@p
	= `credentials$p
</pre>

<p>
`Authorization$h と違って，
`Proxy-Authorization$h ~headerは、［
`Proxy-Authenticate$h ~headerを利用して認証を請求した，`内方$にある次の`~proxy$
］のみに適用される。
`連鎖$にて複数の~proxyが利用されているときは、
`Proxy-Authorization$h ~headerは，［
`資格証$を受信することを予期していた最初の内方~proxy
］により消費される。
複数の~proxyが，所与の要請を協力的に認証する仕組みを成している場合、
`~proxy$は，~client要請からの`資格証$を 次の~proxyへ中継してヨイ。
◎
Unlike Authorization, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
</p>

		</section>
	</section>
	<section id="section-5">
<h2 title="IANA Considerations">5. ~IANA考慮点</h2>

		<section id="section-5.1">
<h3 title="Authentication Scheme Registry">5.1. 認証~scheme~registry</h3>

<p>
［
`~challenge$および`資格証$における，`認証~scheme$
］用の名前空間は、新たに作成された
`Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry＠~IANA-a/http-authschemes$
（ HTTP 認証~scheme~registry）にて保守され, 定義される。
◎
The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the authentication schemes in challenges and credentials. It has been created and is now maintained at &lt;http://www.iana.org/assignments/http-authschemes&gt;.
</p>

			<section id="section-5.1.1">
<h4 title="Procedure">5.1.1. 手続-</h4>

<p>
登録にあたっては，次の~fieldを含まなければナラナイ：
◎
Registrations MUST include the following fields:
</p>

<ul>
	<li>
`認証~scheme$名
◎
• Authentication Scheme Name
</li>
	<li>
仕様~textへの~pointer
◎
• Pointer to specification text
</li>
	<li>
注記（省略可能）
◎
• Notes (optional)
</li>
</ul>

<p>
この名前空間に追加される値は、
`~IETFによる考査$を要する。
◎
Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
</p>

			</section>
			<section id="section-5.1.2">
<h4 title="Considerations for New Authentication Schemes">5.1.2. 新たな認証~schemeに対する考慮点</h4>

<p>
~HTTP認証~frameworkは、次の側面において，新たな`認証~scheme$がどのように働き得るかについての拘束を課す：
◎
There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:
</p>

<ul>
	<li>
~HTTP認証は、`~stateless$であることを~~前提にする：
要請を認証するために必要yな，すべての情報が、その要請~内に供されなければナラナイ
— `~server$が それに先立つ要請を記憶することに依存するのではなく。
下層~接続に
基づく／束縛される
認証は、この仕様の視野~外であり、［
その接続が、認証-済み利用者~以外のどの主体からも利用され得ない
］ことを確保するための手続きが踏まれない限り，内来的に欠陥があるものとされる（ `7230-2.3$rfc を見よ）。
◎
• HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 2.3 of [RFC7230]).
</li>
	<li>
`名前$var `realm$c の`認証~parameter$は、`保護~空間$を定義するものとして予約される。
新たな~schemeは、 "`realm^c" をその定義と非~互換な仕方で利用してはナラナイ。
◎
• The authentication parameter "realm" is reserved for defining protection spaces as described in Section 2.2. New schemes MUST NOT use it in a way incompatible with that definition.
</li>
	<li>
既存の`認証~scheme$との互換性のために，
`token68$p 表記法が導入された
— それは、 `challenge$p／`credentials$p ごとに 1 個しか利用できない。
したがって，新たな~schemeは、代わりに `auth-param$p 構文を利用する~OUGHT
— さもなければ，将来の拡張が不可能になるので。
◎
• The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible.
</li>
	<li>
<p>
`challenge$p／`credentials$p の構文解析は，この仕様により定義され、新たな`認証~scheme$は，それを改変できない。
`auth-param$p 構文が利用されるときは、すべての~parameterが
`token$p, `quoted-string$p 両~構文を~supportする~OUGHT。
また，構文上の拘束は、構文解析-後の（すなわち， `quoted-string$p を処理した後の）`~header値$に対し，定義される~OUGHT。
これは、`受信者$が，［
すべての`認証~scheme$に適用される，汎用 構文解析器
］を利用できるようにするために必要yである。
◎
• The parsing of challenges and credentials is defined by this specification and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes.
</p>

<p class="note">注記：
"`realm^c" ~parameter用の値の構文が `quoted-string$p に制約される事は、悪い設計の選択であった
— 新たな~parameterに対しては繰返されない。
◎
Note: The fact that the value syntax for the "realm" parameter is restricted to quoted-string was a bad design choice not to be repeated for new parameters.
</p>
	</li>
	<li>
新たな~schemeの定義は、未知な拡張~parameterの扱いを定義する~OUGHT。
一般に、
“無視しなければならない”
とする規則が
“解さなければならない”
とするよりも選好される
— さもなければ、旧来の`受信者$が在る下で，新たな~parameterを導入することが難しくなるので。
更には、新たな~parameterたちを定義するための施策を述べる方が良い（ “〜の仕様を更新せよ” や, “この~registryを利用せよ” など）。
◎
• Definitions of new schemes ought to define the treatment of unknown extension parameters. In general, a "must-ignore" rule is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of legacy recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification" or "use this registry").
</li>
	<li>
`認証~scheme$は、［
`生成元~server$による認証（すなわち， `WWW-Authenticate$h を利用）／
`~proxy$による認証（すなわち， `Proxy-Authenticate$h を利用）
］に利用できるかどうかを文書化する必要がある。
◎
• Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), and/or proxy authentication (i.e., using Proxy-Authenticate).
</li>
	<li>
`Authorization$h ~header内に運ばれる`資格証$は，`~UA$に特有なので、それが出現する要請の視野の下で，~HTTP~cacheに対する `private$sdir `Cache-Control$h 応答~指令と同じ効果を持つ。
したがって，新たな`認証~scheme$は、`資格証$を `Authorization$h ~header内に運ばせないことを選択する場合（例えば，新たに定義される~headerを利用して）、~cachingを明示的に許容しない必要がある
— `Cache-Control$h 指令（例：
要請に対する `no-store$qdir や, 応答に対する `private$sdir
）の利用を義務化することにより。
◎
• The credentials carried in an Authorization header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the "private" Cache-Control response directive (Section 5.2.2.6 of [RFC7234]), within the scope of the request in which they appear. Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private").
</li>
</ul>

			</section>
		</section>
		<section id="section-5.2">
<h3 title="Status Code Registration">5.2. 状態s~code登録</h3>

<p>
`~HTTP状態s~code~registry＠~IANA-a/http-status-codes$
は、以下の登録により更新された：
◎
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at &lt;http://www.iana.org/assignments/http-status-codes&gt; has been updated with the registrations below:
</p>

<div>
<ul><li>`401$st
</li><li>`407$st
</li></ul>

<pre lang="en" class="_en">
   +-------+-------------------------------+-------------+
   | Value | Description                   | Reference   |
   +-------+-------------------------------+-------------+
   | 401   | Unauthorized                  | Section 3.1 |
   | 407   | Proxy Authentication Required | Section 3.2 |
   +-------+-------------------------------+-------------+
</pre></div>

		</section>
		<section id="section-5.3">
<h3 title="Header Field Registration">5.3. ~header登録</h3>

<p>
~HTTP~headerは、
`Message Headers＠~IANA-a/message-headers/$
~registryにて登録される。
◎
HTTP header fields are registered within the "Message Headers" registry maintained at &lt;http://www.iana.org/assignments/message-headers/&gt;.
</p>

<p>
この文書は、次の~HTTP~headerを定義する。
それに伴い
"Permanent Message Header Field Names"
~registryは更新された（`BCP90$rを見よ）。
◎
This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).
</p>

<table><thead>
<tr><td>~header名
<td>~protocol
<td>位置付け
<tbody>

<tr><td>`Authorization$h
<td>http
<td>standard

<tr><td>`Proxy-Authenticate$h
<td>http
<td>standard

<tr><td>`Proxy-Authorization$h
<td>http
<td>standard

<tr><td>`WWW-Authenticate$h
<td>http
<td>standard
</table>

<pre lang="en" class="_en">
   +---------------------+----------+----------+-------------+
   | Header Field Name   | Protocol | Status   | Reference   |
   +---------------------+----------+----------+-------------+
   | Authorization       | http     | standard | Section 4.2 |
   | Proxy-Authenticate  | http     | standard | Section 4.3 |
   | Proxy-Authorization | http     | standard | Section 4.4 |
   | WWW-Authenticate    | http     | standard | Section 4.1 |
   +---------------------+----------+----------+-------------+
</pre>

<p>
変更~制御者は~IETF-orgである。
◎
The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</p>

		</section>
	</section>
	<section id="section-6">
<h2 title="Security Considerations">6. ~securityの考慮点</h2>

<p>
この節は、［
開発者／情報~provider／利用者
］向けに，
~HTTP認証に特有な，既知な~securityの懸念を伝えることを~~意図している。
より一般的な~securityの考慮点は、
~HTTP~messaging `7230-9$rfc, および
~HTTP意味論 `7231-9$rfc にて取組まれている。
◎
This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP authentication. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].
</p>

<p>
~HTTP認証の論題についての何でもが~securityの考慮点になるので、下に挙げる考慮点は，網羅的なものではない。
更には、［
一般的な，認証~frameworkに関する~securityの考慮点
］に制限されている
— 特定の`認証~scheme$について考え得る，あらゆる考慮点を論じるのではなく（それらは，各~schemeを定義する仕様にて文書化される~OUGHT）。
様々な組織が，~Web~appの~securityについての時事的な情報や現在の事実調査への~linkを保守する（例： `OWASP$r ）
— 実施において見出される`認証~scheme$や, 実装する／利用する際に共通的な罠など。
◎
Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not exhaustive. Furthermore, it is limited to security considerations regarding the authentication framework, in general, rather than discussing all of the potential considerations for specific authentication schemes (which ought to be documented in the specifications that define those schemes). Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]), including common pitfalls for implementing and using the authentication schemes found in practice.
</p>

		<section id="section-6.1">
<h3 title="Confidentiality of Credentials">6.1.`資格証$の機密性</h3>

<p>
~HTTP認証~frameworkは、［
`資格証$の機密性を保守するための，単独の仕組み
］を定義しない
— 代わりに、各 `認証~scheme$が［
伝送に先立って`資格証$が符号化される方法
］を定義する。
これは、将来の`認証~scheme$の開発に柔軟性を供する一方で、［
自前の機密性を供さない, あるいは
反射攻撃に対する保護には足らない
］ような既存の~schemeの保護には，必要十分でない。
更には，`~server$が［
個々の利用者に特有な`資格証$
］を期待する場合、それらの`資格証$の交換は，その利用者を識別する効果ももたらす
— `資格証$の中の内容が機密的であり続けるとしても。
◎
The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead, each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying that user even if the content within credentials remains confidential.
</p>

<p>
~HTTPが供する~headerの伝送の機密性は、下層［
~transport／~session
］~level接続の，各種 ~securityの~propertyに依存する。
言い換えれば、`~server$は，［
この~frameworkを利用して，~accessを認証-済み利用者のみに制限する場合
］には，［
その接続が，利用する`認証~scheme$の資質に則って適正に~secure化される
］ことを確保する必要がある。
例えば、個々の利用者~認証に依存する~serviceは、［
`資格証$を交換するに先立って，接続が~TLS（ “Transport Layer Security”, `5246$R ）により~secure化される
］ことを要求することが多い。
◎
HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of header fields. In other words, if a server limits access to authenticated users using this framework, the server needs to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used. For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC5246]) prior to exchanging any credentials.
</p>

		</section>
		<section id="section-6.2">
<h3 title="Authentication Credentials and Idle Clients">6.2. 認証 `資格証$と遊休~client</h3>

<p>
既存の~HTTP `~client$／`~UA$が 認証~情報を維持する~~期間は、概して 不定である。
~HTTPは、［
`生成元~server$が、`~client$に対し，~cacheされた`資格証$を破棄するように指令する
］ための仕組みは供さない
— この~protocolは、［
~UAが`資格証$を 得する／管理する 方法
］については関知しないので。
［
`資格証$を 失効させる／廃用する ための仕組み
］は、`認証~scheme$定義の一部として指定し得る。
◎
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of an authentication scheme definition.
</p>

<p>
少なくとも，次に挙げる状況下においては、資格証の~cachingが，~appの~security~modelに干渉し得る：
◎
Circumstances under which credential caching can interfere with the application's security model include but are not limited to:
</p>

<ul>
	<li>
`~client$が期間を延長して遊休~中にあるときに、`~server$が，`~client$に対し［
再度，利用者に`資格証$の~~入力を促す
］ように望むことがあるとき。
◎
• Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt the user for credentials.
</li>
	<li>
~appは，~sessionの終了n指示（~page上の “~logout” や “~commit” ~buttonなど）を含んでいて、それにより，~appの~server側は［
`~client$が`資格証$を維持する理由は それ以上~無い
］ことを “知る” ようなとき。
◎
• Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the server side of the application "knows" that there is no further reason for the client to retain the credentials.
</li>
</ul>

<p>
`資格証$を~cacheする`~UA$には、［［
~cacheされた`資格証$を，利用者-制御の下で破棄する
］ための，~~簡単に~access可能な仕組み
］を供することが奨励される。
◎
User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
</p>

		</section>
		<section id="section-6.3">
<h3 title="Protection Spaces">6.3. 保護~空間</h3>

<p>
［
`保護~空間$を確立するときに，もっぱら `realm$c の仕組みに依拠する
］ような`認証~scheme$は、［
`生成元~server$上のすべての資源に対し，`資格証$を公開する
］ことになる。
資源への認証-済み要請を成功裡に為した`~client$は、同じ`生成元~server$上の他の資源に対しても，同じ認証 `資格証$を利用できる。
これは、［
ある資源が，他の資源~用の認証 `資格証$を採取すること
］をアリにする。
◎
Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the same authentication credentials for other resources on the same origin server. This makes it possible for a different resource to harvest authentication credentials for other resources.
</p>

<div class="p">
<p>
これは特に、［
`生成元~server$が、同じ`正準的~root~URI$の下で，複数の主体~用に資源を~hostするとき
］に，懸念される。
とり得る軽減策としては、次が挙げられる：
◎
This is of particular concern when an origin server hosts resources for multiple parties under the same canonical root URI (Section 2.2). Possible mitigation strategies include＼
</p>

<ul>
	<li>
認証 `資格証$への直接的な~accessを制約する（すなわち， `Authorization$h 要請~headerの内容を可用にしない）。
◎
restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header field available), and＼
</li>
	<li>
異なる~host名（あるいは~port番号）を利用して，`保護~空間$を各~主体ごとに分離する。
◎
separating protection spaces by using a different host name (or port number) for each party.
</li>
</ul>
</div>

		</section>
	</section>
	<section id="section-7">
<h2 title="Acknowledgments">7. 謝辞</h2>

<p>
この仕様は、以前に `2617$R にて定義された
HTTP Authentication Framework
の定義に取って代わる。
その仕様の仕事をされた次の方々に感謝する（
更なる謝辞は `2617-6$rfc に）：
◎
This specification takes over the definition of the HTTP Authentication Framework, previously defined in RFC 2617.
</p>

<div lang="en">
We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that specification. See Section 6 of [RFC2617] for further acknowledgements.
</div>

<p>
この文書による改訂に関係する謝辞は、
<span class="trans-note">【
`RFC723X 共通~page＠~723X#acknowledgments$
に移譲。
】</span>
◎
See Section 10 of [RFC7230] for the Acknowledgments related to this document revision.
</p>

	</section>
	<section id="section-8">
<h2 title="References">8. 参照文献</h2>

<p class="trans-note">【
この節の内容は、
`RFC723X 共通~page＠~723X#references$
に移譲。
】</p>

	</section>
	<section id="appendix-A">
<h2 title="Appendix A. Changes from RFCs 2616 and 2617">付録 A. RFC 2616, 2617 からの変更点</h2>

<ul>
	<li>
~HTTP認証~用の~frameworkは、今や，
`2617$R でなく，この文書にて定義される。
◎
The framework for HTTP Authentication is now defined by this document, rather than RFC 2617.
</li>
	<li>
`realm$c ~parameterは、
もはや，常に `challenge$p 上に要求されることはない
— その帰結として，
~ABNF は、 `auth-param$p ~parameterを伴わない `challenge$p も許容する。
（ `2$sec ）
◎
The "realm" parameter is no longer always required on challenges; consequently, the ABNF allows challenges without any auth parameters. (Section 2)
</li>
	<li>
`Basic^c などの旧来の`認証~scheme$との一貫性のため、
`auth-param$p ~listに対する `token68$p による代替が追加された
（ `2$sec ）
◎
The "token68" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic". (Section 2)
</li>
	<li>
この仕様は、新たな`認証~scheme$のための考慮点と伴に
Authentication Scheme Registry を導入する。
（ `5.1$sec ）
◎
This specification introduces the Authentication Scheme Registry, along with considerations for new authentication schemes. (Section 5.1)
</li>
</ul>

	</section>
	<section id="appendix-B">
<h2 title="Appendix B. Imported ABNF">付録 B. 取込まれた~ABNF</h2>
	</section>
	<section id="appendix-C">
<h2 title="Appendix C. Collected ABNF" data-cycling=".bnf">付録 C. 総集的~ABNF</h2>

<p class="trans-note">【
付録 B, C の内容は、
`総集的~ABNF＠~723Xabnf#abnf-7235$
に移譲。
】</p>

	</section>
</main></div>