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

Hey John!

I think this is a pretty reasonable thing to do, and I'll chat with
Chrome's password management folks to see if they're interested in the
same. Have you thought about how you'd expose this functionality to your
user? I suppose you'd need to prefetch the endpoint to see if it returned
anything useful, for example?

That said, I share Brad's opinion that it would be possible to do a bit
more if we have server-side cooperation, and that there's real value in
creating more opportunities for that kind of cooperation. I'd sketched out
an automated password-changing mechanism a while back (
https://mikewest.github.io/change-password/), which might be a reasonable
place to start the conversation for something more robust if that's
something in which folks end up being interested.

-mike

On Wed, Apr 4, 2018 at 7:16 AM Brad Hill <hillbrad@gmail.com> wrote:

> I'd love the option for this to be just a bit more sophisticated.
> Discovery of the password change resource is just the first part of the
> authentication discoverability problem.  I'd argue that 2FA is a much
> bigger one.  It's been a dormant pet project of mine to write an browser
> extension that notifies users when 2FA is available on a site, and directs
> them to the appropriate settings page.  It would be even better if the well
> known resource could be authenticated and offer an indication of whether
> and what kind of 2FA is on, and the availability of advanced features like
> U2F or WebAuthentication.  This would allow the extension (and eventually
> the browser) could show the user a traffic light or similar for their
> security posture and encourage 2FA adoption.  e.g. if the browser knows
> you've used U2F on one site, it can notify you when you visit somewhere
> else where you could use it, without having to disclose that you are a U2F
> user to the site so they could make the promotion themselves.
>
> On Tue, Apr 3, 2018 at 9:04 PM John Wilander <wilander@apple.com> wrote:
>
>> Hi Jeffrey!
>>
>> On Apr 3, 2018, at 8:45 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>
>> I don't have a strong opinion about this, but have any existing password
>> managers or websites given you feedback about how they'd use this proposal?
>> For example, LastPass has an "Auto Change Password" option. Would this be
>> enough to help that work in more cases, or do they need something more
>> structured at the endpoint?
>>
>>
>> We run a popular password manager ourselves which is where this proposal
>> originates. In addition, we have discussed it with one other password
>> manager. Rather than speak for them I’ll see if I can get them to comment
>> straight to the list.
>>
>> Maybe we have password manager folks on the list already? Would this
>> well-known location be useful to you?
>>
>>    Regards, John
>>
>>
>> Jeffrey
>>
>> On Tue, Apr 3, 2018 at 4:32 PM John Wilander <wilander@apple.com> 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.
>>>
>>> # 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.
>>>
>>> What are your thoughts?
>>>
>>>    Regards, John
>>>
>>