Web Authentication WG F2F -- 20 Sep 2019

<jcj_moz> rmondello FB7299047 is the feedback ID

Logistics, Introductions, and Agenda

tony: today agenda . pull request, transport, open issues, account recovery. joint meeting with accessible platform architecture
... had some join t meetings this week with web apymetnst WG, trying to figure out how to best integrate web authn into web payments
... want one authentication scheme
... web payments people have signed up and we will add from Web Authn
... will have docomo presentation. will provide feedback on the specifications.
... Moriyama-san will lead off the day with Max Hata.

moriyama-san: thanks WG for its work. we have three deployments of web authn/fido2
... gomi-san is also here from yahoo japan.
... Rual mendez is here from ISR.

<Jiewen> wseltzer thanks.

moriyama-san: isr deployed web authn
... also looking at Office 365 and web authn
... they have 4 OEM and vendors, with security key and Win Hello .
... also Fijitsu, palm reader based on web authn

raul: thanks for protocol web authn. getting on with move from passwords

presenting demo

max: looking at web authn and parts of the eco system
... providing feedback , uneven support, end-users want frictionless experience,
... uneven support. showing implementation status.
... for simple and frictionless user experience. looking at this from RP perspective. there are problems for this market.
... issues with selecting authenticator attachments. each deployment has slightly differences.
... lack of best practices is another concern
... these are high level experiences. and RP looking for answers.
... lack of best practices, is another concern that the WG should consider.
... also extensions, transactions confirmation is something that Japan group would want.

akshay: looking at high level feedback concerns.
... uneven support is something that will take time to work out.

max: if we want to see this is 2020, we should ber honing the spec now.

akshay: there are forcing issues everywhere.
... end user experience. comments. selecting UV method. the issues is the RP does not know what is on the machine. User have to select
... selecting authnticator. we have a reasonable UX on Windows. one thing that is interesting, saying we don't like security keys or we only like platform authenticator, so there, we leopt it as choice
... third point on UX. all the combinations. we have two solutions we are working on with another vendor
... we are planning to talk about some of these options in the near future.
... extensions. we probably are not going to pre-determine the authenticator selector

max: my request is to take care of some of these issues as they effect many, many consumers.

jbradley: what you are asking is to supress options for authenticator selection.
... RPs getting involved in that will cause more confusion than not.

max: you have seen the consumers here in Fukuoka, but have can I show the value of these things., but it is a tough sell with these issues.
... some RPs specify platform. this may be different in enterprise market, it is difficult.

jbradley: but if uses creates authenticator on a device, they willl get that platform authenticator, but does not cover case where that authenticator is specified.

shin: think this is only for mobile

gomi-san: Yahoo Japan also released mobile solutions. if we support external authenticators, customers may be confused.

akshay: it is troublijng what yo uare saying. because user does not understand security key, so we don't use them at all.

bradley: given that mobile OS is questions - which is andorid. Then explore makeing android as seamless as possible.

arnard: we have not explored this

bradley: your problem is that something that does not work. we shold support empty allow lists before we add some other feature.

<inserted> slides from Hata-san and Moriyama-san on deployment feedback

<Jiewen> ^^^

Ricky: we have all heard the problem, it makes sense. go back and think about what has shipped and see how to correct. you can't turn off a patform authenticator, but it has to have option to be a roaming authenticator

tony: it is not just a knob to turn.
... not just a knob to turn, .
... we need to understand the use cases and see how to approach.
... we apprciate the feedback and deployment status. important to the spec.
... move to pull requests and issues
... #1256

<wseltzer> https://github.com/w3c/webauthn/pulls

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

jeffH: may ned tot dive into this is web app sec WG
... want to get at least to a pull request.

tony: timeframe?

jeffH: in next week or so in Web App Sec.

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

selfissue: I reviewed that.

jeffh: I thought I approved this.
... I will merge, all things have passed

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

tony: editorial

jeffH: I need to review.

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

jeffH: ready to go

tony: akshay do you want to look.

tnoY: go ahead and merge.

tony: lets prioritize the ones Ricky has open, .

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

