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

Hi Brad!

> On Apr 3, 2018, at 10:11 PM, 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.

I’m not sure I fully understand what you’re going for here, so let me ask some questions.

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? So that the user and browser extensions can read the status of the user’s account — 2FA on/off, WebAuthn on/off etc. — if they are authenticated?

3. Are you envisioning proactive extensions or password managers that iterate through these well-known locations, reading the status, and warning users? Or just when the user is about to authenticate?

4. If extensions etc can read the security level of accounts, what abuse cases do you see? Would it also be OK to have an indicator saying whether the user has a strong or weak password? That would be equally good for security warnings but would allow for identification of brute force targets. Are you saying this kind of status check can already be done for specific sites, just not in an automated way?

   Regards, John

> 
> On Tue, Apr 3, 2018 at 9:04 PM John Wilander <wilander@apple.com <mailto:wilander@apple.com>> wrote:
> Hi Jeffrey!
> 
> On Apr 3, 2018, at 8:45 PM, Jeffrey Yasskin <jyasskin@google.com <mailto: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 <mailto: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 <mailto: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 <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