<wseltzer> present=
https://github.com/w3c/webauthn/pull/1466
tony: concerns with this one?
agl: I think I see an error,m, let me fix that before we land this.
tony: JC is this something you can look at
jc_moz: yes
https://github.com/w3c/webauthn/pull/1467
agl: one comment I need to look
at.
... I need to make some wording changes in response
tony: akshay reviwe
akshay: yes
agl: no normative changes.
includes changes with previous PR
... get this done in Level 2
tony: that is the PRs.
selfissue: https://github.com/w3c/webauthn/pull/1469
... hot off press
... I asked for review. Who can look at this. changing registry
entries
jc_moz: I can go through it
tony: let's move to issues
... still waiting on Apple attestation stufgf
https://github.com/w3c/webauthn/issues/1422
https://github.com/w3c/webauthn/issues/1462
jc_moz: waiting for response. I
am worried about this making through the tag alive.
... I don't think we should ignore this before tag
reviewe
... we should add to the interface that is returned by the
getclient extenstion
... the ability to go straight to web crypto
... I will propose moving this to its own file
jbradley: I can see why you may
want this with web crypto
... key derivation to de-crypt something a service
... why not do that with one gesture
jc_moz: a lot of people will want this to use straight to web crypto
jbradley: do we want to do user
presence checks?
... if general purpose crypto device don't want use to touch
each tim
jc_moz: thinking where they want
this next to full web authn
... what is easiest path?
... we could make web authn cleaner
jbradley: this is in CTAP on FIDO
side.
... key derivation is different
... UP is not always required in CTAP
... can't do it silently
jc_moz: this makes sense to have web crypto types
tony: you are saying want main function in web auhthn
jc_moz: if we had a web crypto
group, we would work thre.
... so i don't know the right answer
... I fell like this will come up in Tag
agl: a couple of RPs asked for
this. seemed minor.
... I did not anticipagte an objection.
... if it goes away I am not going to shed tears
... my team wants this.
... we need to explain more why this is there
selfissue: leave it in, then come
back ot it
... I could do this later
jbradley: you want a web crypto interface to this?
selfissue: define new web authn
doc with same extension text
... we could make a second doc only if we get push back an AC
review time.
jc_moz: this is early review from my side.
jbradley: objection is - they see it for progressive web apps and expose through web crypto
jc_moz: this is the key is avaialble to javascript engine
tony: you don't expect push back in terms of hardware
jc_moz: not many web crytpo
people left here
... we have this risk now with this doc
agl: flip side here is not bad,
if things expand in the future we will have this key
... array buffer might be ideal way to interface them
jc_moz: doesn't seem as dangerous
to me.
... this is more generic web authn
agl: web auhtnn expanding expanding seems plausible, web crypto, no
jc_moz: this is blend, web crypto
being inside web authn
... this was intended to be a complete replace to the extension
in web authn
agl: when you start to duplicate,
you have to look at more things
... this extension is relatively eaiser
jc_moz: we can wait. i can take issue and make a PR about web crypto
jbradley: that might be a useful step
agl: I don't want to sink web authen on this, we can throw this out. can make it a specific API
akshay: we wanted this to be
useful feature. we had a use case.
... another group that does not care about signature calls
(?)
... I was thinking a platform API
... I see both points. I would prefer this to be here
jbradley: the question seems to be features creep
akshay: this has nothing to do with log-ins. more like disk de-cryption
agl: do yo have web context
akshay: not yet
jc_moz: I see it coupled with
LastPass
... for example
tony: are there web app sec requirements?
self-issue: at meta-level
spending lot of time on this
... table this and see if they come true.
agl: we can't ignore mozilla and plow ahead
selfissue: not saying that, we see push back coming
jc_moz: that is not firm, but concerned.
selfissue: leave it in and let JC do a PR
tony: jc, agl you OK with that
jc_moz: I will continue to get better resolution internally
tony: has to be closed by review
time.
... fine with that
selfissue: that's fine.
jc_Moz: ok
akshay: sounds resonable.
jbvradely: you going to do a PR with some additional text
jc_moz: yes. but might not satisfy all this issue
tony: any other issues to
discuss
... untriaged issue
https://github.com/w3c/webauthn/issues/1465
akshay: they did some work for windows so it can be done in private keys, not sure on other platforms
tony: will that ship
akshay, incognito mode, yes.
agl: this is not a web authn
issue
... for incogniton, not a spec issue
wendy: w3c specs do not refer to specific browser modes
<wseltzer> https://w3ctag.github.io/private-browsing-modes/
tony: is this something for web authn adoption should take up
nickS: yes, i will talk about it there
tony: anything else
shane: yes.
should we have language in web authn how platform authenticators should behave.
akshay: we have issue for that
shane: OK, I will let it
go.
... then I withdraw the idea of a new issue.
adjourn
This is scribe.perl Revision of Date 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/jfontana_/jfontana/G Present: jfontana wseltzer jcj_moz selfissued agl akshay billleddy davidturner eric jeremyerickson davidwaite nadalin nsteele nina sbweeden elundberg Rae johnbradley No ScribeNick specified. Guessing ScribeNick: jfontana Inferring Scribes: jfontana WARNING: No "Topic:" lines found. Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Aug/0029.html 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]