Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider whether browsers should truncate name and displayName. #1296

Closed
agl opened this issue Sep 10, 2019 · 2 comments · Fixed by #1316
Closed

Consider whether browsers should truncate name and displayName. #1296

agl opened this issue Sep 10, 2019 · 2 comments · Fixed by #1316
Assignees
@agl
Labels
stat:pr-open type:technical
Milestone
L2-WD-02

Comments

@agl
Copy link
Contributor

agl commented Sep 10, 2019 •
edited by equalsJeffH

We say of PublicKeyCredentialEntity's name and PublicKeyCredentialUserEntity's displayName, that:

Authenticators MAY truncate […] to a length equal to or greater than 64 bytes.

Some authenticators do, indeed, truncate these strings at 64 bytes. This may cut a UTF-8 sequence and thus produce invalid strings in responses. Because of this, WebAuthn now has a section on handling these truncated strings.

However, some authenticators will also reject any operations where the strings are longer than 64 bytes. Whatever the fidelity of that behaviour to the spec, it's now reality. Therefore we should consider whether it's the browser's job to do the truncation in order to ensure that requests work. If we do not, then RPs will probably do it themselves because things will fail otherwise and once RPs do it, we'll not be able to add support for future authenticators which have more storage.

(Since there exist truncating authenticators out there, the rules around string handling still apply because those authenticators aren't going away either.)

(I don't know, off-hand, what the behaviour for icon is in practice.)

(This relates to fido-alliance/fido-2-specs#673.)
@nadalin nadalin added this to the L2-WD-02 milestone Sep 11, 2019
@lgarron
Copy link
Contributor

lgarron commented Sep 13, 2019 •
edited

I don't know if this is the best place to comment, but: if RPs do have to truncate in the future, it would help to have some guidance on whether it matters that the RPs do a strict truncation.

Something like an ellipsis would help distinguish between names that are ≈64 bytes and those that are longer: thisismyexteemelylongusernamethatistotallyreasonabletouseonth…

I would assume that this is fine because the name is meant for user-facing UI, but it wouldn't be strict truncation and I'd be a tad worried that some corner cases of authenticators/browsers/servers implementations might run into issues with this in the future.

@nadalin
Copy link
Contributor

nadalin commented Oct 2, 2019

@agl to create PR

@agl agl removed the type:editorial label Oct 9, 2019
agl added a commit to agl/webauthn that referenced this issue Oct 15, 2019
@agl
Truncate strings for authenticators where needed.
7e19d38 
There exist a significant number of authenticators that do not conform
to the current WebAuthn requirements in that they fail requests with
name/displayName strings longer than 64 bytes, rather than truncating
them.

This change adds a new requirement on user-agents that they maintain the
authenticator model for RPs by doing the truncation on their behalf in
this case. The alternative is that each RP will hit this edge-case and
do the truncation itself, thus the ecosystem will never be able to
support longer strings.

Since user-agents may now be doing truncation, this change also permits
truncation at the level of grapheme clusters (since user-agents
presumably have Unicode tables available).

Fixes w3c#1296.
agl added a commit to agl/webauthn that referenced this issue Oct 15, 2019
@agl
Truncate strings for authenticators where needed.
c7406dd 
There exist a significant number of authenticators that do not conform
to the current WebAuthn requirements in that they fail requests with
name/displayName strings longer than 64 bytes, rather than truncating
them.

This change adds a new requirement on user-agents that they maintain the
authenticator model for RPs by doing the truncation on their behalf in
this case. The alternative is that each RP will hit this edge-case and
do the truncation itself, thus the ecosystem will never be able to
support longer strings.

Since user-agents may now be doing truncation, this change also permits
truncation at the level of grapheme clusters (since user-agents
presumably have Unicode tables available).

Fixes w3c#1296.
@agl agl mentioned this issue Oct 15, 2019
Merged
equalsJeffH pushed a commit that referenced this issue Oct 29, 2019
@agl @equalsJeffH
Truncate strings for authenticators where needed. (#1316)
428bf82 
* Truncate strings for authenticators where needed.

There exist a significant number of authenticators that do not conform
to the current WebAuthn requirements in that they fail requests with
name/displayName strings longer than 64 bytes, rather than truncating
them.

This change adds a new requirement on user-agents that they maintain the
authenticator model for RPs by doing the truncation on their behalf in
this case. The alternative is that each RP will hit this edge-case and
do the truncation itself, thus the ecosystem will never be able to
support longer strings.

Since user-agents may now be doing truncation, this change also permits
truncation at the level of grapheme clusters (since user-agents
presumably have Unicode tables available).

Fixes #1296.

* Address Jeff and Emil's comments.
emlun pushed a commit that referenced this issue Nov 6, 2019
@agl @emlun
Truncate strings for authenticators where needed. (#1316)
4f14069 
* Truncate strings for authenticators where needed.

There exist a significant number of authenticators that do not conform
to the current WebAuthn requirements in that they fail requests with
name/displayName strings longer than 64 bytes, rather than truncating
them.

This change adds a new requirement on user-agents that they maintain the
authenticator model for RPs by doing the truncation on their behalf in
this case. The alternative is that each RP will hit this edge-case and
do the truncation itself, thus the ecosystem will never be able to
support longer strings.

Since user-agents may now be doing truncation, this change also permits
truncation at the level of grapheme clusters (since user-agents
presumably have Unicode tables available).

Fixes #1296.

* Address Jeff and Emil's comments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@agl agl

Labels
stat:pr-open type:technical
Projects
None yet
Milestone
L2-WD-02
Development

Successfully merging a pull request may close this issue.

Truncate strings for authenticators where needed. agl/webauthn
4 participants
@agl @lgarron @emlun @nadalin