ricky: filed this because working on security keys over web authn .
... it is looking like lightning is shaping up to have same characteristics, this might not be a a useful

jbradley: hopefully you are right and it won't be relevant to webkit.
... there will be devices pre-6s and before and iPad series that won't get web authn in web kit
... for those people and apps like dashlane, Brave, others that have directly integrated with the iPod extension framework.
... they want to know it is plausible to use these transports.
... do you want use to plug in key when you know there is nothing there.
... google wants optimize that experience, using smart lock, that will focus on only creds that work

arnard: this is used to optimize useability
... we don't have different flavors for authenticators

jbradley: it is slightly more complicated as I see it.
... a native app on iOS cannot talk to a HID device. needs to use special chip in lighnign connnector
... more important thing is logical protocol ccccccjekcfhehdchjrnbjhjbvuiinibfbiikbiubjkh
... i have no affinity to call it lightning.
... we can change the string name, also.

ricky: I think I can deal with destiny of this issue. In future we might have distinction with WebKit. It might be worth revisiting this when all things are in place

jbradley: I thnk we need some hint to show functionality of the authenticator

jeffH: close this or punt.

tony: don't close this now, but look at it later in Level 2 work

Arnar: from google point of view, we do need it. we don't care what it is called. I agree we should revisit when world is in different state. and we can think about UX

<Jiewen> Sounds good to me.

ricky: sounds good

jeffH: in terms of process, we should initiate CR and PR milestones and punt this to one of those

jcj_moz: if we put this into spec, would we remove in 2024? and what happens when we remove transport.

<Zakim> jcj_moz, you wanted to ask about the future

arnar. it is not a tranport. but we would reference the former language. it will be a type of thing hhat can be use.

jbradley: maybe just say this is a bit and use this...
... because credentials will exist with that string.

jcj_moz: we will have to deprecate things at some point.

tony: I will move this over to the CR milestone.

https://github.com/w3c/webauthn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+1293

ricky: have had great conversation on this.
... seems there are in fact flows that would be severely compromised.
... in having a user gesture requirement
... we have listened to the feedback, but if conversation only about make credential it is less important than before.

jbradley: question will be like with DUO, maybe a hidden I-frame with cross origin, may force another OK button.
... I see at moment it is not an issues, but when we get to cross domain stuff. I am sympathic to a gesture

Tony: so don't do anything with make credential .'

akshay: lets talk to see if we can do something different, .

<Zakim> jcj_moz, you wanted to bring up bad actors

Nick: it would break more things.

jcj_moz: kicking can down the road not terrible, but need to keep thinking how to solve this issue. don't ignore, but not a hurry.
... what does iFrame activation mean? those sorts of things.

tony: should it be level 2 or 3

jcj_moz: feel at some point this will be urgent.

tony: this is going to be potential breaking change.

ricy: i agree with JC. there are tricks and malicious things that can happen in browser. sometimes we can use gestures. some need more subtle UIs
... sooner rather than later is best to look if it could be a breaking change

jbradley: what would be do and give RPs options.

tony: I moved it to WD-03in level 2

ricky: for clarification. we are hestitant to let third party i-frames to make credential without a user gesture.

<wseltzer> [20 min break]

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

ricky: there are many use cases for web authN. the intention of this device is to bypass 2-factor, as opposed to enrolling this key to supplant a backend system. given that how do we phrase questions.

do yo want to use face ID or touch ID to sign into this device in the future.

scribe: we think user can understand that
... but what will change. in this case we want to reduce the number of accidents that can happen in this
... may be possible to solve with language in the spec that can help end users. but clarity in API of the high level options is key

rolf: sometimes settings or other things change, how do you deal with it.

ricky: this credential is the only one available. can user option optimize the experience.
... and what is on going experience.

rolf: things may change over timem, but you don't care right now.

ricky: yes.

<Max> q

jbradley: having some higher level things to express. if we had some higher level objective then the broswer would have better change to set reasonable defaults
... I am willing to support this.

tony: see as normative change is spec?

bradley: see this as normative change.

tony: how are you thinking about this

bradley: think there is a need for a normative change here.

jcj_moz: if we can indicate the high level use case. can we take out all old flags.
... seems like positive change.

