<jcj_moz> scribenick: jcj_moz

john: There's an agenda in everyone's email
... We'll go through 4,5,6 and then pick up again at 2PM PST
... We want to go through all the PRs so we can publish WD-07 by the target date, 3 Nov

starting with #548

John: https://github.com/w3c/webauthn/issues/584

(we are setting up screen sharing)

christiaan: We think this might no longer be an issue, because the hash of the client data has more information than just the RP ID
... so we think maybe this is not needed anymore and we can just close this

rolf: Can we jump to #597?

john: OK, let's close down 584
... now https://github.com/w3c/webauthn/pull/597

rolf: I hope we can pull the trigger on this

Alex: Microsoft doesn't understand what this issue was

rolf: Signature counter not described at the right level. Some vendors want to be able to opt-out.

Alex: Is there math to show that there is a privacy issue?

rolf: No.
... Some authenticators might not want to persist this

John Bradley: This was from Adam Langley, about correlating counters

Alex: I do not want to lose this feature for a theoretical attack

John Bradley: Some argue that RPs won't use this counter the way it's defined

Dirk: We disallow tokens that are malfunctioning at Google

(a fire alarm goes off)

Rolf: This is easy to handle on the server side, some having the counter and some don't.

Mike Jones: To the extent that we're not bifurcating the behaviors that are allowed, code is simpler

Mike Jones: In general for protocol design, if you give people multiple ways to do things it generates interop problems

Rolf: So this is PR 539

https://github.com/w3c/webauthn/pull/539

jfontana: We'll table this until the microsoft folks get back
... now https://github.com/w3c/webauthn/pull/498

jeffh: This is not ready yet
... We can probably do the webauthn side without waiting for credman

jfontana: let's move on then

jeffh: oh and I want to thank jyasskin for his help

jfontana: Now #544 https://github.com/w3c/webauthn/pull/544

(Angelo is here)

angelo: Not a lot of objections to making this work

<jfontana> jcj_moz want our dom masters to look at this. they need to review

jcj_moz is aking annevk to review

Angelo: ... so it still needs work

jfontana: https://github.com/w3c/webauthn/pull/600

jeffh: I've reviewed this

jfontana: jeffh can you merge this?
... Now https://github.com/w3c/webauthn/pull/602

jcj_moz: We should start a list of PRs to review and merge this afternoon, and start with 602

jfontana: OK
... https://github.com/w3c/webauthn/pull/603
... is that also a candidate for that list?

jeffh: yes

jfontana: https://github.com/w3c/webauthn/pull/604

jeffh: I'll add this to the wd-07 milestone and add it to the review list this afternoon

(Alex has returned)

jfontana: Let's start again on 597 and 539

Akshay: I want to merge 539 and close the 597, I think 539 is closer to what we're talking through here
... and then we can open a PR to make sure the counter is mandatory

