Requesting properties of created credentials.

[ve7jtb]

In conversations with some government RP around national ID (aka "eID") programs, there seems to be a requirement that keys not be exportable or shared.

That may or not be the case with Fido L1 and L2 authenticators depending on a number of factors.

In some cases, the RP may also want to guide the user to an authenticator with a particular certification.
As an example, a US Fedramp high application may need a FIPS-140-L2 certified authenticator.

Currently, an RP needs to call makeCredential and ask for an attestation, they then reject any that don't meet the requirements set in meta-data.

In the first use case, an authenticator might be able to store both restricted and unrestricted credentials if it could get the RP's requirements.

I am proposing a new extension that would pass policy requirements to the authenticator and platform.

In the case of the RP wanting a restricted credential, the extension would have a map with { "keyProtection" : 2 , "isKeyRestricted" : True } to indicate it wants HW protected keys that aren't shared with other applications.

One concern is that at some point platform authenticators will start backing up keys. If we don't have a way to flag a key as restricted then eID systems may not allow platform authenticators causing regrettable fragmentation.

We will need to discuss what sorts of policies are appropriate. The extension containing a map is the simple part.

[sbweeden]

The credProps extension was initially headed down this path and then brought back to a more narrow use case...

[equalsJeffH]

on 2020-07-01 call: keep this issue open for L3 and see how all the subtle issues here play out.

[emlun]

I was also thinking this could perhaps be an addition to the credProps and/or credProtect extensions.

[eldanb]

With platforms introducing support for cross-device credentials, don't we also need/want a mechanism to allow signalling to the platform, on credential creation, that a hardware-backed key is desired?

[sbweeden]

An authenticator selection criteria perhaps....

[Firstyear]

With platforms introducing support for cross-device credentials, don't we also need/want a mechanism to allow signalling to the platform, on credential creation, that a hardware-backed key is desired?

@eldanb I think what @sbweeden is trying to say is that the spec for webauthn already has these capabilities. What you may be encountering is that sometimes the language used for these things in the spec is quite specific to this spec, and requires some experience and interpretation. Have a look at https://www.w3.org/TR/webauthn-2/#client-side-discoverable-credential which talks about keys that are stored in the hardware, vs stored in the client-id on the server (key-wrapped key). To determine if this was indeed done, you need to check some extensions to guarantee it (normally it's a hint that you prefer this, to make it enforced you have to check the extensions in the registrations).

[sbweeden]

Actually I think there is room for expansion of the AuthenticatorSelectionCriteria to be more explicit as to what the RP wants or requires. For example, you could imagine additional criteria to indicate if there is a requirement for a device-bound credential vs accepting a cloud-account-backed credential. Per recent discussion on the WebAuthn WG call I believe there is a PR coming related to an extension for supporting device-bound credentials associated with a cloud-account-backed credential.

I think this issue can be revisited in the context of that PR, however it may well be the right time to look at new or modified AuthenticatorSelectionCriteria properties that permit an RP to be more selective.

[sbweeden]

I also think the existing credProps extension could be used as a means for the client to indicate (to RP's that are not being prescriptive on cloud vs device-bound) what was actually created.

[eldanb]

@Firstyear I think what you referred to are resident vs non resident keys (or discoverable vs non discoverable) whereas the distinction here is between device-bound vs shared across devices. The latter has implications re keys being hardware backed or not, the former doesn’t necessarily have those.

@sbweeden yes, that’s what I’m getting at. Allowing an RP to require (or prefer) hardware backed keys when using platform authenticators (probably could be generalized for roaming too?)

[emlun]

probably could be generalized for roaming too?

Roaming or not already has the authenticatorSelection.authenticatorAttachment option, and getTransports() can sometimes tell what the result ended up being ("internal" means platform credential, any other value means roaming; note that both "internal" and other values may potentially appear together).

I also think that if an RP needs to require a hardware-backed credential (say, for legal compliance reasons), then that will also require attestation since that's the only way to know for sure (which also means that use case is already supported - in a roundabout way perhaps, but you'll still have to do all that work even if we add a "require hardware-backed" parameter). But a new AuthenticatorSelectionCriteria parameter could certainly be useful for less strict use cases were it could be treated more like a hint than a requirement.

[Firstyear]

With platforms introducing support for cross-device credentials, don't we also need/want a mechanism to allow signalling to the platform, on credential creation, that a hardware-backed key is desired?