tony: that is big change...authenticator

jcj_moz: doesn't have to be.

ricky: this clears up the user experience in the future.

<Zakim> jcj_moz, you wanted to discuss deprecating all the existing options in favor of this

jeffH: we think we can boil this down to use cases. concerned about baking this in at this stage in the spec
... things may change down the road.

arnar: the API we have arrived at is complex. it would be great to have a better API, but we don't wnat to make an API that has hard coded use cases
... want to see what people can do.
... what if option conflicts with other settings.
... the real questions is do we want on deep re-thinking of API
... should we think of better API now

akshay: there are various ways to do this. non-resident keys, can be passwordless or not. I will at some time flip over options when users get more experience.
... what does User verification mean? what is preferred situation.
... these are not the only corner cases out here.
... all the magic happens here with make credentials.
... can we have an option parameter as helping function, giving direction.

max: I agree with program statement. the web authn provides rich set of options, but just options
... if you want solution, that is not straight forward.
... difficult for people to come in late and see how options put together.
... there are many options.
... we think we need to have 3 -4 -5 use cases and come up with solutions. a cook book
... think that is what needs to be done for this specification.
... this may be easier than normative changes.

rolf: we should come up with a better approach. resolving is tough
... maybe look at concrete examples. can we do something at the UI
... there is a lot of guessing. an api that tell me what to ask for is more help in near term.

nick: we are generally supportive of this change
... it is pretty challenging to intuit what RPs need
... do we pass a "moral judgment"
... do we give Devs ability to do chalnges

rickey

scribe: I've heard there are context scenarioes, I ack that. the most sophisticated RPs need to be able to break molds

<jeffh> ....ie there may be conflicting options

scribe: I am interested in taking on conflicting options
... I heard we are still in experiment phase. think that is true. it might support claim that we may be early in this game.
... we don't have the mass deployment. we are learning and experimenting, but some good use cases.
... whiile still adding more knobs
... the api design. what would be fantasitic is to make common options known, and the tough ones possible.
... can we do both?
... heard ask for concrete examples. if user agent knows intention. authenticator could present options based on that
... point is to avoid negative experience.

<Zakim> jcj_moz, you wanted to consider adding new types to replace PublicKeyCredential interface for higher-level api-ness

jcj_moz: to questions about how to do.
... what about defining another top-level interface. say public key cred.
... instead of all the richness, when avail in windows object could do standard call
... we could do that with any of the use cases we are talking about.
... set a precedent for adding more powerful features and how to do that.

<jcj_moz> ack

jeffH: i will try to build on ricky and JC. to entertain major changes, need to craft spec text and have concrete ideas.
... one way to do that is , to get an easier to use api
... shooting from hip, layer something on current spec
... we seem to agree with need more explanation on this, and we have example code.
... it should reflect use cases.
... lot of devs will cut and paste.

jbradley: if i understand ricky correctly, there are two issues
... better options are needed.
... maybe there is some interm step for RPs with helper app
... can we experiment? before we bake something else into API
... having a flag could give the browser some hint to goal, like ricky said.
... may want to separate these things.

akshay: 3 things we can do
... specify journeys and options
... second thing. having normative thing that conflicts with existing options will not work .
... other thing is dev needs to understand how things are set.

ricky: the over debating here. what we need to do is meet more and more goals.
... if we entertain something one or more surgical or tactical
... if the outcome is more destructive after the fact, that might be interesting to have in the conversation.
... we want things to map on to each other. destructive style enrollment

jeffH: so we are postulating a Level 3.
... specs have done this, as they learn they build on top of the spec

tony: so go to 1300 to do the clairfications. this beign the normative change. but we need some text and proposals .
... to move the current forward. does it fit in level 2 or after.
... that is my summary.

jeffH: issue #1292 stays on Level 2, but if it stalls, we go to level 3

akshay: I like this idea at this point.

ricky: keeping issue open is good, with understanding we will work for progress.
... what do skeptical folks want to see as progress.

tony: i imagine the conflicts that have been raised.

jcj_moz: which ones.
... yes? my idea fixes that.

akshay: lookng at all the flows we are talking about.

