<scribe> scribenick: elundberg

https://github.com/w3c/webauthn/pull/375

nadalin: ongoing

https://github.com/w3c/webauthn/pull/906

scribe: agl said he'd look at it

https://github.com/w3c/webauthn/pull/951

jeffh: this is an alternative to #878
... someone involved in i18n submitted #593
... I think they'll have review comments
... I'm not sure what aphillips's latest comment means
... in the spec we match the values of RP ID and userHandle
... it's probably good hygiene to recommend normalization for displayed values
... I think he's asking for a health warning at least
... this still needs sorting out
... are there examples of such warnings in other specs we can copy
... this needs more work, maybe we can punt it

nadalin: it could break implementations
... at least change them

jeffh: jcj_moz notes they don't currently display the strings because of these issues
... #951 is a little complex, don't know if we want to deep dive into it now

<jeffh> https://github.com/w3c/webauthn/issues/593#issuecomment-369402225

agl: Chrome isn't displaying the strings either, but only because we haven't got around it
... we display a lot of untrusted strings
... atm we pass them through to authnr unchanged
... we may reject invalid utf

jeffh: I don't think we'll solve this on the call today
... judging by aphillips, maybe changing the SHOULDs to MUSTs would be enough

jbradley: Edge is displaying the user name

akshayku: yes

nadalin: why is this a concern for us and not the authnr?

agl: the authnr just passes bytes back
... some guidance of some sensible things to do, is that what's being suggested?
... or should clients do normalization

jeffh: if you don't do normalization, matching is problematic

agl: when do we need to match here?

jeffh: we don't on name and displayName
... the discussion proposes discouraging RPs from making authc decisions on those

akshayku: you cannot pass the unicode string as I understand

jeffh: you may want to restrict certain characters from usernames/displayNames

akshayku: so they're saying platform should adhere to these guidelines?

jeffh: also RP name is supplied by the RP

jbradley: that shouldn't be unicode, should be punycode

jeffh: you're confusing rp.id with rp.name

akshayku: is this a MUST or a SHOULD?

jeffh: it's a SHOULD in the PR, i18n guy is objecting and saying it should be MUST

nadalin: what if they don't display it at all?

agl: even then you need to do normalization before sending to the authnr

akshayu: are we saying every windows component must comply to this RFC?
... looks to me like this is a recommendation, not must

agl: this proposal would add additional processing on top of converting bytes to utf-8

akshayku: I need to look at this
... looks like they're saying best practice is to not do this

selfissued: request moving on

akshayku: I'm not sure this RFC is the best
... are there competing RFCs?

selfissued: no, this is standard practice

nadalin: close #878, merge #951

https://github.com/w3c/webauthn/pull/956

elundberg: looks ready to go
... merged

https://github.com/w3c/webauthn/pull/971

nadalin: agl please comment

agl: this seems plausible
... sure

jeffh: this is what jcj_moz said moz is doing

https://github.com/w3c/webauthn/pull/976

jeffh: elundberg wanted to discuss this on the call
... this adds a note with a lowercase must
... which just spells out what should already be obvious
... pedantic reminder
... we're asking: should this be a note or a normative MUST?

nadalin: if we cast it as a note, I think that would be fine

selfissued: this is fine, we should merge

elundberg: ok

jeffh: merged

https://github.com/w3c/webauthn/pull/979

nadalin: looks ready to go

https://github.com/w3c/webauthn/pull/986

scribe: ready to go

https://github.com/w3c/webauthn/pull/989

jeffh: we can merge this

elundberg: merged

https://github.com/w3c/webauthn/pull/993

jeffh: I'm looking at this

https://github.com/w3c/webauthn/pull/994

nadalin: same situation

https://github.com/w3c/webauthn/pull/995

nadalin: same
... agl and akshayku please review

agl: looks ok

akshayku: so true means appid was used and not rpid?

agl: underlying issue is we have a return value
... I don't think it's needed
... the RP already knows the information this provides

akshayku: I think this adds clarity

selfissued: it looks fine, it implements what was discussed in #982

agl: I think this adds no information
... but I don't think the bit should exist at all, so I'm fine with it meaning anything