(Rolf gives a 60 second summary of #539)

JakobEhrensvard: Does this cover U2F makeCredential?

jcj_moz: Yes

jfontana: If we do 539 versus 597 are we leaving something on the table?

AkshayKumar: No, they are alternatives

jcj_moz: So AkshayKumar will open a follow on, rolf will update the PR, and we will merge it

jfontana: Yes
... So ... 604?
... Now 607

https://github.com/w3c/webauthn/pull/607

jfontana: let's coffee break

https://github.com/w3c/webauthn/pull/611

jeffh: Let's add this to the list, #611, for this afternoon

https://github.com/w3c/webauthn/pull/614

jfontana: elundberg, can you give us the rundown of https://github.com/w3c/webauthn/pull/614
... please merge 614
... https://github.com/w3c/webauthn/pull/615

jcj_moz: Already r+'d

jfontana: ok to merge 615
... https://github.com/w3c/webauthn/pull/617

jcj_moz: Out of date, closed

jfontana: https://github.com/w3c/webauthn/pull/619

selfissued: Let's defer discussing this until we get Angelo back on the call

jfontana: https://github.com/w3c/webauthn/issues/620
... Will add this to the review list

AkshayKumar: The credential ID in this PR has two forms
... it can be random, or a hash of a public key

jyasskin: I shouldn't say random if it is a hash

AkshayKumar: I think this makes sense

jyasskin: Make sure my definitions are good, jeffh

<weiler> scribenick: weiler

https://github.com/w3c/webauthn/issues/537

"Make create() and get() abortable "

jeffh: will be fixed by 618?

<jyasskin> jcj_moz: The JS->CBOR conversion is often specified in "Authenticator extension input", and the reverse is in "Client extension output".

https://github.com/w3c/webauthn/issues/547

selfissued: the cose algs are well-specified. this should be closed.

breaking for 1 hour; resuming 4pm EDT, 1pm PDT

resuming.

<selfissued> Jeff Hodges says that #498 is making progress but is still not ready to merge

Dirk: I left Sydney with the homework of figuring out how to shorten these name

<selfissued> We're talking about https://github.com/w3c/webauthn/pull/582 - Restore identifier alignment with CTAP and WD-06

<jcj_moz> https://github.com/w3c/webauthn/issues?page=2&q=is%3Aopen+is%3Aissue+milestone%3AWD-07

<jcj_moz> updated sort: https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AWD-07+sort%3Acreated-asc

proposing to close 238 as a duplicate of issue 537 / pr 544.

https://github.com/w3c/webauthn/issues/292

angelo: i think this is a corner-case race condition. even specifying this will not help much.

jcj: a race condition here is a sign of miscreance.

we're not sure what to do with this. ....

should say something in impl. considerations. will know more once we have multiple transports.

https://github.com/w3c/webauthn/issues/374 restrict WebAuthentication API to only top level browsing context

angelo: idea #1: have the UI show the source. #2 feature policy. #3 tell credman to open up.

<jeffh> https://github.com/w3c/webappsec-credential-management/issues/3

angelo: recommend #3.

<jeffh> that is the credman issue

<jeffh> alexei: chrome/goog is thinking that it is ok if a non-top-level-browsing-context calls into navigator.credentials.{create,get}, that that is OK if and only if there is explicit user interaction that explains what origin is doing what

<jeffh> angelo: three positions on this: (1) show user explicit UI, (2) rely upon "feature policy" spec that allows top-level browser context to set policy down context stack, (3) just relax the restriction that is presently in Credman

<jeffh> ... and mike jones has a fourth option

<jeffh> alexei: (explains context to mikej) notes that proposal (0) is leave things as-is

<jeffh> jcj_moz: notes that (3) is not "just screw privacy" -- there's actual security issues in here

<jeffh> mkej: while we build experimental versions, maybe we should be lenient, and in meantime collect data and discuss with credman folks eg mkwst et al to tighten it down later....

<jeffh> alexei: easier to keep restrictions now and relax them later, than the opposite

<jeffh> alexei, jcj_moz, angelo: <going around the options....>

<jeffh> angelo: in looking at schedules, does not think the feature policy spec is viable in our timeline...

<angelo> personally speaking, I do think feature policy is the optimum solution

<jeffh> alexei & jcj_moz: do not think feature policy will solve this completely... and yes there's timing issues

<angelo> notwithstanding the schedule

<jcj_moz> https://github.com/w3c/webauthn/issues/380

<jcj_moz> https://github.com/w3c/webauthn/issues/524

<jcj_moz> ^ punting to L2

<jcj_moz> https://github.com/w3c/webauthn/issues/535 gets addressed by 498

<jcj_moz> https://github.com/w3c/webauthn/issues/536

<jcj_moz> https://github.com/w3c/webauthn/pull/557

<jyasskin> https://www.w3.org/TR/WebCryptoAPI/#JsonWebKey-dictionary

<selfissued> JC said that at most he could support adding get methods that return data in different formats. He doesn't support duplicating data.

<angelo> We have a principle across the web platform to provide APIs to enable extensible web platform

<angelo> We provided complicated data structure so that developers can build frameworks on top of them

<selfissued> Angelo said that as a browser vendor, he doesn't see why they would want to write the extra get methods when applications can do that themselves

<selfissued> JC - I don't want to change the dictionaries and I don't want to duplicate the data

<angelo> The general direction in the past few years across the web platform is to write basic APIs such as WebAssembly to allow developers to build on top of

https://github.com/w3c/webauthn/issues/557 include public key in result from create() #557

<selfissued> JC will close #557

was not consensus. closing it as "won't fix"

630 has been merged.

<jcj_moz> https://github.com/w3c/webauthn/pull/620 and https://github.com/w3c/webauthn/pull/623

https://github.com/w3c/webauthn/pull/623

rolf: this redefinition of Credential ID does not make sense to me.

https://github.com/w3c/webauthn/issues/561

and https://github.com/w3c/webauthn/issues/560

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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: jyasskin elundberg jcj_moz jeffh gmandyam selfissued jfontana weiler ChristiaanBrand JakobEhrensvard AkshayKumar apowers JohnBradley Rolf AlexRadutsky nadalin angelo dirk
Found ScribeNick: jcj_moz
Found ScribeNick: weiler
Inferring Scribes: jcj_moz, weiler
Scribes: jcj_moz, weiler
ScribeNicks: jcj_moz, weiler

WARNING: No "Topic:" lines found.

Found Date: 11 Oct 2017
Guessing minutes URL: http://www.w3.org/2017/10/11-webauthn-minutes.html
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