<weiler> no meeting next week. tpac in november.

<weiler> jfontana: still need a couple of charter votes.

<jeffh> https://github.com/w3c/webappsec-credential-management/pull/100#issuecomment-327968338

498

jeffh: Webauthn 498, CredMan PR 100
... still need more review

<Rolf> .. by credman folks

<jeffh> https://github.com/w3c/webauthn/pull/498#issuecomment-329175945

jeffh: Please review in the CredMan issue on PR100
... still need to look at Rolf's comment
... and then, if correct, apply same changes to getAssertion algo
... should be fairly smooth once nailed down.

Rolf: my comment relates to multiple sigs authenticator might create
... how to disambiguate credentials
... there was one proposal on the table, authenticators should sign all assertions

jeffh: could you edit your Aug 2 comment on #498 to add pointers to the issue

Rolf: I'm looking at that

jeffh: underway. We've made good progress
... and one Q from mkwst that I've asked about in PR 100

Rolf: relates to a FIDO CTAP discussion. I added a comment

jeffh: thanks

539

Rolf: I think it's ready to be merged

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

scribe: I think I addressed comments
... jeffh?

jeffh: I'll look after the call

544

jfontana: Angelo is working on PR 544 and 545

Rolf: comments addressed on 544; waiting for conflict resolution

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

Angelo: how we should abort when viewport is not visible
... on the way

jfontana: 545? privacy issues with icon URL?

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

Angelo: JC was arguing to remove the icon
... gain privacy, lose complexity
... counter-argument, that it's better than old UI and not much privacy difference

christiaan: gaining privacy because when you fetch icons, you fetch all at once, giving correlation possibility
... showing that all accounts are on the same authenticator

Rolf: we discussed different ways of doing
... instead of putting remote URL, use image URI.
... include the image directly, so you don't have the remote fetch

@@: that has implications for limited capability authenticator

john_bradley: I take it that image would need to be stored on the key
... which has impact on storage

@@: alternative is just to drop it.

scribe: and users use username to disambiguate account

Rolf: and htat reduces complexity re updating images
... I'm fine with that

@@: what I learned from identity people, account chooser UI is stronger because it has image

john_bradley: depends which account chooser you're talking about

@@: if someone wants to take iconURL out, feel free to do so

scribe: the PR here is about ensuring it's secure
... so you don't end up with mixed content
... Maybe merge this PR, and Alexei, fi you wnat to take it out, make a new PR

angelo: this PR is that URL must be secure
... so you don't end up with mixed content

Rolf: Alexei's arguemnt is that if you want to guard against correlation by same RP, this doesn't help

angelo: true

john_bradley: won't browser cache so it won't go back every time?

@@: probably, but platform specific

Rolf: but if you move ext authenticator to different platform, there won't be a cache yet

jfontana: how shall we proceed? merge and then have Alexei proceed with separate PR?

angelo: that's what I'd suggest, leaving issue 139 open
... CTAP doesn't say you need stored image

Alexei: fine

jfontana: why don't you merge, and we'll come back to it at next meeting

558

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

christiaan: when making credential, you pass in a number of parameters
... including userid we though would be usable as reference
... unique index
... credential ID is not guaranteed to be unique
... and it's hard for us to change the indexes in our database to refer to crednetial ID
... we were hoping to get this in

john_bradley: initially skeptical, but since it's provided by RP and going back to RP, problem overstated
... I favor the PR. we may want to clarify that it's not a userid in the traditional sense
... but rather a correlation handle provided by the RP

gmandyam: I understand the convenience; I'd hope that authenticators could create unique public keys

Alexei: we looked at keyhandles we have in our DB
... (the U2F name for credential IDs)
... and we found collisions
... so while we might hope for uniqueness, there's not assured compliance
... Secondly, whenever you create secondary index for DB, you need global consistency
... you get more latency, another rpc
... Requiring this db index creates added complexity

gmandyam: most concerning that you're finding clashes in public key

@@: key handle isn't necessarily the public key

alexei: nothing prevents people generating bad private/ i believe -- eg u2f tokens place the private key in the keyhandle keys
... I looked at raw values
... whatever you use, I think you have the same issue
... you can't make guarantees without a code audit
... we shouldn't build dbs depending on indices you don't control
... adds latency
... and causing reimplementation of dbs for everyone using spec

@@MS: agree

scribe: probably we should say some # of bytes
... e.g. 16 minimum
... re userid, beneficial for everyone to return to RP
... so I agree with Alexei

gmandyam: not all client-side rngs are created equal

<apowers_> I joined late -- did we talk about how awesome the interop was yesterday?

jfontana: do we have an agreement yet?

jeffh: I'd like to review it, not for a few days

jyasskin: some discussion at end of thread re restricting to multi-factor authenticator
... either call out in privacy considerations, or restrict to those that actually check the user
... if it's being used as a second factor, you can't just use it to login

alexei: what any sane RP will do is store not "userid" in that field, but add a nonce, encrypt it
... so every time you call same "userid" will get different result

@@: should displayname be there....?

scribe: No

jeffh: note that consideration as a separate isseu, implementation and securtiy considerations

christiaan: if it doesn't have pin unlock

@@: I'll file a new issue to put that into privacy considerations

john_bradley: should we use another name to say people shouldn't put userid directly into that field?

@@: agree

john_bradley: give that advice

jeffh: agree

jyasskin: I'm currently typng an issue

jfontana: we'll continue this discussion

jeffh: in webauthn spec side, it's just called ID

john_bradley: that's fine. just need appropriate privay consids re what you put in that field

jeffh: it gets called user.id in some places

<weiler> JBradley: will you open an issue to add that?

571

jfontana: 571, Dirk isn't here

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

christiaan: this is about cleanup
... think it's ready to be merged

jeffh: fine by me

jfontana: let's merge

572

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

christiaan: minor

jeffh: without investigating details, looks fine to me

jfontana: go ahead and merge

573

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

christiaan: another clarification

jeffh: fine to me

jfontana: merge

Any open issues to discuss?

jfontana: hearing none
... remember to have your AC reps cast votes for revised ccharter

apowers: did we talk about interop?
... We had a bunch of people get togheter to test WD05
... good interop between browsers and servers
... we have a new version of WPT tools that haven't been checked in yet
... hoping to do PR soon
... good milestone, good implementations are in the works.

[adjourned]

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/external/different/
Succeeded: s/538/558/
Succeeded: s/staded/stated/
Succeeded: s/public/private/ i believe -- eg u2f tokens place the private key in the keyhandle/
Present: jeffh gmandyam wseltzer weiler akshay battre christiaan_goog rolf jbradley kpaulh jyasskin apowers alexei Ibrahim
Regrets: nadalin
No ScribeNick specified.  Guessing ScribeNick: wseltzer
Inferring Scribes: wseltzer
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Sep/0328.html
Found Date: 20 Sep 2017
Guessing minutes URL: http://www.w3.org/2017/09/20-webauthn-minutes.html
People with action items: