tony: let's look at #1095
https://github.com/w3c/webauthn/pull/1095
tony: JeffH you are on the list to review.
jeffH: wait another week.
tony: OK
https://github.com/w3c/webauthn/pull/1191
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
agreement
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.
https://github.com/w3c/webauthn/pull/1192
tony: this looks ready to go, can someone merge
elundberg: merged.
https://github.com/w3c/webauthn/pull/1193
tony: akshay do you want to review.
akshay: I am OK
elundberg: done.
https://github.com/w3c/webauthn/pull/1195
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
https://github.com/w3c/webauthn/issues/1197
elundberg: I'll do this, put this at WD 2
https://github.com/w3c/webauthn/issues/1199
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
https://github.com/w3c/webauthn/issues/1200
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.
https://github.com/w3c/webauthn/issues/704
jeffH: this is just background editorial. spec cleanup. not to worry
https://github.com/w3c/webauthn/issues/991
jeffH: we already disccused.
tony: meant 996
https://github.com/w3c/webauthn/issues/996
https://github.com/w3c/webauthn/issues/1004
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.
https://github.com/w3c/webauthn/issues/1060
tony: addressed in shane's update.
https://github.com/w3c/webauthn/issues/1088
https://github.com/w3c/webauthn/issues/1099
1142, 1147, 1122 1149, 1166 JeffH working on these
https://github.com/w3c/webauthn/issues/1174
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
https://github.com/w3c/webauthn/issues/1194
elundberg: I will do it when shane's PR is merged
https://github.com/w3c/webauthn/issues/1198
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.
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]