Groups keyboard shortcuts have been updated
Dismiss
See shortcuts
Preventing registration on multiple devices
184 views
Skip to first unread message
Marin Kirkov
Jan 21, 2025, 4:17:16 PMJan 21
to FIDO Dev (fido-dev)
I have read the considerations about avoiding turning webauthn into a super cookie but the whole point of biometrics is to be able to identify a user on many devices. So imagine the following use case. You are developing a wallet for universal basic income. To avoid malicious behavior you want to make sure a user can register only once and can't get new wallets from new devices. Is there a way to achieve that while maintaining the security per device? Is it possible to avoid tracking while covering this use case?
Tim Cappalli
Jan 21, 2025, 10:58:01 PMJan 21
to Marin Kirkov, FIDO Dev (fido-dev)
On Tue, Jan 21, 2025, 13:17 Marin Kirkov <m.ki...@gmail.com> wrote:
I have read the considerations about avoiding turning webauthn into a super cookie but the whole point of biometrics is to be able to identify a user on many devices. So imagine the following use case. You are developing a wallet for universal basic income. To avoid malicious behavior you want to make sure a user can register only once and can't get new wallets from new devices. Is there a way to achieve that while maintaining the security per device? Is it possible to avoid tracking while covering this use case?
--
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 visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/af148f63-38fc-47e7-9498-7839885cfc27n%40fidoalliance.org.
Pro Coder 101
Jan 22, 2025, 7:33:54 PMJan 22
to Marin Kirkov, FIDO Dev (fido-dev)
Yes, when registering or enrolling on WebAuthn, you get a field called Credential ID inside the attestationObject, authenticatorData. You can use this credential ID to uniquely identify the devices and then build your application based on that.
On Wed, Jan 22, 2025, 5:58 AM Marin Kirkov <m.ki...@gmail.com> wrote:
I have read the considerations about avoiding turning webauthn into a super cookie but the whole point of biometrics is to be able to identify a user on many devices. So imagine the following use case. You are developing a wallet for universal basic income. To avoid malicious behavior you want to make sure a user can register only once and can't get new wallets from new devices. Is there a way to achieve that while maintaining the security per device? Is it possible to avoid tracking while covering this use case?
--
Tim Cappalli
Jan 22, 2025, 8:43:17 PMJan 22
to Pro Coder 101, Marin Kirkov, FIDO Dev (fido-dev)
A credentialID does not identify a device.
Arshad Noor
Jan 23, 2025, 11:40:47 AMJan 23
to Marin Kirkov, FIDO Dev (fido-dev)
There are multiple design requirements in this paragraph that are not
consistent with how FIDO works, or how non-technical consumers are
likely to perceive digital wallets.
First, FIDO was designed to be a privacy-protecting, authentication
protocol based on the use of public-key cryptography (PKC).
Theoretically, the public-keys in a specific key-pair are not bound to a
specific user by themselves - other identifying information has to be
maintained by the relying party (RP) undertaking the challenge-response
protocol inherent in PKC systems. In the X509 world, it is the digital
certificate issued by a certificate authority (CA); in the FIDO world,
it is the combination of the relying party identifier (RPID), the
credential ID created by the Authenticator, and the Authenticator device
itself (Security Key, TPM, etc.).
The logical consequence of this paradigm is that X509 and FIDO permit a
user to have any number of public-keys bound to them - be they in the
form of multiple digital certificates or credential IDs from different
Authenticators. Your desire to have users have only a single credential
to authenticate them for universal basic income (UBI) is contrary to the
properties of PKC.
The design paradigm you should be pursuing should be to create a robust
process to identify process to identify users uniquely, and enable them
to register their "origin" (first) credential on an Authenticator with
strong security and attestation capabilities, that does NOT release the
private key out of the Authenticator under any circumstance.
Once the "origin credential" is created, you can then authenticate the
user with that credential and allow them to create additional
credentials (as business processes warrant) that meet similar security
goals as the "origin credential". (Theoretically, there are other
possible designs, but not knowing all the UBI business requirements, it
is hard to conjecture solutions).
Having Authenticators providing the security, privacy and attestations
that meet business, operational, technical and security requirements is
fundamental to leveraging PKC effectively. Trying to bend PKC in any
protocol implementation is only likely to lead to unpleasant surprises.
Arshad Noor
StrongKey
P.S. I normally would not bring this up in an authentication forum, but
given that there is mounting hype around "digital wallets", I feel I
should mention something here.
Designing a system that allows a user to have only a single digital
wallet is contrary to how consumers view wallets in the real world.
Wallets are containers for all kinds of objects; to design a digital
wallet for a specific purpose without being able to store all kinds of
digital objects that meet certain basic (security and privacy)
requirements will not be very useful in the long term.
If the" UBI Authorization" is a properly constructed, digitally signed
document (DSIG, JWS, VC, etc.), then it does not matter which digital
wallet can store it, or how many digital wallets store the same
authorization - the authorization should be bound to a specific person,
attested to by an appropriate authority with appropriate (secure)
digital controls. That the same authorization can live in multiple
wallets should not impede the user from choosing the digital wallet of
their choice. With the right implementation of the aforementioned
protocols/standards, flexibility can be achieved without constraining
users of bending PKC protocols.
> dev+uns...@fidoalliance.org>.
> af148f63-38fc-47e7-9498-7839885cfc27n%40fidoalliance.org <https://
> groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/
> af148f63-38fc-47e7-9498-7839885cfc27n%40fidoalliance.org?
> utm_medium=email&utm_source=footer>.
consistent with how FIDO works, or how non-technical consumers are
likely to perceive digital wallets.
First, FIDO was designed to be a privacy-protecting, authentication
protocol based on the use of public-key cryptography (PKC).
Theoretically, the public-keys in a specific key-pair are not bound to a
specific user by themselves - other identifying information has to be
maintained by the relying party (RP) undertaking the challenge-response
protocol inherent in PKC systems. In the X509 world, it is the digital
certificate issued by a certificate authority (CA); in the FIDO world,
it is the combination of the relying party identifier (RPID), the
credential ID created by the Authenticator, and the Authenticator device
itself (Security Key, TPM, etc.).
The logical consequence of this paradigm is that X509 and FIDO permit a
user to have any number of public-keys bound to them - be they in the
form of multiple digital certificates or credential IDs from different
Authenticators. Your desire to have users have only a single credential
to authenticate them for universal basic income (UBI) is contrary to the
properties of PKC.
The design paradigm you should be pursuing should be to create a robust
process to identify process to identify users uniquely, and enable them
to register their "origin" (first) credential on an Authenticator with
strong security and attestation capabilities, that does NOT release the
private key out of the Authenticator under any circumstance.
Once the "origin credential" is created, you can then authenticate the
user with that credential and allow them to create additional
credentials (as business processes warrant) that meet similar security
goals as the "origin credential". (Theoretically, there are other
possible designs, but not knowing all the UBI business requirements, it
is hard to conjecture solutions).
Having Authenticators providing the security, privacy and attestations
that meet business, operational, technical and security requirements is
fundamental to leveraging PKC effectively. Trying to bend PKC in any
protocol implementation is only likely to lead to unpleasant surprises.
Arshad Noor
StrongKey
P.S. I normally would not bring this up in an authentication forum, but
given that there is mounting hype around "digital wallets", I feel I
should mention something here.
Designing a system that allows a user to have only a single digital
wallet is contrary to how consumers view wallets in the real world.
Wallets are containers for all kinds of objects; to design a digital
wallet for a specific purpose without being able to store all kinds of
digital objects that meet certain basic (security and privacy)
requirements will not be very useful in the long term.
If the" UBI Authorization" is a properly constructed, digitally signed
document (DSIG, JWS, VC, etc.), then it does not matter which digital
wallet can store it, or how many digital wallets store the same
authorization - the authorization should be bound to a specific person,
attested to by an appropriate authority with appropriate (secure)
digital controls. That the same authorization can live in multiple
wallets should not impede the user from choosing the digital wallet of
their choice. With the right implementation of the aforementioned
protocols/standards, flexibility can be achieved without constraining
users of bending PKC protocols.
> --
> 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-
> 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
> dev+uns...@fidoalliance.org>.
> af148f63-38fc-47e7-9498-7839885cfc27n%40fidoalliance.org <https://
> groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/
> af148f63-38fc-47e7-9498-7839885cfc27n%40fidoalliance.org?
> utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages