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: Mon, 09 Apr 2018 09:21:25 -0700
Message-id: <DF7CD109-0CEA-4592-8DC9-B76924961BC5@apple.com>
Cc: Brad Hill <hillbrad@gmail.com>, Jeffrey Yasskin <jyasskin@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
To: Daniel Veditz <dveditz@mozilla.com>
Hi Dan!

Thanks for your feedback.

> On Apr 4, 2018, at 12:28 PM, Daniel Veditz <dveditz@mozilla.com> wrote:
> 
> On Wed, Apr 4, 2018 at 11:25 AM, John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
> 1. Are you saying we should have additional well-known locations for these additional services?
> 2. Or are you saying we should have requirements on the markup of the page you end up on when loading .well-known/modify-credentials?
> 
> ​My first reaction was that it seemed strange (and limiting!) to have a working web page at a .well-known address​, and especially strange for a .well-known address to be a redirect. Are there any others that behave that way?
> 
> If instead it returned data about where to find the password change URL on the site we could easily add more information, such as the ones Brad suggested or where to find the programmatic log-in (no web page required) suggested in Mike's proposal.

Our thinking was like this:
What is the easiest for web developers to figure out? A JSON with a URL is just an abstraction, whereas a page, an HTTP redirect, or a page with a client-side redirect can be loaded directly in a browser to check that it’s working. Developers and users can even bookmark it. 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.

But we don’t have strong opinions on this. If page vs. JSON is blocking progress, we’d rather pick one and move ahead.

   Regards, John
Received on Monday, 9 April 2018 16:21:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 April 2018 16:21:53 UTC