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

On Mon, Apr 9, 2018 at 9:18 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> On Mon, Apr 9, 2018 at 9:21 AM, John Wilander <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.

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.

-mike