<scribe> scribenick: elundberg

tony: charter is out of time
... ends in september
... need to update charter so we can do L2
... email went out
... there were comments on authenticator selection
... that was in there since L1
... it will stay in
... request making same-origin stuff a little more specific
... the new charter gives us 2 more years
... hearing no objections to proposed updates
... second agenda item is timelines
... there have been concerns around us trying to align with FIDO
... we tend to lock-step with FIDO and release specs around the same time
... we may be on too fast a cadence
... we can probably achieve L2 in Q1 2020
...question: is that too soon?
... please discuss

rolf: delegation will help adoption
... iframe support
... delaying this will not help adoption

agl: it's in now

rolf: you can't use it yet

agl: chrome hasn't released it yet but plan to soon
... we don't usually wait for formal spec release to implement
... we won't wait for L2 to implement L2 draft

akshay: we can always do more review drafts while waiting for FIDO
... and bump L2 when they're ready

agl: there's not a lot of interlock between CTAP and WebAuthn at this point

akshay: WebAuthn can move faster but FIDO vendors need time
... tying the two together is not practical

agl: also browsers can change in a week, authenticators can never change

tony: next agenda item: TPAC
... there will be 2 meetings
... one with web payments WG
... one with web payment security IG
... web payments WG on spt 17th at 14:00
... will discuss their use cases for cross-origin WebAuthn

agl: a clear enumeration of use cases would be very valuable

tony: payments security IG on thursday 10AM
... will discuss 3D-secure use cases

agl: same comment
... I hear PSD2 work was delayed

tony: will put out exact times for the meetings
... other TPAC discussions?
... hearing none
... pull requests

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

scribe: still on hold

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

scribe: under discussion

akshay: move to WD03

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

elundberg: updated, need re-review from jeffh

tony: akshay please review

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

agl: we can bring Nina in next week

akshay: I'll look at this

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

agl: we should merge this, then change this to not an enum

tony: hearing no objections to merge

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

elundberg: small suggestion in review

tony: please merge when ready

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

scribe: blocked

tony: untriaged issues

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

agl: we spoke about this last week
... jeffh has redirected this to CTAP2
... can probably close
... or is this about WebAuthn generic extensions?
... no, never mind
... let's close

jeffh: will close

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

agl: I think this is resolved by transports

elundberg: I think so too

agl: RP will not get an immediate error due to privacy reasons
... but browser will not show pointless UI about inserting an external authenticator

akshay: what about empty allowCredentials

agl: in that case it is true this cannot be expressed

jeffh: cookies/ambient credentials can kind of solve this

akshay: yes, but not a good general solution

tony: is this make sense to support

agl: we support platform-only registration

akshay: say I'm RP and only want android fingerprint authnrs

rolf: if you move to a different browser on the same device there are no cookies

akshay: when user moves from machine to machine RP cannot give passwordless experience [with platform-only authenticators]

agl: I'm not convinced there's good reason to forbid external authnrs
... they abuse the parameter at registration time and are upset they can't do the same abuse for authentication

akshay: when we added the registration parameter it was to help register one of each kind
... for authentication if RP doesn't care about one type of authnrs
... this could fragment the ecosystem
... let's say 2 years from now, platform authnr is the only choice for most RPs
... will that make business problems for external authnr vendors

agl: if we see lots of RPs unnecessarily restricting this, browsers should allow users to ignore the RP's wish

shane: if an RP wants to really enforce, they probably can via attestation metadata

agl: users have an interest to use the authnr they want
... RP's wish should not override all other interests

akshay: MS has two separate login pages for external/platform authnrs

agl: that's fine, that's different

rolf: this could improve user experience

agl: I'm not against that, but the RP's settings should maybe not be an absolute
... may need reconsideration in the future

shane: might be against the spirit of FIDO to place that restriction on users

rolf: this is about a hint, but currently even the hint is not possible

akshay: yes, but we can't make it a hard requirement

agl: I'm not against adding a hint
... also not against telling this RP they're doing it wrong

tony: RPs might complain if they get the hint but browser doesn't respect it

agl: I thought valid use cases would come up, but not really hearing any
... RP should not decide this

rolf: hint is useful for a pleasant UX, but not an absolute
... asking in issue if that's what OP has in mind

agl: maybe the hint could help tweak UI messaging

jeffh: but starts conflating API and UI

jbradley: we should try to make UI as good general-purpose as possible
... let's not make people upset because we gave them what they want but it didn't work

nick: can see enterprise use cases with credentials provisioned for machines
... but adding this might be more confusing than helpful

jbradley: it's dangerous to lock users out of valid recovery options
... if there is a platform cred the client will probably prefer that anyway

akshay: if user registers only platform authnrs and moves to new device, they might be asked to connect an external authnr
... probably not a big deal

tony: hearing more discussion needs to be done
... more definite use cases needed

jeffh: Kieun just replied in issue, requesting immediate error with no UI
... we cannot accomodate that

agl: at most I could see a transports hint parameter
... to help tweak UI
... if we had that, browser could also say "all your creds are NFC, this device has no NFC"

jbradley: you can do that with allowList
... if you don't know who the user is this is not useful

agl: I'm convinced we should not do anything here

tony: punted to L3 for now
... 5 more minutes, any particular issues to discuss?

agl: iframes
... we're convinced we should do something
... adding parent domains to client data was proposed
... that would introduce a way for iframe to detect parent domains, we should probably not do that
... "should the embeddee have to opt in", we say no
... other APIs don't do that, would be weird here
... that is possible via content security policy

jbradley: can we have a boolean indicating if caller is embedded

agl: a Boolean is probably is okay
... iframe currently cannot detect parent domain through any browser API, don't want to add one

jbradley: what about postMessage

jeffh: embedder can reveal domain to embeddee

jbradley: would be good for auditing to know the authentication happened in a different security context

agl: top-level domain in clientData would be okay if it was already available information

jeffh: if parent frames postMessage down to the embedded to reveal themselves, that's different

jbradley: [do we need to make RPs opt in to being embedded] (?)

agl: we could break the clientData for embedded frames
... not sure that's a good idea

tony: we'll submit charter updates to wendy

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: Rolf elundberg jeffh
Regrets: jcj_moz
Found ScribeNick: elundberg
Inferring Scribes: elundberg

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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.)