<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.)[End of scribe.perl diagnostic output]