Re: [webauthn] Use of in-field metadata not preferred (#1643)

We met with @aphillips June 4th, then further discussed the issue on June 11th.

Implementing resource-level fields as proposed in https://github.com/w3c/webauthn/pull/2280 requires authenticators to support those fields. This presents a problem: authenticators deployed today wouldn't have support for them. For security keys, we'd need to add support on the next version of FIDO and new keys would have to support it, which would take well over a year. And, existing security keys would never get support. Chrome is therefore unlikely to ever implement the current proposal as-is.

The in-field metadata solution does not have the problem, since it embeds the metadata on existing strings. The number of implementations that have to understand the encoding is also very limited: only browsers and OSs have access to and render credential metadata, not relying parties. I understand that this also has issues as described above.

We can meet in the middle in one of two ways:
- Expose the resource-level fields, but encode the information in the string. This still requires browsers to understand the custom encoding scheme, but relying parties won't have to. This is quite a bit of work to specify and implement, so I would punt that work for L4 and keep the status quo for L3.
- Remove the custom encoding, at least the language tag. The language tag seems ignored by browsers now, but the direction marks seem to work. This would reflect reality, while leaving open the door to make changes in L4.

-- 
GitHub Notification of comment by nsatragno
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1643#issuecomment-2963962653 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 June 2025 19:45:23 UTC