[webauthn] Possibility of client-only implementation of authenticator extensions?

dwaite has just created a new issue for https://github.com/w3c/webauthn:

== Possibility of client-only implementation of authenticator extensions? ==
Is it possible for a client to exclusively provide support for an authenticator extension?

Ill give an example using geolocation, although the two transactional forms seem equally valid:

I have a browser which knows the user's location, interfacing with an authenticator which does not support location information. My understanding is there is no way today within a client implementation to support answering this request for geolocation for an existing authenticator.

The first solution to this seems suboptimal - have the client behave as an intermediate authenticator, which loses the original attestation/signature/aaguid.

My understanding as well is that there isn't a way to write a new "client location" extension to be used when authenticator support is unavailable.

A second possibility for client support would be to put the client location information within the client collected data JSON document before communicating with authenticators. This would provide the same level of integrity protection as the other client collected data. However, this is not how client extensions work - extension data is returned as part of the javascript API, with no mechanism for a relying party to check integrity.

Is there a third solution envisioned for this problem? I personally would prefer to see the possibility for the browser to natively support extensions exclusively in the absence of a sufficient UX or capabilities on an authenticator, but it appears this cannot be done with any higher level of integrity than the preexisting methods available to a web page.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/912 using your GitHub account

Received on Wednesday, 16 May 2018 06:35:38 UTC