概要
この仕様は、サイトが使用できる well-known URL を定義します。
これにより、パスワード変更フォームをツールから発見可能にします。この単純な
仕組みは、ユーザーがパスワードを変更する方法を見つけるのをソフトウェアが支援する手段を提供します。
この文書のステータス
目次
1 導入
2 基盤
3 パスワード変更 URL
4 IANA に関する考慮事項
4.1 change-password well-known URI
謝辞
適合性
文書の
慣例
適合アルゴリズム
索引
この仕様により定義される用語
参照により定義される用語
参考文献
規範的
参考文献
参考
参考文献
課題索引
1. 導入
この節は非規範的です。
クライアント側のパスワード管理ソフトウェアは、認証を必要とする Web サイトのセキュリティと使いやすさの両方を向上させるのに役立ちます。
クロスサイトでのパスワード再利用を減らすことでセキュリティを向上させ、
自動入力機能を提供することで使いやすさを高めます。
サイトには現在、ユーザーがパスワードを変更できる場所をプログラムにより告知する方法がありません。パスワード変更用の well-known URL を提案することで、
この仕様は、それをサポートするサイト上でユーザーがパスワードを変更するのをパスワードマネージャーが支援できるようにします。
2. 基盤
この仕様は Infra Standard に依存します。[INFRA]
この仕様は、
Fetch、
HTML、
HTTP、および
URL 標準の用語を使用します。[FETCH] [HTML] [HTTP-SEMANTICS] [URL]
3. パスワード変更 URL
オリジン の パスワード変更 URL
とは、クライアントが origin 上でユーザーがパスワードを更新するためにどこへ行くべきかを
発見するために使用できるリソースを指す URL です。
origin が与えられた場合、クライアントは次の手順を実行して パスワード変更 URL を生成 します:
origin が 潜在的に信用できるオリジン でない場合、失敗を返します。
表明: origin は タプルオリジン です。
url を、次のように値を設定した新しい URL
とします:
scheme
origin の scheme
host
origin の host
port
origin の port
path
« ".well-known", "change-password" »。
url を返します。
オリジン
"https://example.com/" のパスワード変更 URL は
"https://example.com/.well-known/change-password" です。
サーバーは、origin の パスワード変更
URL への HTTP 要求 を、302、303、または 307 の リダイレクトステータス
と Location ヘッダーを持つ 応答 を返すことで、ユーザーが実際にパスワードを変更できるページへリダイレクトするべきです。[FETCH] [HTTP-SEMANTICS]
クライアントは、パスワード変更
URL を要求する際、そのようなリダイレクトを処理しなければなりません。
注記: 上記の段落は、サーバーが一時的なリダイレクトコードを使用するよう制限しています。
Issue 13 を参照してください。
必要な場合、サーバーは、
refresh 状態 の
http-equiv
pragma ディレクティブを含む HTML 文書で応答してもかまいません。[HTML] クライアントは、
パスワード変更
URL を要求する際、そのようなリダイレクトを処理するべきです。
サーバーは、RFC8615 §1.1 Appropriate Use of Well-Known
URIs に従い、実際のパスワード変更ページを パスワード変更 URL に配置してはなりません。
クライアントは、パスワード変更
URL を要求する際、
ok status
応答を処理しなければなりません。
注記: 実装は、パスワード変更 URL を表示する際に ToUnicode を使用したい場合があります。[IDNA]
[RESPONSE-CODE-RELIABILITY] の オリジンの応答ステータスコードの信頼性をテストする を使用する。
4. IANA
に関する
考慮事項
4.1.
change-password well-known URI
この文書は、“.well-known” URI change-password を定義します。
この登録は、[WELL-KNOWN] で定義されるテンプレートを用いて、
IANA への登録のために、審査、承認、および登録を求めて IESG に提出されます。内容は次のとおりです:
URI suffix
change-password
Change controller
W3C
Specification document(s)
この文書が該当する仕様です。(§ 3 パスワード変更 URL を参照)
Related information:
なし。
謝辞
Anne van Kesteren、
Cl1608Ho、
Dan Bernstein、
David Singer、
Dean Jackson、
Florian Rivoal、
John Wilander、
Maciej Stachowiak、
Mark Nottingham、
Mike West、および
Ricky Mondello
に、この提案に対するフィードバックを感謝します。そのすべての機能は彼らのものであり、そのすべてのバグは私のものです。
文書の
慣例
適合性要件は、記述的な表明と
RFC 2119 用語の組み合わせにより表現されます。
この文書の規範部分におけるキーワード “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”,
“MAY”, and “OPTIONAL”
は、RFC 2119 で説明されているように解釈されます。
ただし、読みやすさのため、
これらの語はこの仕様ではすべて大文字で表示されるとは限りません。
この仕様のすべてのテキストは規範的です。
ただし、非規範的であると明示された節、例、および注記を除きます。[RFC2119]
この仕様の例は、「たとえば」という語で導入されるか、
または規範的テキストから切り離して
class="example" により示されます。
次のようになります:
情報提供用の注記は “Note” という語で始まり、
規範的テキストから切り離して
class="note" により示されます。
次のようになります:
注記、これは情報提供用の注記です。
アルゴリズムの一部として命令形で表現される要件
(たとえば "strip any leading space characters"
や "return false and abort these steps")
は、そのアルゴリズムを導入する際に使用されるキーワード
("must", "should", "may" など)
の意味で解釈されます。
アルゴリズムまたは特定の手順として表現される適合性要件は、
最終結果が等価である限り、
任意の方法で実装できます。
特に、この仕様で定義されるアルゴリズムは
理解しやすいことを意図しており、
パフォーマンスが高いことを意図していません。
実装者は最適化することが推奨されます。
索引
この仕様により定義される用語
参照により定義される用語
[FETCH] は次の用語を定義します:
ok status
redirect status
request
response
[HTML] は次の用語を定義します:
host
http-equiv
port
refresh state
scheme
tuple origin
[IDNA] は次の用語を定義します:
[RESPONSE-CODE-RELIABILITY] は次の用語を定義します:
test the reliability of an origin's response status
codes
[RFC7231] は次の用語を定義します:
[SECURE-CONTEXTS] は次の用語を定義します:
potentially trustworthy origin
[URL] は次の用語を定義します:
URL
host
origin
path
port
scheme
参考文献
規範的参考文献
[FETCH]
Anne van Kesteren. Fetch Standard . Living
Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard .
Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTTP-SEMANTICS]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. HTTP Semantics . June 2022. Internet
Standard. URL: https://httpwg.org/specs/rfc9110.html
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra
Standard . Living Standard. URL: https://infra.spec.whatwg.org/
[RESPONSE-CODE-RELIABILITY]
Ricky Mondello; Theresa O'Connor. Detecting the
reliability of HTTP status codes . CG-DRAFT. URL: https://wicg.github.io/change-password-url/response-code-reliability.html
[RFC2119]
S. Bradner. Key words for use in RFCs to
Indicate Requirement Levels . March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content . June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[SECURE-CONTEXTS]
Mike West. Secure Contexts . 10 November
2023. CR. URL: https://www.w3.org/TR/secure-contexts/
[URL]
Anne van Kesteren. URL Standard . Living Standard.
URL: https://url.spec.whatwg.org/
[WELL-KNOWN]
M. Nottingham. Well-Known Uniform Resource
Identifiers (URIs) . May 2019. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[IDNA]
Mark Davis; Michel Suignard. Unicode IDNA
Compatibility Processing . 5 September 2023. Unicode Technical Standard #46. URL: https://www.unicode.org/reports/tr46/tr46-31.html
課題索引