Multiple Credential ids in allowCredential

[Santhosh Murugan]

Hi All,

Assuming  i am registered two platform authenticator in device.

During authentication, i pass these two credential id in allowCredential. Now which authenticator will pop up?

Whether popup will based on order of allow credential or both authenticator will popup or in general what happen when we send multiple credential id in allow credential

Thanks

[nuno sung]

Select any credential from the applicable credentials list.

So it would be a behavioral choice of user-agents/platforms/browsers.

santh...@gmail.com 在 2022年10月6日 星期四下午3:46:25 [UTC+8] 的信中寫道：

[DUBOUCHER Thomas]

If the platform sends a list of credential id, all those credentials are considered valid and ok wrt. privacy. The authenticator selects any credential it can use and create the assertion, as any credential in the list will be accepted for the authentication.

 

Best regards,

 

--

Thomas Duboucher

--
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/dec625c7-f8c1-4e73-91f1-99ae9c1acce2n%40fidoalliance.org.

[Philipp Junghannß]

normally you shouldnt be able to run 2 credentials for the same account on the same authenticator, as there is excludeCredentials.

and when you are using resident credentials you get asked but there you dont have an allowlist in the first place.

--

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/b3809039-a79e-4de8-a8ba-d66aac3cba67n%40fidoalliance.org.

[Santhosh Murugan]

Thank you all for your reply.

I understood that authenticator select any credential from the applicable credentials list.

my doubt is If i have two platform authenticator in device, which one examines credentials list first. As a user do we have control over selecting authenticator over multiple authenticators if  credentials list contain credential id of both authenticator or it is behavioral choice of device.

[Philipp Junghannß]

may I ask how you have multiple platform authenticators in your machine, to be honest I never heard of that before.

[nuno sung]

Could you provide the example of "two platform authenticator in device" in current ecosystem?

I will still assume it's user-agent's preference about how to act with multi available platform and cross-platform-authenticator(s).

santh...@gmail.com 在 2022年10月6日 星期四下午6:37:04 [UTC+8] 的信中寫道：

[Philipp Junghannß]

well when you have multiple roaming authenticators, usually platforms just ask to interact with the one you care about. with roaming and platform I only know windows so far which prefers itself

[Arshad Noor]

Santhosh,

It doesn't matter how many Security Keys and Platform Authenticators you
have connected to the computer - if they have ALL been used to register
a FIDO credential with a specific RP, and even if you have sent ALL
credential IDs in allowCredentials, and even when all of them start
lighting up, blinking, etc., the user can choose whichever Authenticator
they want. As long as that Authenticator has a private-key for that
RPID, it will be the one that will generate the assertion.

You need to look at FIDO with new eyes - it is unlike any other
authentication protocol in the past. Here is an example of how I usually
demonstrate the power of FIDO - the attached picture shows 13 keys
registered to the same account on our DEMO application on the internet -
you can try it out too if you want to see this work:
https://demo.strongkey.com.

@Philipp/@Nuno, it is trivial to connect multiple TPMs to a PC, where
all of them show up for access by an application. On a Linux PC, for
instance, each TPM simply shows up as /dev/tpm0, /dev/tpm1, /dev/tpm2,
.... FIDO credentials can be registered by any TPM if the software
chooses to use one TPM or another (if the user has taken "ownership" of
the device and it is ready to be used). I'm pretty sure Windows can do
the same thing too.

Arshad Noor
StrongKey

> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/b3809039-a79e-4de8-a8ba-d66aac3cba67n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:fido-dev+u...@fidoalliance.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eb7b4d82-8b6c-4fdb-a79f-f3cb83c5be5an%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eb7b4d82-8b6c-4fdb-a79f-f3cb83c5be5an%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[Santhosh Murugan]

Some android phones have both facial and fingerprint verification. In that case, I considered both as different platform authenticators. is it a wrong consideration?

Another case i considered is one registration in windows hello and another registration in security key or two registration in different security key . During authentication, (both windows hello and security) or (two different security keys) are available in device.

So from the discussion, it all depends on user agent/platform.

[Philipp Junghannß]

For facial vs fingerprint that's, just 2 different ways to access the authenticator (in fact the pin you set up can also be used). It's the same on Android where you can pick between face finger and/or your alternative lockscreen method (pin/pattern/password) 

hetin k <het...@gmail.com> schrieb am Do., 6. Okt. 2022, 16:26:

