<scribe> scribenick: jcj_moz

tony: We don't have Angelo on the call, but yesterday he was generating WD-08 (or whatever we name it) before we ask for CR and he was having some issues with generation
... he's working those now
... we should have something generated by today
... With that, we've addressed all issues we wanted to handle before CR wrapped up, so we're down to PR issues.
... But before I get into PR, does anyone have questions about the status of the document?

jcj_moz: Whoever diffs it first should share it!

tony: Angelo is doing that.

jeffh: I'll produce my diffs too.
... If you look at our webauthn repo, I've tagged releases with 'what's new in this version?' information in there
... would be good to crowdsource the differences on the mailing list

<jeffh> https://github.com/w3c/webauthn/releases

jeffh: Getting the diffs does help to extract what's going on. And I say let's call this WD-08, and we can submit this for CR

tony: OK [agreement statements]
... We'll hopefully get the document generated today and get some diffs out this week
... If there are no major heart attacks then maybe we can submit
... But publishing happens tuesdays or thursdays?

wseltzer: Yes, publications happen Tues/Thurs. And transitions ask for a week.

tony: Any other words of wisdom?

wseltzer: What I've seen so far looks good.

<wseltzer> https://www.w3.org/Guide/transitions?profile=CR&cr=new

tony: Any other discussion on moving forward with WD-08 for CR?
... Let's move on to the ... We've been through the pull requests.

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

gmandyam: I was hoping for review from Rolf and Jeff. It's about UVI. It's been a sticking point in the past.

tony: OK. Issues.

https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3APR

tony: We got up to #358 last time

jeffh: We should see what comes out of CR, before getting too involved here

tony: Token binding https://github.com/w3c/webauthn/issues/360

jeffh: This is related to Fetch, which is ongoing
... I also have a PR open on Credential Management which affects WebAuthn which needs to be finished
... which could come up in CR review

tony: Constrain the timeout range https://github.com/w3c/webauthn/issues/364
... Describing attacks on privacy https://github.com/w3c/webauthn/issues/382

<scribe> ... ongoing, we're okay there

tony: 403, allowing multiple registrations.. https://github.com/w3c/webauthn/issues/403
... still... valid?

elundberg: The language could be clearer

jeffh: This is polishing that the spec could use

tony: okay, 405, list notation... https://github.com/w3c/webauthn/issues/405

jeffh: Internal editorial thing

tony: OK 410, replacing auth model with CTAP
... https://github.com/w3c/webauthn/issues/410

jeffh: I thought we decided not to do that. Maybe we can close this?

tony: I think we discussed this the last couple of calls

jeffh: Is this begging the question of further editorial highlighting and/or guidance needs to be added to the spec?
... that would be part of the feedback we'd need to get from CR candidate

mike: I think we agreed not to do this

tony: Right, we're just wondering if it will lead to editorial changes

jeffh: From Mike's perspective we should just close it

tony: We can do it. Either jeffh or selfissued, can you close it?

jeffh: I ... can't.

selfissued: I'll close it.

tony: Auth taxonomy, 422 https://github.com/w3c/webauthn/issues/422

elundberg: I believe this is a good thing to do

tony: ECDAA in 433, https://github.com/w3c/webauthn/issues/433
... I thought this was already addressed?

jeffh: Rolf should say whether or not this is closed. He's our ECDAA guy.

tony: And Akshay is our TPM guy

Akshay: The 2 curves, the TPM folks do not support both of them
... it's in the TCG docs

tony: Ok, 452, Web Auth model prohibits random AAGUIDs? https://github.com/w3c/webauthn/issues/452

mkwst: This is one of mine. I think the wording needs to be changed before it's final. It's very minor.

tony: OK, 452, privacy section. https://github.com/w3c/webauthn/issues/454
... we understand that one
... undefined terms 462, that's an ongoing thing
... OK, 493 same user at get and create https://github.com/w3c/webauthn/issues/493

jeffh: just an editorial thing

tony: More clarity?

jeffh: I think it would be a good thing

tony: 517, why is only valid domain allowed for effective domain?> https://github.com/w3c/webauthn/issues/517

jeffh: I have to... mm
... Basically we're doing the same thing as was done in HSTS spec but we're not as explicit in this spec, so it's another impl-cons / editorial thing that we should clarify

tony: OK, but that didn't get fixed in 515?

jeffh: I'd have to look. Let's leave this open and I'll figure it out.

tony: COSE algorithm constants, https://github.com/w3c/webauthn/issues/529

jcj_moz: Let's CLOSE THIS SUCKER

selfissued: Will do

tony: OK, 540 which is changing the credential pubkey to user pubkey https://github.com/w3c/webauthn/issues/540

jeffh: I just edited the title to that
... that cred pubkey is the same as the user's pubkey
... we should clarify it editorially

tony: ok https://github.com/w3c/webauthn/issues/575

jcj_moz: Firefox doesn't try to complete, we just throw away the promise

mkwst: We haven't resolved this

jeffh: OK, interesting, further discussion here

tony: 576, RP guidelines... https://github.com/w3c/webauthn/issues/576

jeffh: I think we fixed this

elundberg: I think some of this is resolved with the RP conformance class we added

