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.)