tony: since we have wendy on the phone. PAS submission
wendy: paper work has started. we
understand the process
... we'll eventually get back to chairs and group
tonuy: at FIDO morning, approved
CTAP doing the same thing (other than PAS submission) will go
through USA body
... they will make the submission.
... any questions?
none
https://github.com/w3c/webauthn/pull/966
akshay: not working on it yet.
https://github.com/w3c/webauthn/pull/1300
jeffh an agl on
jeffH: in progress
https://github.com/w3c/webauthn/pull/1330
tony: stilll blocked
https://github.com/w3c/webauthn/pull/1366
tonhy: some updates but not there
yet
... akshay take a look at this one also
jeffH: i thnk we can clear JC changes
tony: put in a note
jeffH: I will do it
https://github.com/w3c/webauthn/pull/1375
agl: SSH people are chewing on it, still on hold.
tony: two untriaged PR
nina: I just read akshay comment on it.
tony: would like to get done in next working draft?
agl: probably
tony: you will respond to aksay
nina: yes
elundberg: ligic is in the client layer
nina: yes
https://github.com/w3c/webauthn/pull/1390
tonuy: agl just opened this one up
agl: don't want to change we have
things in the wild. signature counter is not ambiguous
... if you just do make cred. you don't know sig counter is
supported, but may be too late to change that
https://github.com/w3c/webauthn/issues/1336
tony: jc has not created PR yet
jeffH: to some degfee it depneds on #1377
tony: yes
... but not referenced from #1336
... make a note.
... i don't believe apple has waded in on this.
... its cross origin i-frames
ricky: in face to face we are in favor. I will add comment
https://github.com/w3c/webauthn/issues/1363
tony: no further progress
https://github.com/w3c/webauthn/issues/1376
tony: need JC follow up
jeffH: in enterprise attestation, we addressed it there.
tony: this is going to address the one agl is going to take care of. JC has the rest.
agl: i folded in #1366
https://github.com/w3c/webauthn/issues/1377
jeffH: need to crank out a
P
... PR
https://github.com/w3c/webauthn/issues/1379
jeffH: ditto
https://github.com/w3c/webauthn/issues/1381
tony: I don't see any change here.
agl: more of a fido issue I think.
bradley: transport hints are defined here
https://github.com/w3c/webauthn/issues/1385
agl: seems to have stalled
shane: I think elundbergs
scenario is fine
... i will do a PR for it.
... outstanding questions from elundberg.
elundberg: what info. is
conflicting.
... if it is confusing, we should correct
tony: he has not come back with
that info.
... let this one hang out a bit longer
https://github.com/w3c/webauthn/issues/1386
tony: interesting thing are happening here. many opinions
bradley: the issuee at fido board was transactions confirmation.
tony: so the proposal is to
remove unimplemented extensions.
... thye took that as UAF, most of the things were UAD
artifacts.
... but proposal is to remove the unimplemented extensions.
akshy: some issues in progressing the spec
tony: that took time to get
worked out.
... we had to prove that these extensions were implemented via
UAF
bradley: I don't think we can take that path this time.
tony: are we giving people false hope.
selfissue: they can still reference from Level 1 spec
dwaite: I see lot of people want so new support, what there is now is not compatible.
akshay: from apart of extensions. I was thinking move to separate document altogether.
bradley: we can document them at FIDO.
tony: they were trying to link
PSD2 to these extensions.
... it requires work
... thre are others way to satisfy dynamic linking.
... not sure we want to get into supporting things like
this.
... there is a note policy we could look at.
selfissue: L1 is done, in L2 we can only deal with the ones we want to go ahead with
<wseltzer> +1 to selfissued, the Level 1 Rec won't go away
skshay: looking at these extensions, there are things we are not thinking of ever doing
selfissue: merge bradley's PR and
let extensions stand at Level 1
... if we leave it level 1, we still recognize for that
work
... my point it tactically, we should delete what is not
implemented.
bradley: there are a couple of new ones, exclude list, some might implement before we go final
selfissue: any L1 extensions that are not part of sh;pping browser we should delete
bradley: might be good to have some transactions confirmation, but it will need to have some revolution, and there are UI issues
akshay: I say delete these extensions.
agl: if we think we are doing the right thing we should go ahead.
tony: transaction can be done other ways
<selfissued> I added the comment to the issue
akshay: I propose to remove it, we can deal with comments latert
DTurner: it is obvious this removes something
selfissue: you can still do them at L1
<jeffh> wrt to issue #1366 "remove unimplemented extensions" and doing transaction confirmation see https://github.com/w3c/webauthn/issues/1386#issuecomment-600105458
bradley: extension can be
document in many places, some in CTAP. nothing magic being in
L2 spec
... only thing is that without 2 interop implementation, we
can't publish L2
... but nobody has implemented.
selfissue: there is a registry,
you can register extensions from any place
... point of registry is to create a list of extensions.
... L1 stuff will be in registry.
tony: my recollction is that L2 does not supercede L1
brettM: question about timing. what is the timing that we need implentations
tony: look at github you see target dates for milestones. milestone for CR - aug. Recommendaiton: Oct.
brettM: yes, that answers my questions.
bradley: we could drag this out, but none of the browsers plan to implement
tony: I would like to get a way
forward on this early. lets talk to opposition now
... someone can still implement Level 1
... question, anybody opposed to this issue.
rolf: I have strong preference to keepbtransaction confirmation
bradley: need to have browser vendor accept extension
agl: we would not reference this, we would reference what we built
bradley: maybe we make a new work item about transactions
tony: so we have the PR, is there opposition
bradley: rolf on transaction
confirmation.
... I will make PR.
tony: we have some issue that
have not be triaged.
... anybody have anything else, no more business I have, if
not.
... keep same time slots over the next few meetings.
... 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) Present: wseltzer fontana nina akshay davidturner John_Bradley sbweeden rae rolf elundberg nadalin davidwaite jfontana jeffh rickymondello agl selfissued ArmenAnoyan BrettMcDowell No ScribeNick specified. Guessing ScribeNick: jfontana Inferring Scribes: jfontana WARNING: No "Topic:" lines found. Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Mar/0042.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]