ricky: initial take on this needs to differentiate , user nameless vs. having a name.

rtolf: if you could carve out needs for recovery scenarioes. how do those fit in
... today you can not derive any check on the account recovery.
... avoid conflicts as much as we can

jeffh: interesting. submit an issue on recovery and submit to #1292 to cross link

ricky: destructive I metioned, is ilmportant to us in the end game.
... what happens if everything goes extremely well. users have fewer passwords.
... if we know the intention will replace an existing cred. we need recovery and portability

tony: any further discussion.

akshay: is this also a case to get assertion.

jcj_moz: i have not figured out how we message between get vs. create. but it is a distinct possibility if we create a layer.
... what do we do that is different. I don't know.

ricky: we think about this in terms of make credential. for now. there may be need an make cred time.
... but so far unexplored.

jcj_moz: I would not make this a mis-match

tony: conclude that discussion, now go into https://github.com/w3c/webauthn/issues/1296
... akshay have you looked at this one.

lskahay: i think we can figure this out at the browser level.

tony: keep this open and on wd02

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

akshay: if we need new timeouts. we can make recommendations.

<Zakim> jcj_moz, you wanted to discuss modalness

jcj_moz: when we put this together. I might not put restrictions on this

akshay: you have to give the RP something

tony: so akshay will get a PR created.

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

tonhy: this is the icon issue.
... discussion is split here.

jcj_moz: would any authenticator download an icon and show it.
... these display things trigger discussion on how will they be used for phishing.
... this all seems like a bad idea now
... mark them deprecated and strip from spec in level 3. Displays names, icon s
... maybe not names.

tony: say depreciate in level 2 and remove in level 3

no implementations.

tony: would help authenticator vendors if deprecated.

jbradley: yes, it is kind of pointless
... if we had a clear indication from UI producers that they would not show it, we would show

tony: will JC write a PR that deprecates this?

jcj_moz: absolutely

jbradley: we had some test with account chooser

aksahy: I would go for deprecating.

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

tonuy: mike, where do we stand.

selfissue: I need to create the pr. an editorial change

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

tony: might be blocked
... nothing further until FIDO meets.

jeffH: yes.

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

akshay: this needs to happen
... I will look at it.

tony: jeffH: you are working on the cred man stuff. #1004, #911, #876

<wseltzer> [lunch break for 1 hour, resuming with network transport]

Lunch. Will begin again in an hour (1pm, Japan time).

JBarcley: here to talk about network transport for Web Authn
... 4 transports in web authn
... we are extending cable
... caBLEW
... caBLE

jBarclay: ... Binding by pre sharing a key
... we are talking caBLE transprot extended beyond BLE.
... this could be a fall back if BLE is not possible
... why desirable? low common denominator. there are similar things on market Crypton for example

NicK: allows for novel solutions, makes ecosystem safer, low common denominator for compatibility
... we think people will build interfaces that people like

jbarclay: this is not the first time to talk network based transport.
... we think it is time to think about this - in a safe way.
... think about BLE and HTTPS.
... BLE requires proximity, not so with network transport
... think we can still maintain phishing resistance.
... if you look at caBLE 2 seeks to establish cryptography connection.
... bottom line is maintain phishing resistance.
... if you look at binding. two main purpsoes. establish credentials and connect to the correct party
... there is sharing of secret but not over the network.. then handshake that happens over BLE ( but can do it over network)
... we are proposing once binding stablished , we can use a message passer to carry the CTAP2

NickM: we had an umn-session on Wednesday
... this does not have to be part of FIDO2 spec, does not have to speak CTAP.
... components needed. serialization. replace all ArrayedBuffers. with URL safe base 64-encoding strings
... Need some form of configuration.
... we could have a delgated authenticator extension.

demo

scribe: we are curious if this is compelling

max: show us a typical use case.

nickM: mobile, typically there is authenticator there.

tony: this is one way cloud services can participate.
... could do in the cloud, that is where credential is.

