From 260c3c63be345c6dbdc41a738e4b74ac85f06382 Mon Sep 17 00:00:00 2001 From: Theresa O'Connor Date: Mon, 3 Jun 2024 20:15:46 +0000 Subject: [PATCH] Drop a reference to Request's synchronous flag, which was removed from the Fetch spec. (#47) SHA: 5650b772595b7ec63b41fc9b7b88c6adf9aa6d82 Reason: push, by hober Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- change-password-url.html | 1133 ++++++++++++++++++++++++++------------ 1 file changed, 772 insertions(+), 361 deletions(-) diff --git a/change-password-url.html b/change-password-url.html index d0f7696..a659f8c 100644 --- a/change-password-url.html +++ b/change-password-url.html @@ -5,12 +5,10 @@ A Well-Known URL for Changing Passwords - - + - - - + - + - + - + - - + -

A Well-Known URL for Changing Passwords

-

Editor’s Draft,

+

Editor’s Draft,

More details about this document
@@ -473,7 +538,7 @@

A Well-Known URL for Changing Passwords

-

Copyright © 2022 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.

+

Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

@@ -503,7 +568,7 @@

public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

-

This document is governed by the 2 November 2021 W3C Process Document.

+

This document is governed by the 03 November 2023 W3C Process Document.

@@ -548,12 +613,12 @@

1. Sites currently lack a way to programmatically advertise where a user can change their password. By proposing a well-known URL for changing passwords, this specification enables password managers to help users change their passwords on sites which support it.

2. Infrastructure

-

This specification depends on the Infra Standard. [INFRA]

+

This specification depends on the Infra Standard. [INFRA]

This specification uses terminology from the Fetch, HTML, HTTP, and -URL standards. [FETCH] [HTML] [HTTP-SEMANTICS] [URL]

+URL standards. [FETCH] [HTML] [HTTP-SEMANTICS] [URL]

3. Change Password URLs

A change password url of an origin is a URL that points to a resource that clients can use to discover where a user should go to update their password on origin.

Given an origin, clients generate a change password url by running these steps:

@@ -561,19 +626,19 @@

3.

  • If origin is not a potentially trustworthy origin, return failure.

  • -

    Assert: origin is a tuple origin.

    +

    Assert: origin is a tuple origin.

  • Let url be a new URL with values set as follows:

    scheme
    -

    origin’s scheme

    +

    origin’s scheme

    host
    -

    origin’s host

    +

    origin’s host

    port
    -

    origin’s port

    +

    origin’s port

    path

    « ".well-known", "change-password" ».

    @@ -582,17 +647,17 @@

    3.

    Return url.

    The change password url for origin "https://example.com/" is "https://example.com/.well-known/change-password".

    -

    Servers should redirect HTTP requests for an origin’s change password url to the actual page on which users may change their password by returning a response with a redirect status of 302, 303, or 307, and a Location header. [FETCH] [HTTP-SEMANTICS] Clients must handle such redirects when requesting a change password url.

    -

    Note: The above paragraph restricts servers to using temporary redirect codes. +

    Servers should redirect HTTP requests for an origin’s change password url to the actual page on which users may change their password by returning a response with a redirect status of 302, 303, or 307, and a Location header. [FETCH] [HTTP-SEMANTICS] Clients must handle such redirects when requesting a change password url.

    +

    Note: The above paragraph restricts servers to using temporary redirect codes. See Issue 13.

    -

    If necessary, servers may respond with an HTML document containing an http-equiv pragma directive in the refresh state. [HTML] Clients should handle such redirects when requesting a change password url.

    +

    If necessary, servers may respond with an HTML document containing an http-equiv pragma directive in the refresh state. [HTML] Clients should handle such redirects when requesting a change password url.

    Servers must not locate the actual change password page at the change password url, per RFC8615 §1.1 Appropriate Use of Well-Known URIs. Clients must handle ok status responses when requesting a change password url.

    -

    Note: Implementations might want to use ToUnicode when displaying change password urls. [IDNA]

    -

    Make use of test the reliability of an origin’s response status codes from [RESPONSE-CODE-RELIABILITY].

    +

    Note: Implementations might want to use ToUnicode when displaying change password urls. [IDNA]

    +

    Make use of test the reliability of an origin’s response status codes from [RESPONSE-CODE-RELIABILITY].

    4. IANA considerations

    4.1. The change-password well-known URI

    This document defines the “.well-known” URI change-password. -This registration will be submitted to the IESG for review, approval, and registration with IANA using the template defined in [WELL-KNOWN] as follows:

    +This registration will be submitted to the IESG for review, approval, and registration with IANA using the template defined in [WELL-KNOWN] as follows:

    URI suffix
    @@ -634,7 +699,7 @@

    [RFC2119]

    + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

    Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", @@ -648,20 +713,22 @@

    , like this:

    Note, this is an informative note.

    -

    Conformant Algorithms

    -

    Requirements phrased in the imperative as part of algorithms +

    +

    Conformant Algorithms

    +

    Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

    -

    Conformance requirements phrased as algorithms or specific steps +

    Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

    +

    Index

    @@ -670,175 +737,55 @@

    change password url, in § 3
  • generate a change password url, in § 3 - - - - - - - - - - - - - - - - - - - -

    Terms defined by reference

    • [FETCH] defines the following terms:
        -
      • ok status -
      • redirect status -
      • request -
      • response +
      • ok status +
      • redirect status +
      • request +
      • response
    • [HTML] defines the following terms:
        -
      • host -
      • http-equiv -
      • port -
      • refresh state -
      • scheme -
      • tuple origin +
      • host +
      • http-equiv +
      • port +
      • refresh state +
      • scheme +
      • tuple origin
    • [IDNA] defines the following terms:
        -
      • ToUnicode +
      • ToUnicode
    • [RESPONSE-CODE-RELIABILITY] defines the following terms:
        -
      • test the reliability of an origin's response status codes +
      • test the reliability of an origin's response status codes
    • [RFC7231] defines the following terms:
        -
      • location +
      • location
    • [SECURE-CONTEXTS] defines the following terms:
        -
      • potentially trustworthy origin +
      • potentially trustworthy origin
    • [URL] defines the following terms:
        -
      • URL -
      • host -
      • origin -
      • path -
      • port -
      • scheme +
      • URL +
      • host +
      • origin +
      • path +
      • port +
      • scheme

    References

    @@ -849,7 +796,7 @@

    N
    [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://www.rfc-editor.org/rfc/rfc9110 +
    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] @@ -868,71 +815,535 @@

    N

    Informative References

    [IDNA] -
    Mark Davis; Michel Suignard. Unicode IDNA Compatibility Processing. 26 August 2022. Unicode Technical Standard #46. URL: https://www.unicode.org/reports/tr46/tr46-29.html +
    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

    Issues Index

    - - + + + \ No newline at end of file