W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2018

Re: Proposal: https://example.com/.well-known/modify-credentials

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 4 Apr 2018 12:47:56 +1000
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-Id: <514B7FBC-6895-4389-A251-6166F73FDA2B@mnot.net>
To: John Wilander <wilander@apple.com>
On 4 Apr 2018, at 9:27 am, John Wilander <wilander@apple.com> 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 wellknown-uri-review@ietf.org.
> # 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
> https://example.com/.well-known/modify-credentials 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.
> What are your thoughts?

Hi John,

Scheme restrictions aren't an issue; a well-known URL can specify what scheme(s) it can be used with (as long as they're covered by well-known; currently the set is (http, https, ws, wss).

The other way to do this would be some form of metadata in the response -- either a header or something in HTML (probably a new link relation in both cases would cover it). That's more verbose, but also would allow more flexibility. Have you considered that? (Not saying it's better necessarily).


Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 4 April 2018 02:48:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:03 UTC