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

Add a WebDriver Virtual Authenticator extension #1256

Merged
merged 36 commits into from Oct 2, 2019
Merged

Conversation

nsatragno
Copy link
Member

@nsatragno nsatragno commented Jul 10, 2019

This change introduces a WebDriver Extension that lets clients create and manipulate virtual authenticators. This API can be used by web developers to write tests against the WebAuthn API and it's also possible to leverage it on WPTs through testdriver.js. Being able to instantiate virtual authenticators on WPTs would be a major step towards enabling testing a larger surface area of the API across multiple browsers.

Fixes #1236


Preview | Diff

Copy link
Contributor

@equalsJeffH equalsJeffH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thx @nsatragno !

T3-M4 pushed a commit to bayandin/chromedriver that referenced this pull request Jul 23, 2019
Add the `RemoveVirtualAuthenticator` command to ChromeDriver.

A draft of the proposed addition to the specification is available at
w3c/webauthn#1256

This is one in a series of patches intended to create a Testing API for
WebAuthn, for use in Web Platform Tests and by external webauthn tests.

For an overview of overall design, please see
https://docs.google.com/document/d/1bp2cMgjm2HSpvL9-WsJoIQMsBi1oKGQY6CvWD-9WmIQ/edit?usp=sharing

Bug: 922572
Change-Id: I5b6094cc5eb9a52afc8ee89d548c3452a728b1fe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1713301
Auto-Submit: Nina Satragno <nsatragno@chromium.org>
Commit-Queue: John Chen <johnchen@chromium.org>
Reviewed-by: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#679727}
aarongable pushed a commit to chromium/chromium that referenced this pull request Aug 1, 2019
Add the `AddCredential` command to ChromeDriver.

A draft of the proposed addition to the specification is available at
w3c/webauthn#1256

This is one in a series of patches intended to create a Testing API for
WebAuthn, for use in Web Platform Tests and by external webauthn tests.

For an overview of overall design, please see
https://docs.google.com/document/d/1bp2cMgjm2HSpvL9-WsJoIQMsBi1oKGQY6CvWD-9WmIQ/edit?usp=sharing

Bug: 922572
Change-Id: Id9b9fb75ab6682126d5d1275b12785640b7f0053
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1729963
Commit-Queue: Nina Satragno <nsatragno@chromium.org>
Auto-Submit: Nina Satragno <nsatragno@chromium.org>
Reviewed-by: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#683364}
T3-M4 pushed a commit to bayandin/chromedriver that referenced this pull request Aug 2, 2019
Add the `AddCredential` command to ChromeDriver.

A draft of the proposed addition to the specification is available at
w3c/webauthn#1256

This is one in a series of patches intended to create a Testing API for
WebAuthn, for use in Web Platform Tests and by external webauthn tests.

For an overview of overall design, please see
https://docs.google.com/document/d/1bp2cMgjm2HSpvL9-WsJoIQMsBi1oKGQY6CvWD-9WmIQ/edit?usp=sharing

Bug: 922572
Change-Id: Id9b9fb75ab6682126d5d1275b12785640b7f0053
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1729963
Commit-Queue: Nina Satragno <nsatragno@chromium.org>
Auto-Submit: Nina Satragno <nsatragno@chromium.org>
Reviewed-by: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#683364}
@jcjones
Copy link
Contributor

jcjones commented Aug 12, 2019

Note: I've asked @AutomatedTester to do a review pass here from the Mozilla side.

index.bs Show resolved Hide resolved

The [=remote end steps=] are:

