See also: IRC log
<weiler> Agenda: trackbot-ng, start telcon
<rbarnes> for the record: JC will not be able to make it today
<JeffH> scribenick: jeffh
vgb: rolf and he are converging
on PR # 161, down to naming issue
... question is what to name some of the things in the
AttestationStatement dict
... thinks rolf's proposed names are not evocative enough, has
proposed revised names in thread...
Rolf: am not fundamtly apposd to those names
vgb: <something about safetynet>
rolf: acks gmandyam's assessment
of safetynet attstn being platform attstn rather than authnr
attestn
... notes that goog android N attstn is similar to how UAF does
it
Alexei -- will review
wrt #162 and #198 (PRs)
vgb: we can choose either of
those PRs, needs review
... in #198: removed eTLD+1, relies on the "relaxing same
origin restriction" in HTML51
jeffh notes that "eTLD+1" should at least appear in foot notes
vgb in anser to rbarnes: likes #198 a bit more, there's one cost to it wrt RP ID
scribe: rp id hash from makecred time needs to match one at getassn time, and so if folks change deployemnt domain names after user did makecred, subsqnt getassns calls may not work...
rbarnes: not sure that'd affect things... but yeah, seems like a richer variety of failure cases -- not sure whether #198s richness is necessary
vgb: am thinking similartly -- yes you get complexity, but only if you don't want strict origin policy
rbarnes: ok, we will finialize #162 / #198 on Tue next week in Lisbon TPAC
<wseltzer> scribenick: wseltzer
JeffH: On processing rules and
exclude list
... teasing it apart a bit
... client will use exclude list re dummy challenges
... = dummy sign requests
<vgb> issue #6
JeffH: that's implementation
guidance that should be in the spec to say why it's in the
exclude list
... since it might not be intuitively obvious
<vgb> https://github.com/w3c/webauthn/issues/6
alexei-goog: background
... There are authenticators that have no storage
... use a key handle, in webauthn, credential ID
... as a way to offload storage
... gen pub-priv keypair
<JeffH> thx wseltzer
alexei-goog: encrypt with key on
authenticator
... take encrypted blob, give to server in credential id
... server sends cred ID to client, client sends to
authenticator
... auth'r decrypts blob, extracts, validates, for RPID,
executes
... reason for exclude list: in registration phase, don't want
duplicate reg from auth'r you already have
... so "here are all the credentials I have"
... reject authenticators that have one of these credentials,
for this operation
... client takes the exclude list, cred ID, and sends to the
authenticators
... if get non-error reply, then auth'r could have generated
assertion -- ie., owns that credential
... don't accept registration replies from that
authenticator
... so that's why exclude list.
rbarnes: what if RP says "I only want to talk to USB credentials". That shouldn't be what we're doing here
alexei-goog: I don't think we're enabling that practice
rbarnes: we might want to add to authenticator model to specify the probing
alexei-goog: I was writing a tool
without necessarily specifying all the priors
... I need to figure out where to put it in the spec
... Should I do in same PR or different?
JeffH: Internal
authenticators
... it wasn't clear what you meant by "local
authenticator"
... authenticator in smartphone might be used for apps on
smartphone or on laptop
... is it "internal" or not?
alexei-goog: transport attribute is a sequence, e.g. both internal and bluetooth
JeffH: if sequence only has "internal", then don't contact "external" devices
alexei-goog: if it can't contact internally, then should reach out, because it knows not made on that device
vgb: it's a should not a must
JeffH: let's do everything in that PR
alexei-goog: sure, and I'll fix the build
https://github.com/w3c/webauthn/pull/196
vgb: I went through errors
... please take a look
... when every authenticator errors out, we return immediately.
creates a bit of a side channel
... as RP, I can tell whether a bluetooth authenticator is in
range
... but we're getting improved user experience, maybe ok
... then I changed credential to scoped credential to avoid
name collision
alexei-goog: I can review the PR
JeffH: I will review
vgb: per conversation in Berlin,
need to assure that 2 creds for same account ID, RP can't
assume 2 continue to exist
... train in a tunnel
... we said things would be easier if 2d makeCredential
replaces the first for same account ID
JeffH: Are all these PRs for WD02?
nadalin: only 2 currently marked that way
vgb: the issues and pr markings don't match
https://github.com/w3c/webauthn/pull/193
JeffH: Giri updated his PR
... I rendered and diff
... had one question
... registry doesn't have to track WDs of the API
... we should discuss in Lisbon
... expect to see Giri there
... I'll try to send the diff to the list
... on WD02 issues, I added all the ones that mentioned
Origin
... will send a PR in the next day or so
... have been reading the HTML spec
... we may need Anne to help identify the object
vgb: the newer HTML5 drafts have
cleaned this up
... settings object
wseltzer: We'll be discussing normative references and HTML5 at TPAC
JeffH: I'll join that
conversation
... and an IETF facet too
... I can update to point to HTML5.1
nadalin: Some other open issues
JeffH: vgb has addressed a bunch
of these in his PRs
... and I'll send PRs for those assigned to me
... Rolf, can you review issue 99?
Rolf: I'll put it on the list
JeffH: Anne raised the question
of service workers
... I submitted an issue on that
... use cases involving not asking user consent in situations
of re-authentication
vgb: can we punt to v2?
... along with the origin issues
... i.e., opaque origin
... I'd rather say, we don
... don't have webauthn in non-interactive context
... for now, we have site wants to know user consented
JeffH: We could create a level 2 milestone and assign the issue there
vgb: yes. does anyone object to putting it aside for now?
JeffH: suggest you put that into
an issue reply
... then we can also make statement there needs to be an active
browsing context
nadalin: we had some issues come
in as people start to read the updated draft
... posted to the list
... e.g. from Yaron
vgb: I was going to reply soon
JeffH: thanks
nadalin: we won't be meeting by
phone next Wednesday
... F2F Tuesday
... I've asked to cancel FIDO meeting next week that overlaps
with our W3C meeting
... at the end of next Tuesday, we'd like to have most of our
WD-02 issues closed
... so we can do an update, get feedback, and head to CR
... important to leave TPAC with a plan for closing all the
open issues
JeffH: I wouldn't be surprised if we have a WD-03 before CR
vgb: If we address all WD-02 issues, does anyone object to publishing a new WD
nadalin: that's our goal
... at our meeting, we can decide whether the next WD is -03 or
CR?
vgb: if we close issues by email, can I push a new WD before Lisbon?
nadalin: any objections?
... hearing none.
JeffH: some of those PRs we wanted to talk about in Lisbon
nadalin: if it happens by email, it can be updated
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) Succeeded: s/scribenick jeffh/scribenick: jeffh/ Found ScribeNick: jeffh Found ScribeNick: wseltzer Inferring Scribes: jeffh, wseltzer Scribes: jeffh, wseltzer ScribeNicks: jeffh, wseltzer Present: wseltzer nadalin Rolf apowers Ketan Regrets: JCJ_moz WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 14 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/14-webauthn-minutes.html People with action items:[End of scribe.perl diagnostic output]