WebAuthn Extensions for the JS client

[Dani Mező]

Hi devs, Yuriy,

I am looking at the WebAuthn extensions and am a bit confused. So Client Extensions  in the spec can be used to communicate additional data with the client, but in WebAuthn, the client is what's behind the user agent implementation of the create() & get() api. What if the Relying Party consists of multiple layers that would need to pass some data to each other? For example the FIDO2 server could pass additional data to the JS client that calls the browser API (or the other way around), that is independent of the WebAuthn spec? As I understand it, unknown extensions will be ignored by the authenticators.. So my question is:

Question 1: Can Client Extensions be used, to communicate custom data between the FIDO2 server and the JS client (that mediates between the browser API and the FIDO2 server)?

An example where this is relevant: in context registration in the WebAuthn spec and the Conformance Api, the spec says [1]:

• The server stores the credential public key in its database and associates it with the user as well as with the characteristics of authentication indicated by attestation, also storing a friendly name for later use.
  

I assume a friendly name for later use is suppose to come from the user, like the credential can be named by the user upon credential creation. Unfortunately neither the WebAuthn spec nor the Conformance Test Api really helps to accomplish this. The Conformance Test Api defines the payload which is to be submitted to the FIDO2 server upon finishing up the registration ceremony in ServerPublicKeyCredential [2]:

dictionary ServerPublicKeyCredential : Credential { 

     required DOMString type; 

     required DOMString id; 

     required ServerAuthenticatorResponse response;
     AuthenticationExtensionsClientOutputs getClientExtensionResults; 

};

It can be seen that in this object there is no room for such data, other than in the AuthenticationExtensionsClientOutputs, but that is regulated by the WebAuthn spec to be coming from the client (the user agent, i.e. the browser) as the computed extension output of a matching client extension input. So where could we put it?

Question 2: Can the JS client (that mediates between the browser WebAuthn api and the FIDO2 server) put data into the AuthenticationExtensionsClientOutputs  independently of client or authenticator processing, just before it would submit the result to the FIDO2 server? (of course our FIDO2 server would be prepared to consume it)

Thanks for the responses in advance,

Daniel Mező

[1] https://www.w3.org/TR/webauthn-3/#sctn-sample-registration

[2] https://github.com/fido-alliance/conformance-test-tools-resources/blob/master/docs/FIDO2/Server/Conformance-Test-API.md#serverpublickeycredential

[John Bradley]

Sort answer is no you can't practically use extensions for that. 

You could possibly send something in the challenge, depending on size. 

John B. 

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/0870db94-1945-4dc9-9134-5e5aad6db57dn%40fidoalliance.org.

[Emil Lundberg]

Hi Dani,

To add to what John said: the example you refer to is only that, an example (the whole of section 1.3 is non-normative, as stated at its beginning). The "friendly name for later use" described there is a common UX feature separate from the WebAuthn API - just an additional database field that the RP can set however it likes. Most commonly the RP just asks the user to choose a nickname for the new credential. Some RPs also pre-fill the input field with a device name from authenticator attestation metadata if available, but that is not required in any way.

Emil Lundberg

Software Engineer | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAANoGhLCNOHPSxp%3Dx%3Dr7FaLMbK6SsbMgh%2BNLijZinh2uRTYe3w%40mail.gmail.com.