1. If |authenticatorId| does not match any [=Virtual Authenticator=] stored in the [=Virtual Authenticator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as above?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are deleting it, if it is not there does it really matter is what I mean. If you feel it does matter then leave it in.


The [=remote end steps=] are:

1. If |authenticatorId| does not match any [=Virtual Authenticator=] stored in the [=Virtual Authenticator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to error here when there are not items that match. Can't we just try do the right thing and if not just go meh?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean exactly? If the authenticatorId doesn't match, just don't do anything and return success? If that's the case, that would potentially be a source of confusion for developers that's easily avoided by returning an error... the UA has to check for the existance of the authenticator anyway. Maybe I'm misunderstanding you?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are deleting it, if it is not there does it really matter is what I mean. If you feel it does matter then leave it in.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does matter. The most likely scenario for trying to delete something that is not there is a developer oversight. Catching that early means less headaches. And if say a library wanted that functionality, they could catch the error and pretend nothing happened.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the above conversation can be set as resolved now?

index.bs Show resolved Hide resolved
Copy link
Member Author

@nsatragno nsatragno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking a look. I addressed the comments below:

index.bs Show resolved Hide resolved

The [=remote end steps=] are:

1. If |authenticatorId| does not match any [=Virtual Authenticator=] stored in the [=Virtual Authenticator
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean exactly? If the authenticatorId doesn't match, just don't do anything and return success? If that's the case, that would potentially be a source of confusion for developers that's easily avoided by returning an error... the UA has to check for the existance of the authenticator anyway. Maybe I'm misunderstanding you?

index.bs Show resolved Hide resolved
@jcjones
Copy link
Contributor

jcjones commented Sep 3, 2019

Just a question @nsatragno:

In the algorithm for adding a Virtual Authenticator, we emit a WebDriver error when the parameter doesn't have a valid value. If, for example, a browser initially only supported protocol being ctap1/u2f, would emitting a WebDriver error for all other protocols (e.g. ctap2) permit the relevant tests to continue on, or is such an error fatal?

@jcjones
Copy link
Contributor

jcjones commented Sep 4, 2019

Just a question @nsatragno:

In the algorithm for adding a Virtual Authenticator, we emit a WebDriver error when the parameter doesn't have a valid value. If, for example, a browser initially only supported protocol being ctap1/u2f, would emitting a WebDriver error for all other protocols (e.g. ctap2) permit the relevant tests to continue on, or is such an error fatal?

To clarify, I think the WebDriver implementation for WebAuthn could be used then for FIDO U2F's JS API, which would let us write Web Platform Tests for U2F. Which I want to get, if at all possible.

Other than this question, I am ready to grant this review from the Mozilla side.

Copy link
Member Author

@nsatragno nsatragno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If, for example, a browser initially only supported protocol being ctap1/u2f, would emitting a WebDriver error for all other protocols (e.g. ctap2) permit the relevant tests to continue on, or is such an error fatal?

To clarify, I think the WebDriver implementation for WebAuthn could be used then for FIDO U2F's JS API, which would let us write Web Platform Tests for U2F. Which I want to get, if at all possible.

If the browser only supports a subset of the protocols, tests that create authenticators using that subset should work. For example, browsers could first support ctap1/u2f to pass the U2F API WPTs and add support for ctap2 later.

Perhaps we can add a clarification to the spec as an additional step under the AddVirtualAuthenticator algo like

1. If the |parameters|' |protocol| property is not supported by the user agent,
   return a [=WebDriver error=] with [=WebDriver error code=] [=invalid argument=].

So yes, this API would let us write tests for the U2F JS API, too :)

What do you think?


The [=remote end steps=] are:

1. If |authenticatorId| does not match any [=Virtual Authenticator=] stored in the [=Virtual Authenticator
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does matter. The most likely scenario for trying to delete something that is not there is a developer oversight. Catching that early means less headaches. And if say a library wanted that functionality, they could catch the error and pretend nothing happened.

@jcjones
Copy link
Contributor

jcjones commented Sep 5, 2019

What do you think?

I think I hit 'approve' :)

@equalsJeffH
Copy link
Contributor

Hi @nsatragno -- IIUC, your answer to @jcjones in #1256 (review) implies that returning a webdriver error does not necessarily halt a testing run, correct?

Also, IIUC, you have not as yet added the step proposed in #1256 (review) to the AddVirtualAuthenticator algo. Is @jcjones' appoval contingent on that being added?

HTH, equalsJeffH

@jcjones
Copy link
Contributor

jcjones commented Sep 10, 2019

The clarification doesn't sound normative to me, but I'd be happy to wait until it is available before merging rather than worrying about it more in the future.

@jabazorius
Copy link

help

@akshayku
Copy link
Contributor

Lets discuss it next week in TPAC where more Edge folks will be present and can review it more thoroughly.

Copy link
Contributor

@akshayku akshayku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

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

Successfully merging this pull request may close these issues.

Create a WebDriver Virtual Authenticator extension to allow automated testing
8 participants