selfissued: all extensions must return a value
... required by architecture

akshayku: if an RP has earlier U2F keys registered with U2f
... and newer U2F keys registered with webauthn

agl: the RP can tell which was used

akshayku: I'm ok with this PR

agl: me too

jeffh: let's merge

nadalin: there are no non-triaged PRs

selfissued: #993 is fine

jeff: #993 is a PR

https://github.com/w3c/webauthn/pull/983

nadalin: this is a MUST, there should be no alternative to a MUST
... suggest closing

elundberg: ok

https://github.com/w3c/webauthn/issues/985

jeffh: we will merge #906
... so it seems for symmetry we should add the same switch branch in makeCredential as we add to getAssertion in #906

agl: so the lines in question are "if the user aborts"?
... that's fine
... I think most browsers will implement it whether we specify it or not

nadalin: jeffh will open PR for this

ibrahim: as you know platform creds are backed by platform key stores
... these could be wiped for a number of reasons
... it's possible a user creates a platform cred
... RP sends allowCredentials of size 1 all the time
... when keystore is wiped RP will keep requesting that credential
... no cred will match
... platform will ask user to insert security key
... so this is about enabling better UX in this scenario
... provide a way to signal to the RP that that platform cred no longer exists
... related to #906

elundberg: ibrahim is talking about https://github.com/w3c/webauthn/issues/851

ibrahim: want to give the RP an unambiguous signal
... could mean timeout, user cancel, or key is not there

agl: christiaanbrand also cares about this a lot

<jeffh> "this issue" is #851 ?

yes

agl: this must not be silent

ibrahim: sure
... if user consents, then we return an unambiguous signal

akshayku: what you were saying last time was to just inform, consent not necessary

ibrahim: not having this makes for poor UX

agl: we have a more fundamental problem
... we have no way to send attachment info

akshayku: we marked those things as L2

ibrahim: I agree with that
... there will be RPs that want platform creds only
... we should enable that
... I think we need more than transport info
... agree it should not be silent

agl: unambiguous signal may not be possible
... if user has more than one machine, half the platform creds will not exist on one of them

ibrahim: RP will set a cookie
... we should be wary about if RP wants to only authc with the one cred they know should exist

gmandyam: couldn't RP policy say if I fail to authc X times then force to register a new one

ibrahim: that makes for poor UX
... but might not be a blocker for RPs

akshayku: I think we should do this in L2

ibrahim: I think we should fix it holistically

gmandyam: I'm fine with L2
... I think this falls into broader category of issues
... there are reasons to not be explicit why a peripheral is no longer accessible

akshayku: let's discuss this for L2

ibrahim: #906 will not wholly fix this

agl: agreed

nadalin: moving to L2, ok agl?

agl: ok

nadalin: moving to L2

if christiaan has an issue we can discuss it

scribe: he's welcome to bring it up if he has issues with the decision

nadalin: we have ~30 outstanding issues for PropRec

jeffh: elundberg asserts in #953 that it's already handled by #906
... I'll close #953

https://github.com/w3c/webauthn/issues/621

nadalin: akshayku is assigned

akshayu: I will look at it today

https://github.com/w3c/webauthn/pull/721

wrong

https://github.com/w3c/webauthn/issues/712

jeffh: this one's in process
... I need to go back to the issue in the infra spec
... this requires a one row change in a table in the JavaScript spec
... I'm trying to push that through

nadalin: I need to know if we're doing this or not
... I have to close the technical ones
... we haven't decided on this and #982

jeffh: maybe we can change webauthn now
... and hope the other specs align
... those changes will take a while
... maybe I can get the one in Infra
... let me take a look at making a PR to Infra

nadalin: no meeting next week because of IETF
... or do people want to?

elundberg: I'm fine with meeting next week

jeffh: me too

nadalin: ok, we will have a meeting

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/scribenick: elundberg jeffh/scribenick: elundberg/
Present: gmandyam wseltzer nadalin elundberg agl apowers akshay jeffh ketan selfissued John_bradley
Regrets: weiler fontana
Found ScribeNick: elundberg
Inferring Scribes: elundberg

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2018Jul/0160.html
Found Date: 11 Jul 2018
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)