Web Authentication WG

08 Jun 2016

See also: IRC log


gmandyam, vgb, JeffH, jcj_moz, SamSrinivas, Rolf, alexei, Hubert-PayPal


<wseltzer> present=

<wseltzer> trackbot, bye

<wseltzer> trackbot, prepare meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

<Jean-Gui> trackbot, prepare meeting

<trackbot> Sorry, but no Tracker is associated with this channel.

<Jean-Gui> trackbot, prepare meeting

<trackbot> Meeting: Web Authentication Working Group Teleconference

<Jean-Gui> tackbot end meeting

<Jean-Gui> trackbot end meeting

<trackbot> Meeting: Web Authentication Working Group Teleconference

<trackbot> Date: 08 June 2016

<apowers> hi

Vijay: Big theme of recent discusison unprompted exyensions

Shoudl autehnticator add them wihout prompting by RP

Should user agents be in the position of gatekeeper -- this is a 2nd issue.

we had agreed so far to mandate that one way or the other -- clients could choose what they do.

the 2nd issue seems to be settled to everyone's saatisfaciton more or less, but 1st issue (authenticaiton adding extension)

is the one under active discussion

(meta; Vijay speaking still)

Proposal: RP would say "These are the extensions we would like".

Jeff: I thyght we had agreed that the backstop for autehnticatior added extensions was certification testing (reputational recourse). Giri agrees.

Giri: We don't have consensus. Vijay: Yes, we are in the process of discussing

<gmandyam> Giri: There does not seem to be a way in the standard to preserve the packed attestation signature if the client starts stripping unprompted extensions. This is problematic.

Jeff metnioned ReputationaL Recourse via Certifcation. Vijay says: Certifiucation is not required, how do we handle that?

Vijay: What is the case for unprompted extension if we were starting from scartch?

Jeff: UVI extension.
... Such extensions are in UAF.
... Was used by a server and autehnticator being both from same vendor
... They don't need to update front end on server -- hence we should have unprompted -- since RP will not need to query for it.

Rolf: Unprompted extensions make sense since authenticator can put them in without expecting browser to understand it
... I share the privacy concerns, but need to understand the threat model.
... No way to get authenticator to be any particular way.
... we should only allow privacy presevring

Sam: External authenticator may not knw the privacy constraint and in good faith violate it

This is not theoretical -- there are vendors in this doscussion who may not be undestanding this distinciton.

Vijay: Someone has to police auehtnicators which are privacy vilolating -- how willwe do that

Jeff: Things would work as they do now. There will be certification programs.
... It is not 100% effective but nothing really is. We are trying to foster low friction innovation.

Vijay: Who will police these?

Giri: Things are problematic but dealing with them through the API is the way to go.

The browser can provide user prompts (giri)

<gmandyam> Giri: providing visibility into granted permissions on an authenticator level is a current accepted best practice on the web. Plenty of W3C standards can be used for privacy violations (e.g. Geoloc, EME).

(speaker to be noted) If we do a reputational thing then user agents have to run white lists and black lists. Browsers are expected to try and protect users from poorly beahibg equipment.

Speaker was JC

<gmandyam> Giri: The solution for most browsers is to provide the necessary prompts and request permissions on a per-domain basis.

Vijay: Building on what Giri and JC said, if the browsre has to udnestand the extension and do sensible prompts, it has to have whitelists and blacklists. This would be high friction.

We should be able to allow a user to just "say no" to any privacy 'vioating' stuff and just use the basic autehnitcator. This will not be possible with unprmpted extenstions

What if instead of unprompted extensions we baked them into the spec?

(speaker = ...)

Speaker JC

Rolf: AAGUID can be part of attestation and give device ID

But having browser as police of extensions is impractical coz they all the various user agents have to agree on extensions which work

Tony: its like being in the certificate root list for a browser -- a mechnism to get into all browsers

Jeff: user agent etc will implement whitelists
... UVI use case -- authenticator shold be able to say what kind of biometric was used

Sam: How can browsers even undestand how to whitelist or backlist? What is the information source?

Rolf: Well, authencitaor may add unpromptec extensions anyway

Sam: Wouldn't the browser then drop the entire transaction?

Vijay: Whitelisting is very hard to do for browser vendors.

Tony: We are not converging

Viay proposal: Will try a draft making all unprompted exetsnsions into prompted extensi0ons

<Rolf> +1 for Vijay's proposal

Giri: already has proposal for locaton, vijay take into consideration

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/08 18:59:55 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: SamSrinivas
Inferring Scribes: SamSrinivas

WARNING: No "Topic:" lines found.

WARNING: Replacing list of attendees.
Old list: (no_one)
New list: gmandyam vgb JeffH jcj_moz SamSrinivas Rolf alexei Hubert-PayPal

Default Present: gmandyam, vgb, JeffH, jcj_moz, SamSrinivas, Rolf, alexei, Hubert-PayPal
Present: gmandyam vgb JeffH jcj_moz SamSrinivas Rolf alexei Hubert-PayPal
Regrets: wseltzer

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 08 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/08-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

[End of scribe.perl diagnostic output]