- From: John Wilander <wilander@apple.com>
- Date: Tue, 03 Apr 2018 20:22:32 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Mark! Thanks for your feedback. See inline below. > On Apr 3, 2018, at 7:47 PM, Mark Nottingham <mnot@mnot.net> wrote: > >> 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). Great! > 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). Where would this HTTP header or HTML head element occur? On the response/document for the well-known location or on login pages? We don’t want to cache or save specific locations since they may get stale, stateful things tend to become tracking vectors, and an HTML element sounds like a phishing injection vector. We believe the three options we bring up work for most developers – serve the page straight from the URL, make an HTTP redirect, or make a client-side redirect. You don’t think so? Are well-known URLs hard to support in general? Regards, John > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > >
Received on Wednesday, 4 April 2018 03:22:57 UTC