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

jeffH: I reviewed looks good to me.
... elundberg needs to update

agl: we could address elundberg's comments in a separate PR since JC is not present

jeffH: could look at the details.
... land as is and submit an issue

tony: any objection in doing that?

none

tony: go ahead jeffH

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

agl: ready to be landed

tony: what other reviewers do we need.

aksay: I can take a look.

tony: shane do you want to look at this one

shane: yes

akshay: I will look at it.

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

tony: still going on

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

tony: still blocked.

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

tony: merge 1418? no objections

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

jbradley: this is a known issue; can be fixed in COSE algorithms

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

elundberg: this is what I used to build spec locally, it needed a fix and I did it

agl: what does ticking the block mean, do we trust it is correct

elundberg: it didn't work, but now it does

agl: this is probably good.

davidT: I agree
... I looked at it

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

agl: this HMAC secret at hardware layer. needs two touches.
... pondering this change say you may or may not be able to update at creation time. but for now may need two touches

akshay: when we did this, we didn't want silent. that is why UP was there
... from looking at this; I am wondering how this is different.

agl: i don't propose taking out the touch, but evaluate when it is created and you need a touch
... we could reference the CTAP spec, but think RPs don't know about it.
... it was never written down this stuff was encrypted.
... just use the names in CTAP2 would be reasonable.

akshay: do you think KDF output should be done at app or platform layer

agl: it should be a random string; but to strong feelings

jbradley: encryption was to protect secrets. we could open an attack

agl: we have a fix with salt
... using the same salt everywhere is likely what RPs would do. they just want a key

jbradley: they can store 256 key with a credential

agl: that works. advantage is that it works with currently deployed keys

akshay: regarding same salt. can we something like cred ID?

agl: interesting thought; yes, maybe

.,..means platform has to single step the credentials

jbradley: the cred that comes back is different based on UV or not

akshay: so we find credential, then we find corresponding salt, they authenticator signs it?

agl: there would be a list of salts
... i need to go back and change some things about this

shane: is protecting password managers in scope in this group.

agl: we think the web is a platform

jbradley: password managers is just one example on how to use this.

elundberg: how do we do encryption with FIDO is a common question

shane: I'm just an RP, this feels like propeller-heads are taking over

nickS: I can see blob being used outside PR extension

jbradley: would work with millions of keys in circulation
... we get password manager requests.

jeffH: if we want fundatmental fido2 and web authn to get set and utilized, we need a platform perspective

jbradley: if we could do end to end, maybe. but need to decrypt in browser. Might not be worth the extra complexity

agl: I have work to do on this PR.

tony: should this go in web app sec

jbradley: needs to talk to CTAP here, so I think it is here

me too

<nsteele> xD

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

tony: I am noting that we had closed and this is late.
... lets ask the group

elundburg: this is the recovery extension, we have had it reviewed; going through another peer review
... what this does, it is way to back up credentials
... so two authenticators with a cryptgraphic link, do paring once. put that in safe
... primary authenticator is used everywhere.
... while doing that you make backup credentials that can be used by backup authnticator
... works on resident credentials or not. the backup credentials are not discoverable
... that is how scheme works
... creds can be resident or non-resident
... browser folks should take a look. not much is done in the browser.

tnoy: would this be better in fido

elundburg: I don't think so. there are CTAP parts
... for initial set-up between authenticators. gives interop between vendors
... interface for RP needs to be in web authn

agl: this does tie us to eliptic curves?

elundburg: yes.
... but can have primary key that is RSA, but recovery key can be any other curve - used P256 now

<scribe> ...new key can be any key as well

agl: could we replicate this module in quantum...

elundburg: this key generation closely tied to eliptic curve
... nice thing is key generation is opaque to RP
... key agreement is up to authenticator.
... if we migrate to post-quantum, there won't be change in RP code.

tony: since we had this extension issue, will browser vendors implement this extension

agl: we need more detail. answer is maybe

akshay: need to look at it. have to consider the RP.

nickS: as RP, I would like to have account recovery flows easier for users.
... if this can be done by user and RP that is good

elundburg: that is a valid concern
... most of this can be implemented in libraries.
... but still is a bunch of UI stuff
... but verification logic can go in library

shane: as RP stakeholder. on flip side you sell keys as a pair with recovery key burnt into second key
... as RP, I find that more appealing

<nsteele> more rpeeling!

shane: throw myself under the bus here. the technical sophistication of audicence goes not and the usage seems to broaden

jbradley: I see how selling pairs of keys is attractive to some. If they lose a key they have to buy two more
... I imagine a key on phone lets you leave key in safe place
... I don't know we need only one recovery method
... can see andriod or apple doing something recovery in their platforms.

akshay: the proposal looks promising, I will take a second look.

jbradley: this is likely Level 3, we need more bits in CTAP

shane: I agree with that suggestion.
... perhaps ensure the RP and browsers work together.

tony: some possible interest in edge and chrome, so we have to hear from everyone - also apple and mozilla
... the other question, this is late from feature freeeze
... do we take this further in the group?

elundburg: that's fine

tony: do we want to see it in L2 or move it out

agl: i need a chance to read it.

tony: let's leave un-triaged.
... see what RPs, browser vendors and authenticator vendors.

jeffH: need a few weeks.

tony: leave in un-triage.

elundburg: not expecting L2.

tony: come back to it next week with updates.

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

jbradley: need some checks, it is short

tony: is this something that you want to clarify in L2

jbradley: WG said we had to replace what was removed.
... this was just a cleanup.
... cred props, i think that was right. AppID exclude needs a review
... that is #1401 tagged for L2

tony: open un-triaged issues
... well one. #1413

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

scribe: this is safety net

agl: I need to ask some Android folks

tony: I think this is someone asking a question. We will leave this un-triaged.
... for now

agl: I will look at this. it looks quite generic

tony: any issues to discuss? Open issues we have

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

tony: we should go over this

jeffH: just a low-level thing. low priority

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

scribe: #1422 is similar.
... it needs some polishign

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

scribe: we got a response

jeffH: we may need to update the build stuff.

tony: any other issues?
... nothing new on network transport

nickS: no

tony: adjourn

rrsagent: makes logs public

rrsagent: make logs public

rrsagent: draft minutes

Zakim: list attendees

Additonal attendees: jbradley, Adam Langley, Shane Weeden,

* webpage updated with minutes

This is scribe.perl Revision of Date 
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/1402/1401/
Default Present: jfontana, jeffh, elundberg, nsteele, jbarclay
Present: jfontana jeffh elundberg nsteele jbarclay
Regrets: wseltzer
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020May/0097.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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