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

On Fri, Apr 20, 2018 at 11:12 PM John Wilander <wilander@apple.com> wrote:

> Hi all!
>
> Sorry for the silence. We’ve worked this through with all of your feedback
> in mind and what we will propose is:
> https://example.com/.well-known/password-change
> … and have it be restricted to HTTPS, and serve a page or a redirect to a
> page rather than JSON.
>

Sounds fine to me as a first step.


> Our reasons why:
>
>    1. Password managers of today need a dedicated place to take users for
>    the specific task of changing their password. We believe an explicit
>    reference to "password change" increases the likelihood of developers
>    getting it right and users not being navigated to a more general “Account
>    Settings” page.
>    2. Websites that support both strong and legacy authentication may
>    want to use separate pages for managing, say WebAuthn and password-based
>    auth. User agents' and password managers' ability to help the user will
>    increase if the well-known location request is distinct.
>    3. There is the wider scope of modifying credentials other than, or in
>    addition to, passwords. Let’s save well-known locations with “credentials”
>    for when we address that wider scope.
>    4. While we could propose both .well-known/credentials-modification
>    and .well-known/password-change, we don’t want to cause confusion or end up
>    having to load two locations and check for HTTP 404.
>    5. We changed from a verb to a noun to make the well-known location
>    not sound as an action in itself. Just loading the page should not result
>    in any state change.
>
> We will put something more formal up on GitHub. But eventually, the spec
> needs a permanent home for IETF to refer to. Can we add it to the
> Credential Management API spec, Mike?
>

I don't think it's a good fit for that spec (which I already intend to
break up into smaller pieces), as I'd prefer for it to narrowly define the
web-facing API, and not ancillary things about credentials. I'd suggest
just drafting a quick ID and submitting it via
https://datatracker.ietf.org/submit/. mnot@ might be able to help you
through the process of finding way to publish it as an informational RFC
(and might also be able to tell you if this is at all a reasonable response
:) ).

I've used Martin Thompson's https://github.com/martinthomson/i-d-template
for this in the past to produce exactly the textual format the IETF wants.
It's a bit of overhead for a one-off, but pretty straightforward to use.

-mike

   Regards, John
>
> On Apr 12, 2018, at 2:48 PM, Peter Saint-Andre <stpeter@mozilla.com>
> wrote:
>
> On 4/3/18 5:27 PM, John Wilander wrote:
>
> Hi WebAppSec!
>
> We’re thinking of proposing a well-known URL location where users can
> change their password or other credentials. Since this working group owns
> the Credential Management spec, we’d like to get your feedback before we email
> wellknown-uri-review@ietf.org <wellknown-uri-review@ietf.org>.
>
> # The problem
> When a password/credential manager wants to facilitate a user updating
> their credentials, there isn't a good way to determine which part of the
> relevant website to send the user to or to signal to the website that the
> user's intent is to modify their credentials.
>
> # The proposal
> https://example.com/.well-known/modify-credentials as a well-known URL
> endpoint that signals user intent to modify their credentials. The web
> server can serve a page at this location or do an HTTP or client-side
> redirect. The location should be restricted to HTTPS, including any
> redirects. RFC5785 doesn’t mention scheme restrictions but hopefully we can
> work that out with the reviewers.
>
>
> Given the extensive list discussion, it's not fully clear to me what the
> proposal is at this point. John, would you mind creating a strawman
> document (at GitHub or wherever) so it's easier to track?
>
> Thanks!
>
> Peter
>
>
>
>
>