Web Authentication WG

12 Jun 2019



jfontana, elundberg, davidwaite, jcj_moz, jbarclay_, nadalin, Rolf, sbweeden, christiaan, jeffh, agl, selfissued
Nadalin, Fontana


<wseltzer> https://www.w3.org/2019/09/TPAC/

<wseltzer> https://www.w3.org/2019/09/TPAC/schedule.html

<wseltzer> nadalin: WebAuthn meets Friday of TPAC

<wseltzer> (Sept. 20, 2019, in Fukuoka, Japan)

Pull Requests


tony: still have not completed , need to work on the CTAP 2 side


tony: akshay is not on the call. will report next week


agl: there are lots of comments.

tony: akshay will get back to pull requests.

jeffH: plus issue on the TAG

agl: we don't see any strong opinions
... just sad.


elundberg: this is ready to go

jeffH: agree

elundberg: I will merge


elundberg: need to point this to master
... merge 1223 as well


tony: ready to go

elundberg: one more comment from JeffH
... I have not linked the extensions

jeffH: not a big deal

agl: on chromium list some said we can't create or choose ... you can't exclude U2F credentials

elundberg: means you could have an existing u2f cred and at registration and could end up creating a credential even if you did not want.

agl: this is motivation to me to fix this

jcj_moz: not sure confusion is bad enough to add U2f credential
... I think we might need separate discussion for that
... this can be confusing, but not problematic
... think this can be covered by UX

agl: you are making sense. saying this is just a transition is the least amount of work

elundberg: would changing affect authenticators.
... I don't think so. It would only be issue for duo-protocol authenticators.

agl: aren't all ctap authenticators duo

elunberg: it might not be worth the problem.

dwaite: users will have to figure out which keys and UI.
... other thing would be to have built in support.
... thinking more of a migration detail
... would correlation be an issue?

agl: wwe want to move the U2f interface eventually, but not in the next 5 years

jeffH: is there an issue to submit here.

agl: I could fire one so it is on the list somewhere.
... we could address in web authn and add an extension if we wanted to

elunberg: on #1230 I will make changes
... and should I merge

jeffH: i agree
... agl will submit an issue.


rtony: this is the pass through assertion formats.
... there is lot of negative toward this.

rolf: I don't have update yet. need one more week

Moving to issues


tony: akshay is out

jeffH: we probably need to refine some of this.
... understanding of this has been evolving.


tony: was kim going to update

jeffH: or I will

elundberg: some looking to close this

tony: Kim was going to create the PR.
... akshay this is not needed.

jbradley: does not think this is needed.

jeffh: maybe this is guidance for UI

tony: this is something you and Kim should work on

jeffH: yes.


jeffH: punt. back to discussion with Rolf


jeffh: I am working on this right now.
... I am half done already.


elundberg: I'll take a stab at this
... I don't think it needs to make WD 02

tony: when closer to WD-02 we could punt this one.

jcj_moz: this is nice to have, but it is huge
... can we work collaborative on this.
... we can talk offline.

jeffH: put that comment in the issue


jeffH: jc was going to take a look at that.

elundberg: on this topic. the spec is under assumption that browsers do some generic translation, but no browsers are doing that
... so should we update spec?

agl: I don't want that world

selfissue: it is not that black and white
... it references transformation and we should not ignore that
... many of the extensions use this.

eludnberg: ok

selfissue: i will try to put a comment in it. ,

jcj_moz: I had meant to look at it.


jeffH: just editorial to clean up

tony: can we skip over this next time.

jcj_moz: this has come up before
... maybe need a cross reference to people's compliants.

jeffH: not sure what you said applies to #1099

jcj_moz: i'll make not for future reference.

jeffH: excellent


jeffH: editorial cleanup


jeffH: editorial cleanup


jeffh: we should do this. doesn't have to be lots of work

jcj_moz: yes. I can't do PR in near term.

jeffH: assign to me.


jeffH: these are ones that I intend to do - those that are not marked on-going


agl: same as ever

tony: still waiting for some stuff from FIDO land


agl: I will close this one. I don't know who has been agitating on this

shane: it was Christiaan

agl: maybe we should wait.

tony: close?
... wait another week.


elundberg: I intend to do this one


agl: I asked martin to fill in what we do here

tony: i will ask akshay.


jeffH: on my list


jeffH: assigned to Rolf

tony: is this still needed

rolf: you can argue it is needed more than ever.
... giving reasons why certain algorithms are there or not.

tony: is that appropriate?

rolf: we should support algorithms.

tony: let them do their own

rolf: that's what I would say.

tony: what to do?

rolf: there is not a lot of meat here. do we give a public statement?

tony: we don't want to go into detail why each algorithm is used.

rolf: not our decision in the end.

tony: do we just close

rolf: yes.
... our basic attestation is not the best decision from a security perspective.
... this issue is about telling people how to look at algorithms

tony: i think they are looking for cryptographic guidance here
... so close or open

rolf: I vote for close no action.

jcj_moz: i could see a separate doc.

tony: not in the spec

jcj_moz: in spec the move would be to pull algorithms.
... i support closing if we could start planning an "explainer" for implementors
... and also best practices around the algorithms.

selfissue: make that comment and close it.

jcj_moz: OK



jeffH: there is PR open


agl: no plausible action.

tony: so you want to close

agl: i don't think we are going to do anything about it any time soon

alexei: maybe just add a recommendation

agl: lets close it

jeffH: or punt to future

tony: or level 3


tony: jeffH

jeffH: correct'


no comment


tony: jeffH will do

jeffH: I think what we are trying to convince Giri, we don't need to do this.
... we should not do this.
... he has come back with some arguments.

tony: let him look at this one again.


assigned JeffH


jeffH assigned


jeffH: need to assign someone on this one.


tony: more jeffh


tony: this one should go away soon


jeffH: editorial clean up.

james: I can take that one.

tony: james needs to be on the github list

wseltzer: link w3c account to github account

james: I will dol


tony: do we think this is going to happen

agl: no one has implemented that I am aware.

alexei: so far we have been against such things

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/06/12 20:03:52 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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: jfontana elundberg davidwaite jcj_moz jbarclay_ nadalin Rolf sbweeden christiaan jeffh agl selfissued
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2019Jun/0069.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: 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]