arnar: looks cool
... a few things. boils down to binding moment. I have trusted device, and I have a new fresh browser session and bless it as a good browser
... the way I would phish binding moment is , I give victim a web page. I don't call web authn at all. on backend, I get QR code that I screen shot and show to user.
... they create a binding between their authenticator and bind authenticator to bad guy
... the binding moment in caBLE requires a local connection
... two things to know, adds to attack surface.
... the second thing, there is locality strength may be eroded. do we need controls.
... final comment. don't understand how binding moment works in cloud. want to see how that works.

jbradley: if we can get over the initial pairing and securing that, this, in general is a good idea. would rather do it in CTAP
... as way of extending the USB connector, then maybe.
... if we can solve the binding issue, then worthwhile.
... has some dangerous security gotchas if we get it wrong.

akshay: what about scenario offline. you fallback to something local?

nickM: yes.

Gerhard: do you need to consider binding and authenticator here?
... what about in Open Banking, to re-authorize.

nickM: once a binding is established with all the properties we need, security wise it does not matter the transport.

gerhard: maybe breaking it into two issues progress may be quicker.

nickM: good point
... we can probably do binding without locality.
... but the other is transport doesn't matter when security is established.

arnar: I want to discuss the binding without phishing.
... how do you managed the bindings.
... what am I binding to, what is the data model

jeffH: on caBLE, we render the QR code in browser UI.

arnar: we ask if we want to maintain the binding.

jbradley: chance of bad things go up as you do more things with the binding

Jbarclay: we look at the alternative, can we do this in a safe as possible way, it would increase adoption.

nickM: in our proto-types, trusted device is the mobile phone.

jcj_MOZ: what do we do with attestation with this model.

<Arnar> ac Max

<Zakim> jcj_moz, you wanted to ask about transformations between the browser and the authenticator

nickM: we established an end ot end channel with the browser and autheticator software on the phone.

jcj_moz: worry about the app on the phone.

arnar: the attestation format will be signed

jcjc_moz: not helpful at get credential time.

jbradley: as these things evolve, it may not be able to proxy through a phone. so thte app on the phone may not talk U2F directly to the key\
... have to look at issues like this.
... let the RP-ID soft all that out on some level.

jcj_moz: the implementations of this would be OS and not random app.

rolf: what does this solve that caBLE 2 does not

arnar: about half of all windows machines.

tony: no USB ports in gov. agencies.

jbradley: how do you make web authn work in certain environments
... older window machines do not work well with BLE.

tony: USB might not be available.

nickM: main claim. if we can establish a binding, it does not have to be over https, but it does not have to be BLE.

rolf: this is getting more complex now.
... what are the transports, is a key question

Max: I have the same concerns on proximity.
... we hav to review all the assumptions.

tony: probably depends on where this gets done. bradley is talking about doing it in CTAP
... where is it a better fit?
... best fit
... this seems viable. some concerns. and see how next week goes at FIDO Plenary.

jbarclay: thanks for the feedback

akshay: I am not sure on this at this point. looks like saying bluetooth is flaky, lets add this. then we have to old machines.
... I think we have proximity concerns. I would like to discuss at CTAP and more integration with caBLE.

arnar: think about the use cases, not just the architecture.

tony: move to next agenda item.

jeffH: in agenda. the virtual authenticator PR is just waiting for review by akshay

ttony: yes. we talked about that

tony: continue with issues, then account recovery, then break, the accessibility joint meeting.
... jeffH has pile of editorial issues

jeffH: feedback, is maybe. yes, do it. etc. If you want to comment, please pile on. I don't think we are holding up on a second working draft for these editorial issues.

tonyh: so close technical issues, and punt editorial to wd-03
... some un-triaged issues to go through

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

akshay: this looks like web auth should be about web platform and try not to define other thngs

tony: so you want it closed.

jeffh: I agree this is about validation
... maybe we include a note in RP validation rules, might be appropriate.
... then explain what is happening.

jcj_moz: this is a reference to FIDO spec. maybe this is out of scope for our document. So look there.

jbradley: some explanation some place , just tell people to buy a server...

tony: so where do we go? people heading more towards CTAP - and closing this with no explination.

jcj_moz: ctap is not the right place.

tony: the platform vendors?
... it is pointer to talk to platform vendors.

akshay: web authn is not the place to do this

