Re: Proposal:

Hi all!

Sorry for the silence. We’ve worked this through with all of your feedback in mind and what we will propose is: <>
… and have it be restricted to HTTPS, and serve a page or a redirect to a page rather than JSON.

Our reasons why:
Password managers of today need a dedicated place to take users for the specific task of changing their password. We believe an explicit reference to "password change" increases the likelihood of developers getting it right and users not being navigated to a more general “Account Settings” page.
Websites that support both strong and legacy authentication may want to use separate pages for managing, say WebAuthn and password-based auth. User agents' and password managers' ability to help the user will increase if the well-known location request is distinct.
There is the wider scope of modifying credentials other than, or in addition to, passwords. Let’s save well-known locations with “credentials” for when we address that wider scope.
While we could propose both .well-known/credentials-modification and .well-known/password-change, we don’t want to cause confusion or end up having to load two locations and check for HTTP 404.
We changed from a verb to a noun to make the well-known location not sound as an action in itself. Just loading the page should not result in any state change.
We will put something more formal up on GitHub. But eventually, the spec needs a permanent home for IETF to refer to. Can we add it to the Credential Management API spec, Mike?

   Regards, John

> On Apr 12, 2018, at 2:48 PM, Peter Saint-Andre <> wrote:
> On 4/3/18 5:27 PM, John Wilander wrote:
>> Hi WebAppSec!
>> We’re thinking of proposing a well-known URL location where users can change their password or other credentials. Since this working group owns the Credential Management spec, we’d like to get your feedback before we email
>> # The problem
>> When a password/credential manager wants to facilitate a user updating their credentials, there isn't a good way to determine which part of the relevant website to send the user to or to signal to the website that the user's intent is to modify their credentials.
>> # The proposal
>> as a well-known URL endpoint that signals user intent to modify their credentials. The web server can serve a page at this location or do an HTTP or client-side redirect. The location should be restricted to HTTPS, including any redirects. RFC5785 doesn’t mention scheme restrictions but hopefully we can work that out with the reviewers.
> Given the extensive list discussion, it's not fully clear to me what the
> proposal is at this point. John, would you mind creating a strawman
> document (at GitHub or wherever) so it's easier to track?
> Thanks!
> Peter

Received on Friday, 20 April 2018 21:07:24 UTC