摘要
本规范定义了一个知名 URL,站点可使用该 URL
使其更改密码表单能够被工具发现。这种简单的
便利机制为软件提供了一种方式,帮助用户找到
更改其密码的方法。
本文档状态
目录
1 引言
2 基础设施
3 更改密码 URL
4 IANA 考虑事项
4.1 change-password 知名 URI
致谢
一致性
文档
约定
一致性算法
索引
由
本规范定义的术语
由引用
定义的术语
参考文献
规范性
参考文献
信息性
参考文献
问题索引
1. 引言
本节为非规范性内容。
客户端侧密码管理软件有助于改进需要认证的网站的安全性和可用性。
它通过减少跨站点密码复用来提高安全性,并通过提供自动填充功能来增强
可用性。
站点目前缺少一种方式来以编程方式声明用户可以 在何处
更改其密码。通过提出一个用于更改密码的知名 URL,本规范使
密码管理器能够帮助用户在支持该机制的站点上更改其密码。
2. 基础设施
本规范依赖 Infra 标准。[INFRA]
本规范使用
Fetch、
HTML、
HTTP 和
URL 标准中的术语。[FETCH] [HTML] [HTTP-SEMANTICS] [URL]
3. 更改密码 URL
一个更改密码 url
是某个源 的一个 URL,它指向客户端可用来发现用户应前往何处
在该源 上更新其密码的资源。
给定一个 origin ,客户端通过运行以下步骤生成更改密码 url :
如果 origin 不是潜在可信源 ,则返回失败。
断言:origin 是一个元组源 。
令 url 为一个新的 URL ,
其值设置如下:
方案
origin 的方案
主机
origin 的主机
端口
origin 的端口
路径
« ".well-known", "change-password" »。
返回 url 。
源
"https://example.com/" 的更改密码
url 是
"https://example.com/.well-known/change-password"。
服务器应将对于某个源 的更改密码
url 的 HTTP 请求 重定向到用户可在其上更改密码的实际页面,方式是返回一个具有 302、303 或 307 重定向状态
的响应 ,并带有 Location 头。[FETCH] [HTTP-SEMANTICS]
客户端在请求更改密码
url 时必须处理此类重定向。
注: 上述段落将服务器限制为使用
临时重定向码。
参见 Issue 13 。
如有必要,服务器可以响应一个 HTML 文档,其中包含一个
http-equiv
pragma 指令,并处于刷新状态 。[HTML] 客户端在请求更改
密码 url 时应处理此类重定向。
根据 RFC8615 §1.1 知名
URI 的适当使用 ,服务器不得将实际的更改密码页面放置在更改密码 url 处。客户端在请求更改密码 url 时必须处理ok 状态 响应。
注: 实现在显示更改密码 url 时,可能希望使用 ToUnicode 。[IDNA]
使用来自 [RESPONSE-CODE-RELIABILITY] 的测试某个
源的响应状态码的可靠性 。
4. IANA
考虑事项
4.1.
change-password 知名 URI
本文档定义了“.well-known”URI change-password。
此注册将提交给 IESG 进行审查、批准,并使用
[WELL-KNOWN] 中定义的
模板向 IANA 注册,如下所示:
URI 后缀
change-password
变更控制者
W3C
规范文档
本文档是相关规范。(参见 § 3 更改密码 URL )
相关信息:
无。
致谢
感谢
Anne van Kesteren、
Cl1608Ho、
Dan Bernstein、
David Singer、
Dean Jackson、
Florian Rivoal、
John Wilander、
Maciej Stachowiak、
Mark Nottingham、
Mike West 和
Ricky Mondello
对本提案提供的反馈。它的所有特性都归功于他们,而所有 bug 都归我。
文档
约定
一致性要求通过描述性断言
与 RFC 2119 术语的组合来表达。
规范性部分中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、
“MAY”和“OPTIONAL”
应按照 RFC 2119 中的描述进行解释。
然而,为了可读性,
这些词在本规范中并非全都以大写字母出现。
除明确标记为非规范性的节、示例和注记之外,
本规范的全部文本都是规范性的。[RFC2119]
本规范中的示例用“for example”一词引入,
或者使用 class="example"
与规范性文本分开,
如下所示:
信息性注记以“Note”一词开头,
并使用 class="note"
与规范性文本分开,
如下所示:
Note,这是一个信息性注记。
作为算法一部分以命令式措辞表达的要求
(例如“strip any leading space characters”
或“return false and abort these steps”)
应解释为具有引入该算法时所使用的关键词
(“must”、“should”、“may”等)的含义。
以算法或特定步骤形式表述的一致性要求
可以用任何方式实现,
只要最终结果等价即可。
特别是,本规范中定义的算法旨在易于理解,
并不旨在具有高性能。
鼓励实现者进行优化。
索引
由本
规范定义的术语
由引用
定义的术语
参考文献
规范性参考文献
[FETCH]
Anne van Kesteren。Fetch 标准 。现行
标准。URL:https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren;等。HTML 标准 。
现行标准。URL:https://html.spec.whatwg.org/multipage/
[HTTP-SEMANTICS]
R. Fielding,编;M. Nottingham,编;J. Reschke,编。HTTP
语义 。2022 年 6 月。互联网
标准。URL:https://httpwg.org/specs/rfc9110.html
[INFRA]
Anne van Kesteren;Domenic Denicola。Infra
标准 。现行标准。URL:https://infra.spec.whatwg.org/
[RESPONSE-CODE-RELIABILITY]
Ricky Mondello;Theresa O'Connor。检测 HTTP 状态码的
可靠性 。CG-DRAFT。URL:https://wicg.github.io/change-password-url/response-code-reliability.html
[RFC2119]
S. Bradner。用于在 RFC 中
表示要求等级的关键词 。1997 年 3 月。当前最佳实践。URL:https://datatracker.ietf.org/doc/html/rfc2119
[RFC7231]
R. Fielding,编;J. Reschke,编。超文本传输
协议(HTTP/1.1):语义和内容 。2014 年 6 月。拟议标准。URL:https://httpwg.org/specs/rfc7231.html
[SECURE-CONTEXTS]
Mike West。安全上下文 。2023 年 11 月
10 日。CR。URL:https://www.w3.org/TR/secure-contexts/
[URL]
Anne van Kesteren。URL 标准 。现行标准。
URL:https://url.spec.whatwg.org/
[WELL-KNOWN]
M. Nottingham。知名统一资源
标识符(URI) 。2019 年 5 月。拟议标准。URL:https://www.rfc-editor.org/rfc/rfc8615
[IDNA]
Mark Davis;Michel Suignard。Unicode IDNA
兼容性处理 。2023 年 9 月 5 日。Unicode 技术标准 #46。URL:https://www.unicode.org/reports/tr46/tr46-31.html
问题索引