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

tony: question is do we want emil to review or are we OK with Mike and Akshay - both have approved
... jeffH are you comfortable with those reviews

JeffH: yes. OK.

jeff will merge.

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

tony: same boat

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

tony: same with this
... merge both JeffH

jeffH: yes.

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

gmandyam: my proposal is that if Safety Net is available it makes sense as a extension (re: Android key store)
... under the gun with a new PR , so getting this before the group. We need some Google poeple..

correction .. new CR

<weiler> scribenick: jfontana

Akshay: seeing something is not ubiquitous .... I would not remove anything from Safety Net.
... I would be against remviong Safety Net as attesation...

gmandyam: I think the key word is addition.
... Safety net does not provide an attestation of authenticator or the credential

akshay: I don't think it is our decision to make a client to say which one we would prefer

gmandyam: an authenticator in android today, they have key store attestation

jbradley: onoy about 5% of andorid phones can do attestation.

gmandyam: they can create a packed attestation

jbradley: packed is less used...

gmandyam: I disagree with that.

jbradley: point is you know who the authenticator is
... with pakced you cant manage the key

gmandyam: suer there is. it can be published on a meta data service
... they can supply that separately

jbradley: the packed attestation is the problem.

selfissue: seems odd to have an extension for attestation

gmandyam: its not an attestation for webauthN credential...it is not a reliable indicator of the authenticator

jbradley: tells you what the authenticator is. if phone is rooted in way safety net can't detect you are screwed

dmandyam: idela is RP can detect that

jbradley: safety net attestation is better than self signed pack attestation

gmandyam: I don't think you are making a case for this. We have been doing this on Qualcomm phones...

jeffH: there is no consensus and google is not here. let's move on.

tony: so that is pending. as far as PR are concerned we are down to one more jeffH has to read and merge.
... and #375 which is the roadmap

gmandyam: to follow up. I want google to comment
... what I said it is not giving you an attestation

tony: can we move to L2

gmansyam: yes, but can move it back if we hear from Google

tony: back to issues
... want to close technical issues.

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

jeffH: summarize here: deal is we currently don't follow things to letter on algorithms and ??? sources.
... it will not get fixed today. I don't know if this will hold up for PR.
... I'm not sure what to do at this point.
... it is not less than a one day thing, maybe a week
... a learning curve involved. and we need Boris to review.

akshay: can you confirm. when it is called you can change and client can make a copy of it.

jeffH: pattern for algorithm is you make copies of the buffer sources.
... we have implementations of this
... to make spec proper in some community of spec writers, we should do this.
... we run risks of objections. I assume

<John_Bradley> My point was not that packed is a problem, rather that self signed packed is less useful than a safty net attestation signed by google that identifies the authenticator. Knowing the authenticator lets you make judgements about hate keys are stored.

jeffH: if we cut another CR today...there is some risk, but I don't know how to quantifyi it.

wseltzer: not sure on detail, but looking at comment, but Boris wants more detail, if he sustains as objection, it would go to director to determine clarity
... we could end up non-compliant.
... I could see we are ready to move to CR pending resolution of this detail

jeffH: I don't think I can do this in 2 days.

<John_Bradley> Not all authenticators and attestations are created equal. The RP needs to make decisions based on the attestation type and authenticators identified. Removing saftynet attestations is probably not helpful.

akshay: from implementation. we take a constant and not have it change after that.

tony: so we will not be able to do anything with this now. but it sounds like we need to fix this before we move on.

jeffH: maybe, maybe not. There is indication that implementers are doing the right thing.
... it had been swept under the rug because it was labeled editorial, but it effects the algorithm, so it is technical

wselter: if timing is critical, and we still want to wait. as long as we have a reasonable explanation.
... if we explain why we chose what we have that is potentially an acceptable way forward.

jfontana: i think transparency is key here.

tony: anymore comments.

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

jeffH: do we wait for PRs to land here. maybe waiting is best thing. people are implementing.
... not making change to WebAuthn spec until those two PRs land

tony: if we take that approach this might not make it to CR
... might not be in this version

jeffH: I think it is OK given our implementation history. it is technical polishing

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

jeffH: we should punt to level 2. Boris said we probably want to wait.

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

akshay: I am working on this. give me a few hours.

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

tony: this is nice, but it is a feature that will break things. do in level2

jeffH: agree

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

tony: this is not linked right
... we have two technical issues, that we feel we can make a stance on. And we can do them in level 2

jeffH: in level 1 is an open question is the way I would phrase it.

tony: wendy, sam guidance
... gut feeling is we consider these two closed, in that implementation doing right thing today. If we make the changes at PR level it won't affect the implementations

sam: I am fine with that

wseltzer. requirement is we get call for patent exclusions that is why it is normative change.

scribe: might I have a different patent to exclude if the text changed. if that is the case there is a risk to waiting.

tony: my interpretation is .. moving forward with a CR would be something I would suggest.
... if these two things come in later we have argument there is not change in implementation.

slefissue: we looked at #876 but did not resolve

<wseltzer> [by "risk to waiting", I meant "risk to waiting and then making a change post-CR"]

tony: we did. we gave akshay time to work on a PR and a review
... I wold like to see if we have consensus moving on with CR, the two we talked about and the null reference.
... this would be my proposal

jeffH: #1007, i still have to resolve and close the issue.

tony: do we have consensus on that approach going forward?
... move forward with CR.
... any more comments. any objections?

<wseltzer> PROPOSED: CfC to move forward with CR after addressing 876

thanks wendy

<wseltzer> [no objections]

<wseltzer> https://www.w3.org/2018/Process-20180201/#revised-cr

<wseltzer> https://services.w3.org/htmldiff

<weiler> reminder: TPAC registration fee goes up July 31st. the refund date is 14 October; it might make sense to register now and cancel later, if needed.

<weiler> our meeting is monday; webappsec is tuesday; the plenary day is wednesday; thursday is currently free for joint meetings (e.g. with WebAppSec or PING) with nothing current scheduled; and Friday are the Privacy and Web Sec IG meetings.

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)

Present: weiler wseltzer gmandyam jeffh apowers Akshay jfontana nadalin John_Bradley Ketan selfissued Rolf Yuriy
Found ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Found Date: 25 Jul 2018
People with action items: 

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


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