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

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

From: John Wilander <wilander@apple.com>
Date: Tue, 10 Apr 2018 12:53:07 -0700
Message-id: <39BB0F61-518E-47AE-B724-178E7FBEF948@apple.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>
To: Mike West <mkwst@google.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

This archive was generated by hypermail 2.3.1 : Tuesday, 10 April 2018 19:53:35 UTC