Re: Proposal:

Hi Mike!

> On Apr 9, 2018, at 11:08 PM, Mike West <> wrote:
> On Mon, Apr 9, 2018 at 9:18 PM Daniel Veditz < <>> wrote:
> On Mon, Apr 9, 2018 at 9:21 AM, John Wilander < <>> 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? 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