What is residentKey?

[Sabarinathan Eaganathan]

What is residentKey?
Why it is required to configure passkey?

Can someone please explain in detail

[My1]

resident key, nowadays iirc also called client discoverable credential, basically means that you don't need help from the relying party (aka website) for credential discovery. Normally this means that the keys are resident on the FIDO Device, hence the name.

This is mainly used for username-less login where you just click a login button, enter your PIN, touch your FIDO device of choice and are in. or if you have multiple credentials to the site, you get a list.

This is in contrast to "normal" credentials which need the credential ID (or Key Handle if you have been in U2F) to actually calculate the stuff out needed to do everything.

The primary restriction is that there's a limited amount of RK space on FIDO devices (like Yubikeys only support TWENTY-FIVE of them which is kinda nothing.

Why they are so heavily wanted for passkeys is beyond me, but I guess they wanted to have a specific list of credentials to sync around so you can also know what credentials even exist, instead of just having a master key that works with the credential IDs.

--
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/eea7eb28-71fe-4020-bbfa-3d1d8186e017n%40fidoalliance.org.

[Arshad Noor]

https://www.w3.org/TR/webauthn-2/#enum-residentKeyRequirement

residentKey was historically intended to mean that the key-pair is
generated within cryptographic hardware on the client, and the
cryptographic hardware does NOT release the private key, even when the
public key is registered with the relying party's FIDO server.

Passkey implies - at least without an adjective - that the key-pair
(including the private key) is sent to the cloud (by the passkey
provider), and comes down on whichever device the passkey provider
enables it to do so.

The FIDO protocols have gone through a convoluted evolution in the last
8-9 years; as each large platform provider joins the alliance, it goes
through yet another metamorphosis where even people who have been around
since its inception have a hard time understanding/explaining what the
current state of FIDO is today; so don't beat yourself. Hopefully,
someday this dust will settle and FIDO may still represent something we
can all believe in.

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 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/eea7eb28-71fe-4020-bbfa-3d1d8186e017n%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/eea7eb28-71fe-4020-bbfa-3d1d8186e017n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[Tim Cappalli]

This may help: https://passkeys.dev/docs/reference/terms/#discoverable-credential

---

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of Sabarinathan Eaganathan <mail2sa...@gmail.com>
Sent: Wednesday, September 6, 2023 7:39:09 AM
To: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: [FIDO-DEV] What is residentKey?

 

What is residentKey?
Why it is required to configure passkey?

Can someone please explain in detail

--

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/eea7eb28-71fe-4020-bbfa-3d1d8186e017n%40fidoalliance.org.

[Emil Lundberg]

A client-side resident key ("resident key") is a private key stored in memory within the authenticator (security key) and/or client (browser). This is in contrast to a server-side-resident key ("non-resident key"), where the private key (or parameters for deriving the private key) is instead encoded into the credential ID which is stored on the server.

Non-resident keys do not consume storage space on the authenticator, but they have the drawback that the credential ID must be retrieved from the server and provided to the authenticator before the authenticator can unwrap the key material and then use the unwrapped private key to sign a challenge. This means that non-resident keys are usually used as a second factor after a user has first identified themself (usually with a username) and authenticated themself with a first factor (usually a password), after which the server can respond with a WebAuthn challenge containing that user's credential IDs.

A resident key consumes storage space, but does not need to be retrieved from the server first. This means that the server can issue an anonymous WebAuthn challenge without knowing who the user is yet, and the authenticator can respond with both an authentication signature and a user ID at the same time.

Arshad Noor's description is incorrect - whether a key is a resident key has nothing to do with whether that key is hardware-bound. A non-resident key may be hardware-bound and non-exportable - and are on YubiKeys, for example - and a resident key may be implemented in software and copied between machines. It is also incorrect that an unqualified passkey is cloud-synced - an unqualified passkey may be either a hardware-bound passkey (for example on a YubiKey) or a synced passkey (for example on a smartphone).

Note that "resident key" is a deprecated term, now replaced by the term "discoverable key", though the WebAuthn API still uses the residentKey parameter name for backwards compatibility. The term was changed because authenticators can choose to not reveal the existence of a key even if it is stored within the authenticator - the key can be "resident" in authenticator memory but not "discoverable" without knowing the credential ID. The new term "discoverable key" better describes whether the key can be used without first providing the credential ID. Thus a discoverable key must necessarily be stored within the authenticator, but a key stored within the authenticator might not necessarily be discoverable.

A passkey is by definition a discoverable credential, so you need to request residentKey: "required" if you want to create a passkey.

Emil Lundberg

Senior Software Engineer | Yubico

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/a0cbae3a-1333-4234-e071-44b6184ea156%40strongkey.com.

[My1]

maybe just call them client side key and server side key and drop the resident in the middle, makes it just more confusing imo.

Regards

My1

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

[Arshad Noor]

Hi Emil,

On 9/6/23 05:01, Emil Lundberg wrote:
> Arshad Noor's description is incorrect - whether a key is a resident key
> has nothing to do with whether that key is hardware-bound. A
> non-resident key may be hardware-bound and non-exportable - and are on
> YubiKeys, for example - and a resident key may be implemented in
> software and copied between machines.

I appreciate - and understand - your perspective. Given that Yubico's
implementation is built on this model (using a symmetric key in the
authenticator to encrypt key-pairs and send them to the FIDO server for
storage), the term "resident key" is fluid.

Having cut my teeth on PKI, "resident key" implied a key pair generated
on a chip (preferably, FIPS certified) and designed to never let the
private key out of that chip. Coming into the FIDO Alliance 8-9 years
ago (with 15+ years behind me in PKI) I had a different interpretation
than what the U2F working group might have bandied around.

Neither of us are wrong - just different contexts shaping our notions.

It is also incorrect that an
> unqualified passkey is cloud-synced - an unqualified passkey may be
> either a hardware-bound passkey (for example on a YubiKey) or a synced
> passkey (for example on a smartphone).

This, IMO, is a significant problem with FIDO/WebAuthn: very fluid
definitions and interpretations depending on who you talk to. Yes, there
are specs, but the complexity of the specs makes it very difficult for
newcomers to understand - and adopt - the technology.

If an unqualified passkey can be two things at the same time, why does
anyone use an unqualified "passkey" in their text? It cannot be for the
sake of simplicity because it only adds to the confusion.

If the goal of the "passkey" providers is obfuscation of the fact that
private keys are going into the cloud where users have little control of
them, then it will succeed admirably. Except for those who are trying to
be precise for the sake of educating/informing non-technical people
about the security of FIDO.

Arshad Noor
StrongKey

[Emil Lundberg]

residentKey was historically intended to mean [...]
[...]

I had a different interpretation than what the U2F working group might have bandied around.

My apologies - I missed that you were referring to a historic context before the introduction of FIDO. The point still stands within the context of FIDO, though, which is the context of the question.

This, IMO, is a significant problem with FIDO/WebAuthn: very fluid

definitions and interpretations depending on who you talk to.

I hope the confusion around the term "passkey" will diminish as the terminology and implementations mature. The FIDO Alliance has formally agreed on the definition I mentioned earlier, and in my opinion, at least the W3C Web Authentication working group has been consistent in using this definition and qualifying the term when relevant.

If an unqualified passkey can be two things at the same time, why does
anyone use an unqualified "passkey" in their text?

Not all use cases, nor all users, care about the exportability/mobility characteristics of the passkey.