Filter Passkey alone in Configuration

[Sabarinathan Eaganathan]

HI all,
In our service we are giving Yubikey as second factor already,and now we given support for configuring Passkey as first factor. How to stop configuring Passkey(Mobile based security key) by clicking Yubikey in our service. As i explored there is not such differentiation for Passkey over security key. We do only have differentiation for platform and cross-platform authenticators.

We even not getting AAGUID for Passkey devices.

The Transport data which will be (usb,nfc) for security key devices 
it will be (cable,hybrid,internal) for Passkey devices. But we are not getting transport data too while configuring Passkey most times. Browser is not giving Transport data to us. Hence we are struggling for filtering Hardware key and Passkey(Mobile based Authenticator).

1) either we need to show Allowed transport based configuration filtering
2)Or we must need AAGUID for restricting configurations

Can anyone say a solution for our use case.

[My1]

shouldnt setting cross-plat do the trick, as I would expect a passkey to be platform by definition.

--
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/7d74e212-8c4d-4eca-8a0d-61ae369fd85cn%40fidoalliance.org.

[Sabarinathan Eaganathan]

Hi ,
Replying to above thread,we need QR based passkey configuration which can be done via Mobile which is cross-platform authenticator type. So, we cant seperate this via 'platform' authenticator selection. Please suggest a solution for this team

Regards,

Sabarinathan.e

[Tim Cappalli]

You can reject a registration for authenticators that do not meet your requirements (by looking at attestations).

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/90baa96e-6d8e-44bb-babe-47976b55e345n%40fidoalliance.org.

[Sandeep Dhankar]

The Paaskeys do not have attestation and without that it is not possible to identify the Authenticator reliably. However assuming that the Authenticator is following the spec, it should be setting the backupEligibilty and/or backupState but which can be used to deduce if it’s a Passkey.

On Thu, Dec 8, 2022 at 7:08 AM 'Tim Cappalli' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> wrote:

This message originated outside your organization.

---

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/DM6PR00MB04739608D929FE9B560B90B1951D9%40DM6PR00MB0473.namprd00.prod.outlook.com.

[Tim Cappalli]

Yes, and if you only want to allow Yubikeys, reject any registrations that are not Yubikeys (which would include those without attestations).

 

(Disclaimer: not something I would recommend. Just answering the original question.)

[Cody Salas]

If there's interest, Yubico has some material around this use case - https://developers.yubico.com/WebAuthn/Concepts/Authenticator_Management/ 

It essentially boils down to what has been discussed above:

1. Configure an allow list in your relying party - The example above leverages AAGUIDs
2. Capture attestation from the registration ceremony
3. Send the registration to your relying party where it will either:
   
• Accept the registration if the attestation matches what is set in your allow list
  
• Reject the registration otherwise
  

The material also outlines some pros, cons, and pitfalls to a few different approaches. Hope it helps.

Cheers,

Cody Salas

Developer Advocate | Yubico

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/DM6PR00MB047345CD6A24EE895889BF81951D9%40DM6PR00MB0473.namprd00.prod.outlook.com.

[Sabarinathan Eaganathan]

As a concussion the following trial and error approaches are working for filtering Passkey in configuration side
1)Id length based filtration the credential Id length will be 28 for Passkey devices.

String credentialIdRecoded = BaseEncoding.base64Url().encode(BaseEncoding.base64Url().decode(keyHandle));
2)Backup state(BS) and backup eligibility (BE) data comes true for Passkey.

Above cases are tested by iPhone scan qr passkey configuration.

Thank you all.

[Emil Lundberg]

I would advise against filtering on credential ID length, as the platform vendors could decide at any time to generate them in some other way with a different length.

Perhaps an explanation of what you're trying to do would help us understand what would be the best way to do it. What is it you want to do by "filtering" (platform?) passkeys? It is not clear to me if by "filtering" you mean forbidding use of a platform passkey (likely not since you said you want to support QR-based cross-device authentication?), or just giving them different markers in your database.

Emil Lundberg

Software Engineer | Yubico

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

[Sabarinathan Eaganathan]

