Peter: I want to get rid of them. Browsers know that they're being driven by a human. Can browsers send a meaningful signal as part of form submission?

Rossen: that's a strong statement. The browser does not know that it's being driven by a user.

Tess: in trust token world - a trust token would be issue some number of trust tokens - it sees this <input type="token"> and sends one of these.

Peter: it doesn't intrinsically know but it can determine it once and then fill it into forms automatically. Do it in such a way that the browser can display a captcha.

Tess: trust token API that people are working on doesn't have any form submission integration .. this is a natural approach. However if a browser doesn't recognize a type value it displays it - but it could be set to display=none - it would be easy to polyfill.

Rossen: I agree with the premise of the issue. I want to see how it ties into identity... Stronger mechanisms that could be present to signal that a human is driving the browser. Reducing the repitiveness of capchas would be a huge win. Perhaps this is a case where the trust token is indefinite?

Dan: [raising the issue about fraudsters using farms of workers to mint 50 tokens at a time]

Rossen: ... the tokens need to be scoped at the session or something... it would be great to (a) tie it into user identity - verifiable identifier that says I'm logged into a session... browser and slack [running as electron app] - should use same underlying tech. I'm the same user. Can this be somehow associated with a larger scope session?

Rossen: where do we go from here?

[Tess left a comment and @-mentioned others]

Tess: Being worked on in WICG... some concern about the cryptography involved.

[some new comments]

Rossen: some folks have engaged from the HTML side.

Peter: good to get good feedback

Peter: we talked about maybe starting a community group or taking it to WICG

Rossen: I think what is being discussed here is great - in terms of how this might work. Ways to incorporate this back into form control management. Main point raised by Anne which still stands - we need the protocol underneath. I don't see anyone answering those question.

Peter: the proposal presumes trust tokens or something like it.

Rossen: Have you considered any other than trust token solutions? Any other identity solutions that might work?

Peter: something that a browser can send to asite.. ideally doesn't provide additional PII. Trust tokens fit the bill.

[discussion on who is in trust token work]

Dan: need for a workshop maybe? Engage with Wendy Seltzer to see if there is w3c "strategy" interest? [emails wendy]

Peter: we should let it percolate for a while...

Peter: Dan reached out to Wendy to see if there's any appetite for a workshop on this topic. As far as I know he haven't heard back yet.

Tess: Maybe the best thing to do is just to ping her again. It'll be tough to make progress on a CG or workshop without anybody in the driver's seat of this.

Deferred.

Peter: we talked about pinging Ping and we haven't heard anything back yet... Will ping again.

Tess: doesn't really make sense as a design review issue

Amy: agreed

Tess: mentioned in Trust Token API thread. Close?

Amy: check with Peter..