jcj_moz: there were these rules for uaf and u2f

tony: is anyone adverse to creating a PR here.

jcj_moz: I will look at this.

tony: shane should create this PR.

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

akshay: this looks solid to me.

jcj-mOZ: this is a web test issue that Boris found. we need a web test.
... its a bug we have to define what should happen
... presumably I have to work with the Chrome team. then we need a web platform test that none of us will run for quite awhile.

<Jiewen> Certainly we do need wpt. Will be glad to work on it as well.

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

jcj-moz: it has come up that we should set expectations before assumptions are made about web authen
... let everyone understand, thou shalt not.
... I will write the PR.

jbradley: this may block some of 3D Secure.
... there is another idea how we might do delegation.

johnApple: we support this.

tony: to get clarificaiton. you want to prohibit in hidden i-frames.

johnApple: yes.

jbradley: not against this, but might surprise some people. It will break some demos

chairs: we never received a response

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

Jbradley and Rolf debating topic

arnar: this is a can of worms. different for different RP. leave this to the RPs?

jeffH: I will metion, we are moving much of the UI into the platform, so issue for us - not RP

Rolf: what is the magic.
... no one thinks putting a finger on a sensor is security.
... people do not know what it means to "register your fingerpirnt"
... this is a hard problem to solve. but we have to do it. or we get crappy solutions in the market.

tony: there is not a clear way forward for this one.

rolf: we need some hint for what to prompt for.

jbradley: we don't need more logos

jcj_moz: we got rid of the lock icon on the browser.

tony: what do we do with this one.
... not sure we want more complexity. my suggestion is to close this one.

jcj_moz: not sure this helps

akshay: without this help, RP has to do a lot of work to guide the user.
... we still have to solve the localization issues.

jbarclay: one other thing to add, this will become less of an issue, but need to bridge the gap now.

rolf: this is more about an abstract term to use for that thing (say biometric).
... asking to register a FIDO authenticator makes no sense to lots of people
... if we don't solve, people will make up there own terms.

jcj_moz: think we need a brand name.
... maybe with Firefox in the name.

johnApple: I want to understand what is going on?
... do you think that the icon gets put into some way?

jcj_moz: not what I was saying but like your idea.

johnApple: if we did anything like this, it has to be opaque to the page
... we need some pixels.

next agenda item - account recovery

<jeffh> https://unicode.org/emoji/charts/emoji-list.html

presenters: emil lundberg, john Bradley

jbradley: I don't want to call this account recovery, this is way to backup your authenticator
... just to set expectations
... there is issue. can't always get to second authenticator. have to enroll somehow.
... bakcups are problematic.
... simple solution, is export key, but that is privacy killer
... the rub is how do we allow for statically registration on two keysl
... working on how to recover credential
... this involves crptography.
... we are getting reviews from orgs. like Mozilla
... this is not entirely new crypto. uses elliptic curves
... use the EC, to create a key that is exported to backup authenticator to main authenticator but different derived key is given to each arty can not be correlated.
... registratioin with RP. use backup key and go through RP
... what we have been trying to do, trying to generalize this for any CTAP2 device.
... the goal is any to any credential recovery system
... this bypasses a lot of the need for account recovery, you can recover from a second device without a "formal" account recovery
... may have 3 actions. generate, recover, state

arnar: can I fabricate key that another key can create a new key and be used.
... this is sensitive. it does not allow you to creates backups that any RP would accept.

weiler: does this overide existing creds

elundberg: what id someone gets my key and adds a bunch of creds. then could people steal keys again.

sam: when you do the recovery, do you invalidate the primary key

elundberg: each backup is bound to one main credential

sam: so if I wanted two recovery creds, I would need two main as well,.

elundberg: no

jbradley: you have one key be the backup to the other one, theoretically

sam: there is a use case I am interested in is delegation.

jbradley: it does not support that by design.
... we want this to be obvious that if someone gets ahold of your main key that you notice that a new one has been created.
... we want to meet the FIDO security requirements.

elundberg: we want it to be obvious when the backup credential is used.

jbradley: no shared exported secrets. automatically invalidate main cred

attestation

