<weiler> jfontana: re: horz review: we talk to brad hill (webappsec) - hadn't heard anything from mike west - brad will ping them.

<weiler> ... we need version numbers of broswers w/ support in the transition doc.

<weiler> ... we have firefox's.

<weiler> @@: Chrome is aiming for 66.

<weiler> jeffh: mike jones in on a plane and on IRC only

<weiler> angelo: targetting next windows release; fall 2018 (sept?). no separate release for edge. "insider build" for edge sooner.

<selfissued> I am on a plane today so while I'm on the IRC, I can't be on the call.

<weiler> jfontana: we're looking at Feb for CR (discussed f2f in monterey)

<selfissued> Please put info you want me to be aware of or act on in the IRC.

<weiler> adam: is that getting CR started, or published?

<weiler> jfontana: I think that's published

PR510

<scribe> scribenick: elundberg

https://github.com/w3c/webauthn/pull/510

gmandyam: selfissued raised some issues; I don't understand what he means
... he seems to think that sources like the FIDO MDS are not reliable, which I don't know how to respond to

<selfissued> Let me look

<selfissued> It's not clear to me that the percentages data is authoritative or even actionable

gmandyam: for biometrics you get a certification for a third party lab because it's expensive

<selfissued> Why should this data not come out of a database lookup based on the device type, rather than be self-asserted in the protocol?

<selfissued> What's the business case for including this in the protocol?

apowers: in practice everything out there is self attested at this point

<selfissued> Yes, but why put this information in the protocol?

apowers: it's for RPs to make risk assessments on
... and there's a lot of other signals that go with it in the MDS

<weiler> supplementing... apowers: fido requiring 1/10000 FAR, 3% FRR, allows self-cert for lower FAR. this is the first time we're seeing this in private sector.

jeffh: I think this extension is for the RP to stipulate its requirements, not for the authenticator to communicate it to the RP

gmandyam: a certification will only certify you to a certain extent

jeffh: so selfissued's question is how does the client know whether an authenticator satisfies the requirements?

<selfissued> Do any of the authenticator vendors on the call think that if the RP sent values other than the defaults, that your authenticators would really be able to act on those values and fulfill them?

gmandyam: there's an authorative source: the MDS

jeffh: that's what we suggested you mention in the PR
... are these performance data public?

gmandyam: yes, they are

<selfissued> If for instace, the RP requested that the false accept rate be 10 times less than the normal one, is this practically achievable?

<selfissued> Or is it just wishful thinking on the RPs part?

<selfissued> If just wishful thinking, we shouldn't have an API for expressing these wishes

jfontana: I think we should move the continued discussion to the list

<selfissued> Agreed

<jeffh> fontana: pls take further discussion of this to the PR & mailing list

https://github.com/w3c/webauthn/pull/623

<apowers> seems like it would be better to have a way of discovering available AAGUIDs and then looking up any information about them... otherwise you end up building a dozen extensions just to filter authenticators in a number of different ways

<selfissued> There's a lot that isn't clear about both what this is intended to do and why

jeffh: I'm handling #623
... I think mostly everything was taken care of

<selfissued> Are we discussing #623 now?

yes

jeffh: I need to look at emlun's comments from last night, too

<selfissued> I think what's in the PR is an improvement over what's in the current draft, and so should be merged

https://github.com/w3c/webauthn/pull/724

gmandyam: I've made as many changes as possible
... there still seems to be objections which I don't understand
... apparently this would imbalance the spec, but the extensions are already imbalanced

<selfissued> My objections are just that the issue was to add CDDL to all the extensions whereas this PR only added it to one

gmandyam: I personally didn't want to do that because there's not very good procedure for writing these extensions

<selfissued> The will be a lot clearer after #765 is merged

<selfissued> They will be a lot clearer after #765 is merged

jcj_moz: as long as we have CDDL for all exts before next publish, I'm happy

<jcj_moz> ^^ that was jcj_moz

oops, sorry

<selfissued> I'd be OK if this was merge after #765 is - provided that someone takes ownership of finishing the CDDL job

jcj_moz: it is true that #765 will make things much more obvious, but I still think we should have CDDL to lower the risk of incompatibilities
... I think we should merge them both

<selfissued> I agree that we want CDDL. I just want someone to sign up to write the CDDL for the other extensions.

jcj_moz: #765 is a much bigger change, so I agree with landing that first

<selfissued> Who wants to own doing that?

jfontana: ok, let's deal with #765 first

<jcj_moz> https://github.com/w3c/webauthn/pull/760/files

https://github.com/w3c/webauthn/pull/760

jeffh: I think selfissued needs to respond to my recent replies to his comments

<jcj_moz> https://github.com/w3c/webauthn/pull/762

https://github.com/w3c/webauthn/pull/762

jeffh: this is ready as far as I'm concerned

<selfissued> #760 shouldn't say platform-specific

jfontana: let's merge #762

https://github.com/w3c/webauthn/pull/765

<selfissued> Agreed on merging #762

