Unclear how to distinguish between: no credentials versus user dismisses login window (clicks X)

[seansan]

It is unclear how to distinguish between: no credentials versus user dismisses login window (clicks X)

In this example the else if statement is triggerd for both

• no credentials stored
• or when unmediated & more than 1 credentials stored
• or when users clicks cross/dismisses login

for the first two the flow is fine. But for the latter we would want to set a cookie or at least do something to not disturb the user again if he/she refreshes the page or moves to a seocnd page on our website

navigator.credentials.get({password: true, }).then(function(cred) { 
            if (cred) {
                } else if (typeof cred === "undefined") {

[mikewest]

We could consider either rejecting the promise, or returning null (as opposed to undefined) if the user explicitly chooses not to give credentials to a site. I guess I was a little reluctant to do that, as it reveals data about the user's state to the site that the user explicitly chose not to reveal. But I recognize that there's some value from a UX perspective in giving the user an appropriate response.

/cc @vabr-g

[vabr-g]

I wonder if this is something the user agent, as opposed to the website, should handle. We did recently add mechanisms to Chrome's UI which stop showing "Save password?" prompts for form-based password manager, if the user ignored them before. Solving this issue in the user agent seems more systematic than expecting every website to redo it. The user agent could have, say, some minimal time interval to wait between the account chooser is shown for the same origin. The time interval could also vary on the past behaviour of the site, etc. This seems to be doable with the current spec already.

[battre]

I am not opposed to exposing the dismissal reason but what do you think of the following heuristic:

navigator.credentials.get({unmediated: true}) can always be called, nothing changes.

navigator.credentials.get({unmediated: false}) memorizes a flag dismissed_by_user for each origin.

• if called in the context of a user gesture (e.g. login button):
  • case 1: No credentials available: resolve to undefined
  • case 2: User selects credential or credential can be provided without mediate: resolve to credential and set dismissed_by_user to false.
  • case 3: User dismisses the dialog: set dismissed_by_user to true.
• if called in the context of a page load (no user gesture):
  • if credentials may be provided without mediation, resolve to credentials.
  • otherwise:
  • if dismissed_by_user is true: return
  • otherwise:
    • case 1: No credentials available: resolve to undefined
    • case 2: User selects credential: resolve to credential
    • case 3: User dismisses the dialog: set dismissed_by_user to true, resolve to undefined

[seansan]

Thanks. To elaborate a little further on "no credentials versus user dismisses login window (clicks X)": I think there is a huge difference betw user mediation (clicking X button) and system dismissal in the case of no credential and my main point is that we should be able to dsitinguish betw the two somehow.

[battre]

Is that a gut feeling or do you have a concrete usecase in mind that would not be addressed by my proposal above? Note: I am not trying to push for that proposal, I am just trying to understand the situation better. I see some value in hiding complexity from the developer.

[seansan]

the proposal could work fine

as long as a user who clicks the cross (they dont want to) can be ignored somehow

On Fri, Dec 23, 2016 at 1:49 PM, Dominic Battre notifications@github.com wrote:

Is that a gut feeling or do you have a concrete usecase in mind that would not be addressed by my proposal above? Note: I am not trying to push for that proposal, I am just trying to understand the situation better. I see some value in hiding complexity from the developer.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/webappsec-credential-management/issues/23#issuecomment-268985310, or mute the thread https://github.com/notifications/unsubscribe-auth/AAn0a1h7pwC_jt_eK0y-xgys_QSeGu_Rks5rK8NFgaJpZM4KKXDd .