Steps to get fido certify my software-based passkey authenticator
383 views
Skip to first unread message
Aravinth Vj
May 14, 2025, 6:09:46 PMMay 14
to FIDO Dev (fido-dev)
Hi Everyone,
I'm new to passkeys and have been developing a software-based passkey authenticator to get integrated into our solution. I was able to make it work on some test websites and a few other websites which accepts self-attestation certificates and still struggling to make it work on major platforms like google. so can anyone explain the steps in obtaining a proper attestation certificate and make my solution a fido trusted(MDS.) if anyone has already been through the process. Thanks in advance
I'm new to passkeys and have been developing a software-based passkey authenticator to get integrated into our solution. I was able to make it work on some test websites and a few other websites which accepts self-attestation certificates and still struggling to make it work on major platforms like google. so can anyone explain the steps in obtaining a proper attestation certificate and make my solution a fido trusted(MDS.) if anyone has already been through the process. Thanks in advance
Tim Cappalli
May 14, 2025, 6:15:27 PMMay 14
to Aravinth Vj, FIDO Dev (fido-dev)
There is no current certification for passkey providers. Platforms do not restrict passkey providers. If you’re having issues, there is likely an issue with your provider.
You do not have to be certified to be listed in MDS; follow the instructions here: https://fidoalliance.org/metadata/
--
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
[email protected].
To view this discussion visit
https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-b2c42885134cn%40fidoalliance.org.
Paul Heim
May 14, 2025, 9:20:06 PMMay 14
to Tim Cappalli, Aravinth Vj, FIDO Dev (fido-dev)
Hi All,
Please get in touch with [email protected] for more information on in-development certification programs related to Passkey Providers.
Thank you,
Paul
Paul Heim | Certification Director | FIDO Alliance
Aravinth Vj
May 15, 2025, 10:48:03 AMMay 15
to FIDO Dev (fido-dev), Paul Heim, Tim Cappalli, Aravinth Vj
so, I guess all I need to do now is to get listed in mds with my aaguid(my solution works fine in many websites which accepts none or self-signed certificates for attestation like accounts@microsoft,github,discord... just not the ones that validates the authenticity with mds like google)
Am i right? . and also do i need to have my certificate signed by a CA.
On Wednesday, May 14, 2025 at 11:50:06 PM UTC+5:30 Paul Heim wrote:
Hi All,
Please get in touch with [email protected] for more information on in-development certification programs related to Passkey Providers.
Thank you,
Paul
Paul Heim | Certification Director | FIDO Alliance
From: 'Tim Cappalli' via FIDO Dev (fido-dev) <[email protected]>
Sent: Wednesday, May 14, 2025 8:15 AM
To: Aravinth Vj <[email protected]>; FIDO Dev (fido-dev) <[email protected]>
Subject: Re: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticator
There is no current certification for passkey providers. Platforms do not restrict passkey providers. If you’re having issues, there is likely an issue with your provider.
You do not have to be certified to be listed in MDS; follow the instructions here: https://fidoalliance.org/metadata/
From: [email protected] <[email protected]> on behalf of Aravinth Vj <[email protected]>
Date: Wednesday, May 14, 2025 at 11:09
To: FIDO Dev (fido-dev) <[email protected]>
Subject: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticatorHi Everyone,
I'm new to passkeys and have been developing a software-based passkey authenticator to get integrated into our solution. I was able to make it work on some test websites and a few other websites which accepts self-attestation certificates and still struggling to make it work on major platforms like google. so can anyone explain the steps in obtaining a proper attestation certificate and make my solution a fido trusted(MDS.) if anyone has already been through the process. Thanks in advance
--
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 [email protected].
--
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 [email protected].
Arshad Noor
May 15, 2025, 11:35:56 AMMay 15
to Aravinth Vj, FIDO Dev (fido-dev)
Aravinth,
If you are new to FIDO/WebAuthn/passkeys, you owe it to yourself - and
the companies/people who will depend on the software Authenticator you
have developed - to do the research and understand why the FIDO protocol
mandated an attestation since 2015, and what it does within the
authentication process.
If all you needed was passwordless authentication, you could have used a
self-signed CA to issue digital certificates to your users, and used TLS
Client Authentication - it is a 30-year old technology supported by
every browser and is still being used worldwide. In fact, the latest IoT
standard for Matter-compliant devices mandates Product Attestation
digital certificates for even a smart-bulb that costs less than USD 10.00:
https://csa-iot.org/certification/paa
https://csa-iot.org/resources/developer-resources/?dr_keywords=matter&dr_format%5B%5D=1087
The point of attestation is to give a relying party aka RP (someone who
relies upon the digital signature from a user to verify their identity)
an assurance that the user is using an Authenticator they can trust to
mitigate risks of identity-theft.
The FIDO Alliance worked for over a decade to create security and
certification standards, leveraging cryptographic hardware modules and
an attestation data-structure in the FIDO registration process to
provide assurances about the Authenticator, attesting to the security of
the device to protect private keys and verify the identity of the user
(through a PIN or biometric matching on the Authenticator).
If the RP does not get an attestation ('none') or is self-signed during
a FIDO registration, what basis do they have to trust the Authenticator,
and consequently, the authentication? A digital certificate with TLS
ClientAuth gives you that without having to create any browser
extensions and also provides the benefit of making your site "invisible"
on the internet without the right Client certificate:
https://www.linkedin.com/pulse/path-deterring-ransomware-attacks-arshad-noor-vqdjc
The authentication process is not just about eliminating passwords -
that problem was addressed 3 decades ago (people can have debates about
the cost & the complexity of digital certificates, but that is a
different discussion). Attestations in the FIDO ecosystem are about
establishing trust between the user and the RP; the higher the assurance
delivered to the RP, the greater the trust for business transactions.
To get an idea of how powerful attestation is, try out this demo and see
what happens when you define different security policies in your FIDO
server:
https://demo.strongkey.com/fidopolicy/
Attestation enables RPs to calibrate their security to manage risk at
varying levels; eliminating attestation offers RPs nothing.
Arshad Noor
StrongKey
> [email protected]>.
> fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> b2c42885134cn%40fidoalliance.org?utm_medium=email&utm_source=footer>.
If you are new to FIDO/WebAuthn/passkeys, you owe it to yourself - and
the companies/people who will depend on the software Authenticator you
have developed - to do the research and understand why the FIDO protocol
mandated an attestation since 2015, and what it does within the
authentication process.
If all you needed was passwordless authentication, you could have used a
self-signed CA to issue digital certificates to your users, and used TLS
Client Authentication - it is a 30-year old technology supported by
every browser and is still being used worldwide. In fact, the latest IoT
standard for Matter-compliant devices mandates Product Attestation
digital certificates for even a smart-bulb that costs less than USD 10.00:
https://csa-iot.org/certification/paa
https://csa-iot.org/resources/developer-resources/?dr_keywords=matter&dr_format%5B%5D=1087
The point of attestation is to give a relying party aka RP (someone who
relies upon the digital signature from a user to verify their identity)
an assurance that the user is using an Authenticator they can trust to
mitigate risks of identity-theft.
The FIDO Alliance worked for over a decade to create security and
certification standards, leveraging cryptographic hardware modules and
an attestation data-structure in the FIDO registration process to
provide assurances about the Authenticator, attesting to the security of
the device to protect private keys and verify the identity of the user
(through a PIN or biometric matching on the Authenticator).
If the RP does not get an attestation ('none') or is self-signed during
a FIDO registration, what basis do they have to trust the Authenticator,
and consequently, the authentication? A digital certificate with TLS
ClientAuth gives you that without having to create any browser
extensions and also provides the benefit of making your site "invisible"
on the internet without the right Client certificate:
https://www.linkedin.com/pulse/path-deterring-ransomware-attacks-arshad-noor-vqdjc
The authentication process is not just about eliminating passwords -
that problem was addressed 3 decades ago (people can have debates about
the cost & the complexity of digital certificates, but that is a
different discussion). Attestations in the FIDO ecosystem are about
establishing trust between the user and the RP; the higher the assurance
delivered to the RP, the greater the trust for business transactions.
To get an idea of how powerful attestation is, try out this demo and see
what happens when you define different security policies in your FIDO
server:
https://demo.strongkey.com/fidopolicy/
Attestation enables RPs to calibrate their security to manage risk at
varying levels; eliminating attestation offers RPs nothing.
Arshad Noor
StrongKey
> --
> 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 [email protected] <mailto:fido-
> 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
> [email protected]>.
> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> b2c42885134cn%40fidoalliance.org <https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> b2c42885134cn%40fidoalliance.org?utm_medium=email&utm_source=footer>.
Pro Coder 101
May 15, 2025, 12:04:12 PMMay 15
to Arshad Noor, Aravinth Vj, FIDO Dev (fido-dev)
Further to add to Arshad's answer, I have been working on developing malicious security keys that can exfiltrate your cryptographic secrets when used. (Just a PoC for a research project but it works). https://github.com/AdityaMitra5102/Evil-FIDO-Key
And there are cases where the RP does not validate the attestation. Google being the biggest example. And I have been able to compromise test users using the same.
Telling from the experience of a red teamer, verifying attestation is very very important.
Aditya
Aditya Mitra
CCNA, SecurityX
https://AdityaMitra5102.github.io
https://www.linkedin.com/in/AdityaMitra5102
https://scholar.google.com/citations?user=oXPSCNUAAAAJ
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/f95968ca-9fe4-4041-9015-529737dab633%40strongkey.com.
Aravinth Vj
May 15, 2025, 3:12:35 PMMay 15
to FIDO Dev (fido-dev), Arshad Noor, Aravinth Vj
sorry I didn't mean it that way. I do really want to have a proper attestation process in my solution. I just wanted to confirm if I am on the right track of doing it.I'm definitely not using self-signed in production.
Tim Cappalli
May 15, 2025, 4:14:46 PMMay 15
to Aravinth Vj, FIDO Dev (fido-dev), Arshad Noor, Aravinth Vj
There is no attestation model for synced passkeys today.
If your software authenticator creates device-bound passkeys, you can use traditional attestation but there is no certification today.
Sent: Thursday, May 15, 2025 8:12:35 AM
Cc: Arshad Noor <[email protected]>; Aravinth Vj <[email protected]>
Subject: Re: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticator
To unsubscribe from this group and stop receiving emails from it, send an email to
[email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/e62e2f46-5aab-46b7-861c-4dcd11232f11n%40fidoalliance.org.
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/e62e2f46-5aab-46b7-861c-4dcd11232f11n%40fidoalliance.org.
My1
May 15, 2025, 5:59:19 PMMay 15
to Tim Cappalli, Aravinth Vj, FIDO Dev (fido-dev), Arshad Noor
yeah, the biggest issue with synced passkeys and attestation is that
1) you dont exactly have assurance of where it will be synced to (especially regarding changes in the future and you would not want to break users' entire digital lives for relyying on this)
2) you have to protect an attestation key shared across 1000s of users against those users to make sure the attestation is not breached.
@arshad yes attestation is a useful tool but there are certainly places where even a non attested WebAuthn credential helps a lot more than requiring users to buy devices for that and yes while TLS Client Auth is technically an option it is kinda clunky especially when the cert expires and you dont have an easy way to renew after that, also unlike FIDO, there are not really many good ways to take your certificates with you, especially if you as a user want to actually use something secure as PIV cards often have comparably small amounts of certificates while server-side FIDO credentials allow for literally unlimited credentials, and even for resident ones, the sizes are growing, even Yubikey supports 100 of them on their newest models, which is more than many would likely need.
while I am not exactly a fan of synced passkeys for enough reasons, I do see their appeal especially for lower risk sites. One thing that I assume is likely not possible is a way to do TLS Client Auth when you are on a simple web hoster as Client Auth is something more deeply set in the server where a site admin would not have access to, while webauthn is just something sent as data where the site admin can just push webauthn data through a library
Arshad Noor
May 16, 2025, 12:36:46 AMMay 16
to My1, FIDO Dev (fido-dev)
Hi @My1,
While I concede that its a matter of opinion, professionally and
personally, I believe the internet is a LOT safer when the minimum bar
is a FIDO credential using Security Keys (with a secure element) plus an
attestation from the manufacturer using a multi-level CA hierarchy
(rather than self-signed certificates). For users in OECD countries (who
represent the majority of targets for attackers), the price for such a
device is, most likely, the equivalent of a couple of exotic concoctions
at their local coffee shop.
Ideally, I would prefer to see (and have advocated for it in the past)
computing device manufacturers to simply include a Security Key with
their brand name and ship it with the computing device to the user.
While it does add to the cost of the bill-of-materials, at the scale of
some popular manufacturers, it would be a negligible cost buried in the
cost of the computing device. And would send a very powerful message
that they REALLY do care about their customers' security & privacy
rather than synched passkeys!
All the issues you mention for certificate renewal, portability, and PIV
compatibility can be addressed - just a question of working with someone
who knows both domains extremely well. There are at least 4
manufacturers that support TLS-ClientAuth + FIDO2 in the same device:
Feitian, GoTrust, Thales and Yubico. (If there are others, I would
definitely like to hear from them since we have a strong interest in
such products).
Lastly, since we do not use hosted sites (but manage all our own
infrastructure), even with Apache HTTPD, Payara, Wildfly, etc., it is
possible to enable TLS-ClientAuth for each virtual server using
different CA chains - just a question of how much the hosting company
wants to invest in tooling to automate the process for customers; but
that's a business decision - not a technical one.
Arshad
> (fido-dev) <[email protected] <mailto:[email protected]>>:
> *From:* [email protected] <mailto:[email protected]>
> <[email protected] <mailto:[email protected]>> on
> *Sent:* Thursday, May 15, 2025 8:12:35 AM
> *To:* FIDO Dev (fido-dev) <[email protected] <mailto:fido-
> [email protected]>>
> *Cc:* Arshad Noor <[email protected]
> <mailto:[email protected]>>; Aravinth Vj
> <[email protected] <mailto:[email protected]>>
> *Subject:* Re: [FIDO-DEV] Steps to get fido certify my software-
> certification/paa>
>
> https://csa-iot.org/resources/developer-resources/?
> dr_keywords=matter&dr_format%5B%5D=1087 <https://csa-iot.org/
> resources/developer-resources/?
> dr_keywords=matter&dr_format%5B%5D=1087>
> attacks-arshad-noor-vqdjc <https://www.linkedin.com/pulse/path-
> deterring-ransomware-attacks-arshad-noor-vqdjc>
> demo.strongkey.com/fidopolicy/>
> <https://groups.google.com/a/>
> > fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> <http://fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd->
> > b2c42885134cn%40fidoalliance.org <http://40fidoalliance.org>
> <https://groups.google.com/a/ <https://groups.google.com/a/>
> > fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> <http://fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd->
> > b2c42885134cn%40fidoalliance.org?
> utm_medium=email&utm_source=footer <http://40fidoalliance.org?
> groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/
> e62e2f46-5aab-46b7-861c-4dcd11232f11n%40fidoalliance.org?
>
While I concede that its a matter of opinion, professionally and
personally, I believe the internet is a LOT safer when the minimum bar
is a FIDO credential using Security Keys (with a secure element) plus an
attestation from the manufacturer using a multi-level CA hierarchy
(rather than self-signed certificates). For users in OECD countries (who
represent the majority of targets for attackers), the price for such a
device is, most likely, the equivalent of a couple of exotic concoctions
at their local coffee shop.
Ideally, I would prefer to see (and have advocated for it in the past)
computing device manufacturers to simply include a Security Key with
their brand name and ship it with the computing device to the user.
While it does add to the cost of the bill-of-materials, at the scale of
some popular manufacturers, it would be a negligible cost buried in the
cost of the computing device. And would send a very powerful message
that they REALLY do care about their customers' security & privacy
rather than synched passkeys!
All the issues you mention for certificate renewal, portability, and PIV
compatibility can be addressed - just a question of working with someone
who knows both domains extremely well. There are at least 4
manufacturers that support TLS-ClientAuth + FIDO2 in the same device:
Feitian, GoTrust, Thales and Yubico. (If there are others, I would
definitely like to hear from them since we have a strong interest in
such products).
Lastly, since we do not use hosted sites (but manage all our own
infrastructure), even with Apache HTTPD, Payara, Wildfly, etc., it is
possible to enable TLS-ClientAuth for each virtual server using
different CA chains - just a question of how much the hosting company
wants to invest in tooling to automate the process for customers; but
that's a business decision - not a technical one.
Arshad
>
> There is no attestation model for synced passkeys today.
>
> If your software authenticator creates device-bound passkeys, you
> can use traditional attestation but there is no certification today.
>
>
> ------------------------------------------------------------------------
> There is no attestation model for synced passkeys today.
>
> If your software authenticator creates device-bound passkeys, you
> can use traditional attestation but there is no certification today.
>
>
> *From:* [email protected] <mailto:[email protected]>
> <[email protected] <mailto:[email protected]>> on
> behalf of Aravinth Vj <[email protected]
> <mailto:[email protected]>>
> *Sent:* Thursday, May 15, 2025 8:12:35 AM
> *To:* FIDO Dev (fido-dev) <[email protected] <mailto:fido-
> [email protected]>>
> *Cc:* Arshad Noor <[email protected]
> <mailto:[email protected]>>; Aravinth Vj
> <[email protected] <mailto:[email protected]>>
> *Subject:* Re: [FIDO-DEV] Steps to get fido certify my software-
>
> https://csa-iot.org/resources/developer-resources/?
> dr_keywords=matter&dr_format%5B%5D=1087 <https://csa-iot.org/
> resources/developer-resources/?
> dr_keywords=matter&dr_format%5B%5D=1087>
> deterring-ransomware-attacks-arshad-noor-vqdjc>
>
> The authentication process is not just about eliminating
> passwords -
> that problem was addressed 3 decades ago (people can have
> debates about
> the cost & the complexity of digital certificates, but that is a
> different discussion). Attestations in the FIDO ecosystem are about
> establishing trust between the user and the RP; the higher the
> assurance
> delivered to the RP, the greater the trust for business
> transactions.
>
> To get an idea of how powerful attestation is, try out this demo
> and see
> what happens when you define different security policies in your
> FIDO
> server:
>
> https://demo.strongkey.com/fidopolicy/ <https://
> The authentication process is not just about eliminating
> passwords -
> that problem was addressed 3 decades ago (people can have
> debates about
> the cost & the complexity of digital certificates, but that is a
> different discussion). Attestations in the FIDO ecosystem are about
> establishing trust between the user and the RP; the higher the
> assurance
> delivered to the RP, the greater the trust for business
> transactions.
>
> To get an idea of how powerful attestation is, try out this demo
> and see
> what happens when you define different security policies in your
> FIDO
> server:
>
> demo.strongkey.com/fidopolicy/>
> > fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> <http://fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd->
> > b2c42885134cn%40fidoalliance.org <http://40fidoalliance.org>
> <https://groups.google.com/a/ <https://groups.google.com/a/>
> > fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd-
> <http://fidoalliance.org/d/msgid/fido-dev/79e6d8a2-e091-43f1-b9bd->
> > b2c42885134cn%40fidoalliance.org?
> utm_medium=email&utm_source=footer <http://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,
>
> --
> 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 [email protected] <mailto:fido-
> [email protected]>.
> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/
> e62e2f46-5aab-46b7-861c-4dcd11232f11n%40fidoalliance.org <https://
> [email protected]>.
> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/
> groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/
> e62e2f46-5aab-46b7-861c-4dcd11232f11n%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,
>
> --
> 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 [email protected] <mailto:fido-
> [email protected]>.
> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/
> BN8PR13MB2753D6F008F136BA86A86BB0A090A%40BN8PR13MB2753.namprd13.prod.outlook.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/BN8PR13MB2753D6F008F136BA86A86BB0A090A%40BN8PR13MB2753.namprd13.prod.outlook.com?utm_medium=email&utm_source=footer>.
> [email protected]>.
> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/
>
Oracle X
May 16, 2025, 12:37:45 AMMay 16
to Aravinth Vj, FIDO Dev (fido-dev), Paul Heim, Tim Cappalli
You're right, there is no current certification requirement for passkey providers to be listed in the FIDO Alliance's Metadata Service (MDS). Providers can follow the instructions on the FIDO Alliance website to get listed. If issues arise, it's likely related to the provider's implementation.
On Thu, May 15, 2025, 10:56 AM Oracle X <[email protected]> wrote:
To get a FIDO attestation certificate for your passkey authenticator:
1. Choose a trusted Certification Authority (CA) like Google, Apple, or Microsoft.
2. Meet FIDO conformance requirements and pass testing/certification.
3. Request an attestation certificate from the CA.
4. Create and submit a Metadata Statement (MDS) to the FIDO Alliance.
5. Integrate with major platforms and test for compatibility.Collaborate with experts and utilize FIDO Alliance resources for guidance.
On Thu, May 15, 2025, 10:48 AM Aravinth Vj <[email protected]> wrote:
so, I guess all I need to do now is to get listed in mds with my aaguid(my solution works fine in many websites which accepts none or self-signed certificates for attestation like accounts@microsoft,github,discord... just not the ones that validates the authenticity with mds like google) Am i right? . and also do i need to have my certificate signed by a CA.
On Wednesday, May 14, 2025 at 11:50:06 PM UTC+5:30 Paul Heim wrote:
Hi All,
Please get in touch with [email protected] for more information on in-development certification programs related to Passkey Providers.
Thank you,
Paul
Paul Heim | Certification Director | FIDO Alliance
From: 'Tim Cappalli' via FIDO Dev (fido-dev) <[email protected]>
Sent: Wednesday, May 14, 2025 8:15 AM
To: Aravinth Vj <[email protected]>; FIDO Dev (fido-dev) <[email protected]>
Subject: Re: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticator
There is no current certification for passkey providers. Platforms do not restrict passkey providers. If you’re having issues, there is likely an issue with your provider.
You do not have to be certified to be listed in MDS; follow the instructions here: https://fidoalliance.org/metadata/
From: [email protected] <[email protected]> on behalf of Aravinth Vj <[email protected]>
Date: Wednesday, May 14, 2025 at 11:09
To: FIDO Dev (fido-dev) <[email protected]>
Subject: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticatorHi Everyone,
I'm new to passkeys and have been developing a software-based passkey authenticator to get integrated into our solution. I was able to make it work on some test websites and a few other websites which accepts self-attestation certificates and still struggling to make it work on major platforms like google. so can anyone explain the steps in obtaining a proper attestation certificate and make my solution a fido trusted(MDS.) if anyone has already been through the process. Thanks in advance
--
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 [email protected].
--
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 [email protected].
--
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 [email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/e0de864b-684c-4650-8304-cb202a1abd6en%40fidoalliance.org.
Oracle X
May 16, 2025, 12:37:45 AMMay 16
to Aravinth Vj, FIDO Dev (fido-dev), Paul Heim, Tim Cappalli
To get a FIDO attestation certificate for your passkey authenticator:
1. Choose a trusted Certification Authority (CA) like Google, Apple, or Microsoft.
2. Meet FIDO conformance requirements and pass testing/certification.
3. Request an attestation certificate from the CA.
4. Create and submit a Metadata Statement (MDS) to the FIDO Alliance.
5. Integrate with major platforms and test for compatibility.
Collaborate with experts and utilize FIDO Alliance resources for guidance.
On Thu, May 15, 2025, 10:48 AM Aravinth Vj <[email protected]> wrote:
so, I guess all I need to do now is to get listed in mds with my aaguid(my solution works fine in many websites which accepts none or self-signed certificates for attestation like accounts@microsoft,github,discord... just not the ones that validates the authenticity with mds like google) Am i right? . and also do i need to have my certificate signed by a CA.
On Wednesday, May 14, 2025 at 11:50:06 PM UTC+5:30 Paul Heim wrote:
Hi All,
Please get in touch with [email protected] for more information on in-development certification programs related to Passkey Providers.
Thank you,
Paul
Paul Heim | Certification Director | FIDO Alliance
From: 'Tim Cappalli' via FIDO Dev (fido-dev) <[email protected]>
Sent: Wednesday, May 14, 2025 8:15 AM
To: Aravinth Vj <[email protected]>; FIDO Dev (fido-dev) <[email protected]>
Subject: Re: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticator
There is no current certification for passkey providers. Platforms do not restrict passkey providers. If you’re having issues, there is likely an issue with your provider.
You do not have to be certified to be listed in MDS; follow the instructions here: https://fidoalliance.org/metadata/
From: [email protected] <[email protected]> on behalf of Aravinth Vj <[email protected]>
Date: Wednesday, May 14, 2025 at 11:09
To: FIDO Dev (fido-dev) <[email protected]>
Subject: [FIDO-DEV] Steps to get fido certify my software-based passkey authenticatorHi Everyone,
I'm new to passkeys and have been developing a software-based passkey authenticator to get integrated into our solution. I was able to make it work on some test websites and a few other websites which accepts self-attestation certificates and still struggling to make it work on major platforms like google. so can anyone explain the steps in obtaining a proper attestation certificate and make my solution a fido trusted(MDS.) if anyone has already been through the process. Thanks in advance
--
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 [email protected].
--
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 [email protected].
--
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 [email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/e0de864b-684c-4650-8304-cb202a1abd6en%40fidoalliance.org.
John Bradley
May 16, 2025, 1:19:12 AMMay 16
to Oracle X, Aravinth Vj, Dev FIDO, Paul Heim, Tim Cappalli
You don’t need to pay a commercial CA for a certificate.
You can make your own CA and issue batch certificates that chain to that root.
That self signed root is what goes in the MDS.
Your other option not recommended if you have a small number of authenticators is use a self signed cert as the batch attestation and put each one in the MDS, you can list multiple certs for a single AAGUID.
Your biggest problem for software authenticators is protecting the batch key for the attestation. You may not want attackers to be able to impersonate your authenticator. The hardware keys don’t want to be impersonated so that key is kept in a secure element.
You can distribute the private keys in your code or you could use some network based Attestation signing service as long as you can authenticate the authenticators.
Key management is the hard part. Self signed certs will work just fine. You can put the authenticator in the MDS without being certified.
Depending on the RP they may have settings to allow a tenement to reject aaguid that are not certified.
Paul included a link in his response on an upcoming certification program for software authenticators.
Regards
John B.
My1
May 16, 2025, 8:27:00 AMMay 16
to Arshad Noor, FIDO Dev (fido-dev)
Sure Hardware authenticators are safer, no one disputes that, but there are a bunch of issues that come with hardware authenticators.
1) dealing with backups (needing to not forget to register your second authenticator everywhere, and replace if lost/broken etc)
2) credential sharing in a team (especially on places with lower limits for the amount of security keys allowed on the account)
3) one some especially older devices the issue that a lot of sites now want resident and until comparatively recently kne of the most well known makers of fido devices has had only storage for 25 (not to forget the absolut whack that ctap2.0's rk implementation was)
Especially for non technical users in most cases having synced passkeys is not merely a matter of cost, but also a matter of convenience and ease of access from a standpoint of knowledge required.
We cannot forget that we in here are all nerds who specifically have worked with fido for years. I myself got my first u2f key in January of 2016 and basically started developing a localhost resident party shortly after, but many users know very little about technology and it should be easy on them to not lose access to all their digital accounts.
Heck even i who has an ARMY of all sorts of aithenticators, sometimes just use Google because i either forgot bringing an authenticator or just dont wanna deal with it for that account.
As i also said it all depends on the type of site. For some small forum or just generally site that desperately wants you to register but doesn't really carry any risk, i think software authenticators are more than fine. I obviously wouldn't use them for bank or gov stuff tho obviously.
Shane Weeden
May 16, 2025, 8:47:33 AMMay 16
to My1, Arshad Noor, FIDO Dev (fido-dev)
Here’s the counter argument….
I would used synched passkeys for my bank in a heartbeat, and recommend them to others - if they offered them. For starters it’s a whole world better than what the banks I use do now - and most importantly it virtually eliminates my most concerning threat - that of being phished via a fake copy of my financial institution. And for those just saying “oh, you’ve just moved your phishing threat to a centralised point which is even more attractive for attackers”, understand that I (as has most of the world) have already placed a fair deal of faith in these providers - they control my OS, my browser, and I kinda like the fact that I have one or two “passkey cloud providers” accounts (I’m including traditional password manager vendors in this bucket) that I really need to focus my security posture on rather than a matrix of HSKs to retail accounts.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNo6Y0k2MHXeFJ86HPZXP6YmPzAUQM%3DkqwjJu_sA%3DE1kkg%40mail.gmail.com.
Kiara
May 16, 2025, 8:35:10 PMMay 16
to John Bradley, Oracle X, Aravinth Vj, Dev FIDO, Paul Heim, Tim Cappalli
- Aravinth Vj inquired about FIDO certification for a software-based passkey authenticator, but there is currently no formal certification for passkey providers.
- Discussion revealed listing in the Metadata Service (MDS) and the importance of attestation for security, with differing views on the value of synced passkeys.
Arshad Noor
May 17, 2025, 12:12:48 PMMay 17
to Shane Weeden, FIDO Dev (fido-dev)
@Shane,
Choosing between synchronized passkeys and passwords is a false dichotomy.
RP applications that support synchronized passkeys have to do NO
additional work to support Security Keys or secure elements on platforms
with the right FIDO server. That banks may be choosing not to support
FIDO is not likely to be because they are anguishing over what kind of
FIDO credentials to accept.
If a bank has chosen to support FIDO, and chooses not to inform their
customers that using a Security Key or a secure element on a compatible
platform is a more secure option, it is perpetuating the tech industry's
fallacy that convenience trumps security & privacy; IMO, they are
selling out their customers!
Arshad
Choosing between synchronized passkeys and passwords is a false dichotomy.
RP applications that support synchronized passkeys have to do NO
additional work to support Security Keys or secure elements on platforms
with the right FIDO server. That banks may be choosing not to support
FIDO is not likely to be because they are anguishing over what kind of
FIDO credentials to accept.
If a bank has chosen to support FIDO, and chooses not to inform their
customers that using a Security Key or a secure element on a compatible
platform is a more secure option, it is perpetuating the tech industry's
fallacy that convenience trumps security & privacy; IMO, they are
selling out their customers!
Arshad
My1
May 17, 2025, 2:42:19 PMMay 17
to Arshad Noor, Shane Weeden, FIDO Dev (fido-dev)
well if an RP restricts users to only use synced passkeys and if especially banks dont inform that passkeys are an option then yes that is really bad.
talking about banks, I would say we should bring txAuthSimple back, at least in Europe banks cant use WebAuthn regardless of phone or not because FIDO uses an inherently blind signature not allowing you to visually check what are confirming on another device. yes it would lock out most security keys from them but there are a class of device capable to do that aside from phones, that do have the screen needed to do that.
but at least for a basic login a plain Fido key should be enough imo.
so here the choice for banks is often between their proprietary app, and a proprietary device.
attested on-device passkeys are going away too as far as I can tell, so even that is no longer an option even if they would have supported txauthsimple.
also the choice between synced passkeys and passwords is more a user thing than an RP thing, enough ppl would not want to take care of a special USB stick just to login everywhere, including the added loss of access risk.
--
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 [email protected].
Arshad Noor
May 18, 2025, 9:48:44 PMMay 18
to My1, FIDO Dev (fido-dev)
@My1,
While WebAuthn Level-2 and DRAFT Level-3 do not have this anymore,
StrongKey has an open-source library - available since 2021 that
supports simple transaction authorization (from WebAuthn Level-1) on
Android devices using:
- Android 9 or greater;
- Secure Element (Trusted Execution Environment if RP supports it);
- AndroidKeystore Attestation;
- BiometricPrompt authentication;
- Secure Display;
- FIDO Authentication Data in EMV 3DS Messaging
(https://fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-secure-using-fido-for-payment-authentication/)
You can find a high-level description of the StrongKey Android Client
Library (SACL), starting in the middle of this presentation (at about
the 5-minute mark):
https://authenticatecon.com/content/video-authenticate-financial-services-summit-keynote-toward-frictionless-strong-customer-authn/
You can find source code for the library, as well as a sample app and
back-end web application that works with StrongKey's open-source FIDO
server at:
https://sourceforge.net/projects/strongkeyfido/files/v4.16.0/sampleapps/java/sacl/
The library will be updated in the near future to work with newer
versions of Android and support libraries.
So, while banks will still have to build their own app, they can take
advantage of a standards compliant, open-source distribution to build
the capability if they want to.
Arshad
On 5/17/25 4:41 AM, My1 wrote:
> talking about banks, I would say we should bring txAuthSimple back, at
> least in Europe banks cant use WebAuthn regardless of phone or not
> because FIDO uses an inherently blind signature not allowing you to
> visually check what are confirming on another device. yes it would lock
> out most security keys from them but there are a class of device capable
> to do that aside from phones, that do have the screen needed to do that.
..
While WebAuthn Level-2 and DRAFT Level-3 do not have this anymore,
StrongKey has an open-source library - available since 2021 that
supports simple transaction authorization (from WebAuthn Level-1) on
Android devices using:
- Android 9 or greater;
- Secure Element (Trusted Execution Environment if RP supports it);
- AndroidKeystore Attestation;
- BiometricPrompt authentication;
- Secure Display;
- FIDO Authentication Data in EMV 3DS Messaging
(https://fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-secure-using-fido-for-payment-authentication/)
You can find a high-level description of the StrongKey Android Client
Library (SACL), starting in the middle of this presentation (at about
the 5-minute mark):
https://authenticatecon.com/content/video-authenticate-financial-services-summit-keynote-toward-frictionless-strong-customer-authn/
You can find source code for the library, as well as a sample app and
back-end web application that works with StrongKey's open-source FIDO
server at:
https://sourceforge.net/projects/strongkeyfido/files/v4.16.0/sampleapps/java/sacl/
The library will be updated in the near future to work with newer
versions of Android and support libraries.
So, while banks will still have to build their own app, they can take
advantage of a standards compliant, open-source distribution to build
the capability if they want to.
Arshad
On 5/17/25 4:41 AM, My1 wrote:
> talking about banks, I would say we should bring txAuthSimple back, at
> least in Europe banks cant use WebAuthn regardless of phone or not
> because FIDO uses an inherently blind signature not allowing you to
> visually check what are confirming on another device. yes it would lock
> out most security keys from them but there are a class of device capable
> to do that aside from phones, that do have the screen needed to do that.
My1
May 19, 2025, 1:15:51 AM (14 days ago) May 19
to Arshad Noor, FIDO Dev (fido-dev)
interesting, provided that browsers dont ax it, also maybe if it's easy enough to implement that could be implemented in things like cryptocoin wallets with FIDO, as they are like a prime target for adoption aside from phones as they have the needed tech already.
Arshad Noor
May 19, 2025, 8:30:25 AM (14 days ago) May 19
to My1, FIDO Dev (fido-dev)
Browsers chose not to support it because PSD2 mandates that the code
responsible for strong customer authentication (SCA) must be
independently audited and certified. I suggested W3C get behind a common
FOSS component that could meet the PSD2 mandate, but I don't think
browser manufacturers could get that approved internally within their
organizations.
That is why txAuthSimple had to be removed in WebAuthn Level-2 - IIRC,
W3C rules state you cannot have a feature in a spec if it is not
supported by at least 2 independent browsers.
SACL does not use a browser (or the WebView component) for SCA - and is
FOSS; so, there's no reason why the feature cannot remain in the library
(as long as apps that use it are willing to accept its LGPL license).
Arshad
On 5/18/25 3:15 PM, My1 wrote:
> interesting, provided that browsers dont ax it, also maybe if it's easy
> enough to implement that could be implemented in things like cryptocoin
> wallets with FIDO, as they are like a prime target for adoption aside
> from phones as they have the needed tech already.
>
> Am So., 18. Mai 2025 um 20:48 Uhr schrieb Arshad Noor
> <[email protected] <mailto:[email protected]>>:
> fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-
> secure-using-fido-for-payment-authentication/>)
> services-summit-keynote-toward-frictionless-strong-customer-authn/>
> strongkeyfido/files/v4.16.0/sampleapps/java/sacl/>
responsible for strong customer authentication (SCA) must be
independently audited and certified. I suggested W3C get behind a common
FOSS component that could meet the PSD2 mandate, but I don't think
browser manufacturers could get that approved internally within their
organizations.
That is why txAuthSimple had to be removed in WebAuthn Level-2 - IIRC,
W3C rules state you cannot have a feature in a spec if it is not
supported by at least 2 independent browsers.
SACL does not use a browser (or the WebView component) for SCA - and is
FOSS; so, there's no reason why the feature cannot remain in the library
(as long as apps that use it are willing to accept its LGPL license).
Arshad
On 5/18/25 3:15 PM, My1 wrote:
> interesting, provided that browsers dont ax it, also maybe if it's easy
> enough to implement that could be implemented in things like cryptocoin
> wallets with FIDO, as they are like a prime target for adoption aside
> from phones as they have the needed tech already.
>
> Am So., 18. Mai 2025 um 20:48 Uhr schrieb Arshad Noor
>
> @My1,
>
> While WebAuthn Level-2 and DRAFT Level-3 do not have this anymore,
> StrongKey has an open-source library - available since 2021 that
> supports simple transaction authorization (from WebAuthn Level-1) on
> Android devices using:
>
> - Android 9 or greater;
> - Secure Element (Trusted Execution Environment if RP supports it);
> - AndroidKeystore Attestation;
> - BiometricPrompt authentication;
> - Secure Display;
> - FIDO Authentication Data in EMV 3DS Messaging
> (https://fidoalliance.org/technical-note-fido-authentication-and-
> emv-3-d-secure-using-fido-for-payment-authentication/ <https://
> @My1,
>
> While WebAuthn Level-2 and DRAFT Level-3 do not have this anymore,
> StrongKey has an open-source library - available since 2021 that
> supports simple transaction authorization (from WebAuthn Level-1) on
> Android devices using:
>
> - Android 9 or greater;
> - Secure Element (Trusted Execution Environment if RP supports it);
> - AndroidKeystore Attestation;
> - BiometricPrompt authentication;
> - Secure Display;
> - FIDO Authentication Data in EMV 3DS Messaging
> (https://fidoalliance.org/technical-note-fido-authentication-and-
> fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-
> secure-using-fido-for-payment-authentication/>)
>
> You can find a high-level description of the StrongKey Android Client
> Library (SACL), starting in the middle of this presentation (at about
> the 5-minute mark):
>
> https://authenticatecon.com/content/video-authenticate-financial-
> services-summit-keynote-toward-frictionless-strong-customer-authn/
> <https://authenticatecon.com/content/video-authenticate-financial-
> You can find a high-level description of the StrongKey Android Client
> Library (SACL), starting in the middle of this presentation (at about
> the 5-minute mark):
>
> https://authenticatecon.com/content/video-authenticate-financial-
> services-summit-keynote-toward-frictionless-strong-customer-authn/
> services-summit-keynote-toward-frictionless-strong-customer-authn/>
>
> You can find source code for the library, as well as a sample app and
> back-end web application that works with StrongKey's open-source FIDO
> server at:
>
> https://sourceforge.net/projects/strongkeyfido/files/v4.16.0/
> sampleapps/java/sacl/ <https://sourceforge.net/projects/
> You can find source code for the library, as well as a sample app and
> back-end web application that works with StrongKey's open-source FIDO
> server at:
>
> https://sourceforge.net/projects/strongkeyfido/files/v4.16.0/
> strongkeyfido/files/v4.16.0/sampleapps/java/sacl/>
Aravinth Vj
May 19, 2025, 9:27:50 AM (14 days ago) May 19
to FIDO Dev (fido-dev), FIDO Dev (fido-dev)
As a follow up question, since I want my solution to work on RP that validate certificate for CA signing. Can anyone point me towards a CA who can actually sign my attestation certificate because I approached DigiCert and they said they can't do it (or maybe the person didn't understand my request).
Shane Weeden
May 19, 2025, 9:37:29 AM (14 days ago) May 19
to Aravinth Vj, Dev FIDO
I don’t think you should use a commercial CA for this purpose. You need to protect the attestation batch private key and publish metadata (preferably in FIDO MDS) regardless of the signing chain for RPs to validate so there is zero upside to using a commercial CA.
Regards,
Shane.
Sent from my iPhone
On 19 May 2025, at 4:27 pm, Aravinth Vj <[email protected]> wrote:
As a follow up question, since I want my solution to work on RP that validate certificate for CA signing. Can anyone point me towards a CA who can actually sign my attestation certificate because I approached DigiCert and they said they can't do it (or maybe the person didn't understand my request).
--
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 [email protected].
Arshad Noor
May 19, 2025, 11:56:31 AM (13 days ago) May 19
to Aravinth Vj, Dev FIDO
Aravinth,
As Shane pointed out, you do not necessarily need a commercial CA to
create your attestation certificate - it can be created with a
self-signed CA maintained by you/your company. Creating a self-signed CA
(and an attestation certificate issued by that CA) is trivial - it can
be done with OpenSSL, OpenJDK's keytool, EJBCA and many other tools -
including those designed to work with TPMs for very good security.
However, before you go down that path, have you considered how you will
protect the private key of the attestation certificate that must be
embedded with each FIDO Authenticator? If you cannot protect the
attestation certificate's private key while executing in somebody's
browser, anyone with the knowledge and capability will be able to copy
your AAGUID, private key and attestation certificate, and duplicate the
Authenticator [1] [2].
Having a password to protect that private key is useless since the
password must be available in the Authenticator of that browser to be
able to use the private key to sign the attestation during FIDO
registrations.
Providing a unique attestation certificate for each Authenticator is
prohibited by FIDO specification, as it violates user privacy (users can
be tracked across sites even though their FIDO credential does not carry
any username); an attestation certificate must be used for a minimum of
100,000 Authenticators (last time I read FIDO security guidelines).
These security & privacy problems are not simple and were debated for
years within the FIDO Alliance before the CTAP and WebAuthn Level-1
specifications were published. Not understanding the implications of
these designs can lead to a disaster for the RP (if you are working on
an important application).
Arshad
[1] Note that if your RP application has other protections to verify the
identity of its users besides the software Authenticator, having your
Authenticator duplicated may not be of great concern to you. But, if it
is the only means of authentication besides the initial identity
verification, then it should matter.
[2] I am also assuming you are planning to prompt the user for some PIN
or password to protect their newly generated private key - otherwise
that becomes another vector for attack.
>> and- <https://fidoalliance.org/technical-note-fido-authentication-
>> and->
>> > emv-3-d-secure-using-fido-for-payment-authentication/ <https://
>> > fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-
>> <http://fidoalliance.org/technical-note-fido-authentication-and-
>> authenticate-financial->
>> > services-summit-keynote-toward-frictionless-strong-customer-authn/
>> > <https://authenticatecon.com/content/video-authenticate-
>> financial- <https://authenticatecon.com/content/video-
>> authenticate-financial->
>> an email to [email protected] <mailto:fido-
>> [email protected]>.
>> fidoalliance.org/d/msgid/fido-dev/cc3b6b92-cc61-4780-9fb9-
>> fba071af7678n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
> [email protected]>.
> A518-36D6DEF7ABB3%40gmail.com <https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/6F167E0B-15F4-4587-
> A518-36D6DEF7ABB3%40gmail.com?utm_medium=email&utm_source=footer>.
As Shane pointed out, you do not necessarily need a commercial CA to
create your attestation certificate - it can be created with a
self-signed CA maintained by you/your company. Creating a self-signed CA
(and an attestation certificate issued by that CA) is trivial - it can
be done with OpenSSL, OpenJDK's keytool, EJBCA and many other tools -
including those designed to work with TPMs for very good security.
However, before you go down that path, have you considered how you will
protect the private key of the attestation certificate that must be
embedded with each FIDO Authenticator? If you cannot protect the
attestation certificate's private key while executing in somebody's
browser, anyone with the knowledge and capability will be able to copy
your AAGUID, private key and attestation certificate, and duplicate the
Authenticator [1] [2].
Having a password to protect that private key is useless since the
password must be available in the Authenticator of that browser to be
able to use the private key to sign the attestation during FIDO
registrations.
Providing a unique attestation certificate for each Authenticator is
prohibited by FIDO specification, as it violates user privacy (users can
be tracked across sites even though their FIDO credential does not carry
any username); an attestation certificate must be used for a minimum of
100,000 Authenticators (last time I read FIDO security guidelines).
These security & privacy problems are not simple and were debated for
years within the FIDO Alliance before the CTAP and WebAuthn Level-1
specifications were published. Not understanding the implications of
these designs can lead to a disaster for the RP (if you are working on
an important application).
Arshad
[1] Note that if your RP application has other protections to verify the
identity of its users besides the software Authenticator, having your
Authenticator duplicated may not be of great concern to you. But, if it
is the only means of authentication besides the initial identity
verification, then it should matter.
[2] I am also assuming you are planning to prompt the user for some PIN
or password to protect their newly generated private key - otherwise
that becomes another vector for attack.
>> and->
>> > emv-3-d-secure-using-fido-for-payment-authentication/ <https://
>> > fidoalliance.org/technical-note-fido-authentication-and-emv-3-d-
>> <http://fidoalliance.org/technical-note-fido-authentication-and-
>> emv-3-d->
>> > secure-using-fido-for-payment-authentication/>)
>> >
>> > You can find a high-level description of the StrongKey Android
>> Client
>> > Library (SACL), starting in the middle of this presentation (at
>> about
>> > the 5-minute mark):
>> >
>> > https://authenticatecon.com/content/video-authenticate-
>> financial- <https://authenticatecon.com/content/video-
>> > secure-using-fido-for-payment-authentication/>)
>> >
>> > You can find a high-level description of the StrongKey Android
>> Client
>> > Library (SACL), starting in the middle of this presentation (at
>> about
>> > the 5-minute mark):
>> >
>> > https://authenticatecon.com/content/video-authenticate-
>> authenticate-financial->
>> > services-summit-keynote-toward-frictionless-strong-customer-authn/
>> > <https://authenticatecon.com/content/video-authenticate-
>> financial- <https://authenticatecon.com/content/video-
>> authenticate-financial->
>> [email protected]>.
>> To view this discussion visit https://groups.google.com/a/
>> fidoalliance.org/d/msgid/fido-dev/cc3b6b92-cc61-4780-9fb9-
>> fba071af7678n%40fidoalliance.org <https://groups.google.com/a/
>> fidoalliance.org/d/msgid/fido-dev/cc3b6b92-cc61-4780-9fb9-
>> fidoalliance.org/d/msgid/fido-dev/cc3b6b92-cc61-4780-9fb9-
>> fba071af7678n%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 [email protected] <mailto:fido-
> --
> 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
> [email protected]>.
> To view this discussion visit https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/6F167E0B-15F4-4587-
> A518-36D6DEF7ABB3%40gmail.com <https://groups.google.com/a/
> fidoalliance.org/d/msgid/fido-dev/6F167E0B-15F4-4587-
> A518-36D6DEF7ABB3%40gmail.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages