Webauthn: Define sensible limits for User and RP Entity to be stored on Authenticator as part of create credential

[akshayku]

Currently, we have not defined limits to individual fields for User and RP entity to be stored on Authenticator apart from User.id which can be maximum of 64 bytes. We should define a scheme which can work for both constrained and non-constrained authenticators for a predictable ecosystem.

Here is one proposal:

User Entity:

• Id: Authenticators MUST support maximum of 64 bytes.
• Name: Authenticators must support minimum 64 UTF8 characters. If RP provides more than 64 UTF8 characters, authenticator optionally can truncate how much it wants to store.
• DisplayName: Authenticators MUST support minimum of 64 UTF8 characters. If RP provides more than 64 UTF8 characters, authenticator optionally can truncate how much it wants to store.
• Icon: Authenticators MUST support minimum of 128 UTF8 characters. If RP provides more than 128 UTF8 characters, authenticator optionally can drop this field all together. Here truncation does not makes sense.

RP Entity:

• Id: Authenticators can use HASH of this field as a primary index inside their database. So limit is not really needed. For completeness, we can say maximum 256 UTF characters.
• Name: Authenticators must support minimum 64 UTF8 characters. If RP provides more than 64 UTF8 characters, authenticator optionally can truncate how much it wants to store.
• Icon: Authenticators MUST support minimum of 128 UTF8 characters. If RP provides more than 128 UTF8 characters, authenticator optionally can drop this field all together. Here truncation does not makes sense.

[jovasco]

@akshayku I have a problem with the minimum of 128 bytes for icon. Especially for cases where there is no local storage, this means at least 129 bytes extra in the key handle. I believe the authenticator should be allowed to drop this field.

As a side issue for id, this becomes "MUST support 64 bytes.".

Additionally, unless I am missing some scenario, none of these fields are important if you do not have local storage or a display.

[jyasskin]

A "minimum of 64 UTF8 characters" is a little odd. Do you mean 64 bytes (64 code units, which could be as few as 16 non-BMP code points), or 64 unicode code points, which means up to 256 utf-8 bytes, or a more general notion of "character", which could be an even larger number of bytes? (I don't have an opinion here, just want the spec to be precise.)

BMP: http://www.unicode.org/glossary/#basic_multilingual_plane

[akshayku]

In CTAP spec, Authenticators only support UTF8 characters for these fields and that is why it is written as UTF8 characters. Defining Unicode characters limits is not needed here as platform will do the translation. The limits are for authenticators which will store these fields.

[jyasskin]

@akshayku There is no such thing as a "utf-8 character". I think you mean "bytes", which will be interpreted as utf-8 code units.

code unit: http://www.unicode.org/glossary/#code_unit
The minimal bit combination that can represent a unit of encoded text for processing or interchange. The Unicode Standard uses 8-bit code units in the UTF-8 encoding form, ...

[akshayku]

Yeah.. I think we are saying the same thing. For example, in authenticatorGetAssertion, rpId field is mentioned as UTF-8 encoded text string (CBOR major type 3).

[jovasco]

If you define these maximum lengths in UTF-8 code points, the length is essentially multiplied by 4 (maximum byte length of an UTF-8 code point). In most cases this will not happen but displayName can certainly contain all kinds of exotic encodings.

If you use bytes, you force the authenticator to handle UTF-8 code points to truncate them correctly to fit inside 64 bytes or you will have to be prepared to handle incorrect code points in the client.

If you use code points, the authenticator has to store up to 1088 bytes of context data, not even counting the rpID, the private key information and length fields. For an embedded device, this is a lot of data.

I strongly prefer the limits to be in bytes but I have no problem to include code to truncate them correctly (its not that hard).

In the end, it just needs to be defined.

Again, this needs to be scoped to the use cases where it makes sense. If I have to add up to 1088 bytes inside a Credential ID, we already exceed the minimum buffer length of a CTAP message without even the data we really need.

[equalsJeffH]

wrt @akshayku's original post (OP):

1. suggest that we have length limits simply expressed in bytes rather than "UTF8 characters" (as @jyasskin says, there is no such thing).
2. any encoding requirements should also be unambiguously stated. Note: this is orthogonal, but intersecting, to byte length.

[akshayku]

I thought UTF-8 code points always result single byte representation. @selfissued ?..
Anyway, I made the #667 defining limits in bytes as I agree that Authenticators should not be dealing with code points.

[equalsJeffH]

I thought UTF-8 code points always result single byte representation.

nope. you are likely thinking about the UTF-8 feature of being backwards-compatible with USASCII encoding. However, UTF-8 is a multi-byte encoding form.

UTF-8: A multibyte encoding for text that represents each Unicode character with 1 to 4 bytes, and which is backward-compatible with ASCII.

[jovasco]

@akshayku We need to deal with code points anyway if we need to truncate it unless you want to get back malformed UTF-8 code points?

[akshayku]

Fixed by #667. Closing.