@Firstyear I think what you referred to are resident vs non resident keys (or discoverable vs non discoverable) whereas the distinction here is between device-bound vs shared across devices. The latter has implications re keys being hardware backed or not, the former doesn’t necessarily have those.

You literally asked for hardware backed vs not - that's the definition of resident vs non-resident.

If you meant a credential that is PART of the device vs not, then @emlun is correct that you want roaming or non-roaming. You can only assert this via attestation however.

[equalsJeffH]

@ve7jtb wrote:

In conversations with some government RP around national ID programs, there seems to be a requirement that (A) keys not be exportable or shared.
[ ... ]
In some cases, the RP may also want to (B) guide the user to an authenticator with a particular certification.
As an example, a US Fedramp high application may need a FIPS-140-L2 certified authenticator.

Overall, it would be good to have the fine-grained use cases & requirements from the eID folks.

Requirement (A) seems to actually be two requirements:

• (A.1), the credential (aka key) be device-bound (in hardware), and
• (A.2), only be usable by the RP ID and specific app (browser or native app?) that created it (I'm not sure how workable that is...).

Regarding (A.2) and (B), they would seem to be things that would foster fragmentation (users needing multiple authnrs for specific purposes and/or RPs) in the consumer context, and so would seem more applicable to the enterprise context ...?

Regarding (A.1), it may turn out to be addressed by the device-bound key we are envisioning in answer to issue #1546.

[arshadnoor]

Given that the WebAuthn specification has already become sufficiently complex to make it challenging to follow (even for people who've been part of the FIDO Alliance for years), may I suggest a simplification?

The TLS Cipher Suite defines very precise requirements through mnemonics/hex-codes on precisely what cipher suite (aka security policy) is desired in a TLS connection. Would it not make sense to define a sequence for FIDO credential policy requirements, mnemonics for those policies with equivalent hex-codes and just pass those mnemonics/hex-codes in a credentialPolicy to the authenticator?

This would allow for a simpler WebAuthn specification for defining policy, and allow for a table to list all the policies that RPs may define, that implementions might support and labs might test for certification. If new policy attributes arise, then by simply adding new mnemonics to existing policies with new hex-codes would extend credential policies without creating new versions of WebAuthn to deal with every policy change that comes along.

It would greatly simplify FIDO authenticator and server implementations for policy management.

[ve7jtb]

In conversations with some government RP around national ID programs, there seems to be a requirement that (A) keys not be exportable or shared.

By shared I was referring to what we currently have as the restricted property.

The key if stored in a secure element or secure exciting environment it needs to only be available to the authenticator application.

In some architectures any application can ask for a key to be used for signing if the user is authenticated.

The eIDAS regulation is quite clear on this requirement for level high.

CZ.nic who run a Czech eIDAS service that supports Fido2 authenticators has been through this with there auditors for certification.

I have had similar conversations with other eIDAS providers in other countries.

The way they deal with it now is by doing the makeCredential with attestation and comparing that to a white list and rejecting or allowing non conforming authenticators to only work for lower levels.

The idea would be to provide a hint to the platform with the makeCredential so that the platform could help the user, and perhaps reduce the number of round trips the user needs to do if they have multiple authenticator options.

If in the fedramp case any non FIPS certified authenticators are going to have there attestations rejected the user could be warned if they select an authenticator that doesn't meet the requirements without having to round trip the transaction.

The fedramp use case may be specific to an Enterprise.

The eIDAS one is a grey area between consumer and Government.

I don't know if any of the current platform authenticators would qualify for eIDAS high now, or if proposed changes with syncing keys between devices would have an impact.

That is something we would need to take up with EU regulators.

For clarification by cross device I was referring to discoverable credentials created on one device and replicated to other devices by a password manager or keychain replication method. Not roaming authenticators. So this is not currently coverd in credential props.
John B.

[cyberphone]

@ve7jtb It is not evident how to use FIDO/WebAuthn in a market which to date in many cases build on the PKI model. I guess you are targeting those who are using IdPs rather than client-certificates? In case you are also considering the PKI model, you will probably need something like the SPC folks; a dedicated application in the browser which among many things keeps track of which sites the user has decided to trust/accept.

Related: https://ec.europa.eu/commission/presscorner/detail/en/IP_21_2663

[ve7jtb]

Yes I am referring to the growing number of IdP using federation rather than PKI smart cards for eIDAS and other civil registry backed services around the world.

Some IDP have additional regulatory constraints.

[timcappalli]

Closing as a duplicate of #1688