Length restriction on user handles has no processing model associated with it

[bzbarsky]

https://w3c.github.io/webauthn/#dom-publickeycredentialuserentity-id says:

A user handle is an opaque byte sequence with a maximum size of 64 bytes

but nothing says where or whether that maximum size is enforced. Based on code inspection, Firefox checks for this in code that gets called from CredentialsContainer.create and throws an exception (a DOMException with name "TypeError") if the user handle is longer than 64 bytes. Also based on code inspection it looks like Chrome throws a JS TypeError in this situation (with a comment about https://www.w3.org/TR/webauthn/#user-handle).

Note that the lack of clear processing model leads to lack of interop here: the two browsers are throwing totally different kinds of exceptions...

@jcjones

[bzbarsky]

Also, disabling this check in Firefox does not obviously lead to any web platform test failures, unless I am missing something....

[equalsJeffH]

@jcjones notes at webauthn f2f 20-Sep-2019 that this underscores the desirability for landing PR #1256 and being able construct viable Web Platform Tests.

[nsatragno]

We already have a WPT that checks for this. I think this is good enough - closing the issue.

[bzbarsky]

Just because there are tests doesn't mean the spec actually defines the behavior the tests are testing for. And in particular, the test is testing that a TypeError is thrown, but the spec doesn't actually say that!

That is, the test is not actually based on the spec, so it's not a valid test. Please do fix the spec. @nsatragno I can't reopen this issue, unfortunately; can you please do that?

[agl]

On the 2020-11-18 call the WG decided that if a WPT existed for this then the issue would be closed. There are lots of requirements in the spec that are not explicitly tested for in the processing steps and the value in writing them all out does not seem worthwhile.

[bzbarsky]

That is so completely backwards. The point of a spec is that it needs to specify what an implementation is supposed to do. A spec that does not do that is not actually usable for implementation. The tests can be used to validate implementations, but the tests are not the spec; they have no normative value and can be wrong, not match the spec, etc.

@annevk I don't know whether Mozilla's W3C rep cares about this, but they should at least know about it.

[bzbarsky]

To be clear, the issue here is not that the requirement is not explicitly "tested for in the processing steps"; the issue is that requirement does not actually define what the behavior should be!

[nsatragno]

Friendly reminder to follow the code of ethics and professional conduct for all w3c communications.

[othermaciej]

I agree with @bzbarsky. Tests are supposed to test normative requirements defined by the spec. While tests are a great help to interoperability, it’s actively harmful to have the tests checks for things that are not normative requirements of the spec. Normally, when it’s noticed that a test checks for something not in the spec, either the spec is fixed to specify what’s intended, or the test is removed or modified. That is how other WGs do it. WebAuthentication should not be an exception to that normal flow.

[jcjones]

Per all the above comments. re-opening to re-triage

[dveditz]

NB that this issue is not about the difference between Chrome and Firefox behavior in this specific case: Firefox was changed to match the Chrome behavior in bug 1610732 last January. The point is that the behavior is not in the spec and can only be determined experimentally.

[agl]

Neither of the working group member organisations who requested action here have actually proffered any pull requests thus I've attempted #1539 to move things forward.

[annevk]

I have to say I rather disagree with the idea that the onus is on those raising a problem to fix it. I'm reasonably certain that if you'll ask others in the Chrome team they'll agree that a specification that does not define its processing models fully has a problem. And that it's not necessarily up to those pointing that out to fix it.