key agreemtn scheme opaque to client and RP

recovery cred cannot bve resident key

still per-RP recovery

jcj_moz: the server cannot invalidate a resident key

elundberg: you need an allow list for the backup

jbradley: open questions. how to manage the backup seeds in the browser. can you edit backups. have some tamper protection/prevention
... still details to sort through
... there is a draft.

tony: what do you want as next step.

jbradley: will discuss at FIDO meeting next week.

Janina: ... we have been looking at captcha
... we are looking at Web Authn and DIDs group
... can we expand what it means to authenticate.
... maybe just not individual, but other services

tony: did you sit in on the trust tokens work

Jaina: yes, we wrote some things up in our paper.

tony: that might have a play in here.

Jaina: we had five things in our doc. the bottomline. with accessibility online it will impact somebody
... keep in as much privacy and security as you can.
... Google has a nice solution, but there are various "costs"
... one piece of advice is scale. lightweight might do you.
... the more we can do to drop inactivity is good.
... www.w3c.org/TR/turingtest/
... we may do a minor point rev
... can we help along those lines with what you are doing. We are interested in that.

tony: we need to read this over and see where we can help

jcj_moz: I see a section using a public key to prove human-ness.
... not probably what you are looking for, but maybe you could use web authentication or user presence, user verfiication
... UV could be a problem in PIN mode.

nickM: user presence could be adequate for many uses.

tony: we can measure for a user

janina: fingerprint don't work so good for older people

tony: we could look over paper. see if anything we have in our spec to help. Then maybe get back together with you guys.

jcj_moz: would be interesting to get Google Captcha team to talk to us
... if we could be sure that the public key was used once and proof of authenticator and not a tracking token
... not sure how to balance.

tony: Dan anything from DIDs side.

<scribe> unknown: if web authn is handling it that might be sufficient, but maybe DIDs fits in some place.

moriyama-san: docomo, we are trying to enable to support for fingerprint or other biometric device.
... so web authn could do some more, but already it enables to support variety of authenticators.

jbradley: I can imagine that there might be opportunity to adding a new parameter to web authen to add a disposable credential

tony: cold be just a trust token.

jbradely: not all FIDO authenticators require hardware
... we could just do a user presence check. not beyond the realm of possibility.

akshay: could be non-resident key. it can be temporary.
... we have something coming with FIDO 2

jbradley: would need some attestation to make sure it is a FIDO authenticator that tests user presence (UP)

janina: don't you have a service that would do some work on your behalf.

jbradely: I would not require a third party,

jcj_moz: there is a model for building a specific authenticator

jbradley: don't want to add tracking capabilities.
... and add policy to sort things out.

jcj_moz: a web authn flow that does not produce a credential, could be used.
... you can be the RP ID with junk on the end

jbradley: use CRTAP 2 authenticator and randomize the ID

jcj_moz: need to get with the Captcha folks.

arnar: this assume that almost everybody has an authenticator that can generate attestation
... it need a lot of people to make it a viable system.

jcj_moz: with v3 it should be better than v2

janina: we heard from the v2 guys and did not say anything about data collection

jeffh: you could fake the touch

arnar: we can set up contacts with the captcha team. but I am having a hard time to see how it scales.

jcj_moz: don't think captcha 3 won't worth on Tor Browser
... will work on Tor Browser

DBurnett: we were looking at number of approaches today to person-hood and building a credential. but was moer looking at how to use and what could go wrong,
... I am just mentioning it.
... you can show unique personhood, without exposing the individual
... ,my interest in this, i believe VC and DIDs, if it takes off, we could end up with identifiers that are not servicing their intended purpose.

jeffH: is there an action for us.

janina: we want to see what we can add to this paper, but want to get it done. a dot rev is not beyond the realm of possibility.
... want you all to think about what you might come up with.
... we have put in a lot of work. OCR is getting better, but we need something better.
... we are not the experts on how to make it work

jeffH: you want to kill captcha

janian: interactive captcha is not meeting our needs.
... thank you very much .

end

- DRAFT -

Web Authentication WG F2F

20 Sep 2019

Attendees

Contents

Logistics, Introductions, and Agenda

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output