Hi Emil and all. 
    In our service we have given support for configuring hardware key (Yubikey) as a second factor authentication using u2f protocol long ago once u2f protocol deprecated we updated to FIDO2 protocol for configuring hardware key. Recently we given support for configuring passkey (here passkey i meant mobile based security key - using apple or android devices for authentication) as first factor. In our service mobile based security key(Apple,Android passkey) want to be registered as first factor alone and Hardware keys(Yubikey) want to be registered as second factor alone. If users tried to configure mobile based passkey tokens as second factor we need to block configuration as well as if a user tried to configure security key as first factor we need to block that too. This is what our requirement. we need solution for this usecase.

First factor : Email id + passkey

Second factor : Email id + password + hardware key.

Regards,

Sabarinathan.e

[Sabarinathan Eaganathan]

Hi all,
This two solution is not working for finding passkeys.
1)String credentialIdRecoded = BaseEncoding.base64Url().encode(BaseEncoding.base64Url().decode(keyHandle));

This credentialIdRecorded data is coming in length 28 for apple passkey but the same is coming as length 88 for android passkey use case. So we cant use length.
2) Backup state(BS) and backup eligibility (BE) data comes true for apple passkey (tested on iphone 8plus device) but for android mobile this both data is coming as false. 

If any one has better solution for my usecase please advise me. thank you.

Regards,

Sabarinathan.e

[My1]

why would you not want passwordless with hardware keys tho?

I mean FIDO2 based ones do have a User Verification, be it a code, or biometrics, just like Passkeys on phones do.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4f520414-b484-41a6-ac8f-a58cbd2d0bd4n%40fidoalliance.org.

[Shane Weeden]

I think your best bet is:

For second-factor registration with a hardware security key:

 - always request (and require, and check) attestation, rejecting registrations that do not match your expectations (perhaps by way of allow-listing AAGUID if you control the issuing of the make/model of expected hardware security key)

 - during navigator.credentials.create set: userVerification = discouraged, authenticatorAttachment = cross-platform, residentKey=discouraged (for backward compatibility also set requireResidenteKey=false), attestationConveyancePreference = direct (as mentioned above)

For first-factor passkey registration:

 - use client-side detection to try figure out if the local OS/Browser even supports the capabilities you want. This would include use of client-side detection of OS/user-agent, the PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable API, and quite possibly also use of the PublicKeyCredential.isConditionalMediationAvailable API. Some experimentation required, as this is a moving target. Ideally though, do your best to make sure you have tested and support the use case on the platform the user is on.

 - during navigator.credentials.create set userVerification=required (and of course make sure it was set in the returned authenticatorData), authenticatorAttachment = platform, residentKey=required (for backward compatibility also set requireResidenteKey=true although the chances of an OS/browser not supporting residentKey=required and still supporting multi-device passkeys is near zero)

 - you presently won’t get attestation from passkeys registered on either Apple or Android so whether or not you even bother requesting it is up to you. You may find it useful to request attestation and at least record what you got back.

 - Take a look at the BE/BS flags in the returned authenticatorData, and if they are *not* set then most likely (not a proof when there is no attestation) you did not get a multi-device passkey. You could choose to reject the registration at this point if what you were really after is a multi-device passkey, understanding that it’s an awful user experience to do so, and I would question why you would think that’s a good idea?

 - consider requesting the DPK extension (Android passkeys beta supports this) for later use in risk decisions

 - consider modifying your login form to not just request email id, but also add support for the autofill UI (aka the mediated/conditional UI) when PublicKeyCredential.isConditionalMediationAvailable returns [a promise which returns] true. This is a better passkeys login experience.

I’d be interested in hearing what *doesn’t align* with your use cases with the above pattern of suggestions. It’s quite possible there are rough edges.

Regards,

Shane.

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4f520414-b484-41a6-ac8f-a58cbd2d0bd4n%40fidoalliance.org.

[Emil Lundberg]

Why do you want to split the use cases like that? I fail to see why you wouldn't want to allow using an iPhone or Android passkey just because the user has typed a password, or conversely why you wouldn't want to allow using a hardware-bound passkey on a YubiKey as a first factor if the user happens to have one.

Emil Lundberg

Software Engineer | Yubico