Re: Comments on Credential Management Spec

Hi Tanvi, thanks for this feedback! I've replied inline, but it might make
sense to fork the thread (or file a GitHub issue!) if we want to have a
longer discussion about one or more of these.

On Wed, Apr 22, 2015 at 7:52 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:

>  Hi Mike,
>
> I went through the current version of the Credential Management spec (
> https://w3c.github.io/webappsec/specs/credentialmanagement/) and have
> some comments/questions.
>
> 1.2.3 - How do websites tell the credential manager that sign-in
> succeeded?  In example 3, we check for a response code of 200.  But most
> websites will return a 200 ok even if the sign-in failed, and they will
> just redisplay the login page.
>

In this example, we're not talking about a navigational form POST, but a
successful asynchronous submission to a sign-in API endpoint. I think the
latter is much less likely to send a 200 response for a failed login, but I
agree that that's not clear enough from the text. It's also not the case
that that's the only detection mechanism; the application could certainly
parse the response body for some sort of `success` signal.

I've added a note about that to the example:
https://github.com/w3c/webappsec/commit/da6eb858f19def86219c07cc09457d603d73fe5a


> 1.2.2 - What exactly happens when you fill federated credentials?  Is the
> Credential Manager just telling the website which of the providers you
> logged into the site with the last time to "kick off the sign-in flow"
>

The `FederatedCredential` object is, at the moment, a hint to the site
about what sign-in flow to trigger:
https://w3c.github.io/webappsec/specs/credentialmanagement/#examples-federated-signin
lays out how this would work today.


> or does it also seamlessly log you in without any popups from the identity
> providers used to go through an oauth flow?
>

This isn't part of the first pass at the API, but I'd certainly like to
figure out together how we can do it (see
https://w3c.github.io/webappsec/specs/credentialmanagement/#future-work).
Baby steps. :)


> 1.2.5 - Change Password.  It would be useful for websites to indicate to
> the credential management page when the user is on a change password page
> and whether or not the user needs to enter their current password before
> changing to a new one.  This way, it can try and avoid filling in the
> current password into the new password field.
>

I'd suggest that this can be done declaratively via `autocomplete`
attributes on the form (e.g. `<input type='password'
autocomplete='new-password'>`). Do you think we need an imperative
mechanism as well?


> 4.2.2 - In the case that a user has multiple credentials for a website, we
> don't want to reveal all of these to a website.  At this point, I assume
> the user-agent can pop up the Credential Chooser to ask the user which of
> the accounts it would like to login with.  Should we mention that in this
> algorithm?
>

Step 3 of
https://w3c.github.io/webappsec/specs/credentialmanagement/#request-locallystoredcredential-without-mediation
is meant to deal with exactly this case; if we're requesting without user
mediation, the algorithm returns `null` if there's not an unambigious
choice.

Basically, step 8 of
https://w3c.github.io/webappsec/specs/credentialmanagement/#request-credential
does the following:

1. Requests without user mediation (which we just discussed).
2. Returns a value if available.
3. Returns `null` if we shouldn't ask for user input.
4. Requests with user mediation.
5. Returns the result.

So, if a user has opted-into a world where they're logged into an origin
automagically, and they only have one credential, then #1 will return the
Credential right away. If either of those is not true, then we'll fall
through to user mediation in #4.

Does that help?


> 4.2.7 - What is the intent behind "Fuzzy Match".
>

It's often the case that `example.com`, `admin.example.com`, and `
subdomain.example.com` all have login forms. Using the PSL to group these
origins together will allow the credential manager to, in certain cases,
offer the user the option of using a set of credentials for this set of
origins.

I've tried to outline this scenario in
https://w3c.github.io/webappsec/specs/credentialmanagement/#security-cross-origin-leakage.
Is that helpful?


> 5.2 - When you clear private data in Firefox, it is for all origins (not
> for a specific site).  And clearing passwords isn't listed as one of the
> options.  From Number 4 here, clearing private data will set the mediation
> flag from false to true on all saved credentials where the user has opted
> out of mediation.  This can be a confusing experience for users - why
> aren't any of their passwords getting autofilled anymore?  Since the
> password hasn't changed, there is no reason for the Credential Manager to
> prompt the user to save the password again.  Hence, any UI we add for this
> situation would only be to ask the user if they want to autofill (like
> their browser did before they cleared private data).  I'm not sure it is
> worth interrupting the user to reselect this preference after they clear
> private data.  If they were clearing their passwords, this would make sense.
>

Chrome's "clear browsing data" dialog distinguishes between cookies and
site data on the one hand, and passwords on the other. Since a user who
clears her cookies is expressing an explicit intent to wipe her state on a
particular origin, it makes sense to ensure that the browser doesn't
subvert that intent by providing credentials to the site right away.

I'd also note that "autofill" is a completely separate topic from the API
proposed in this document. I don't intend to mandate browser behavior with
regard to autofill, as it's something that's fairly vendor-specific
already, and much more of a UI/UX question than something amenable to
normative declarations. The mandate in 5.2 is to prevent Credentials from
being explicitly delivered to a site via this API. If a vendor chooses to
continue autofilling passwords into forms on sites after a user clears
browsing data (as both Chrome and Firefox do today), they're totally free
to do so.

6.1.1 - Can credentials stored for http://example.com be made available to
> https://example.com?
>

Credentials can't be stored for `http://example.com/` via this API; it's
locked to privileged contexts. See step 3.3 of
https://w3c.github.io/webappsec/specs/credentialmanagement/#store-credential,
and step 3.3 of
https://w3c.github.io/webappsec/specs/credentialmanagement/#request-credential
.

(Again, this doesn't mean that the browser's autofill system can't choose
to offer users the ability to store credentials. It does mean that we don't
trust those sites to directly interact with the credential store.)

(Also: Chrome's autofill system refuses to fill `https://example.com/`
credentials into `http://example.com/`, but will happily go the other way.)

6.1.3 - In this example, could the user agent also offer credentials to
> completely different domains (ex: https://bar.com) via the Credential
> Chooser?  Perhaps example.com and bar.com are related somehow.  The
> credentials aren't given to bar.com unless the user explicitly chooses to
> send example.com credentials to bar.com.
>

The spec doesn't allow that, no. Credential objects have an `[[origin]]`
slot, and if it doesn't at least PSL-match the requesting origin, it
wouldn't be in the list of credentials offered via the chooser.

Is there a use case you're thinking of that we ought to support? I know
that Token Binding folks have something vaguely similar to this concept, so
I can see how it might be helpful for signing tokens, but it's not clear
that it's necessary (or valuable) for credentials


> 6.2 - typo, the word "like" is used twice in a row: other environments
> like like Workers
>

Good eye, thank you!
https://github.com/w3c/webappsec/commit/9e4d19a5b5050af3b86b741ef72f30a764c20f4f


> 7.2 - Is the iconURL really necessary?
>

If we want the browser to be able to display exciting UI to the user, then
an icon seems like a nice to have. I wouldn't insist on it (and it is
marked


> What do you mean by 'MUST be fetched with the credentials flag set to
> "omit"'?
>

s/flag/mode/ and it makes more sense:
https://fetch.spec.whatwg.org/#concept-request-credentials-mode

https://github.com/w3c/webappsec/commit/224283901c4bf7c5b28d90338dd52a48325b5839

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)