Web Authentication WG

17 Apr 2019


wseltzer, Akshay, Nadalin, jfontana, elundberg, sbweeden, DavidWaite, JasonFisher, =jeffh, agl, jeffh
Nadalin, Jfontana


tony: let's look at #1095


tony: JeffH you are on the list to review.

jeffH: wait another week.

tony: OK


shane: I don't think there are outstanding comments
... elundberg and akshay are talking about this.

tony: I think akshay approved.

elundberg: I would like an indifferent option, but will not hold this up.

tony: why"

elundberg: it expresses a different intent for the RP

akshay: i think we can add this.

shane: I have a definition on indiffernt from last draft, do we want it as the default
... I will put indifferent in and make it the default


tony: agl do you have indifferences here

agl: I can talk to them

jeffH: I need to catchup also

shane: I have not seen agl's issues.
... happy to read them or he can explain them.

agl: I think my comments are coming from two areas, don't express a default value;
... some higher level stuff around wording this as where the private key is stored ....

shane: i think there is a wider issue

agl: this change is adding a lot more wording along those lines.

shane: thought this was land it now and change later.

agL: if group is OK, you can ignore my comments.

skshay: to verfiy trying to discuss what core values mean.
... two thing going on. this is what I understand. first, two different paraments and they are for controlling two different properties on is user verification
... discussion in PIN or not

akshay: the proposal today says three things, do we want to go to four.
... second one is preferred
... platform should try resident key , if it doesnt work try non-resident
... third, for server creds we are fine without PIN, this is mainly I don't want PIN so i put it as ...
... the fourth one is this independent one. just give me some credential. it should be default

agl: would you consider the different and discourage at the same time?

akdhay: I don't like to put two variables out there.
... I want to keep it seprate.

agl: i don't see that I would implement any difference between these two values.

akshay: I don't think there is a difference now

agl: as a n RP, the reasons I might now want preferred over required, I need more compatiblilitiy
... the docs we send to web masters on how to use WebAuthn
... I think one of these should not exisits

akshay: are you OK with one value

elundberg: I am ok with that. but I think this better captures the default of the RP. discourages reflects an a tion
... discouraged is better than indifferent if you have to pick one.
... I OK with just discouraged.
... but having indifferent it allows the RP to better express ...
... I see that the documentation may be confusing as AGL said

agl: to try and tease out thinking, what RP would use your method.

elundberg: not to have UV pop up.

shane: emil is ok without indifferent. so is there anything holding up the PR

agL: I think this PR needs some changes before it lands.

jeffh: I have not been through it in detail

shane: if we agree on discourage, I will take some time to review today.


tony: this looks ready to go, can someone merge

elundberg: merged.


tony: akshay do you want to review.

akshay: I am OK

elundberg: done.


tony: is there a clear path on this one?

agl: this is more negative, I say drop it.
... the older wording was better.

jeffH: thi slined to UV, which I thought it shold not do.
... lets not merge it now. needs polishing

tony: move to issues


elundberg: I'll do this, put this at WD 2


elundberg: request here is getting a list of extensions. want to check this without going through ceremony.

tony: you mean the full ceremony

agl: not so coerned about fingerprint. I want to see here a concrete case, this extension, this behavior

akshay: is it a questions of passing the value or not.

agl: I don't understand the problem.

elundberg: can you note in the issue

jeffh: I did

tony: we could push it off to another draft.

jeffH: lets put it on WD-02


elundberg: about updating metad ate stored in credential
... this is possible now because you can do another registration ceremony with new credential

akshay: most of the time you don't have more than one RP. don't know if it is a big issue

jeffH: name changes do occur in practice
... does not happen that often. could just be re-registraion

agl: if you register with the same name the authenticator will replace the resident key

tony: just close this.

akshay: push it off

jeffH: I agree

elundberg: yes.
... very much not a big issue.


jeffH: this is just background editorial. spec cleanup. not to worry


jeffH: we already disccused.

tony: meant 996



jeffh: that is over in CredMan

tony: is there any advancement in credman

jeffH: No i have been kind of busy.

tony: I thnk it is open just to track it in web app sec

jeffH: yes.


tony: addressed in shane's update.



1142, 1147, 1122 1149, 1166 JeffH working on these


agk: I have not written on this. I am afraid we may have changes in Chrome

tony: this looks like it won't be working draft 01 item

agl: that is reasonable.

tony: lets move it to draft 2

jeffH: done


elundberg: I will do it when shane's PR is merged


tony: does a PR make sense here?
... can you make a PR on this one

elundberg: I can do that

tony: any other issues to talk about.
... some other things to discuss.
... want to get some of this closed to get to wd-01
... jeffH look at the issues.
... people saw the secure web payments group has spun up.
... it is the web payments security group, it is with EMVco and FIDO Alliance
... might be helpful to look across both, what do we need to do with web authn to supply an EMVco with the proper info. to do secure payments.
... there might be some interest from this group to over there
... also be awerw the is a DIDs charter that is looking to get established, they do have authentication scattered in there,
... this is all I had for today's agenda
... does this time work for everybody? no complaints.
... we will stay at this time.
... adjourn.

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/04/17 20:01:34 $

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)

Default Present: wseltzer, Akshay, Nadalin, jfontana, elundberg, sbweeden, DavidWaite, JasonFisher, =jeffh, agl, jeffh
Present: wseltzer Akshay Nadalin jfontana elundberg sbweeden DavidWaite JasonFisher =jeffh agl jeffh
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

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]