Some android phones have both facial and fingerprint verification. In that case, I considered both as different platform authenticators. is it a wrong consideration?

Another case i considered is one registration in windows hello and another registration in security key or two registration in different security key . During authentication, (both windows hello and security) or (two different security keys) are available in device.

So from the discussion, it all depends on user agent/platform.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4872a650-c3cc-fad6-f8d2-61a03a3c987d%40strongkey.com.

[Arshad Noor]

I would recommend thinking of a Platform Authenticator as a combination
of a Secure Element + firmware/software that knows how to handle FIDO
transactions while embedded in a general purpose computing device.

This is different from a Security Key, which is also a combination of an
[optional] Secure Element + firmware/software that understands FIDO, but
is NOT embedded in a general purpose computer; it is an external device
that can "roam" from computer to computer and work with the browser over
a transport protocol (USB, BLE, NFC, etc.).

The Secure Element (SE)[1] handles low-level cryptographic processing,
while the "software" works with the SE and can integrate [optional]
biometrics and/or PIN/Passwords for "user verification" (UV). At a
minimum, however, the "software" must implement "user presence" (UP).

Implementations are jointly standardized by the FIDO Alliance as CTAP,
and by W3C as WebAuthn for browsers - you need both to make it work for
web applications. You can, hoever, use implementations with CTAP without
WebAuthn for non-browser applications (such as SSH), or with PKI digital
certificates using PKCS#11 libraries if a vendor supplies it.

But, that is not the only way to use FIDO - anyone can choose to
implement the capability if they want to in a different way to solve
unique problems that are not addressed with general implementations.

StrongKey created an open-source Android Client Library[2] that uses the
SE (or TEE) on modern phones, leverages biometrics, Android Key
Attestation and delivers Transaction Confirmation using FIDO2 - but not
using CTAP or WebAuthn. It only works with native "rich client apps"
(RCA) and with StrongKey's open-source FIDO Certified FIDO2 Server[3].

The sample app in the same repository can use either a fingerprint or
PINs for UV - but both user verification methods are using the same
"platform authenticator". Because of the way Android separates apps and
their keystores, any other app that uses similar Android APIs (as we
did) can create their own "platform authenticator" on the same mobile
device, but never trip over the FIDO credentials StrongKey's Android
Client Library (SACL) creates because they're walled off from each other
at lower layers in Android.

Google also has their own FIDO2 API for Android, but last I looked (a
couple years ago), I don't believe it used an SE, Android Key
Attestation or supported Transaction Confirmation; perhaps there is an
update now.

We didn't use that API, but went to Android APIs directly to build SACL.
Because of that, technically, an app using Google's FIDO2 API, and
another app using SACL can co-exist on the same mobile device and keep
their FIDO credentials completely and cryptographically separated - even
to the same RPID!

Sounds confusing - but if you read enough, it all falls into place after
a while.

Hope this helps.

Arshad

[1]
https://www.arrow.com/en/iot/iot-security/secure-elements-and-trusted-platform-module
[2] https://github.com/StrongKey/fido2/tree/master/sampleapps/java/sacl
[3] https://github.com/strongkey/fido2

> https://demo.strongkey.com <https://demo.strongkey.com>.

> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/b3809039-a79e-4de8-a8ba-d66aac3cba67n%40fidoalliance.org?utm_medium=email&utm_source=footer

> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/b3809039-a79e-4de8-a8ba-d66aac3cba67n%40fidoalliance.org?utm_medium=email&utm_source=footer>>.
>
> >
> > --
> > 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
> > <mailto:fido-dev+u...@fidoalliance.org>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eb7b4d82-8b6c-4fdb-a79f-f3cb83c5be5an%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eb7b4d82-8b6c-4fdb-a79f-f3cb83c5be5an%40fidoalliance.org>
>
> >

> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eb7b4d82-8b6c-4fdb-a79f-f3cb83c5be5an%40fidoalliance.org?utm_medium=email&utm_source=footer
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eb7b4d82-8b6c-4fdb-a79f-f3cb83c5be5an%40fidoalliance.org?utm_medium=email&utm_source=footer>>.

>
> --
> 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
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c808a1b3-74e0-45ad-ad60-ae09323755e0n%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/c808a1b3-74e0-45ad-ad60-ae09323755e0n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[Reza Rassool]

Thanks Arshad