Regarding the issue of Credential ID exposure(13.5.6), from what perspective should RP compare RK and NRK and which should be adopted?

[keikoit]

Thank you for the other day which I have received a quick response to the #1475 Issue.

Let me raise another discussion in this regard.

I think there are various countermeasures for exposing the Credential ID. RP has to think about how effective they can be, how much complex work RP will have to do, and how it will affect usability for consumers.

On the other hand, if we use RK and set AllowCredentials = empty, the server does not need to send the CredentialID, which I think is one of the fundamental solution to this problem.

I think it would be good to mention this point in the specifications and encourage the RP to decide whether to use RK or NRK in a balance with each risk judgment and ease of implementation.

[ve7jtb]

I agree in general about using an empty allow list, however there are some practical problems.

1. The Android platform authenticator doesn't support empty allow lists.
2. Most roaming authenticators have limited storage for resident credentials.

Without getting at least issue 1 addressed it is hard for RP to rely on discoverable credentials.

Sending an allow list works with 100% of the platforms and authenticators.

It is a trade off for the moment.

[maxhata]

Many RPs are wondering how we can help solving the problem 1.

[ve7jtb]

You know I do what I can to keep the pressure up on 1, but others need to speak up to make it a priority for the Android team.

CTAP2 support would also help RP.
I am getting more RP complaining about getting U2F attestations from Android and FireFox.
That complicates things for them when using WebAuthn.

[j-hayakawa]

I believe RK is simpler and more secure.

For example, if we want to use a platform authenticator instead of a password, but RK is not available, we need to consider the following mitigation measures. 14.6.2. Username Enumeration

At a minimum, the following NOTES should be considered.

Note: If returned imaginary values noticeably differ from actual ones, clever attackers may be able to discern them and thus be able to test for existence Examples of noticeably different values include if the values are always the same for all username inputs, or are different in repeated attempts with the same username input. The allowCredentials member could therefore be populated with pseudo-random values derived deterministically from the username, for example.

In addition, in a real-world use case we need to consider the following

• Length of credential ID. Depends on the type of authenticator and vendor.
• Number of credential IDs. A user may have more than one authenticator registered.

Since these are dependent on user usage, it is difficult to consider the appropriate logic.

[keikoit]

Hell @nadalin -san, Let me follow-up the current status. I would be appreciated if you could tell me what we can do to accelerate the development of the Android team.