Meeting minutes
<jfontana> wendy: charter is out for review
<jfontana> tony: Addison here to talk about internationalization
Internationalization
https://
<jfontana_> addison: ripping out what was added was just going backward.
addison: ripping out your changes would give a string with no language metadata
<jfontana_> ...preference is for additional metadata fields
addison: that could be acceptable
… Or we'd prefer additional metadata
… if you really needed to include metadata in the string, we'd suggest serialization a la RDF
… would appreciate your guidance on constraints
agl: constraints
… hardware that exists only accepts a fixed number of bytes
… we could rev the hardware spec, but that would take years to become prevalent in the wild
… so adding new fields, we expect wouldn't work terribly well
addison: would that also be true re encoding into string?
agl: devices take a lump of bytes
… where we can put anything. (some have screens)
… they're free to truncate arbitrarily
… needs to decay gracefully
… You could imagine API has fields we'd like and the browsers are tasked with encoding
… which we'd have to specify
… it's possible the encoding could happen at browser rather than RP
addison: my concern, suppose we go down the path of cleanup
… language string followed by garbage
… new implementations would have to know about that
… we like separate metadata fields so old things don't have to know about it or care
addison: the characters you're talking about are deprecated
… it wouldn't be fatal if those were displayed as hollow boxes or flags
… newer implementations would know how to read
agl: three places of design
… separate fields pushed down to device, wait until 2024 CTAP spec
… metadata stretched down to the browser, who stuff it into byte strings
… RPs can encode this information (what we have in l2)
addison: these fields shown to users when?
agl: on fresh sign in, browser shows strings from security key to user, as name of account
addison: so they do need to be human-readable
agl: the names come from a website
… as in, "here's an account called Alice"
johnbradley: 2 strings, a friendly name and an account identifier
elundberg: API also has website name and friendly name
addison: trying to get a sense of importance
… of doing things with metadata
… I can imagine things where it would be rendered incorrectly without language to select fonts, text direction
… but ok to take time to get right
addison: I probably need to talk to our i18n WG
… It would be good if we could disappear the existing text pending new text
… we need to choose between add'l metadata with long lead time vs encoding in string
addison: I'm in minority in WG proposing putting metadata at the end
… so that's what's lost in truncation
… others think putting metadata in front is right
agl: I agree with you
johnbradley: authenticators have fixed amount of storage, the more you allocate to identifiers, the fewer credentials you can have
agl: authenticators have fixed lengths
… so have to reserve the max legth
addison: serialization as in RDF...
agl: a marker at the end is useful too, so if that's missing, we know truncation has occurred
nadalin: timing?
addison: why don't we target 8 September for an update
nadalin: thanks, and if needed, we can reschedule
addison: any other questions on other issues?
Christiaan and Stephen on SPC, WebAuthn for Payments
christiaan: and Stephen
[ smcgruer shows slides ^ ]
smcgruer_[EST]: motiviation for https://
johnbradley: what's different about the payment context credential
smcgruer_[EST]: the difference is triggered by passing the payment extension
christiaan: it's a webauthn extension
[to be continued]
[adjourned]