mkwst: If an RP doesn't check attestation, they don't request it and they don't get it

jeffh: So this is fixed

tony: So we can close this one
... 578 privacy consideration https://github.com/w3c/webauthn/issues/578 that's an ongoing thing
... 585 ... https://github.com/w3c/webauthn/issues/585.. an editorial thing

jeffh: There's a PR open on that

tony: 593 display name content rules https://github.com/w3c/webauthn/issues/593

elundberg: I think the answer to this question should be 'no'

tony: J.C., have you comments?

jcj_moz: I can take an action to take this up with our i18n folks

selfissued: I think we should be able to close this w/ a comment that JC will review it

tony: OK 594. Non-ascii .. https://github.com/w3c/webauthn/issues/594

jeffh: We did add non-US-ASCII chars to the name values in examples

tony: So we should just leave this hanging for now

jeffh: Others can weigh in

tony: OK 613 allowing hotplugging https://github.com/w3c/webauthn/issues/613
... I thought this was done

jcj_moz: I'm pretty sure we addressed this

elundberg: I think there are still some issues inline in the spec
... What we have is probably good

<jeffh> jcj_moz's comments: https://github.com/w3c/webauthn/issues/613#issuecomment-343273096

tony: 621 the tx auth extensions are registration and auth extensions? https://github.com/w3c/webauthn/issues/621

elundberg: I think this can be closed
... UAF won't support these extensions, but they're optional anyway
... One could argue whether there's a point for offering this for registration

jeffh: I think he has a point there. The original submitter.

selfissued: I think that's right

jeffh: So this would just be a 1-line change to the spec, so we should leave this open

selfissued: I could leave a comment in the spec about changing to be only a getAssertion extension

Akshay: Can you put me on this too

tony: 649 ... BLE sessions... https://github.com/w3c/webauthn/issues/649 had to be closed
... so that is 656, packed attestations... https://github.com/w3c/webauthn/issues/656.. I thought this one was taken care of

jcj_moz: I will verify and comment on the issue

tony: OK, 679... https://github.com/w3c/webauthn/issues/679
... Adding CDDL to every extension

selfissued: I think this is unnecessary since the transformation from Javascript to CBOR is obvious

jcj_moz: So I think we can close this

tony: OK 704 https://github.com/w3c/webauthn/issues/704 section ID prefixes...

jeffh: Yeah, ongoing but we might not want to do it anymore

tony: 712 JSON serialized client data is wrong https://github.com/w3c/webauthn/issues/712

jeffh: If what we have is what we good enough to get past PR and recommendation, then I don't think we want to gate our milestones on updating the WHATWG spec and the Javascript spec

selfissued: I think we should ask annevk for specific text changes to propose in both specifications
... because those of us who don't live and breathe both javascript and webidl don't know what's going on here

jeffh: I don't think this is a chair thing necessarily
... and it's a prefectly reasonable question to pose to annevk

selfissued: I will ask this question

jeffh: I think we can decouple this and fork it and then ask annevk
... Not change it right now in our spec and see what comes back in CR

tony: OK, 733 https://github.com/w3c/webauthn/issues/733 cognitive accessibility
... I believe weiler said he'd look at this

jeffh: Oh, OK. So I'm the one that's been responding to this.
... What's the next step?
... What I'd suggest is -- unless weiler suggests differently -- is to ask for a detailed review

[weiler will think on this]

tony: 743 privacy considerations ... https://github.com/w3c/webauthn/issues/743
... I think this is ongoing
... and we can see what pops up out of CR review on this one too
... OK, and 750 CredentialRequestOptions on https://github.com/w3c/webauthn/issues/750

jeffh: I need to think about this one

tony: 764, info about authenticator availability / attachments https://github.com/w3c/webauthn/issues/764

elundberg: Could be added to an implementation considerations sections

mkwst: This is essentially the same as what Facebook has said previously

jeffh: Is there somewhere we could point to?

mkwst: Brad's been saying it.

tony: Probably in notes
... Last to look at is 796 which is a todo https://github.com/w3c/webauthn/issues/796

jeffh: There's an issue open (in bikeshed) to cross-reference steps

tony: We won't have a meeting the week of the 21st (IETF)
... so I'll put that into the minutes
... so we will talk to you next week and hopefully by then we'll have a WD-08 generated and have a letter off to the Director for CR by then

<Zakim> weiler, you wanted to ask about unlocking the repo

<weiler> scribe: weiler

weiler: do you want the repo unlocked when wd-08 ships?

nadalin: yes

weiler: what's the history of two groups in github, one -editors, one not? One has 19 members, the other 24.

selfissued: allowing people to be assigned without allowing them to merge changes

nadalin: I'll review the lists.

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)

Succeeded: s/giri/gmandyam/
Succeeded: s/tood/todo/
Present: weiler jcj_moz jeffh wseltzer gmandyam elundberg akshay nadalin selfissued
Found ScribeNick: jcj_moz
Found Scribe: weiler
Inferring ScribeNick: weiler
ScribeNicks: jcj_moz, weiler

WARNING: No "Topic:" lines found.

Found Date: 28 Feb 2018
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.)