Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preventSilentAccess() -- what effect does calling it have? #565

Closed
leshi opened this issue Sep 14, 2017 · 9 comments
Closed

preventSilentAccess() -- what effect does calling it have? #565

leshi opened this issue Sep 14, 2017 · 9 comments

Comments

@leshi
Copy link
Contributor

leshi commented Sep 14, 2017

The webauthn spec does not mention preventSilentAccess(). However, the credman spec does.

What does it mean for public key credentials? If it has a meaning, let's explicitly state that. If it doesn't, let's make it throw an error.

@balfanz
Copy link
Contributor

balfanz commented Sep 19, 2017

@jyasskin - can you advise here and then assign back to @leshi or unassign?

@AngeloKai
Copy link
Contributor

Given that this is a feature (though my guess is our end decision will just be return error for this method), I am putting on WD-07 milestone.

@AngeloKai AngeloKai added this to the WD-07 milestone Oct 25, 2017
@AngeloKai
Copy link
Contributor

AngeloKai commented Oct 25, 2017

@equalsJeffH @nadalin @YubicoDemo for tracking.

@leshi
Copy link
Contributor Author

leshi commented Oct 25, 2017

The danger with allowing "undefined behavior" or "methods that do nothing now, but will do things in the future" in the spec is the following: People may build libraries/websites that do the right thing now, but will break when we update the API to have behavior where things are currently NOOPs

@jcjones
Copy link
Contributor

jcjones commented Oct 25, 2017

I'm guessing we should say something.... somewhere.... like preventSilentAccess() will have no effect on authenticators which require a user ceremony, but setting that flag may potentially exclude authenticators which can operate without user intervention.

@jyasskin
Copy link
Member

credentials.preventSilentAccess() sets the origin-wide "prevent silent access flag" to true. That flag defaults to true, but the browser can set it to false if the user says to do so while signing in.

As I recently added to https://w3c.github.io/webauthn/#getAssertion

The get() implementation calls PublicKeyCredential.[[CollectFromCredentialStore]]() to collect any credentials that should be available without user mediation (roughly, this specification’s authorization gesture), and if it doesn’t find exactly one of those, it calls PublicKeyCredential.[[DiscoverFromExternalSource]]() to have the user select a credential source.

If the "prevent silent access flag" is true, then no credentials should be available without user mediation, so get() always falls back to [[DiscoverFromExternalSource]]. This is redundant with the current behavior of WebAuthn, which always returns an empty set from [[CollectFromCredentialStore]]. It does have an effect on passwords today, which return data from [[CollectFromCredentialStore]].

When we add touchless authenticators in L2, WebAuthn will start returning assertions from [[CollectFromCredentialStore]]. At that point, if a library has called preventSilentAccess() to block silent use of passwords, it'll also require the browser to check with the user if they want to use their touchless authenticator.

Is that the right behavior in that case? The user has done something—probably tap the "sign out" button—which indicates they want to be asked before the browser automatically uses their password to sign them in. Do they also want to be asked before the browser automatically uses their touchless authenticator to sign them in? If we think they probably do, then we're in a good place, with at most editorial changes needed to explain this in the spec. If we think they probably don't, then we need to change something.

@equalsJeffH
Copy link
Contributor

equalsJeffH commented Oct 30, 2017

@jyasskin wrote:

credentials.preventSilentAccess() sets the origin-wide "prevent silent access flag" to true. That flag defaults to true, but the browser can set it to false if the user says to do so while signing in.

however, note that credman does not at this time explicitly specify a means to unset the prevent silent access flag to false. It only says in Requiring User Mediation that a user agent could provide means to do so, eg as part of a credential chooser.

The user has done something—probably tap the "sign out" button—which indicates they want to be asked before the browser automatically uses their password to sign them in. Do they also want to be asked before the browser automatically uses their touchless authenticator to sign them in?

I tend to think "yes".

If we think they probably do, then we're in a good place, with at most editorial changes needed to explain this in the spec.

agreed. this seems congruent with @jcjones's suggestion (#565 (comment)) of saying something about this in the present spec level.

Seems to me we can do now for wd-07 or add this to the CR pile.

@nadalin
Copy link
Contributor

nadalin commented Nov 9, 2017

@jyasskin What is the status ?

@selfissued
Copy link
Contributor

I will create a PR based on @jcjones 's October 25th comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants