<inserted> scribenick: wseltzer
Nadalin: Welcome
... Goal of the meeting is to kick off Level 2
... make some decisions about work that would involve big changes
... so we're not dealing with big changes at the end
Nadalin: proposed by Rolf
... to date, I haven't heard support other than from Rolf
agl: 991 has some benefits
https://github.com/w3c/webauthn/issues/991
sbweeden: user experience
... inform user about site capabilities based upon what they register
... how do we help the user, who may not have resident key
john_bradley: agree we want to support it
... what would it actually mean
... in practice
christiaan: other side, wanting the option to say I forbid the making of a resident credential
johnbradley: different PR. don't have the option not to request a PIN
Nadalin: you have the potential metadata when you first register
johnbradley: after you register, you get metadata
<jfontana_> test
<jfontana_> Do you want to tag team scribe duties?
jcj: Browser finds out at make-credential
... RP finds out after registration
sbweeden: It's a UX issue
... As someone registering a key, I want the best possible experience
... Relying party doesn't know capabilities of my key before they call register
... RP wants passwordless, resident key, if they can
... but they'll take non-resident if that's all the user has.
... How can we get that?
christiaan: we raised this in a FIDO doc
Nadalin: We closed 987 after sbweeden opened it
<scribe> ... closed as a breaking change
agl: 987 is different, it's about RP detection
https://github.com/w3c/webauthn/issues/987
sbweeden: I want to ask for it, know what was done, so can use it later
christiaan: we can't adopt resident credentials until we have
alexei: I like this. let's do a PR
Nadalin: fairly big change to RPs
agl: we can do it in a way that doesn't require changes to RPs who don't care about it
Nadalin: could be a bad breaking change for existing RPs
agl: not if we're not silly
sbweeden: response too, how does the authenticator indicate what it actually did
Nadalin: JeffH is working on a PR
[discussion of timing of conference calls]
johnbradley: happy to work with JeffH and sbweeden
... I'm not sure about tri-state
Nadalin: want to avoid breaking RPs
sbweeden: raises a point about versioning the API
Nadalin: 476, JeffH suggests we close
jcj: I agree
https://github.com/w3c/webauthn/pull/476
johnbradley: too many options
Nadalin: closing
... We'll come back to 441 and 479
Nadalin: 408
https://github.com/w3c/webauthn/pull/408
agl: re UAF generally, only if there's someone prepared to argue for it
Nadalin: I've asked and haven't found an advocate
... propose to close the UAF issues, 407, 408
... if a supporter wants to put back, come argue for it
JeffH: sure
Nadalin: Closing 407, 408
Nadalin: 909
https://github.com/w3c/webauthn/pull/909
arnarb: ready from our point of view
Nadalin: do we expect browsers to support?
agl: we expect chrome to
jcj: we don't expect to implement in browser, but would pass through if natively supported
johnbradley: would you use on android?
alexei: lots of use cases
[discussion of non-credential-bound CABLE connection]
jeffh: nominally this is mergeable in the webauthn spec
Nadalin: we can't create normative extensions arbitrarily
jcj: a concern. what if the extension comes through and the browser drops it
... will that put users into confusing space
arnarb: if browser doesn't pass on cable registration session, RP will either have to fail or skip
christiaan: example of bank, if the data is available, can enable more use cases opportunistically
jcj: Thinking about the getassertion side
christiaan: we do lots of messaging in browser for the user, so the RP doesn't have to do it
... the browser, platform can give user better advice about what's available
arnarb: registration extension entirely handled by authenticator
Nadalin: does it cause confusion for user if register and can't use
arnarb: compare bluetooth key today, where can register with USB, use with bluetooth later
christiaan: I can register anything, and then show up later on a different machine where it's not avaialble
... the browser can be smart to make the right offer
Nadalin: just making sure we've got that case covered
christiaan: CABLE is a transport and it has extension data
... it only works when you send an allow list
Nadalin: where do we end up on 909?
jcj: not opposed
... worst case, we end up backing it out if there's not enough support
... we probably won't write code, but would pass through where available
david: prefer to wait until CABLE is exposed publicly
... it's currently only in FIDO
Nadalin: we had the same issue with hash
... if we put this in today, we're not defining CABLE, but an extension to use some functionality that could be defined elsewhere
... so here, saying create the framework. Look elsewhere for its implementatoin
... It's an optional extension.
david: concern, not objection
Nadalin: hearing no objections, some concern
... can we get a few more approvers to merge this?
... jeffh, jcj ?
jcj: I added an editorial comment
... once that's resolved, sure
Nadalin: please resolve jcj's comment
jcj: and expect me to raise an issue later if FIDO doesn't publish
... seems cool.
https://github.com/w3c/webauthn/pull/479
agl: In consumer context, this seems to add complexity
... don't see a reason to do this
... ways to filter
Nadalin: UAF had a policy language; this supplements
christiaan: objection
... don't see a use case for the consumer
... would you want RPs to be able to say what authenticators they accept?
Nadalin: Akshay has said he's not in favor
johnbradley: other ways for enterprise to guide users
jcj: All these selection things to avoid rejecting attestation after the fact
... what happens when we strip attestations, as Firefox will default
... You can do this after the fact.
... General use case should be as wide acceptance as possible
... Optimize for the general case
apowers: Amazon merchant use case
johnbradley: policy language not more usable
nsteele: most implementations not using AAGUID but certs
alexei: either browsers or websites have to tell users something didn't work
... RPs can do better at telling users what to do instead
apowers: browser in better postion to know what user has available
johnbradley: not necessarily, e.g. bluetooth
apowers: are you concerned from privacy perspective?
johnbradley: fingerprint vector
christiaan: and do we need it
apowers: high value consumer users
agl: don't add complexity for the edge case; you can do better UI elsewhere for important cases
... when we try to do things in browser UI, websites fight us on it
apowers: worried we're leaving a big chunk of the market
Nadalin: Any objections to closing 479?
... hearing none, closing.
... 441?
agl: close
jcj: same sort of thing
https://github.com/w3c/webauthn/issues/441
johnbradley: not useful except in very constrained environment where it's not needed
Nadalin: Any objection to closing?
<scribe> ... Closed.
Nadalin: that closes all the issues noted for the morning
... We kept 991, 909 open, and closed the others.
[lunch]
<inserted> scribenick: jfontana_
https://github.com/w3c/webauthn/issues/863
Kim: we want smarter UI. thinking
tony: this would be a change in error conditions
kim: at some point the spec supported this, not just the Windows case. The spec should accommodate both use cases.
Alexi: at some point browsers did not have UI for this so everything blinked.
Tony: still lot of value in the blinking
... value is showing authenticator is working
discussion
jbradley: on thing we are proposed to change with Cred API. There is no allow list. Can't tell if there is a credential
... the flows will be changing.
jcj_Moz: right now in Ffox, we blink everything. We want this to be the case. Leaving space for UX to be smarter is cool
... we should think about this from privacy angle.
... the user should still have to have some interaction
jbradely: has to be some kind of interaction
discussion: MSFT does not blink everything
jcj_MOZ: as long as we can ado both. logically we will settle on optimal thing.
Im: i think that is fine, previously it was either or.
[discussion on blinking on authenticator]
Kim: I think we will write a PR
Tony: is it for this issue. does it also include the solution to this issue
Kim: yes.
https://github.com/w3c/webauthn/issues/863
https://github.com/w3c/webauthn/issues/1147
jcj_moz
scribe: mozilla wants to do this in a way that is opt-in
AGL: Chrome position,too
christiaan: maybe there isa either or. a group policy or do it on the token
... I think the browser will be responsible in allowing this - in consultation with the user.
alexei: we need to do more research. Don't close, leave open
christiaan: we should add this in CTAP, and on web authn we can leave to policy
agl: I don't want this to happen, that users demand this. ....
jbradley: we are using pre-reg on tokens to get around this.
... in some instances.
... there are some down sides.
... works for some enterprises.
[discussion on credentials being made on token]
shane: think concept of enterprise can be expanded more broadly
... bank customer, assigned to an account. not just enterprises, it is bindings 1 to 1 , token to account
jbradley: you can do that manually.
... it is enterprise mind set. Credential that is important here.
alexei: exploring if we could get rid of individual attestation and do something else.
... hoping to come back and report what I learned with #1147
jbradley: having individual attestation is a challenge to not violate privacy.
shane: this is almost a contradiction to a run on serial numbers.
tom: it feels much like a credential.
... attestation seems like it is fit for account, is it member of authenticators I trust?
... this does not feel like attestation, feels like credentials; but not like the other credentials. feels like third thing.
[discussion on credential/attestation]
tony: alexei will look at this and come back with additional info.
https://github.com/w3c/webauthn/issues/1164
tony: there is a registry question
selfissue: the authors of the registry spec - JeffH primary- are working with IETF to finish making that an RFC.
... the pub deadline is Monday.
... I don't think there is biz case for adding to Web Auth,
tony: just let this happen on IANA?
seflissue: yes
jeffH: I think we are in agreement
https://github.com/w3c/webauthn/issues/1164
tony: do we let this happen by IANA also.
serlfissue: I would say yes.
... #1121 can use the registry that is being created by IANA
tony: this is likely how we should deal with any attestation we end up creating here.
https://github.com/w3c/webauthn/issues/978
tony: we need to write a PR.
... assigning to Elundberg
https://github.com/w3c/webauthn/issues/968
alexei: I made a PR to remove almost all SafetyNet references.
apowers: do you do IANA registration?
jeffH: yes.
tony: for safety net
selfissue: it will be registered.
... it is in IANA requirements for Level 1
apowers: I will look at #968 and close it.
arnar: we can find Android people to help close it.
apower: OK
... I will look at this are get back to baseline.
agl: these should be android problems, not web authn
tony: go to user verification isues.
https://github.com/w3c/webauthn/issues/1135
correct: https://github.com/w3c/webauthn/issues/1162
tony: keep this open and chip away at it.
https://github.com/w3c/webauthn/issues/1162
tony: think Mike had some issues.
... look and see if it addresses the issues
https://github.com/w3c/webauthn/pull/1118
tony: we don't have the ability to address these things?
jcj_moz: I think it is fine.
... the normative aspect is not in the spec
[discussion of #1118
selfissue: I am OK in merging #1118 and moving on
... adding the example, also helps, which is #1165
... I will reveiw 1165 and 1118.
jcj_moz: I will approve it.
tony: so we will close 1117, when 1118 is approved.
https://github.com/w3c/webauthn/pull/1118
correction: https://github.com/w3c/webauthn/issues/911
tony: to use feature policy, we just need a value.
agl: our web payments guys want i-frame support, how do we advance that.
jeffH: I have been chipping away on this with M. West
... we won't solve this today...
tony: we should try to influence the web app sec people in the direction we would like to see this go and to help move things along
jcj_moz: we should support permissions, feature policy does not
... if we have to make a choice, we should do permissions - for user interaction.
tony: asks if jcj_moz can work with web app sec
... we need the support which ever way it goes
agl: can we send a message to web app sec
wseltzer: I can send a message - needs to be a clear message.
jbradley: we need this to solve some issues - leaning toward permissions.
jcj_moz: looks like Ffox and safari and chrome have permissions - I can look into Edge
... all we have to do is define the string and refer to the document.
tony: we need web app sec credential piece
jeffH: we need to make something happen that is not awful
jbradley: let's inform the group.
selfissue: can this be put in the issue, agl?
tony: I will put a stake in the ground.
agl: we are looking for guidance...
tony: yes.
[break]
[discussion silent authenticator issues]
tony: not in authn, but are in CTAP
tony: wht do we eant ot do here.
<wseltzer> https://github.com/w3c/webauthn/issues/199
tony: they can create some security issues
... not seeing big demand. Google may have one.
tom: is there a use case
https://github.com/w3c/webauthn/issues/199
tom: what are the use cases just for color
selfissue: one co. want to put silent authenticator in racks fo machines and use it as unforgeable way
... there is nobody there for physical presence.
tony: there are payment issues, if transaction is of certain value may not do again the authentication ceremony
... I am not proposing for Web authn. just asking. JeffH opened this up.
tom: could I get the super cookie description
jbradley if you remove user consent for creating for getting cred. and allow remote RPs - they potentially it becomes way to tracking some.
toM: does not sound so much like a big issue
... when we clear cookies, I would no longer do no touch, I would do new touch.
... I think we know how to mitigate this issue
jbradley: lookingfor way around. lots of ways to create super cookeies. not the end of the world. but this is a privacy issue.
tom: I don't think it is good for any web standard to create some thing that may track people
... there are clear ways to attach silent or not-silent privacy controls.
... note that this is scary danger zone.
... and also I think we can probably rely on browsers to not create a super cookie
jbradley: maybe we need something like token binding.
jbradely: creds are not stored in the browser. they can be persisted over a long period of time
agl: I suggest close not action
apowers: we have lots of interest in here, rest api, alexa devices.
... you still want device to show the user is stillthere.
agl: ctap 2 will do this.
shane: what about browser sesssion scenario
jcj_moz: all of these things could be done in a session, we are really talking about having public key crypto version of that
... the continual consent actions of this, is thet one use case that makes sense. question, are we adding that much. How much difficulty do we add for small improvement in security
... we are really talking about something that can auto re-fresh cookies in environment where you are not regularly logging in
pamD: europeans will have something to say about this. PSD2
... the EBA specifies a time limit.
agl: does apowers example require the web?
apowers: if you sniff an entire session, can grab the cookies. ...
agl: ctap2 lets you do silent authenticators...
apowers: the primary use case for us is a ctap2 use case.
... but want this to apply through web as well.
agl: you want continues authentications, the worry.
apowers: compromise
jcj_moz: my question, where does this fit into a web worker?
... not trying to belittle apowers use case, just want to make sure we will use this if we implement
apwers: you dont' want to burn out your security key because every call goes thorugh it.
jcj_moz: on one hand we are saying we don't trust the web security model
... is this CTAP 2 over a separate session?
apowers: I don't like sessions, necessarily
jbradley: there is a spec there
apowers: token binding. :-)
tom: the log in solution will make sessions the weakest link.
apowers: that is philosophical
jbradely: if you exapnd web authn, it may become more confusin gto people.
... this ties sessions to devies.
apowers: conversation is do we have a good way of doing this
... do we kill this.
tony: this one gets to that point. lot to do to make it safe.
jbradley: being able to use CTAP to silently get credential, nothing to stop us from doing that ...
... noting stopping us in ctap or web authn for Oauth client authentication.
apowers: I think we can get a lot of use out of this
jcj_moz: my question, is why not do this in the forehground
jbradley: thye don't want to collect user consent
tom: they don't want a bad user experience
jcj_moz: the longest sessions we see are like New York Times.
... where is the ....how long can we run without user consent.
alexei: do we want to document the questions.
jcj_moz: is this a thing to discuss with web extensions working group.
tony: I would like to close this. if you want to open PR with clear solution to this problem..
... someone can do that.
tom: sounds like there is a plausible argument that is something web authn does not do.
tony: so suggestion is close and open if you have a plausible solution
... adam?
apowers: not excited about this
tony: what are we solving.
alexei: does this prevent us from doing this in the future.
tony: it says currently there is no proposed way to do this.
apowers: what is value prop of Level 2
tony: caBLE, making changes in CTAP, attestation.
... and more
agl: I think there are lots of bug fixes.
tom: if i think of level 2 as 1.1, is that a good mental model of the work being done
agl: that is what today is about
... I am not dissatisfied with Level 1
jbradley: would like to see Level 1 deployments...
apowers: lets educate people now, instead of blind siding that later.
jbradley: this could take two years to figure out, but if there are thing with impact in the short term, lets deal with those things - and then move to level 3
apowers, so silent authn goes to level 3
tom: that sounds reasonable.
... within that we establish a normative judgment what we think Level 2 ia about.
tony: so there is no time for a level 3 in the charter. so we would have to amend charter for level 3.
... we extended charter before
jeffH: we have done this before. We have a level 3 idea before we had new charter.
wseltzer: seem like a good thing to have things in a big bucket.
... we need understanding that it might not ever happen.
jcj_moz: I don't understand how to do this right now, but it would be cool to continue to kill cookies from the web.
... i just don't know how to get from here to there right now
... I have not had these discussion within mozilla
... should I go do that and think about getting rid of cookies.
agl: killing cookies is in the water for Google, but that is M. West's water
... he has at least three solutions.
apowers: can we send him an email
tony: maybe you have that conversation in web app sec. but not here.
... do it there.
... last topic of the day - discovering from device loss.
agl: we need it.
agl: our charter limits scope to level 2, but this is bigger and needs to get done.
tony: do we go with charter revision now, or run out current charter. it will be a formal process.
agl: current charter is a nice deadline.
wseltzer: w3c says it likes groups to come bac kto AC review for long charger extensions.
tony: likely we would need AC review
... do we want to discuss device loss
... I hear motion for level 3
... level 2 is what we want to do. it is not just refinement
... if the group says things are needed then we will work on it.
nick: some direction in the spec would be good re: device loss
tom: seems refinement is next step in level 1. that is valuable clarification. do we push to L3 if it is more than a refinement. let's make a note of where we are
jbradley: the stage seems to be lets put together some proposals.
... we should keep it on the roadmap and see if we can get it donw.
nick: one of first questions we hear is what if I lose my device.
jbradley: now solution is register multiple authenticators
nick: that is something.
shane: it does not have to be authenticator, it is account recovoery.
jbradley: we are loking at something that speaks to account recovery, but pre-mature how it would fit in web auth or elsewhere
jeffH: leave this issue open and tag with...
jbradley: there is a proposal from google, there are others, we need to decide what we might do at CTAP or at Web authn
agl: we have consensus of a model that works.
[google]
tony: so right now this is not tagged t the right level or milsestone. thisis not a working draft 01 issue
... we cna move to level 2, draft 2 or level 3
tom: is there a reference we can use for upstream change that is something we don't know what to do with.
... if we are close to draft and don't have ??? we can move it to a level 3
https://github.com/w3c/webauthn/issues/969
tony: moving to level 3
... level 2 01 and level 2 02
alexei: can I open issues.
tony: yes.
<wseltzer> https://github.com/w3c/webauthn/issues/1173
sure!
https://github.com/w3c/webauthn/issues/1173
<inserted> scribenick: wseltzer
jcj: just opened 1173
... against my previous arguments, because some RPs wanted this
... it's transitory, but several years likely
sbweeden: is it capability support, not just CTAP2?
jcj: but this isn't exposing user info, but just about platform capability
... only version of browser and OS
sbweeden: driver is RP's desire to deliver good UX
Nadalin: do you want L2?
jcj: this is about to ship in FF
johnbradley: they likely want resident credentials
agl: at which point does this become true
... among feature support
johnbradley: helping RPs to guide users to a viable combo
... but as you add feature detection, fingerprinting
arnarb: we need to know use cases better
agl: understand your need to do this
... and still think we should close as wontfix
tomlowenthal: if the answer is purely determined by UA string, then doesn't add to fingerprint surface
jcj: firefox doesn't return build number
... so we preferred to add this string than adding windows build number to UA
Nadalin: close, no action
Alexei: we've done a bit of thinking re incognito, clearing cookies, and what that means for the spec
... User should have a clear expectation
agl: touch ID. If you clear your state in chrome, you wipe out platform touch ID
... but not on windows
Nadalin: you can call API to reset TPM, but not delete individual credentials
alexei: one conception of private browsing session: what you do there disappears at the end of the session
... but not the case for platform authenticators
... how should we help user understand
johnbradley: should private mode use different RPIDs so credentials don't mysteriously cross over
jcj: but different RPID goes back to RP, to know you're in private mode
tomlowenthal: plausible that user thinks of credential like download more than like browsing
... but potential of revealing credential from non-private mode in private mode would be unfortunate
agl: we wrestle with thse issues. a group consensus would be interesting
johnbradley: I think people will be surprised
... if there's no allow list, and pick list shows two logins
alexei: how do we not unpleasantly surprise users?
jeffh: incognito/private browsing doesn't appear in credman
tomlowenthal: private browsing isn't specified in web standards; it's a browser choice
... browsers can make different reasonable choices
... user surprisal is right benchmark, but it doesn't work in private browsing mode because users confidently misdescribe that all the time
Nadalin: since we inherit from CredMan, we should deal with this question there
... other issues?
selfissued: Move Angelo to former editor status
Nadalin: currently we have Draft 1 L2 set for April 15
... ideally, be done with L2 by TPAC, September 16-20 2019
... I'm going to put in for a WebAuthn session there, in Fukuoka Japan
... there's a FIDO seminar the following week
... so I'm going to request meeting Thursday or Friday
... Trying to set a pace for us to finish L2 by TPAC
Nadalin: proposal to move the call 2 hours later
sbweeden: then I could make it
jcj: that's hard for Europe
Nadalin: we'll ask on the list
... polling to see if there are any objections in the room, and hearing none
[adjourned]