- From: John Wilander <wilander@apple.com>
- Date: Tue, 10 Apr 2018 12:53:07 -0700
- To: Mike West <mkwst@google.com>
- Cc: Daniel Veditz <dveditz@mozilla.com>, Brad Hill <hillbrad@gmail.com>, Jeffrey Yasskin <jyasskin@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-id: <39BB0F61-518E-47AE-B724-178E7FBEF948@apple.com>
Hi Mike! > On Apr 9, 2018, at 11:08 PM, Mike West <mkwst@google.com> wrote: > > On Mon, Apr 9, 2018 at 9:18 PM Daniel Veditz <dveditz@mozilla.com <mailto:dveditz@mozilla.com>> wrote: > On Mon, Apr 9, 2018 at 9:21 AM, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote: > Native apps and password managers can just load the URL in the browser or an in-app WebView instead of fetching the JSON, parse it, and then load the page. > > Browsers or general purpose apps have to load it once (or a HEAD request at least) to see if it exists before showing the user that it's an option, and then load it again when the user selects it. You can't present a Log-in button that goes to a 404 page. A site-specific app could rely on that URL existing, but then it could just as easily have some other site-specific URL built-in. > > But we don’t have strong opinions on this. > > I don't either. I'll ask our password manager folks to chime in. > > If you're interested in doing something small today (and it sounds like Jeff at AgileBits is similarly inclined), then I'd suggest that we do something that's forward-compatible with something more robust tomorrow. For example, you could reserve a nested path for the change redirect you initially proposed (something like `/.well-known/credentials/modification-form`), and reserve the parent (`/.well-known/credentials/`) for future use. This leaves room for a more interestingly complicated solution in the future (perhaps a manifest of some sort could live at that URL, which browsers could consume?), while enabling baby steps today. Does a nested path win us something? https://example.com/.well-known/credentials could be defined in the future regardless of what name we use today, right? No strong opinions here, I just want to understand the arguments before we formalize this and send it for review. Perhaps page a better term than form? I mean modification-form v.s modification-page. > I think I agree with mnot@, by the way, that it would be totally possible to build in some hidden metadata to each sign-in form which passed information about change forms to a password manager. My intuition is that that would have lower adoption by developers, as it would require actual changes to their application, rather than the injection of a redirect at a higher layer. It might be useful to talk with developers on this point. It also has to be done and maintained for all pages with login functionality whereas the well-known page is a single thing. Regards, John
Received on Tuesday, 10 April 2018 19:53:34 UTC