<weiler> scribe: gmandyam

Tony - examine open PR's for WD-06

First up - PR 379: https://github.com/w3c/webauthn/pull/379

AngeloKai: Need to merge in master. There are some privacy concerns. Would like to get input from other browser vendors - particularly Moz (JC Jones).

Nadalin - does Google have a similar use case to PR 379

AngeloKai - there is a general problem on how to find authenticators that will work with the user. (in response to Google request for explanation)

<jeffh> much of the discussion is in this issue: https://github.com/w3c/webauthn/issues/345

AngeloKai - using this feature (isAuthReady), the RP can decide what user experience they need to provide to the user to direct them to attach authenticators if necessary

ChristaanBrand - understood. No objection at this time.

jeffh - PR is still not ready to merge

ChristiaanBrand - it is a nice-to-have feature, but we won't prioritize implementation

ChristiaanBrand - to clarify - we may not implement feature as RP, but will implement in browser if it becomes part of the standard

AngeloKai - there are precedents in the web platform, e.g. Permissions API

jeffH - why not use Permissions API?

AngeloKai - because Permissions API asks the user for permission to use an API. In this case, you are asking the user to create a credential.

<jeffh> gmandyam: why is not the perms api relevant to platform authenticators (authnrs) ?

<jeffh> christiaan: two things here: (a) whether the user wants to reg with RP (?), and (b) whether user gives RP perms to interact with authnr [not sure i got this correctly..]

ChristaanBrand - the issues of authenticator availability and granting permissions to the API are orthogonal. I don't know if we want a flow where we need an additional permission grant from the user when the user interaction is required for the credential already.

<jeffh> ... do we need two perms models here for these two aspects ?

AngeloKai - a permissions API for e.g. geolocation will allow application access to GPS. The resulting action (return of location data) due to grant of permission is well understood.

AngeloKai - with webauthn, there is more than just grant of the API permission. There is a user gesture required.

<jeffh> s/employes/employed/

AngeloKai - will augment intro section to better describe UI flow in PR

AngeloKai - this will also address outstanding TAG issue

jeffh - the rationale of why this is only for platform authenticators needs to be in the spec

AngeloKai - Still need a solution for detecting whether device is paired with authenticator

ChristiaanBrand - not sure this applies to cross-platform authenticators.

nadalin - will keep as WD-06 pending Moz input

If still open by WD-06 publish date, can move to CR milestone

nadalin - next PR https://github.com/w3c/webauthn/pull/460. Still needs work.

gmandyam - will close out https://github.com/w3c/webauthn/pull/484 and replace with new PR refining terminology section.

https://github.com/w3c/webauthn/pull/495 and https://github.com/w3c/webauthn/pull/498 need to be reviewed

jeffh - https://github.com/w3c/webauthn/pull/498 is meant to address some algorithm breakage to to 384 merge. (see https://github.com/w3c/webauthn/issues/472#issuecomment-309871552)

jeffh - there look to be broader issues with webauthn algorithms violating the web model

jeffh - reopened Zbarsky's issue that was fixed with PR 371 due to PR 384 breakage

nadalin - is this WD-06 issue?

jeffh - we can delay to CR

selfissued - we should touch base with mwest re: credential spec

nadalin - goal is to make WD-06 as close to CR as possible

jeffh - 60-70 issues are tagged CR

AngeloKai - algorithm fix up would be good. It might be good to reclassify several CR-tagged issues.

nadalin - not detecting major changes in WD-06 versus WD-05

jeffh - a diff between current state and last WD would show significant changes

AngeloKai - TLS-related items should be addressed as well

jeffH - such issues should not necessarily be addressed in WD-06. Expect more WD's between -06 and CR. And CR does not mean we are done.

AngeloKai - and we have other spec reviews that will come up

jeffH - think there will be a WD-07. 495 and 498 don't necessarily need to be in WD-06

nadalin - will leave at WD-06 for now

Review of issues impacting -06 ...

See https://github.com/w3c/webauthn/milestone/10

jeffH - maybe we don't need to get hung up on milestones.Just rely on ED.

nadalin - nominate AngeloKai as backup editor.

jeffH - update mastheads to designate former editors.

jeffH - request someone to address issues 283 and 292

AngeloKai - will take on assignment

jeffH - intending to propose PR for issue 278

jeffH - need volunteers for unassigned issues

selfissued - will take on issue 488

345 assigned to AngeloKai

nadalin - will have meeting on July 5

Meeting adjourned

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)

FAILED: s/employes/employed/
Succeeded: s/(return of location) data/(return of location data)/
Succeeded: s/spc/spec/
Succeeded: s/]//
Present: weiler gmandyam selfissued nadalin JFontana apowers Angelo ChristiaanBrand JeffH AkshayKumar
Regrets: wseltzer
Found Scribe: gmandyam
Inferring ScribeNick: gmandyam

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Jun/0201.html
Found Date: 21 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/21-webauthn-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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