Meeting minutes
Meetings
Tony: June 25 canceled, we have TPAC in November
Internationalization Review
Tony: Thank you, Addison, for joining. we discussed the issue @@
Nina: At TPAC, we talked about internationalization of names and display names
… We should have language and direction, now we have a PR that makes this change
Addison: we're not happy to see a custom serialization scheme to encode the language and direction in the string value. This was from L2, and we strongly recommend to not creating another one, and we recommend metadata fields associated with strings, even if at a cost of complexity, and also difficulties in changing the actual situation
Nina: In these specs, we have different actors: Browsers, Authenticators, and RPs. Adding these features isn't easy with the current status quo. Authenticators don't display it.
Addison: in this situation, it can be optional
Nina: this change can be an issues not for RPs but for authenticators, which are security keys
Addison: We could make that case work if you write native code to the process, if it exists.
Nina: As a user agent, it can be put differently. Having extra fields, we cannot have support from authenticators. It is about compatibility with actual authenticators. We can support the direction, but for actual hardware these are just blobs
… it is not possible to pass these data to the authenticators, so new fields will be filtered
Addison: Newer authenticators would be able to support it
Pascoe: I tested on the default Apple password credential manager, and it works
Addison: the issue is that if you have some arabic, you need metadata to tell the UA how to show them, not only if they are UNICODE. I have a video with a PoC
… as the application does not introspect the strings
Nina: In some cases, this is processed by the UA
Addison: If you want to do things with the string, you don't need to look inside the string, just at the metadata. without introspecting the string
Martin: text is going to appear in the Browser UI or OS UI, and this is defined by the RP
Martin: I can't see how this can be implemented, e.g., putting the information in the field or in the metadata. the only difference I see in these two approaches: one is back-compatible, the another one no
Addison: The main point is that custom serialization is never made well, as we said at TPAC this is the better approach, even we didn't objected to the L2, when the issue was inserted
Martin: The problem is to add the metadata now with the existing infrastructure deployed
… are we trading technical purity for actual use and helpfulness
… ?
Addison: This can be useful for mapping things from one standard to the next using well-known structures.
Martin: I can see that
Addison: On the flip side, this is the internationalization format
Nina: going to the priority of consistency, if we would like the user first, we can have better user support
Addison: I want to make it easier for the future and the users of the standards to display, i.e., native render to text. I understand that making this change will require some work. But I suspect that the intent is to move the data around and maybe you don't have the good cycle for producing and consuming the metadata
… if you say that this is the only mechanism in town, okay, but the UI will be cleaner? If we use metadata, yes, and we can provide examples of why you need it. Also, to avoid serialization
David: one of the point, if we consider deployed hardware, they have not space/support for that metadata
Addison: at this point, I would like to ask about what do you want to do?
Nina: The backward compatibility is a point, this will make this position clear but I don't like
<simone> s/I don't like /it is not to convince me/
Nina: but a Group and other SDOs decisions
Addison: We already talked about on the technical side, if there is an issue within the ecosystem. It is something different. I can't promise that the review group will be happy
… maybe my group would like to open an issue during transition
Tony: As per my understanding, the group feels that the implementations we have, and the user community, support legacy authenticators from L1 and L2
Martin: Things from 2014 still working
Tony: The main goal is to avoid people buying new authenticators. For the group is important to retain the user base.
Addison: It should not be a breaking change supporting optional fields (?)
David: We have some authenticators that support serialization.
Addison: New authenticators will support it, old authenticators will ignore these metadata fields
Martin: One thing is the web-facing API (i.e., creating usernames), in L3, we have the RP doing no serialization and not using serialization. The question is how to deal with the existing situation with metadata from the other entities. And also on the CTAP
Addison: Maybe a direct mapping between the encoded string and the new metadata
Martin: we need to check if this is possible, but the encoding will still exist
Pascoe: mapping can be straightforward, we can discuss it
Nina: We need to understand also with the RPs to avoid double encoding and avoid contradictions
Martin: This can be a breaking change, so a check from the RP side can be useful, e.g., ignore metadata
Addison: you can use the tag character to understand the situation
Tony: we can kept what we have now, and add the metadata, having both
… anyone from Safari/Chrome?
Nina: good to simplify the string for the RP, we can think we have an avenue to pursuit.
Tony: I would not want to remove something that we then lose legacy authenticators, as there will be some
Martin: maybe we can do thius conversion at User agent level, even if add complexity, and is a big change for L3
Tony: we should discuss as a group
Martin: talking with the group and other SDOs (i.e., native platforms, as they will not change)
Tony: we need to talk also with Password Managers
Martin: also iOS and Android, on how they implemented internationalization issues
… but yes, maybe this can be an avenue
Pascoe: translation is straightforward, we can maybe implement and use the same for the Platform API
… but I don't know if they would like to adopt this approach
Addison: some Native API already have the option to provide direction
… happy to discuss more, if needed
Addison: We're here to help you ship, do the right thing, and not to keep you from shipping. Keep me updated, mentioning on GitHub
Nina: Thank you Addison, I appreciated
Pascoe: on, also for the discussion in async
2298
Nina: I have some questions for Emul
… Zach has some good points
… on HMAC secret and we should fix the output also for backwards compatibility
… we should check if this is a technical change even if they don't need to change their implementation
Tony: it depends if we need to put in L3
TAG Review
Simone: we have this request from them, maybe joining in their breakout session w3ctag/
… we'll join in a TAG breakout session
[adjourned]