<weiler> Meeting: Web Authentication Working Group at TPAC 2017
<inserted> scribenick: jfontana
look at Wd-07 issues today
goal is to start the process to take this to CR today
triage today, so we can assign people to the issues. 60 or so
toward CR today
apple is here as an observer
samsung here as observer
DDS here as an observer
<SamSrinivas> +present
<christiaanbrand> +present
<jeffh> elundberg -- webex work for u ?
537 closed
644 pending
<jcj_moz> Sorted list: https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3ACR+sort%3Acreated-asc
https://github.com/w3c/webauthn/issues/644
#96 https://github.com/w3c/webauthn/issues/96
yes.
#96 should we hold up CR for this
jcj_moz I would not hold up CR for this
#96 moved to PR
#106 is just a tracking issue.
https://github.com/w3c/webauthn/issues/106
https://github.com/w3c/webauthn/issues/116
jeffh it is an implementation consideration
jcj_moz what is authenticator cancel? it is not our job in Webauthn to do the sematics of cancel
jcj_moz it should say for cancellation go look at the transport specs
#125 https://github.com/w3c/webauthn/issues/125
jeefH closed #125
https://github.com/w3c/webauthn/issues/139
angelo I thought we had a PR
jeffH it was #545
tony #545 should address this
close 139 becuase 545 adressed it
https://github.com/w3c/webauthn/issues/140
jcj-moz we should not hold up CR so we can write to implementers on privacy
scribe: this can be a PR
jc-moz we just need to write. if RP worried about creating a credential ID. The UA needs to handle this
<jeffh> https://github.com/w3c/webauthn/issues/140#issuecomment-343223907
jcj_moz perhaps we need to open another one to handle unlinkability.
jeffH punt this to PR milestone. and we do not have issue with sub-stream unlink.
https://github.com/w3c/webauthn/issues/184
jcj_moz this is what we have been talking about.
jcj_moz this brings up timing which is interesting. I think this will be advice to UAs
tony: sending #184 to PR
https://github.com/w3c/webauthn/issues/204
jcj_moz duplicate of the last two we talked about they all go togehter 140, 184, 204
https://github.com/w3c/webauthn/issues/210
angelo: #593, #594 these cover
210
... we should link them. these are issues international folks
have asked about
tony: so close #210
https://github.com/w3c/webauthn/issues/227
Rolf closed #210
<elundberg> only about half the room (guessing) is audible in the WebEx meeting
<elundberg> the person speaking now is drowned out by noise, for example
gmandyam: this could possibly be
closed. we have aaguid extension already.
... close this and allow client extensions?
tony: today they do it through extensions
gmandyam: short answer, close this. the issue is what do we do with authenticator selection criteria
tony: today we handle through extensions, any issues with gmandyam doing this
no objections
https://github.com/w3c/webauthn/issues/233
jeffH: i think most of this has
been handled
... emil kindly addressed parts of this
... I think we are good for now
tony: close this?
... open and tag for CR?
JeffH: let's close it
tony: closed
https://github.com/w3c/webauthn/issues/292
jcj_moz: this is implementation
item.
... abort does not have to include everything going on.
... I think we should fix 292. we should fix today. I could
write a PR.
... will write a PR.
https://github.com/w3c/webauthn/issues/296
jeffH: things have changed since this was written. we are not explicit about PublicKeyCredentialType
tony: keep it open?
JeffH: yes. For CR
tony: you will re eval this one. And leave at CR
https://github.com/w3c/webauthn/issues/303
gmandyam: recommend keep this open. or we could shift to PR.
jeffH: I am adding the "process" label.
gmandyam: I don't recommend closing. this has to be addressed somewhere
JeffH: punt to PR milestone>
<elundberg> (backing up a bit to #96: changes proposed in #672 should go some way to address concerns in #96 Privacy across OS accounts)
JeffH: moved to PR
https://github.com/w3c/webauthn/issues/316
tony: close
<jeffh> elundberg notes he can only hear about half the folks in the room
jcj_moz: it may come up again. but it won't be a serious interop issue.
https://github.com/w3c/webauthn/issues/322
tony: we will have to create
something for CR. keep CR milestone.
... going to add mjones to help out.
https://github.com/w3c/webauthn/issues/349
Angelo: this is just mirror language of CTAP, it should go to CR.
correction. move to PR
tony: stay at CR or move it?
<elundberg> thanks jfontana, but I don't think speaking up will help much. It's mostly noise and room acoustics causing the problem.
angelo: closed
https://github.com/w3c/webauthn/issues/361
jeffH: I think we can close this. I think it no longer applies
<scribe> closed
https://github.com/w3c/webauthn/issues/361
correctino
https://github.com/w3c/webauthn/issues/362
sorry elundberg, can't change that
tony: the RP has to know how to select the algorithm
rolf: the browser should have idea what to expect
tony: that should be in for the CR.
<jcj_moz> <-- opened https://github.com/w3c/webauthn/pull/673
tony: we might run into this in interop
Adam: it is good to adopt what has already been created in W3C.
<jeffh> @rlin: i.e. what hash algs that the UA uses to hash the clientData
jeffH: adding rolf to #362
https://github.com/w3c/webauthn/issues/364
angelo: it is difficult at this time to define this.
tony: do we want to punt to PR. we might close it later on. should we go to CR and see what happens
jcj_moz: putting it to PR.
https://github.com/w3c/webauthn/issues/366
jeffH: we changed this to COSE format.
tony: this should be
closed.
... it has been merged.
jeffH: closed
https://github.com/w3c/webauthn/issues/368
rlin: will look at this today.
15 minute break
back at 10:15 PDT
<elundberg> are we still in break?
<christiaanbrand> just got back
<christiaanbrand> break was more like 45 mins...
https://github.com/w3c/webauthn/issues/372
tony: mjones will work with Alex and Akshay to specify the right parts. it's not a review of the whole issue
https://github.com/w3c/webauthn/issues/374
discussion is around iFrame
<jeffh> "restrict WebAuthentication API to only top level browsing context #374"
scribe: security issues, it could foster issues in some browsers,
privacy concerns
suggestion is to block iFrame
adam: hinges on the claim that re-direct is confusing
<jeffh> jcjones: take step back, would be hekpful to think about this instead as something to be more careful about when we do have silent/touchless authnrs ?
<jeffh> ... the ad netw cant track you unless they can confuse u into signing-in twice
<jeffh> ?: asserts that the attacker can do a silent redirect anyway
<jeffh> jcjones: given that, is it really "that bad" to permit iframes?
<jeffh> gmandyam: easier to just allow iframe to do authn than force workarounds at top level context
<jeffh> battre: notes that registering with an unknown party is a privacy issue
if you are typing and on the phone bridge, can you mute, please
jBradley: arguing for W3C Feature Policy
tony: JeffH will talk to Mike West to allow providers to use iFrames or not
https://github.com/w3c/webauthn/issues/394
tony: 374 will stay at CR
jcj_moz: I think this is still
valid.
... this might something we want to write in before we go to
CR
tony: OK
https://github.com/w3c/webauthn/issues/396
gmandyam: I will work on this.
https://github.com/w3c/webauthn/issues/404
CNH: no on disputing this needs to be clarified
jeffH agrees
jeffH: we need to explain the
security ramifications of presenting your challenge
... this is one to think about
... leave at CR
jcjc_moz
my guess is to fix this before we declare a CR
jcj_moz: we should write a PR today to fix this. assigned to jcj_moz and jeffH
https://github.com/w3c/webauthn/issues/410
angelo: this one should go to CR
correction PR
tony: send to PR.
https://github.com/w3c/webauthn/issues/412
jeffH: maybe we should just close
this? It is two views on the same data.
... closed.
https://github.com/w3c/webauthn/issues/417
tony: will ask mjones to verfiy and close
https://github.com/w3c/webauthn/issues/420
jeffH: things have changed. I have to check if it still applies
tony: push to CR
... jeff will work on it.
https://github.com/w3c/webauthn/issues/438
gmandyam: I have a PR ready to go
for this.
... provides background
... I added text that points to limits of Safety Net
JeffH: looks fine. merge
tony: and it will close this issue
https://github.com/w3c/webauthn/issues/455
adam: this is defined in
CTAP
... do we want to echo that as reminder for sites to look at
this other doc.
tony: we reference it now in the
spec
... I will have mjones add another pointer to it.
adam: use CTAP definitions
https://github.com/w3c/webauthn/issues/509
strike #509
https://github.com/w3c/webauthn/issues/590
strike #590
https://github.com/w3c/webauthn/issues/491
jeffH: I need to verify this is still applicable
tony: jeff will verify
https://github.com/w3c/webauthn/issues/509
akshay: did we close this
jeffH: going to COSE key solved.
jcj_moz: closed
https://github.com/w3c/webauthn/issues/543
jeffH: leave it at CR. I will verify
https://github.com/w3c/webauthn/issues/551
angelo: there were changes.
tony: this is no longer valid?
jeffH: I need to verify
https://github.com/w3c/webauthn/issues/565
tony: assigned to Jeffrey. leave at CR for now. See what Jeffrey comes back with
https://github.com/w3c/webauthn/issues/570
<elundberg> I can do this right now
tony: copy over with CTAP spec?
akshay: reference CTAP
... spec
... leave it in CR
tony: ok
https://github.com/w3c/webauthn/issues/576
<elundberg> @selfissued assigned
<elundberg> to #570
#576 going to PR status. include what RP has to do
https://github.com/w3c/webauthn/issues/590
tony: merged
https://github.com/w3c/webauthn/issues/606
rlin: create PR and merge
https://github.com/w3c/webauthn/issues/610
jeffH: we need to have tir right
language and include a reference
... we can push this off to PR. It is editorial
tony: since this is not big issue. Push this off to PR.
https://github.com/w3c/webauthn/issues/613
jeffH: this is fixed
jcjc_moz: agreed
jcj_moz: I think it was fixed in #655. Let's close this.
tony: jcj_moz will verify
rlin: back to #613. there is issue in the spec itself.
jcj_moz that makes sense. leave open. push to CR
correction. pushed to PR. jcj_moz will look at it.
https://github.com/w3c/webauthn/issues/622
elum: #622 has PR ready to go
jeffH: need to review. will do later today.
https://github.com/w3c/webauthn/issues/626
jcj_moz: we should make decision as to where responsibilities lie to define encode and decode
<jeffh> e.g.: see bzbarsky's comment: https://github.com/w3c/webauthn/issues/626#issuecomment-335930727
jcj_moz: I can't implement this as it is.
jcj_moz
tony: Change to use buffer source
and use CDDL and remove client data examples
... assigned to gmandyam
some open issue to change to CDDL. refere new issue to old one. Assigned to gmandyam
Lunch break.
One hour. Return at 1:00PM PDT
<elundberg> https://github.com/w3c/webauthn/issues/627
dirk: I don't think it is changing the spec
tony: moving to PR for WD-07
dirk: will submit a name change
https://github.com/w3c/webauthn/issues/645
tony: dirk is creating a PR on #645
https://github.com/w3c/webauthn/issues/647
jeffH: this may be a duplicate.
tony: close this one?
... close
jeffH: mark as duplicate
https://github.com/w3c/webauthn/issues/648
akshay: I think we should close
it
... no action
tony: JeffH you have something on this one
jeffH: I think he has a point. We may be stuck with it. It is confusing
tony: anyone has problem with closing this no action
jcj-moz: I am fine with closing it and ack. it is sad but true
https://github.com/w3c/webauthn/issues/656
jcj_moz: this is just text I
think. It's technical but not normative
... it's misleading as currently written.
... we should fix the portion of verification procedure to be
more accurate
... I don't think we need any normative changes. Push to
CR.
correction: push to PR
jcj_moz: I don't think we need to hold up CR for this
attendance + mikeo +colin
jcc-moz: willl merge it and put in comment to track
https://github.com/w3c/webauthn/blob/master/index.bs#L738
angelo
thanks, sam.
chairs+ jfontana, nadalin
<elundberg> https://github.com/w3c/webauthn/pull/672
<elundberg> #672 decided to fix conflicts and merge PR
https://github.com/w3c/webauthn/pull/673
<jcj_moz> https://github.com/w3c/webauthn/pull/681
https://github.com/w3c/webauthn/issues/674
Dirk working on a PR.
Privacy Interest Group Joins
<weiler> scribenick:
<weiler> scribenick: weiler
nadalin: we WILL have sec and
priv considerations.
... doc came from FIDO to W3C. editors from fido carried over.
we picked up some add'l editors.
... we have chrome, firefox, and edge in the room.
<jeffh> https://www.w3.org/blog/2015/11/w3c-fido/
nadalin: we've done one interop. another in Jan?
tara: do you have priv considerations you can direct us to?
jcj: we ahve a set of issues marked as privacy that we need to write up.
jeffh: nominally, FIDO principles apply
nadalin: we didn't bring that doc over. but principles carry through.
<jeffh> fido privacy principles: https://fidoalliance.org/assets/images/general/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf
jcj: we've narrowed priv issues
down to three.
... consolidated or mitigated...
... for CR.
<jcj_moz> https://github.com/w3c/webauthn/labels/doc%3Apriv-cons
tara: someone what to talk about one of these?
Rolf: @@
... different RPs use different identifiers; even if RPs
conspire, can't link users.
npdoty: what when same users come back? RP knows who it is?
Rolf: of course.
JohnBradley: might be edge cases, e.g. around private browsing. do you expose all of personas and let user choose?
weiler: perhaps explain info flows? or attestations?
<npdoty> it has been a topic of interest in PING about giving useful guidance on how to explain how a feature interacts with a private browsing mode
jcj: need a physical device
(might be built in). Web site can ask authenticator to create a
new credential. bound login credential between that
authenticator and that web site. not enforced as 1-to-1. in
incognito, reasonable to force that there not be an overlap
between normal mode and incognito mode. that's underspecified
in doc. should be thought about.
... inside the new credential when first created, there is an
attestation providing the provenance of the
authenticator.
... e.g. "this was constructed by yubico". potentially a batch
number.
<jeffh> webauthn registration ceremony diagram: https://docs.google.com/presentation/d/1om__oSew4n48MK_Qcc8deq6hCZ6720-Zvv1PdK0CrjA/edit#slide=id.g2b7fa0712_0127
<jeffh> webauthn authentication ceremony diagram: https://docs.google.com/presentation/d/1om__oSew4n48MK_Qcc8deq6hCZ6720-Zvv1PdK0CrjA/edit#slide=id.g2b7fa0712_0158
jcj: good for banks but is
another identified that could be used to build a profile. when
this is passed from HW to relying party, there is a mode of
"self-attestation" where use splices in a self-signed
cert.
... firefox will likely do that for private browsing mode.
jnovak: notion is that a browser would splice in a cert that would be the same for all instances?
jeffh: unspec. generates a user-specific, rp-specific key pair.
jcj: firefoxes first version, new cert w/ new private key. all random every time. potentially exposing info about randomness of device.
weiler: is this an even more trivial way to detect private browsing mode?
jcj: yes. privacy ca is something
we might pull in later.
... third of the attestation types is Privacy CA. the very
identifying cert on the authenticator is provided to a third
party, tasked to anonymize it.
... general idea is that UA would ask third party...
jeffh: @2. design is to not have UA be a middle man. TCG calls this an Attestation CA - it's in the spec to accommodate TPM.
johnbradley: required to be this, or have large batch size.
<jeffh> Note: Privacy CA attestation type that is presently in webauthn spec is from FIDO specs where it was incorporated specifically in order to accommodate TPM-based authenticators.
johnbradley: there are Q's
floating around "are we disclosing too many bits of entropy
that enable fingerprinting" by identifying model/batch of
authenticator.
... but good reasons to know what device is (HW, SW,
etc.).
... tradeoff. How much entropy already exists? Does this bit
matter?
<jeffh> Note2: the TCG has changed the name of the entity formerly known as Privacy CA to Attestation CA.
npdoty: might need to take this offline.
johnbradley: recommendation is 100k batches or larger.
<jeffh> Note3: what Google is proposing as a so-called "privacy ca" is NOT the TCG-spec'd attestation CA, and wold be an artifact of the UA and NOT the authenticator
Rolf: @4 We want to make sure that attestations don't allow global correlation.
johnbradley: we understand that batch size of 1 would be broken
rolf: but 100M might be a challenge,
johnbradley: if you have a nation state breaking the key embedded in that 100M batch
tara: we'll expect a largely
changed doc soon w/ privacy considerations.
... we'll look at flagged github issues.
nadalin: we want CR by end of Nov.
<jfontana> tony: still have PR #672 #673
<wseltzer> [WebAuthn formal meeting concluded when PING group left]