<selfissued> I see three approvals on #765

jcj_moz: my counterpart implementing this said this is good, adam, kim [and others] said it's good, I think it's ready to go

<selfissued> Shall I merge?

jcj_moz: the upside for FF at least is I can implement this

@selfissued not decided just yet

jcj_moz: the downside to this is that the browsers have to code the IDL for exts in, but in practice we're going to do that anyway
... we lose the flexibility to let things go, but gain not having to fight an IDL change
... it's no more work for us than we're already planning

<selfissued> Per the earlier discussion, there wasn't browser precedent for map of any

gmandyam: can you point to an extension that defines its I/O with this properly?
... ok, I'm fine with merging
... I feel it'd be nice to say somewhere in sect 5 that authnr exts are always a CBOR map

<selfissued> It already says that

jfontana: can we take that up for the PR milestone?

gmandyam: ok

https://github.com/w3c/webauthn/pull/133

<selfissued> Are we merging #765?

jfontana: yes

<jcj_moz> selfissued yes

<selfissued> OK - will do

https://github.com/w3c/webauthn/pull/133

gmandyam: this is addressed by PR #763

elundberg: #763 is replaced by #771

<selfissued> I just approved #771

gmandyam: I think we can merge #771
... which will close #133

jfontana: objections?

<selfissued> Do it

jeffh: yes, I want to review first

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

<selfissued> It's really short jeff - you can probably do it during the call

jeffh: this is in my queue; next
... I'll review #771 after the call

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

agl: we just closed #346 by merging #765

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

akshayku: I'll look at this today

<jeffh> @selfissued: btw, you had "partially fixes #nnn" text in pr #765 which likely closed those issues upon merge is that what you wanted ?

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

<selfissued> I'll look at the partially closes after the call and reopen those with comments that aren't fully addressed

agl: I think U2F self attestation is impossible
... in practical reality, U2F devices don't do this

jeffh: so no-one's going to create any new U2F devices?

agl: even if they do, the U2F protocol doesn't have this capability

jeffh: self attestation is just using the same private key in both the credential and the attestation cert
... so I don't think we can assume noone will do this

<jeffh> call dropped for only me?

<jeffh> yep only me

agl: I think jcj_moz is talking about the FF soft key, where you make up a cert that does just that

jcj_moz: yes

agl: but is the pubkey in the cert the same as the credential key?

jzj_moz: yes

agl: but wouldn't you just define the FF soft token to do that in a webauthn CBOR way?
... I do not believe this will ever be used outside FF, but if that's enough to motivate jeffh to write this then sure

<selfissued> ;-)

jeffh: we could possibly solve this with just a note, what do you think jcj_moz?

jcj_moz: I think that's probably sufficient
... we'll be following the spec, but the authenticator will no longer be the source of the cert for non-direct attestation

agl: but that's not self attestation, because you're signing with a different private key
... with a soft token you could do that
... but in the anonymization case we're signing with a different private key, so it's not self attestation
... I have no objections to doing this, but I expect it will never be used

jeffh: so then the question is do we put anything in the spec or not

jfontana: let's get back to this later

jeffh: when we merged #765 we may have inappropriately closed some issues
... there was some "partially closes #xyz" text in the PR text, which may have inadvertently closed some issues we should keep open

<jeffh> i.e. the two that were noted as "partially fixes #nnn"... ?

<selfissued> As I said, I'll look at the "partially closes" after the call and reopen with comments saying what remains, if anything does

elundberg: selfissued noted earlier that he'll go through this after the call

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

jeffh: #760 addresses this
... I'm working on it

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

agl: there's a PR for this; I think it's ready to go, pending review
... elundberg and selfissued have approved

jeffh: I need to re-review

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

jeffh: this is a relatively minor editorial cleanup
... it's assigned to selfissued

interop report

<selfissued> I have an open question to JEff on #746. I don't know where new text should go and what it should say.

christiaanbrand: we had a handful of authenticators, Edge, FF, Chrome
... it seems like we got most of the tests working

<selfissued> It would probably be better to assign #746 to Jeff since he seems to know what to do

christiaanbrand: spreadsheet wasn't properly filled in
... I think there was only one spec issue, which I opened an issue about
... I think it went really well

agl: what was the issue?

christiaanbrand: the one about packed attestation certs

<weiler> here was the issue: https://github.com/w3c/webauthn/issues/768

christiaanbrand: we had a matrix with client, authnr, server, it wasn't filled in much so it's pretty sparse

<weiler> trackbot, end meeting

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/jeffh/jcj_moz/
Default Present: weiler, elundberg, gmandyam, jfontana, Christiaan, Akshay, jeffh, jcj_moz, selfissued, wseltzer, agl
Present: weiler elundberg gmandyam jfontana Christiaan Akshay jeffh jcj_moz selfissued wseltzer agl
Found ScribeNick: elundberg
Inferring Scribes: elundberg
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2018Jan/0379.html
Found Date: 31 Jan 2018
People with action items: 

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.)