<weiler> scribe: weiler

Review of Web Authentication specification

<scribe> Meeting: Privacy IG special meeting to review Web Authentication specification

<jeffh> https://w3c.github.io/webauthn/

<jeffh> fido priv principals: https://fidoalliance.org/wp-content/uploads/2014/12/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf

<christine> jeff giving an overview of the FIDO principles re privacy

<christine> point 5 relates to linkability

<christine> point 8 relates to users viewing and managing authenticators

<christine> facilitated by protocol but up to implementators to take advantage of that

jnovak: suggest adding a statement to the spec that these principles are guiding it.

<christine> jason - may be helpful to indicate in spec that these principles are guiding development of the spec so know to go look at doc

<christine> jeff submitting issue, should if does not

<christine> tony : privacy considerations is still work in progress

<christine> will clean up before CR

<christine> tests available to make sure did not violate privacy principles of FIDO

<christine> jeff: FIDO has a certified compliance program

<christine> tony: note FIDO has further restrictions not relevant to this spec

<christine> tony: this effort to get APIs acceptable by major browser vendors so could deliver javascript

<christine> as far as the privacy issues, FIDO is currently addressing in implementation in field

<christine> taking that experience to apply here

<christine> here a set of use cases deemed within scope of APi

<christine> we do have things like attestations and identifiers that we have privacy considerations

<christine> major privacy concern is linkability

<christine> adopted basic credential interface from credential api from webappsec

<christine> main interface into credential object

<jeffh> s/#create-passwordcredential//

<christine> jason: re linkability and attestations - re attestations types

<christine> tony: does not exclude others from being defined

<christine> jason: questions about basic attestation and self attestation and privac properties

<jeffh> "large anonymity set"

<christine> is there a mininium number of authenticators with attestation to get privacy property?

<christine> adam: 100,000 and FIDO says will disable tokens if don't

<christine> jason: why not in spec?

<christine> adam: questions of jurisdictions?

<christine> consider separate from W3C work

<christine> tony: where FIDO certification would take place

<christine> jason: UAs would maintain own list of authenticators above 100,000

<christine> adam: block list rather than white list

<christine> FIDO also has a metadata service

<christine> jason: re self-attestation

<christine> in my read, authenticator uses private key to generate attestation signature - could there be linkability issues?

<christine> jeff: credential private key, is specific to relying party so no linkability across relying parties - attestation is optional

<christine> default is none

<christine> recently added to spec

<christine> clarifying, relying parties can indicate whether or not to receive attestation, default is not to receive

christine: when we have cred w/ private key generating attestation sig... is unique to the RP.... is there any issue of linkability across sites within one RP?

agl: cred private keys should be freshly generated for every reg. a givien RP can query whether a token recognizes a credential. browsers will have to mitigate this.
... could discover that same token has creds for two accounts and try to get the other one.

christine: sounds like you're trying to minimize this risk with timeouts. should that risk be documented?

agl: an implementation could subtlely get this wrong and not notice.

christine: valuable to document

weiler: +1

christine: should 100k be in the spec? could have devices that aren't fido devices trying to use this? should we add non-normative guidance?

agl: no objection to mentioning that.

jnovak: we've been talking about linkability across RPs; not sure we've talked about linkablity across accounts on same authenticator

<christine> jason: we have been talking about linkability across relying parties, but what about linkability across accounts on a single authenticator with a single replying party

<christine> (handing over scribing to you sam)

jnovak: issues 204 and 140.

<christine> adam: linkability we discussed earlier, re-probing

<christine> adam: RP probing credential associated with it, but a user it does not know

<christine> need to be careful not to distinguish by timing

<christine> jason: additional questions re state of spec and certain ideas are trending

<christine> allowing for siltent authenticators? that a user does not have to interact with to release the credential, some issues open and discussion about whether in V1 or V2

<christine> if allowed, raises issues of user knowledge and trackability

<christine> tony: majority of group and probably browser vendors think a bad thing to do in Web, but FIDO has another piece that may allow it to work

<christine> jeff: they are in the wild in UAF, implemented by Intel, user notification, in this deployment and implementation, alerted by RP

<christine> want to ascertain whether still you periodically, and are you okay with that? an example for, say, fraud reduction

<christine> adam: not part of spec

<christine> jeff; not now

<christine> tony: microsoft not consider now

<christine> jason: would we allow for cross-origin iframes to call for authenticator

<christine> perhaps impact is changed if silent authenticators not in play for web at moment

<christine> jeff: they are orthogonal but intersect

<christine> rpid is the effective top level domain of the entity that created the top level context

<christine> etld plus 1

<christine> jason: ...

<christine> jeff: handled at credential management level

<jnovak> -q

https://w3c.github.io/webauthn/#sctn-location-extension

<christine> sam: in same vein as silent authenticators, location extension - does it need separate user consent? e.g. on things on location

<christine> adam: geolocation API at W3C - would not let it leak silently, same level of consent for any other way to get location

<christine> sam: other things sensitive?

<christine> jeff: I think we have it covered

<christine> adam: signature counter, fairly minor

<christine> jeff: specifically call out user consent for location extension in 11.2

<christine> sam: not in the extension section

<christine> jeff: if not, need to add to other one, please file an issue

<christine> sam: asking new faces to look at spec, Google, Microsoft etc. good for fine tooth comb

<christine> jason: thanks everyone

<christine> hope to better understand interplay require user verification and user presence - section 6.2.1

<christine> not sure where see necessarily enforced, false in 6.2.7 (e.g.)

<christine> 6.2.2.7

<christine> what is the enforcement relation and mechanism?

<christine> adam: don't see explict reject, could add a step, if two are equal could abort, would address concern?

<christine> jason: yes, I think it would

<christine> jeff: this is a nuanced thing, don't think we have clarify, could be seen as subset as under verification, would not reject

<christine> adam: but defined that way

<christine> jeff: had concern about defn

<christine> adam: could change definition to address

<christine> jeff: sounds like an issue to file

<christine> potentially related to other issues

<christine> adam: will see if fits an existing issu

<scribe> chair: christine

<tara> Thank you also (from late arrival)!

<christine> takeaways - some things to add to privacy considerations, some open issues already to address the things we noted in the discussion

<christine> some things to reference, e.g. privacy principles, size of authenticator batch, etc. (see minutes)

<christine> jeff: ground breaking spec - perhaps a note for implementation kind of things, scattered in spec, whether leave as is or move, or do both

<christine> for discussion in WG

<scribe> scribe: christine

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)

FAILED: s/#create-passwordcredential//
Succeeded: s/register/metadata service/
Present: weiler jeffh agl nadalin christine jnovak SusanPandy MaryHodder
Regrets: wseltzer
Found Scribe: weiler
Inferring ScribeNick: weiler
Found Scribe: christine
Scribes: weiler, christine
Found Date: 11 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.)