Silent Authenticator - FIDO2 passkey alternative

[Nicholas Irving]

Afternoon.

I developed a Silent Authenticator using the FIDO2 passkey implementation and looking for advice on how to get better support for the concept.

https://youtube.com/shorts/tzAJW2FEZNQ?feature=shared

Currently I am using the Client Platform form WebAuthn4j test package to generate a packed response to a Ping Identity ForgeRock Access Manager implementation. What I would like to do is integrate it better to use more of the devices passkey implementation, but without having to use touch popup to generate passkeys directly. I know the security implementations are high, but could not think of a better solution at the moment.

As you can see the solution works, but keys are not secure. version 14 of android will provide better integration to allow me to become my own passkey provider, but I am trying to support devices prior to that version.

Has anybody done any work in that area? All I am after is to identify the device and give it a silent passkey. I can stepup to an actual passkey later, but with my approach I can protect it using PIN, face or touch by creating different intents that wrap the call, as well as extend the request payloads to indicate the type.

Please say if I am mad to do this, but trying to accommodate an old UAF pattern of swipe to auth in a modern framework where I can reuse the keys.

Regards

Nicholas Irving 

[My1]

I frankly dunno where exactly passkey specs are defined but while FIDO2 and U2F can act silently if asked to (in U2F it's even part of the discovery process), WebAuthn as far as I am aware has no concept for silent authenticators last time I checked.

authenticators being silent against the spec on their own can also be a true problem in terms of abusability, and per spec an authenticator that doesnt check presence and sets the UP bit to 0 should have its responses thrown out by most Web Servers adhering to the WebAuthn spec.

although one place where I can see silent authenticators being useful is as a method for a session keepalive, but wouldn't use that with a wireless authenticator that too easily stays connected on accident, but rather a USB or NFC-based one

--
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/CAMqs2CaWWxKL%3DB4UR3RCQOhFu8TVi%3Dc1bW6cKcJ-aHQGuUD72A%40mail.gmail.com.

[Tim Cappalli]

User presence checks are required for passkeys. User verification is optional.

---

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Nicholas Irving <nir...@darkedges.com>
Sent: Tuesday, October 31, 2023 23:22
To: fido...@fidoalliance.org <fido...@fidoalliance.org>
Subject: [FIDO-DEV] Silent Authenticator - FIDO2 passkey alternative

 

--

[Nicholas Irving]

Isn't the fact that a user has to interact with the device enough for a quick establishment of the identity to enable stepup later in the flow to provide verification? Thinking for watch applications where I can push users to a device to provide better verification services.

Regards

Nicholas Irving 

[rjhal...@gmail.com]

Give the tagline of a product we are now rolling out some thought.

 

“Passwordless SSO Authentication in a Zero Trust Environment”

 

If you do so I suspect that like I, you’ll see the value and importance of silent authentication and the authenticators that enable it.

 

And yes, the service and its related authenticator are based in part on FIDO2.

 

Rick

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNrzvqTOyjNwf%2Bz9Z9tyfZcJJ%2BVCtZMaBA%2BnU2-Oq9y9yw%40mail.gmail.com.

[My1]

But why silent tho? Is pressing a button so bad? 

[Nicholas Irving]

Thanks, will have a hunt.

Looking that this as more of a way to migrate a number of UAF authenticators to passkey in a more seamless manner and provide a middle ground in being able to choose Face/finger/pin instead of being jumbled into one. 

Would be nice to do that as part of the scheme too, but I am not sure of the appetite. For example we could ask for server side face with  liveness check to improve the assurance level given to that authenticator, instead of their was a user present but cannot tell which one it was.

Regards

Nicholas Irving 

[rjhal...@gmail.com]

Personally I agree but the pragmatist in me suggests those who use this stuff may not see it that way.

 

So when I consider “Passwordless SSO Authentication in a Zero Trust Environment” a lot jumps out at me all at once.

 

Naturally as an early adopter of FIDO2 before it was even called that, FIDO2 factors in to this  tag line in a big way.

 

So too does SSO and where SSO is concerned there are a couple of realities, one being there are many more folks using SSO than FIDO2. And those folks are accustom to a frictionless experience. That I see as sacrosanct.

 

That and the ZT thing present some tough hurdles to get over in order to reach a place where the FIDO2 ceremony for every SSO reauthentication, which of itself is a challenge, occurs silently yet with full identity proofing. Of course the first SSO authentication ceremony is a full up with gesture FIDO2 thing, but all following reauthentication’s are silent. Should auto identity proofing indicate the need then user interruption and input is necessary.  

 

Of course most implementations of SSO skip reauthentication altogether and simply verify the original log in session has not been closed. But that concept files in the face of never trust, always verify thereby necessitating FIDO2 reauthentication.

 

Rick

[Tammy Walker]

I have used a card such as debit or credit card with a quarter or dime in between phone and card. It triggers the NFC RFID function.

Thanks

--