I have some architectural queries about UAF implementations after considering FIDO 2.0 spec:
In my problem,
I need to establish that device has an embedded authenticator and then extablish connection between FIDO Client to FIDO FP Authenticator .
I am not sure what is FIDO client... is it a separate software which interacts with ASM (Authenticator specific module) and Relying party. or Browser is a FIDO client.
Could you please clarify this because some spec says FIDO client and browser are different entites?
Hi,
UAF is unrelated to WebAuthn, and not part of FIDO2. How communication between client and authenticator works is out of scope for WebAuthn, which specifies only the JavaScript API - you may be looking for FIDO CTAP instead. As an app developer, you should not need to care about how the client finds and connects to authenticators.
In WebAuthn the client and the browser is the same thing. We're aware that there is some duplicate terminology in the spec; we're tracking that in #358.
Does that answer your questions?
@pkuntal FIDO client is the same for all FIDO protocols. It's a layer that connects authenticator and RP and ensures validity of the connection. So it can be browser, desktop application, mobile application, platform(i.e. android/ios).
@herrjemand : I need to implement UAF as authenticator is embedded in my platform (in secured OS). my only confusion is if browser receives FIDO authentication calls from RP/web server, how would it communicate to ASM module deployed on my platform?
Missing piece is communication between (Browser(FIDO client) and ASM) not able to find any relevant info about this link.
@emlun UAF is FIDO protocol and can be implemented if device contains authenticator, my question was how one can establish connection between browser and ASM. and CTAP is required only for roaming authenticator which is not my usecase.
WebAuthn intentionally does not specify how the browser connects to the authenticator; see §6. WebAuthn Authenticator Model (emphasis added):
The Web Authentication API implies a specific abstract functional model for an authenticator. This section describes that authenticator model.
Client platforms MAY implement and expose this abstract model in any way desired. [...]
For authenticators, this model defines the logical operations that they MUST support, and the data formats that they expose to the client and the Relying Party. However, it does not define the details of how authenticators communicate with the client platform, unless they are necessary for interoperability with Relying Parties. For instance, this abstract model does not define protocols for connecting authenticators to clients over transports such as USB or NFC. [...]
Establishing the connection between browser and authenticator is an implementation detail internal to the browser and/or OS. CTAP is one standardised way to do that which requires no additional integration into the browser. Perhaps it might be possible for an OS driver to expose your ASM to the browser as a CTAP USB HID device, for example, but if your ASM can't be shimmed into CTAP then it will require the browser to directly integrate with it with custom code.
Anyway, this issue is out of scope for WebAuthn. This needs to be handled by the browsers and/or your platform OS.
@emlun said:
Anyway, this issue is out of scope for WebAuthn.
Well, not exactly. Some feel that they have use cases for being able to use a UAF authenticator "underneath" the webauthn API. There are pull requests queued which add the necessary language to the webauthn spec:
Add credential type uaf: https://github.com/w3c/webauthn/pull/407
Add uaf attestation format: https://github.com/w3c/webauthn/pull/408
The above PRs are attached to the "webauthn Level 2" milestone (L2-WD-00)
In any case, if there are folks, such as perhaps @pkuntal, who feel they have actual deployment use cases for such functionality, they really ought to weigh-in on this discussion in order to help justify accepting the above PRs.
@emlun :
Establishing the connection between browser and authenticator is an implementation detail internal to the browser and/or OS.---- this is what i am looking for as there is no SDK for Windows OS.
Additionally, CTAP is just a protocol and required only for roaming authenticator and my usecase is related to embedded authenticator not roaming authenticator. Mentioning CTAP is kind of confusing.
@equalsJeffH : Currenly on Windows, If I call MakeCredential or GetAssertion methods, these call are consumed by "Windows Hello". All I want to know If I put my own authenticator in device (embedded authenticator) how can I discover new Authenticator and route MakeCredential call to embedded authenticator.
@pkuntal:
As @emlun commented, in short, currently UAF is NOT part of FIDO2/WebAuthN.
Whether UAF authenticator is embedded or not is irrelevant here. Also, currently there is no such thing as "embedded authenticator" in FIDO2. If in future, FIDO and WebAuthnN groups has to incorporate these type of authenticators, then IMO, there that will be another kind of authenticator class ("platform", "cross-platform") as well as another kind of credential type.
I cannot answer for other platforms, but regarding specifically to your windows question, currently windows will support "removable" "cross-platform" authenticators and "Windows Hello" "platform" authenticator. My advice, either go for external removable authenticators or "integrate" (only applicable for certain kind of use cases/form factors) with Windows Hello as of now OR work with FIDO/WebAuthN community for these types of use cases in next version of FIDO/WebAuthN specs as @equalsJeffH suggested.
Closing this issue as we are discussing strategy here instead of actual issue with webauthn spec.
Hi Akshay,
Thanks for your reply. I found embedded authenticator detail in FIDO2.0
spec :
https://www.w3.org/Submission/fido-web-api/#the-authenticatormakecredential-operation
Anyways, my question is more specific to Windows and I will see how I can
sort it.
On Wed, Jun 6, 2018, 1:17 PM Akshay Kumar notifications@github.com wrote:
Closed #928 https://github.com/w3c/webauthn/issues/928.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/webauthn/issues/928#event-1665450132, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ASfq_G2K537wfBPLRtGc8E8SjXvKDmJxks5t54kngaJpZM4UWn2w
.
Most helpful comment
@pkuntal FIDO client is the same for all FIDO protocols. It's a layer that connects authenticator and RP and ensures validity of the connection. So it can be browser, desktop application, mobile application, platform(i.e. android/ios).