**Session Date/Time:** 22 Jul 2026 07:00

[00:00:05] **Thibault Meunier**: It's such a hobby. It's Saturday.

[00:00:10] **Justin Richer**: Like, it's gonna repair Okay. Yeah.

[00:00:20] **David Schinazi**: Minutes. But This meeting will start soon. Please take your seats. Morning.

[00:00:47] **Raffat**: Having fun so far?

[00:01:12] **David Schinazi**: I had I did wasn't able to attend the signed meeting, but I remember talking with you about it a while back. I don't know how it's evolved since then. I mean, it seemed like a reasonable concept. Nope. Cool.

[00:01:32] **Eric Rescorla**: Oh, that's good.

[00:01:38] **David Schinazi**: Oh, that's really cool. Yeah. Let's roll it.

[00:01:41] **Raffat**: Let me get going.

[00:01:42] **David Schinazi**: Oh, that's awesome. Alright. Can someone in the back of the room please close the doors and me on on both sides? Thanks. Alright. Good morning, everyone in Vienna. Good afternoon, good evening, good middle of the night to everyone else in the world. This is the web bot auth working group, and we are your chairs, Raffat and David Schinazi. And yeah. Next slide, please. Alright. This is the note well. If you are in this room, virtual or IRL, if you're in this room, you have agreed to the note well, and in particular, you will respect the ITF code of conduct. And thank you for that. Next. A few tips. We are using the Meet Echo tool. If you wanna speak at the microphone, you have to join the virtual queue. And if you are remote, please make sure to use headsets. We've had some bad echo recently otherwise. Alright. Recently, we had a web bot off interim in, if I remember correctly, April to decide the two possible approaches for this work. So as a reminder, the charter of Web BotAuth is specifically around bots, which we define as agents or or user agents or programs that run-in someone's infrastructure, like in a data center somewhere. It is kinda separate from something that would be running on your laptop. So it could be a crawler for search. It could be a crawler for AI training, but it is running in the cloud in someone's dedicated infrastructure. That's kind of this delineation around web bot auth. For other things such as identifying agents running locally, that's other working groups. This is kind of how our charter was defined. Within this, we discussed two options. One is, do we identify bots? As in, do we have a cryptographic mechanism that says this is this bot, or do we have an anonymous mechanism that helps us to show and demonstrate the properties of bots? The result of that interim and the ensuing working group mailing list conversation was that we would pursue both of these options in parallel. So our agenda for today is that we are gonna have a presentation from Thibault on the identifying option and then a presentation from Ecker on the anonymous option. One slight note, Ecker's option is dependent on a new technology called Moll. We had a side meeting on Moll yesterday that I think went reasonably well. Obviously, it's a new technology. There's a lot of complicated questions to answer, but there was a sense that we could answer them over time. So we're looking at maybe it becoming a boff at the next ITF. So we could start discussing this even if it has a dependency on other work that would happen in a different potential working group. And then after those two presentations, we'll have one from Gary about the crawler best practices document. That one doesn't fit in our charter, so we don't we have no design to adopt it, but we think it is relevant to the conversation and thought it would be good to spend a little bit of time if we have the time. So it's listed as time permits. Does anyone want to bash the agenda? It's been done before in this working group. Wow. Sometimes quite severe. Indeed. Alright. In that case, Thibault, you're up.

[00:05:58] **Raffat**: Okay. Gonna

[00:05:59] **David Schinazi**: Yeah. I'm checking. Clicker. Yeah. Take it off the stand. It's easier.

[00:06:05] **Thibault Meunier**: I think now it's okay.

[00:06:06] **David Schinazi**: No? Well, because that way, if you wanna look that way, it's easier if you're hold it.

[00:06:10] **Thibault Meunier**: Oh, yes. Because we're very, very close. Okay.

[00:06:12] **Raffat**: Okay. Can I look?

[00:06:14] **Richard Barnes**: I have yeah.

[00:06:14] **Mike Bishop**: I have the screen here. Alright. Let's see how that goes.

[00:06:17] **Thibault Meunier**: Okay. Thanks to the chairs for the introduction. Hi, everyone. So like I'm Thibault. And today, we'll be presenting some of the work that we've done with, like, Sender on an individual draft we have, which is HTTP message Message Signatures for automated traffic. We have, I think, forty minutes for this slot. The goal is really not for me to, like, talk through these, like, through through these forty minutes, but really to have, like, a discussion, like, with the working group to understand if, like, the document that we have is actually, like, in, like, the right shape and, like, the right direction for something that, like, the working group would consider. And that said, let's move to, like, a recap of the problem that, like, we're trying to solve. Bots and origin have been relying on, like, imperfect signal to, like, meet with each other. They've been relying on, like, IP addresses, user agent, reverse DNS, fingerprint, pre shared key sometimes. And, really, none of these signal have been, like, very practical and have served neither the origin nor the clients very well. The server, they get unreliable information that is hard to act on, and sometimes it, like, might change based on, like, a client misconfiguration. And at the same time, bots might get impersonated. They, like, have a poor story for, like, IP mobility, and they have a hard time sharing IP addresses with other bots behind the same network. And, therefore, this bring us to this draft and, like, what we're trying to achieve. I will reuse some of the vocabulary that, like, was discussed on the mailing list and, like, that was sharpened. So, like, two objectives that we have and is the continuity of bot trust across request and over time and also an optional binding to another anchor, such as a domain name as presented in the draft. I will highlight that we have a couple of constraints. Of course, we want, like, the system to be secure and efficient, and, like, there are couple of other constraints that, like, would be cross cutting across the draft. I want to highlight two constraints, which I think are, like, very important and relevant to, like, how this draft was designed. We want to preserve the simplicity of usage for bots, and we want to preserve the simplicity of actions for websites. At the same time, we really focus on, like, having no pre established relationship between these two entities so that we act on that. If we try to make a bit of a concrete example, today, a site can grab its logs for, like, IP addresses and user agent. These are information which are available in, like, website software and something which bots tend to send as well. With these drafts, we tend to provide a bit more, like, guarantee so that we can grab for a verified a verified handle, g b a key ID, or a domain that has been cryptographically binded. The mechanisms through which we do that is a signed request, which is an HTTP message signature, which is defined in RFC ninety four twenty one. As David mentioned, there's a presentation that, like, comes after, which is about Anonymous Bot Authentication. And I tried to, like, highlight and, like, take a a diagram which was presented in April in our April interim by Dick, and and we have two axes. You have in a way, have the self issued versus third party claims, and you could have a public name or you could not also not have a public name. The presentation in, like, these drafts is the clicker works, yes, really fits in the self issued, bucket. For self issued buckets, when there's no public name associated, we will have an opaque value, which is a pseudonym and the key ID in our case. When there is a name, this is provided by domain binding. And I really want to highlight that I do think both of these approaches should be anonymous authentication or the self issue track, are very valuable and complementary because, like, they target slightly different use cases. In all cases, the participation would be voluntary, not sending a signal in the case of anonymous or not anonymous case would remain a valid state, and the protocol and the draft that we have cannot really define origin policies that are applied. This is something that, like, origin would have to decide. As part and, like, following, like, the last meeting that we had in person, Mark volunteered to make a use case draft, and I think it's been, like, discussed quite a lot in this group. I won't go through all of the use cases, but at Broad, they fit into, like, two categories. There's, like, site use cases and bot use cases. For site use cases, it would like to mitigate volumetric attract. It would like to be able to, like, classify traffic. And, like, by classify traffic, I mean, based on, like, the behavior that they observe. When at the same time, both have, like, real use cases to make, like, IP address mobility easier. They would like to work on shared IP or con conveying contextual information. For these drafts specifically, there are things which are out of scope, but which are not described in the use cases. This draft does not aim to tackle end user authentication. These are addressed by, like, all the work and all the working group. And we also do not try and do not claim that, like, we will solve the anonymous authentication problem. That's something which, like, Ecker's draft, like, does well and goes through. If I try to bind these use cases and how they are realized by the draft, if I take mitigating volumetric abuse, well, the origin can, like, rate limit on the verified handle. You can rate limit on the key ID, and, like, that's really the cheapest mode that, like, can realize this use case. If I take a bot use case a bit further down the line, IP address mobility or, like, shared IP addresses, well, this is core to the draft. The signature does not depend on the IP address, and therefore, we enjoy IP mobility or shared IP properties. One other thing I want to point is, like, some of the use cases are realized by the draft, but not with the opaque mode, and they require domain binding. This is a case for conveying contextual information, which would be provided by, like, a verified signature agent and some headers, and therefore, they do fit in the domain mode. Great. So I think we've went a bit through the objective of what we're trying to solve. The shape of the request is very similar to, like, what has been presented in the draft before. You have the agent in the origin. They do exchange some cryptographic key material, and this is not a pre established relationship. It's more that, like, in order to be able to validate the request cryptographically, the origin needs to have the necessary cryptographic material to actually validate that request. One that has been done, the agent sends a request with, like, three headers, a signature, a signature input, and a signature agent, and the content of, like, this header is described on the next slide. The signature agent tries to act as a discovery hint that the client control. As we said, the client the origin needs to have some cryptographic key material in order to be able to validate the client's request and needs to obtain that cryptographic key material. The way it obtains it doesn't confer trust, but the way we do that here is my signature agent, which is a structured field directory. You have the label, sig one in this case, and you have the value, which is example.com. Then another thing that we define for, like, these these draft is signature input parameters, which are covered by the signature. HTTP message signature defines a whole set of parameters, but not not all of them are, like, core and required to achieve the use case, at least for this draft. There are a couple of components which are required, such as, like, authority or target URI, created, expire, key ID, which is a JWK thumbprint, so we it provides some global uniqueness, and we have a tag to scope this signature specific to, like, this draft, which is web portals. Mhmm. There are some parameters which are also optional or, like, in should, such as, like, the signature agent or the. That's part of, like, one of the thing in the input that, like, I would have for the working group is that, are these optional parameters? Should they be optional, or should should they actually fall into, like, what's mandated to be compatible and compliant with the protocol? And finally, we have the signature, which is what is being validated based on all the input that we've discussed. This all goes, and, like, in the interaction into three layers. We have request authentication, which is like the signed request, and it proves that the sender hold the key that they're signing the request with. If you have the same key ID, it means you have the same key, and therefore, we achieve continuity. Then you have discovery, which is how does the verifier find the key so that they can actually, like, validate the request which is being presented. This is provided by the signature agent, at least recommended, but the draft also discussed that, like, the keys could be found out of band via public list or any other mechanism. One thing which is important is that, like, the discovery mechanism here does not confer trust. It's like required sync that is needed by the protocol in order to validate the request, but the mechanisms for which discovery happen does not confer trust. If we want to confer trust, one of the things that could happen is, like, you would have a binding. And so, like, what is the key tied to? In the opaque mode, well, it's tied to nothing. It's just like a regular key ID. However, when you have a directory of a TLS and, like, a signed directory of a TLS, the binding is a domain. Also binding, and there's been a couple which have been discussed on the list, like GNSsec or CMI do, etcetera, would fit in future draft. If we try to highlight a bit how, like, these two binding mode works, we have, like, opaque value and domain binding. Focusing on opaque value first, the anchor for opaque value is a key. It serves for continuity based on the local policy, and there's no infrastructure really needed. This is something that, like, the client can, like, self issue and let go with it. Of course, the re rotation story means that, like, if I have a new key, I have a new identifier in this case. And the failure is, like, if I lose a key or my key is compromised, well, I'm forced to rotate and therefore, like, lose a continuity that is provided, but that seemed to be sufficient in a couple of cases. Then for the domain binding, well, in this case, the anchor is a domain, and in the current draft, it's, like, anchored on the WebPKI. The function which it serves is to allow a policy to be attached and, like, bound to that domain. The infrastructure is, like, slightly more elaborate because we need the domain and a well known over TLS. This is infrastructure which is, like, well understood by a lot of clients, and that does seem to be, like, rather reasonable to go with. Finally, the rotation story is, like, better than, like, what we had with the opaque value because with the directory over TLS, the trust persists as long as we have, like, the directory and a cross rotation. An unreachable directory should be because the server is down or because I just sell the domain means that, like, I will, like, have my my my trust rotated here. Eka, is it something, queuing for at the end of the presentation or right now?

[00:17:41] **Eric Rescorla**: I'm not sure. So let let me try, and you feel free to stop me and tell me later. So it seems to me like you actually have three modes. Namely, you have a mode where you just stuff the key in a data URI, and that really doesn't allow rotation at all. You have a a mode where it's attached to an arbitrary URI that you can't infer any semantics from, and then you have one where it's attached to domain, you construct the well known from. Right? And is that is that correct?

[00:18:07] **Thibault Meunier**: So I think it was correct as, like, the draft is published on the data tracker. The latest PR removes the data URI because it has not been seen using practice, and therefore, it, like, cleans it to two modes only.

[00:18:19] **Eric Rescorla**: Okay. But then in the second mode, don't you have the same problem of the unreachable directory?

[00:18:25] **Thibault Meunier**: The second mode, you mean the opaque binding when you have, like, the signature agent hosted at URI?

[00:18:31] **Eric Rescorla**: Yeah. No. UI that has no no that has no defined semantics.

[00:18:35] **Thibault Meunier**: Yeah. If, like, if you have a signature, you advertise a signature agent for, like, discovery of keys at a URL and this URL is unavailable, then a, a server that, like, cannot access this URI cannot retrieve the key, and therefore cannot validate the request.

[00:18:52] **Eric Rescorla**: Right. So I just think this table is wrong is what I'm saying. The the the the the the if the second column is if this first column, the ones that are under a peak value is actually URI a peak URI, then you can have rotation, but you but you are but you but but you are the keyless to compromise problem. Got a regional directory problem. Right?

[00:19:12] **Thibault Meunier**: I think this is more something that, like, is not covered on the table. The table isn't that doesn't discuss discovery. It covers in terms of, like, once you have the key material and, like, how you do the binding, what is your rotation story, and what is the function served?

[00:19:26] **Eric Rescorla**: Okay. I I think we can oh, we could show this out later. I just was confused.

[00:19:30] **Thibault Meunier**: Okay. Makes sense. Thank you. Great. Very quickly, if we go over, like, the flows and, like, how is the draft going through, I'm a client. I'm reaching out to an origin. I make one request, two requests, three requests, four requests. And at some point, the origin, like, notices that, like, something's happening because, like, I don't know, they see a spike in CPUs. They see, like, more memory, more resource usage, and they start to look at their logs. In this case, the origin identifies that, like, the key ID is unknown. It will fetch the key material from the URL, retrieve the directory, validate the signature. This will prove possession, and then it can apply the policy. I think this goes back, like, to one of the like, Eka's question that like, what Eka presented here. The moment where I need to retrieve the key material, if, like, the server isn't available, well, the key ID stays unknown. Then once I have retrieved the key material associated to the key ID, when I receive the new request, I'm able to validate the request signature instantly. If the same key is provided, it means I have continuity through that, and I can apply local policy. For domain binding, the only thing which is added is that, the the fetch and the retrieval of the key material happens through, like, a well known. The directory is signed, so it's scoped to a specific authority. The origin can, like, validate both the directory signature and, like, at the moment they cache the key. It binds the key ID to the directory, and therefore, like, the origin kinda, like, rinse and repeat the process that was presented before. One of the key question that I think was started by, like, Martin on the list in terms of, like, what is, like, the identifier? What is, like, the trust model that we have for for for for for for this draft. I have, like, purpose on text, like, in PR one one hundred four, and I will, like, walk you through a few changes that are coming into the draft based, like, on the learning from this PR. We have two modes that, like, use the same wire format. The bots can choose whether to bind or not to bind the key ID to a directory, and the verifier can choose if they want to rely on the signed directory or not. In opaque mode, the key alone is the anchor, and new key means you have a new identifier. The signature agents provide some key material. It does not confer trust. It may confer trust in case of domain binding, where the verifier on the domain must validate that directory binding with TLS plus some signature of the directory. Some of the observation that we have from deployment, because this draft has been, like, deployed by bots and server of various sizes. Should they be big or should they be small? Both for bots and and for servers, actually. We have seen multiple open source implementation, which are the only one which, like, would be openly available even though we are aware of, like, a couple of private proprietary and private implementation as well. It's in TypeScript, in Rust. There are also, like, some binding and plugin for KADI, for Apache, for WordPress, and therefore, the implementation has has been rather vibrant on that side. The signing at the HTTP layer seemed to have eased deployment because it doesn't require any modification of the TLS stack, and it works through CDN and proxies, meaning that, like, CDN and proxies can, like, transparently reprovide the inputs and the signature which have been provided so that the origin can make their own policy choices as well. It is extensible with request semantics, and we'd see a couple of extension in other protocols that build on top of that. And finally, one thing which I we want to, like, like, have is, in draft dash o four, we've changed the signature agent from, like, a structured field string to a structured field directory. This allowed for multiple signature agents to be provided on the same request. At the same time, we're seeing both version appearing in deployment, even for new deployments. And that's something which is, like, worth noticing because, like, the two versions actually constitute main compatible change. Finally, we're getting to the last part, which I think would be the discussion that, like, we will have. This draft define one protocol with two modes rather than, like, two distinct protocol. In opaque mode, the rotation is left to the mechanism. We don't provide a rotation story beyond you rotate, you have a new identifier. The draft also defined one binding, which is a directory of a TLS. It leaves all the binding to also like, to separate document. There's been discussion on DNSSEC. Maybe, like, this is an interesting binding for the group. It's not defined in this draft. The question I have for the group is, like, is this the right shape for working group document that we would consider down the line? And that's it. Any question?

[00:24:21] **David Schinazi**: Thanks, Thibault. So to kinda reassert what Thibault was just saying, as a group, we reach rough consensus on advancing a solution to the bot for that identifies bot, and we're trying to ascertain whether the working group thinks this is a good starting point for that. We're not saying that everyone agrees with everything in this draft. Just, like, is this a good start? So the queue's open for discussion. I'm sorry if I'm pronouncing it wrong. Mike?

[00:24:57] **Raffat**: No.

[00:25:03] **Eric Rescorla**: Okay.

[00:25:05] **Presenter**: Just a clarifying question. I might have missed something. But, why don't you want to sign the content digest and content length?

[00:25:15] **Thibault Meunier**: Yes. This could be interesting, like, addition. The main reason we don't sign, like, content digest and content length is both for performance reason and because, like, these are not widely available in deployment. This might be interesting, but, like, not necessary for, like, what we're trying to provide.

[00:25:36] **Eric Rescorla**: Yeah. So I I I wanna come back to the discussion we were having earlier. I think it's a miss so as I understand it, the only modes you're you're currently supporting with this PR involve the client providing some way of identifying a URL, the server going to that URL, retrieving the key, and using that key. Right? There's no way to put the key in line. Right?

[00:26:00] **Thibault Meunier**: No. In this PR, we don't have the key in band with the request.

[00:26:05] **Eric Rescorla**: Right. So I guess I don't I guess I don't think of these as opaque versus can you go back to the previous previous slide, the one that had the the the sorry. Two more.

[00:26:22] **Raffat**: Yep. Maybe. The one that had

[00:26:23] **Eric Rescorla**: the sort of, like, two modes. I'm sorry. I I that that that that that that's fine. You have the the summary is fine. This one? The summary. The summary. Forward one more. There we go. So you say one protocol with two modes. Right? Yes. So your client is opaque and directory over TLS. Right? But these both involve going to the server and doing a TLS fetch. Right? It's just a matter of what the URI is and how it's constructed. Right? Like, in one case, it's a the the the client provides the URI. In the second case, the client provides a domain name that you use to construct a well known. Right? Yes. So I guess, I think this is almost exactly the same thing, technically. And the only difference is is is is one bound is is one come come with some form of endorsement from the site because it's been well known, and therefore isn't just a random URI on the site that has has real semantics? Right?

[00:27:18] **Thibault Meunier**: So if I'm trying to rephrase here, in both cases, the signature agent serves as, a hint, for, like, the discovery. Indeed, if you have the key locally, you don't have to fetch it. If you don't have the key, you fetch them from the URL. Right. So

[00:27:39] **Eric Rescorla**: okay. So, I mean I mean so so I I guess I guess I just think these are one thing, basically. Right? And I understand why you want I understand why you want two ways of making the URL, but I just think, like, you're making them sound very different in your presentation, but they're actually authentical. The only difference is at the very end of the day, do you get to claim it's the domain that endorsed it or this is just some string? Right? You still have why can't you have rotation with the, why can't you have rotation perfectly well with the one where the person has the URL? Do you I mean, you think you can't do a rotation if there's opaque mode. Right? But why?

[00:28:14] **Thibault Meunier**: I think you could do rotation when, like, you refetch a key ID. The thing is it would not be bound to the same identifier.

[00:28:22] **Eric Rescorla**: But but I guess that's that's that's what I'm getting at. Like, in the in in the, in the in the version where you have, like, directory you're directory over TLS. Right? I go to the well known, and there's, like, a set of keys. Right? And what I'm saying is do the one where I give you the UI the exact same way. I go to the UI, and there's a set of keys, and then rotation will work fine. And and then the only difference, again, is kind further domain endorsed it versus, like, kind for and further example.com/ekr/1234 endorsed it. But, like, that's, like, not that has no protocol implications at all. It's purely a rotational issue.

[00:28:57] **Thibault Meunier**: I think, like, the key difference here is, like, in the opaque mode, I mean, you can do rotation, but, like, what is implied by the rotation is, like, distinct from, like, what is implied by, like, the domain binding. In the opaque mode, when you do the rotation, the identifier that you have, which is, the key ID changes, while when you're doing Good.

[00:29:16] **Eric Rescorla**: I'm saying I'm saying use the URI as identifier.

[00:29:19] **Thibault Meunier**: Okay.

[00:29:20] **Eric Rescorla**: The the the UI is identifier, and then rotation will persist, which is what you want. But, I mean, I guess my point

[00:29:25] **Raffat**: is that that that that the

[00:29:27] **Eric Rescorla**: the notion of of opaque is you have a pseudonymous identifier over time. And, and you're saying it's the key, but I'm saying it's the URI. And if you use the URI, then it will survive q rotation, which is good because you get repetition over time. And the only difference is it's not it's not bound to say, like, ours if I'm not common, Dorset, is saying something some URL which I can interpret in Dorset. So I think that would be Yeah.

[00:29:48] **Thibault Meunier**: It doesn't it doesn't provide, like, the continuity of trust, which we have across identifiers.

[00:29:54] **Eric Rescorla**: No. No. It it that that does. That's what I'm saying. It doesn't provide the continuity of naming. That's what I'm that's I I think Justin wants to say maybe maybe make the same point. If if if so, maybe I should just get out of line, because I think I'm not making it very effectively.

[00:30:09] **Raffat**: Okay. Go ahead.

[00:30:11] **Justin Richer**: Hi. Justin Richer. Ecker's right. Okay. So at the end of the day, if you're going and fetching a URL, something different can come back from that URL. That's how the web works. That's key rotation. That's what OpenID Connect itself is based on in its entire key rotation policy in the world. And that doesn't even have to be domain bound because you can have different endpoints and all all sorts of weird stuff. Anyway, so fundamentally, I I I came up to say a couple of things. One, fundamentally, yeah, this is about basically binding a fetchable type key discovery mechanism to a signature at the end of the day. That's sort of the the core mechanic that I see here. That's that's a useful thing. It is something we very explicitly kept out of HTTP signatures for a lot of really good reasons. So, yeah, I would love to see a layering of that, and I think it does help address part of the use cases that Web BotAuth has. Second point that I wanted to make is that you've got some pretty bad holes of your usage of HTTP message signatures in the spec itself. And if this gets adopted, I'm happy to provide that feedback and stuff like that. I only just read the latest draft this morning as I was sitting here, so I don't have a complete picture of whether or not the draft is dependent on those holes being there. If it is, then, yeah, please don't start here. If it is not dependent on those holes and those are things we can patch, then the idea of this is how we introduce a set of key material for the party that's presenting a assigned request seems reasonable. I will also add one last point. I have use cases where presenting keys by value, what is implied by the opaque mode here but is not delivered by it, is is actually super, super useful. And so I would I I need something that solves that as well. I'm gonna be presenting a very bad take on it at the OAuth working group on Friday because I needed something to fill in for for that use case. And I know that there's been something that's been proposed to HTTP BIS as well that does both in a single header and all of the bad ideas that come with that. And but I do think that these are both directions that make a lot of sense in this space. Now as to whether that actually solves any problems specific to web bots, I I I'm not sure. And I'm not sure how specific or general this mechanism is or how specific or general it needs to be in order for it to have a home and do good work here.

[00:33:11] **Thibault Meunier**: Okay. Yes. On your first point about having, like, the key in bond, like, with the header, this was one thing which, like, was in the draft and, like, we're, like, removing like, ensure that, like, the draft is actually scoped one specific mechanism. Mhmm. We haven't seen that much interest, but, like, it's very good. Like like, she was saying interest, like, I do agree they might be valuing was envisioned, but I think it would be good to have it in the draft so it's, like, properly, like, like, defined.

[00:33:37] **Justin Richer**: Yeah. They need to be very clearly separated from each other because the trust semantics are drastically different. Yes. Yeah.

[00:33:46] **Thibault Meunier**: Great. Second point, we definitely value, I think, your input on, like, h two say, again, like, draft. Again, like, if the document, like, like, was made to to the working group. And Right. I think that's it. And Yeah. If I if I missed a

[00:34:02] **Justin Richer**: There was probably more. I've been talking for a long

[00:34:05] **Thibault Meunier**: time.

[00:34:06] **Justin Richer**: Sorry. But one one key point that that we may wanna touch base on in person, don't sign a signature value. And if you wanna understand the math why, this is the guy that wrote the paper that says don't sign the signature value. And, like, no. Seriously, it's it's a really, really easy mistake to make. I made this mistake when we were writing h t p sig until, you know, we sat down in a hallway and what was that? Yokohama, I think, and and and hashed out why I was wrong. And so anyway, yeah, there's there's stuff like that that's really about the application of signatures in this that I'm happy to help you align with that. In terms of how much this applies to web bot auth, I don't actually have a good feeling one way or the other about not to say I have a bad feeling. It's that I do not have a strong feeling one way or the other whether this is a good starting point for this specific case. But I do think the general mechanism is is a reasonable one that I think that we need.

[00:35:11] **David Schinazi**: Okay. Thank you. Thanks. I don't see anyone in the queue after Justin. So we'd like a bit more opinions on what yeah. Let me And then we'll have Eker on on whether this solution fits this. Because I think what I'm hearing from Justin is that there are a lot of things that will need to be changed, but they sounds like things that could be possible to change. We haven't found something that is a complete, like, deal breaker perhaps. I haven't found one yet. Yeah. Yeah. No. No. That's that's fair. And and, obviously, we would give you plenty of time to do a thorough review before we would talk about adoption. Alright. Back to the queue, Ecker.

[00:35:55] **Eric Rescorla**: Yeah. I mean, I mean, so I think this is the the right general shape for something. I mean, if what you want is, you know, is something shaped like identification of the client, which as you know, I'm not that just about, then this is the right general structure for building that. So I I reserve the right not to be in favor of this on principle, but in in terms of in terms of applying the thing that that that that is trying to do, I think this does the right I think there's quite a bit of room simplification here as I think we sort of were discussing at the mic, in particular about reasoning about what the, the the the key directory actually is trying to accomplish. As I was first saying on the chat, one could imagine, only providing a URI and not having a the the what you're what you're calling the binding the direct the binding mode the the the main binding mode and then leaving it to the client to infer that this happens to be a well known URI and therefore has the right semantics. For that perspective, the the mode you're providing is just syntactic sugar for that for that comparison. But I I think if if what we want is to have identified clients, then this is the right general shape of that, modulo common stuff I was making.

[00:37:08] **David Schinazi**: Great. Thanks, Hector. Dick?

[00:37:16] **Dick Hardt**: Hi, Dick Hart. You know, I'm supportive of this general direction for web bot auth. I've got a draft in HGBIS. And per my presentation in the interim, I think we have a general problem on the Internet around how do I identify the client making a call. And so I think aligning on a general purpose mechanism as opposed to just a web bot off mechanism might be better for the Internet more broadly than something that just works for the narrowly defined use cases we have here of a server doing calls. In the signature keys spec in each of these, we have the inline key, which I think might not has problems because of key rotation challenges, of course. But I I like this general direction, although I think it would be better if we aligned how do we solve this problem broadly, which is somewhat out of scope of WebAut off, but would be good if WebAut off adopt something that was a broader protocol, broad broader mechanism.

[00:38:19] **David Schinazi**: Yep. So speaking to our charter there, I think that makes sense that, obviously, the way we handle I've handled the we've handled these things in the past, which I think is successful, is to keep progressing this here within the tight scope of our charter specific to WebAuthor. And have you progressed perhaps your draft in HTTP BIS? And if we see at some point that a more general purpose solution ends up being most of what we need, we could eventually switch to that. But I wouldn't want to wait on that or gate on that because that is a much bigger ocean to boil, and we don't know if that'll be successful yet. Correct.

[00:39:00] **Dick Hardt**: Yeah. Works for me. Just wanna bring awareness that I think this is a general client problem in HTTP.

[00:39:08] **David Schinazi**: Great. No. That makes sense. Thanks. Myria.

[00:39:18] **Mirja Kühlewind**: Mia Kulebin. Yeah. Thanks for structuring this so clearly now. I I think the park mode seems fine. About the binding, there might be multiple options. So I'm wondering if we should maybe take this separately. I mean, at the end, the binding is just, like, some way to get some additional information about the bot. And, like, there might be actually more things you wanna communicate and provide about bot behavior and these kind of things so that maybe fits in that bucket and should be separate.

[00:39:49] **Thibault Meunier**: Okay. Thanks. Richard?

[00:39:53] **Richard Barnes**: Yeah. So so thanks, Tiva, for discussion here. I I think, you know, I I'm convinced that, you know, with the tweaks we discussed here around URLs, like, this we could have an a reasonably good consolidated scheme here. Think the thing that still makes me a little sad about this is it does continue to rely on durable identifiers. So, like, if it were possible to address the use cases with anonymous mechanism, I would I would prefer that one.

[00:40:17] **Thibault Meunier**: Can you repeat sorry, Richard. I didn't get the last part.

[00:40:22] **Richard Barnes**: Oh, just just a preference for, you know, avoiding identifiers to the degree that they're, not needed for the for the use cases. So I think that's that's more just kind of teeing up Eckers Eckers' presentation, and saying, you know, in general, like, I I think we should avoid, you know, tying these identifiers when we don't need to need to.

[00:40:41] **Thibault Meunier**: Okay. Thank you.

[00:40:45] **David Schinazi**: Thanks. So we've drained the queue. I think at this point, maybe we do a kinda show of hands to see on that same question about whether we think this is the overall general right shape. We're not asking for adoption of the document today, but we wanna see is this the general right starting point.

[00:41:10] **Richard Barnes**: If I might cheer from the floor a bit

[00:41:14] **David Schinazi**: Sure.

[00:41:14] **Richard Barnes**: Might that question be better after we have both presentations?

[00:41:20] **David Schinazi**: Sure. Well, actually, no. Because we there's they're pretty separate things, I think. So I would rather do it now. But thanks for the suggestion, Richard. Yeah. Yeah. Yeah. No. No. And and that decision has been yeah. Yeah. Absolutely. And then so this is specific to this one for the identifying. We will have a similar question for the anonymous mode after Ecker's presentation. So, yeah, specific to the identifying version of web bot auth.

[00:42:23] **Raffat**: Thanks. So

[00:42:26] **David Schinazi**: it sounds like we have more yeses, but there are some noes. So if you if you responded no and are comfortable, please come up to the microphone and explain to us why. We'd love to hear your your reasoning.

[00:42:43] **Richard Barnes**: I clicked no because I don't think I have enough information at this moment because we haven't had the other discussion.

[00:42:49] **David Schinazi**: Alright. That's fair. So that's not a permanent no. Let's say we need more more discussion. Okay. That's fair.

[00:42:57] **Raffat**: Why why is that? Yeah. So, Richard, can you say more? Like, what's what's the reason? Yeah. It's not clear.

[00:43:08] **Richard Barnes**: Well, the reason is that it it I mean, in principle, it doesn't have to be either or. In in the great standards committee driven tradition, we could do a number of things. But, I I would argue that, like, if it is possible to meet, the requirements without an an explicitly identifier binding thing, we should not do the identifier binding thing. So to that degree, they are mutually exclusive.

[00:43:30] **David Schinazi**: So, Richard Like, that's I I we have established rough consensus on progressing these two approaches. That has been decided in April, and we are not revisiting that decision today. Ecker?

[00:43:49] **Eric Rescorla**: Mean, I wanna persist that a little bit. I agree there was a consensus call, and I agree that what what you just said about what the consensus was. But, this draft independently needs to have, consensus to adopt, and, and it's perfectly legitimate for us to object to that consensus on the grounds which we just set. And we may lose, but, like, that's not it will that's not that question has not been asked and answered from that perspective, David.

[00:44:12] **David Schinazi**: I I'm sorry. I didn't quite catch that last bit. Can you repeat?

[00:44:16] **Eric Rescorla**: Yeah. I said that regardless of that consensus call, this draft still needs consensus to adopt. And it's perfectly legitimate for us to object to that object to that adoption on the same grounds that Richard just indicated regardless of that consensus call.

[00:44:30] **David Schinazi**: Sure. Well, that's not what we're asking today. We're seeing if this is the right direction, and it sounds like yes. And if people are saying no, we would like to know why. We

[00:44:39] **Eric Rescorla**: Right. But I call on the

[00:44:41] **David Schinazi**: list to give people plenty of time to read the document thoroughly.

[00:44:45] **Eric Rescorla**: Sure. But I'm I'm just saying that Richard answered you why, and and that why remains legitimate despite that consensus call.

[00:44:54] **Richard Barnes**: Okay.

[00:44:58] **David Schinazi**: Other Eric?

[00:45:02] **Eric Nygren**: Hi. Yes. Other Eric from Google. So you asked to, you know, speak if you said no. I actually really wanted to kinda say maybe because we are working on web dot auth, and I'm on a team that's experimenting with it. The real reason I said not yes is because I'm actually worried about in practice if it actually is voluntary over time. And I'm you know, I know we say that it's voluntary, but if if you actually need to provide it to access content on the web, that's something that I'm kinda concerned about. So I really wanna, like, withhold judgment as we continue to experiment. And if there's if it turns out, like, that this is actually us buying the web and and preventing access, then maybe this is something that we decide we'd rather have maybe, like, a more anonymous approach as Eckert's gonna go over. But I definitely wanna, like, continue to explore it without committing to it. So not a no, but I'm also not sure on a yes yet.

[00:45:56] **David Schinazi**: Thank you. Alyssa?

[00:46:03] **Alissa Cooper**: I wasn't a no, but I just wanted to point out that, like, you asked people to come and say why they were a no, and then Richard gave you his answer, which, like, is partially related to the fact that he maybe is in the rough on the previous consensus matter about whether to advance both. So I feel like it was a bit of a setup. Like know, then you were like, well, we already have the consensus, but it's like you invited him to tell you why. So I don't know what that tells us.

[00:46:30] **David Schinazi**: That that's fair.

[00:46:30] **Alissa Cooper**: Just an observation. Yeah.

[00:46:35] **David Schinazi**: Alright. Marlon.

[00:46:42] **Marwan Fayed**: Thanks. This one, I think, just for other Eric, something that I think was raised yesterday in the Moll meeting, which is useful to keep in mind is we we can view this as leading to a closed system of sorts as a requirement, but I think we have to consider that not exploring a path like this, we're actually heading in that direction anyway because website operators can do whatever they choose. And if there's something they don't recognize, they could choose to block it. And so there is that opposite view, which is actually this is a means of providing people an ability to maintain access in a way that suits.

[00:47:17] **David Schinazi**: Thanks. Empty?

[00:47:21] **Martin Thomson**: Yeah. I wasn't sure what I answered in the end. I don't know that I did. But I would like to see a little bit more work on on making the draft clearer about its purpose and intent before we talk about adopt adoption. And I think Wasn't it's look. This is generally headed in the direction that the working group set out, you know, agreed to to explore. But I think we need something a little crisper and sharper than than what's currently there.

[00:47:54] **David Schinazi**: Thanks. So I think what we're hearing is people should keep working on this, keep improving it. It is the right direction. It is not what we are gonna do an option call on, but keep working on it, and we most likely will get there. Okay.

[00:48:10] **Thibault Meunier**: Perfect. And Alright. Of course, I will solicit input on the mailing list and etcetera. So thank you for that.

[00:48:15] **Raffat**: Alright. Thank you, Thibault. Thank you.

[00:48:17] **David Schinazi**: Alright. Edgar, you're up.

[00:48:27] **Eric Rescorla**: Are you gonna do my slides or put them up?

[00:48:30] **Mike Bishop**: How do I

[00:48:31] **Eric Rescorla**: do this again?

[00:48:31] **David Schinazi**: Yeah. We'll put them up in transfer control. One sec. Oh, no. You have to take back from I I

[00:48:38] **Mike Bishop**: got it. I got it. And then close deck. Confirm. Share slides.

[00:48:45] **David Schinazi**: Oh, are you doing it?

[00:48:46] **Daniel Kahn Gillmor**: Yeah. I can.

[00:48:55] **David Schinazi**: Alright. You should have control of the slides, Edgar. Great.

[00:49:02] **Eric Rescorla**: So I understand that the sound is not great, so I'm gonna try to be clear. But, you know, if something you can't hear me, please do, you know, get my attention in some way. Feel free to interject. So I sort of has been foretold. There are two possible approaches to this problem, one of which is the one you just heard. Another is to attempt to do something which, attempts to anonymously authentic to demonstrate the bot has certain properties. And so this presentation is the other version of that. Next slide. Wow. You hear a lot of echo. Yeah. You can control all your information. You're you're right. It's me. I'm just used to dealing with AI, so I just thought maybe if I said next slide, something would happen. Okay. So to recap, we have all these, use cases from Brett Nottingham, and this does not cover all of them. I think some of those are bad, and and it does not cover the ones I think are bad, but tries to cover the ones that I think are good that I know how to cover. So the ones that it covers are in blue here and in bold, and the asterisks mean yes. Do you wanna mute mute the room, or should I stop talking while you try to do that, or should I keep talking while while someone asked to mute the room so that I wouldn't accost him that way.

[00:50:32] **David Schinazi**: I don't think we have the option or you know what? Dennis, can you turn off the microphone behind you? And I'll turn off this one. Thanks.

[00:50:42] **Eric Rescorla**: Great. So so I think so the the the the the the basic structure as will become clear is to allow you to demonstrate that a bot is a bot and is part of a the larger set of bots that has some novel set of properties, but not which individual bot it is. And so that lets you do certain things, but not others. And so what you do in particular is, manage volumetric abuse by, excluding people who are not who are not part of the system at all and people who seem to be using too much traffic, because there's a way to track how much traffic people are using, sort of, excluding non Boston or non non group members entirely, providing different content to people, group members who will not, because once again, you can see group members and not. This classifying traffic version that says, basically, I, you know, measure people who are group members and not. And, obviously, it allows you for the same reason to manage IP address ability to detach yourself from IP addresses. So to have IP address ability and to, also share IP addresses. And there's a small amount of contextual information that can be carried, but not very much. So the basic concept here is that access is bay based on this concept called an anchor, which is an anchor is a third party, and anchors vouch for bots. So, the anchor has some set of policies. So it says, you know, I've checked out that you have a Dun and Bradstreet number or you paid me a billion dollars or whatever, and the clients register with the anchors. And the anchor, evaluates the clients for whatever policy compliance apparatus that is, and the issue was called endorsement to the compliant bots. And the endorsement is then used by the clients to gain access to site by providing endorsement to the sites. And so the site's good to make access to all decisions based on the anchor identity, and maybe some indication of policy, the, anchor applies. But but they don't get to make access to resources based on how you are individually. So the way to think about this is, you know, the is is you might say there is a anchor which checks to see if, you know, you have a a as a Dun and Bradstreet number. And so you go and demonstrate you have a Dun Bradstreet number to the site and the anchor. And then when you go to the site, the site knows this is some point somebody's a Dun and Bradstreet number, but I don't know who it is as long as I just know this was checked out. So, this, this diagram shows basically the same point, largely in a schematic form. So, you go to the anchor and you register, and the anchor hands back this endorsement. And so in this in this diagram, both Alice and Bob have individually, registered, with the anchor and got endorsements. And it seems like Bob's arrow went a little a little too far when I changed the word endorsement from something from, like, attestation or something. And so then so then when Alice goes to the site, she presents the endorsement, but you can see that and but the site only knows the the anchor is the anchor, not not not whether Alice or in the request, and the site gets to respond. So this is the key, practical things happening here. So this this this this is a little hard to apprehend here because what we're actually doing is just completely stealing moly or moles. People seem to wanna call for some reason. So this is literally just what is in mole mole, except that you we mole mole is in this sort of liminal state where it's not yet a working group, and so I'm presenting it to you as if it, like, were something that actually isn't this draft, and it's really just me stealing it. So the so Moly has a slightly more complicated technical structure than, I just laid out, namely that there are two two pieces of credential. One one of which is unfortunately called credential. So the, as I said, the anchor goes to the goes to the, anchor the client interact, and the client gets this endorsement. And then and then the site has what's called a moderator that works for it. And the moderator can be a third party entity or can be, the site itself. And so when the first time the client interacts with the moderator, the client the the client provides the endorsement, and the and the moderator returns this thing called a credential, which is, as I say, a special specialized kind of credential, and the credential's what's used to gain access. And so the credential itself can store some state, and then, particularly, credential comes with a budget. And so the budget can be used for relimading, basically. So what's the protocol logic here? The client, gets one endorsement per time window. So time window, say, you know, day, week, whatever. And each client can show the endorsement once to each moderator per time window to get a credential. So the way to think about this is that I, you know, I go to I go to the anchor, and I get a and I and I get and I get this this this endorsement. And every time I go to a new site, I I hand over the endorsement, and I get back the credential. But I can only do that once for each site integrate when the time went down. And then during the time window, I continue to use the credential over and over again to get service. And each time I interact with the site, they the the, the moderator can add a strap for the client's budget based on their behavior. So the obvious thing to do is that that, basically, there's just a counter in here. And so the and so the the site says, look. Anybody that comes in from this anchor, I give them a million requests over the next time window. And every time I make a request, the site says a deck about one. And because a lot of fancy crypto, I don't actually get to see the I don't get to see the budget. All I get to see as as a site, all I get to see is this guy have enough budget left. So but it's obviously more complicated stuff, and then you could say, like, well, you know, this seems to be you know, you know, I I thought this request was really expensive, so I took I took out more. You know, you just you asked you asked me to do, like, a lot of inference, so I took out more or whatever. Right? So you can do a lot of or or this actually looks abusive, I took out more. Or you could not give back any budget at all, and that basically says this site was abusive. This this client was abusive. She can't come back at so you can do a lot of stuff within this basic framework. But the basic idea, like I said, is that you tran you trade off the the endorsement for the credential, and then the credential is used for management individually. So I just wanna briefly go through how you do the how you do the the the use cases with, with this analogy. So it's pretty obvious they provide different kinds of bots. All you know is the site you know, the site say, it's able to find endorsement, then, then you, then you then you provide them one kind of service. If they don't provide endorsement, they're a different kind of service. Right? On I think I I think I tried to give you an idea of how you, you mitigate biometric attacks. Ignore this this subscript, by the way. That was these slides were in different order, and moderators hadn't been introduced when I initially gave you the slide. So, the clients anonymously authenticated the sites. Right? And the sites can give each client the budget, and so the sites bay and so because the client must prove they have enough budget to meet their request, the site can basically just say, look. You know, this is how much traffic you can use and how much how much, Lloyd, you're able to give me. So this is, like, the core thing you can really do. Obviously, this gives you IP address ability sharing because the thing that's identifying you is the endorsement and or the credential. So, you can that that authentication is completely independent of IP address. You can change the rest of your request is, request using the same credentials. And, similarly, you can have two different people on same IP, and they can use different credentials. So that works fine. So what sort of works here is building this kind of reputation based on client behavior and auditing individual bot behavior. So both these, first of all, are obviously on a per moderator basis. And and like I said, you can say, well, this guy was abusive, so I'm not giving him back any change, basically. I'm not getting back any more budget. And so you can cut him off, and then he and he's basically out. Or you can say, well, these this this was, like, this was semi abusive on penalizing more than I ordinarily would, and, eventually, the person will run out run out of a budget. So so that sort of works, but you don't get you can't, like, do you can't do fancy stuff, really, where, for instance, people can't, like people can't compare notes, really, across moderators. So by design, this is not a lie to authenticate individual bots and doesn't lie to find different experience to clients using the same anchor. As long as you're on the same anchor, you just write the same experience to them. Ted asked me an email whether necessarily you had to identify the anchor, and you are it is technically possible, though I didn't present it here, to actually have the client demonstrate that he has an endorsement from one of a set of anchors rather than an individual anchor. And then, of course, you can't discriminate within the set of anchors as That's a little more complicated, but in that number is the machinery that that that that you need to do that, so I didn't present it. But it's perfectly possible. And then this this again, this is features of Moll. Right? So this is, I think, in full disclosure, a less baked proposal than than Thibault's proposal or in the sense that that the actual proposal is more baked, but that Moll is less baked. Because this is just, like I said, hand waving the direction of Moll largely. And so so the time Moll is done, you know, as well as to be done. As I understand the state, and I think, a number of people in this discussion are actually, more mole people, so they should feel free to correct me. But there was a side meeting here. There's a fairly mature looking draft, or somewhat mature at least. And are they planning to have that, I believe, chartered, or or bought for the next ITF perhaps? So, I think, you know, it'd be premature certainly to draft, until, that had happened. I think in the meantime, what we can do is if, you know, if what I said if if if how I said this allegedly worked, you believe that worked, would you think that was a good a good approach? And if not, what would you want this to do that it doesn't do? And and what would this need from Mollet to make that work? Those are the things we need to flesh out. And as I said, doc and as as a document, any sort of specific issues for us. I think if we're able to get to that point, then we'll be in a good a good place to take the hand off when as Moll moves forward. That's what was hoping to get out of this conversation. Like, is this is this generally the right kind of shape, assuming that it works as advertised and, and what and what people think this is worth doing.

[01:00:50] **Raffat**: Okay. Thanks, Eker. Any oh, we have a list already. Richard.

[01:00:57] **Richard Barnes**: So, Eker, I noticed the word endorsement appeared in both this presentation and the previous one, which makes me wonder if the endorsement provided in the way you this draft describes might be implementable with more boringness more boring technology if with the with this, you know, opaque URL approach and the various postures appear as, you know, different keys underneath the URL. So as long as the URL is the thing to which, you know, reputation or whatever attaches, and the keys are treated as a femoral knot, you know, not semantic artifacts, whether you might get the same benefits, from from that simpler scheme. Does that make any sense? Or is or or if not, like, what what is what is the additional value in this?

[01:01:44] **Eric Rescorla**: Yeah. That's a sensible question, but I think but it's a feasible question, but I don't think it does. And and and the reason is that that fundamentally, two things. Right? One is, we're actually trying to avoid letting the site build a catalog of people or or or requesting and having it tied to the identifiers, if they kinda rotate, that's a complete catalog of your of your behavior. That's undesirable. And the second is, I think it's pretty likely in some sort of circumstances, the mapping of those identities to, you know, you know, mapping those identities to real world identities will leak, and there won't be a situation where you can have quite a bit of discrimination. So, you know, if, like, if I operate you know, if people decide they don't want common crawl, right, or they don't want, you know, my bot my bot that scrapes them, and they learn my they learn my my URL, they can just block me off. And so then I have to keep keep keep of, like, evading them. Whereas, the whole point of this design is that that that you can't do any of those things, basically. All you can do is say, I don't trust this anchor at all. And so, you know, there's a there's a bunch of discussion in and elsewhere about, like, how well it actually works, in terms of how effective it is to say, like, this anchor or not this anchor, but the idea is supposed to be that if have a a set of, like, relatively large anchors, we're quite hard to set on. I'm not wanting to set this anchor. So I think I think this does provide us substantial better privacy properties.

[01:03:00] **Raffat**: Okay. Thanks, Richard. Pablo?

[01:03:05] **Pablo**: Thank you. Hey. I think we have two things that need to be discussed in regards to using Moll for this. One of them is more, like, of the environment, and and one of them is more technical. From the environment side, one of the things we were discussing in the Moll working group is what are the incentives for institutions to be anchors? I got a a relatively good answer or, like, a satisfying answer from, from there that was that, institutions that, want to improve the want to improve the the the experience of their users online and not be blocked, would like to be anchors. In the case of WebAutoff, I find it a little bit ifier because I don't know who I don't know that there will be enough institutions that would want to vouch for a small bot producers, and I don't know that anyone needs to vouch for big bot producers, but that's a that that's a more philosophy part. What I also think we should discuss here is for for Moll to work, you need to you submit your credential, and then you get an update to the credential. And that's gonna take some time. It's whoever's is verifying it is gonna need to do some work. And the whole point of a bot is it's doing requests at a similar speed. For humans, it works. Like, you can expect, like, to wait for the credential return. But I don't see I saw this in the in the chat as well. I don't see how concurrency is gonna be handled within this protocol.

[01:04:57] **Eric Rescorla**: Yeah. That's that's that's a good point. I think I think that the the practical way you actually run this is that the credential gets turned over. That that there's actually a third tier, which the credential gets handed back for cookie or something, and that cookie is used for cookie has to be used for, you know, 10,000 requests. And then, and and then afterwards, they have to that they do a cookie exchange. So I think probably you need you need a third tier memorization. I just don't wanna make it complicated in the presentation.

[01:05:20] **Pablo**: Okay. And and what about the anchor?

[01:05:23] **Eric Rescorla**: I I I oh, I'm sorry. I agree I agree with you. I just thought you moved on. Awesome. I think I think I think that, like I think the weak I think the weakest part of this proposal, frankly, is and and the problem with Moly generally, but, like, Moly has some people as you said, you have some people put put up putting their hands up, is that we actually do need someone to stand up this this infrastructure. I think that's the thing that has to,

[01:05:42] **David Schinazi**: like, pushed out a little bit.

[01:05:45] **Pablo**: Awesome. Thanks.

[01:05:47] **Raffat**: Okay. Move on.

[01:05:49] **David Schinazi**: Turn the mic on. Yeah.

[01:05:57] **Marwan Fayed**: Can you

[01:05:57] **Eric Rescorla**: hear me?

[01:05:58] **Marwan Fayed**: Great. Eckert, thank you. I actually I really like this a lot. Question I have is, why does this need to be an either or? And and from the perspective is actually, I think I feel like there are three groups that we need to worry about. There's the set of people we we want we know. There's the set of people we don't want to know, which I kind of view as being the mole case. And then there's the set of people we just don't know. And I feel like what you're proposing fits in that last set, which is sort of between the we don't want to know and we and we and we know.

[01:06:30] **Eric Rescorla**: Yeah. Yeah. So I think, you know, the the the that that's a perfectly good point. I think I guess what I would say is a lot of the questions around this center kind of in the political economy of it rather than this sort technology. Right? And then I was that could the thrust of thought, Pablo's initial question as well. Right? And so I think, you know, Pablo's concern is that no one wanna do, you know, no one wanna do, set up a Moi Moi anchor. Right? And and and my concern is that, is that the if we identify all the big bots, then it will crowd out the demand for, for non authentication for small bots, and they will be forced to be forced to authenticated. And so, like so so, like, so I think that, like, this the the these questions are all about the political economy. Like, I think it I I actually do not care if, you know, if giant giant if if if, like, OpenAI is able to, like, like, anonymously scrape. But I do care if, you know, if my bot can't hide in the shadow OpenAI, and I'm that that's what I'm concerned about.

[01:07:24] **David Schinazi**: Okay.

[01:07:24] **Eric Rescorla**: So I think that's that's that's so when you when you hear me say, like, I'm not jazzed about about the first solution, that's the reason, not because I think it's not not technically sound. Perfect. Thanks.

[01:07:34] **Raffat**: K. Richard. Hey.

[01:07:36] **Justin Richer**: Hey, Justin. Richard. So I have not read Moll, so I am unfamiliar with that infrastructure and stuff. So, this is a very naive question. Doesn't this just kick the trust up one level to the thing that's providing the endorsements?

[01:07:53] **Eric Rescorla**: Yes.

[01:07:54] **Justin Richer**: In okay. And that is that is the intentional kick that's happening?

[01:07:59] **Eric Rescorla**: Yes.

[01:08:00] **Justin Richer**: Okay. Does the Moll server have insight into where those endorsements are used, or is it private?

[01:08:08] **Eric Rescorla**: No. By by design, no. So the the anchor was not no. Okay. No. The it's

[01:08:13] **Justin Richer**: Yeah. Thanks. I was I was trying to figure out how this worked, why it was different. That was helpful.

[01:08:17] **Eric Rescorla**: Thank you. That that's that. By design. Yes.

[01:08:20] **Daniel Kahn Gillmor**: Daniel. Hi. Thanks. So I attended the Moll Pak discussion yesterday, the the side meeting. And so I'm still wrapping my head around, some of these concepts and how they work. But I wanted to try to understand There's a so so the in the Moll Pak discussion, it was it was more about sort of proof of humanness, you know, how do we get past the captcha, which is relevant for humans, not for web bots. And as I understood it, the the sites or the moderators operating on behalf of the sites, propose a set of anchors they will accept from, and they receive a proof that it belongs to one of those anchors. Am I am I right so far? Yeah.

[01:09:14] **Eric Rescorla**: Yes. Okay. Sorry. I should be nodding vigorously.

[01:09:18] **Daniel Kahn Gillmor**: So the the question that I have is, if this solution is gonna be good for both web bots and for humans, then are we going to is is the site going to be able to distinguish between web bots and humans on the basis of them being from different anchors? Or are we saying that if the site enrolls or their moderator enrolls in a set of anchors, they either can use Moll for the purposes of web bots or for humans? I mean, are we how many bits of distinguishing

[01:09:50] **Eric Rescorla**: Yeah. Yeah. Yeah. Are we talking about here? Yeah. Yeah. So yeah. Absolutely. So so technically speaking, you know, Moll can be op I mean, to the extent to which any these things exist. Right? These can both be operated in either the mode where you prove so, like, let let's do you say let's say there's pieces of anchors, humans and bots. Right? They can be either operating in either the mode where you prove, I'm in the union of those anchor of those sets, or I'm in the the the the the human set or in the bot set. Right? So either one of those can work. I think it's a practical matter. Like, I don't see any any version where you don't have to prove you're in the bot set if you're gonna, like, offer, you know, millions of of requests a second. So I think in practice so I think I think in practice, you will need some way to say, oh, you're gonna act like a bot. You better prove you're the bot's debt. But but, technically, you could operate other way.

[01:10:44] **Daniel Kahn Gillmor**: Okay. So, I mean, this complicates the Moll story a little bit because one of the things that the the one of the the pitches for the Moll story is this can only give you one bit of information. This only gives the the relying parties one bit of information. Sorry. Invert it's an inversion of the usual Yeah. Of the term relying party.

[01:11:04] **Raffat**: Yeah. Yeah.

[01:11:04] **Daniel Kahn Gillmor**: But but now we're saying, well, actually, it can give you two bits of information.

[01:11:08] **Eric Rescorla**: I think that's right. Yeah.

[01:11:09] **Daniel Kahn Gillmor**: Okay. Or and and then presumably, it can give you n bits of information if we have n classes of anchor that are

[01:11:15] **Eric Rescorla**: Yeah. Yeah. Yeah. Yeah. Yeah. And and so and so I think and and and just to, and and I think definitely you need some kind of defenses to stop the site from, like, iteratively asking for each, you know, each anchor subset until it's narrowed you down. I think what this defense is, exist is a little TBD, but I think hey, Martin's the line. I know he's thought about that, so maybe Martin rest away in, actually.

[01:11:36] **Raffat**: Okay. Thanks. Jonathan.

[01:11:38] **Jonathan**: Jonathan, hi. I'm for Tejas. If I select as the anchors that I trust Google, OpenAI, and I don't know, some other big company, then doesn't this have exactly the same effect? And I'm just saying the only people who can get the Google endorsement are Google bots running Google's infrastructure, and the only people who can get the OpenAI endorsement are OpenAI bots run on OpenAI. Aren't you just back at the same place that the small people can't hide?

[01:12:10] **Eric Rescorla**: I think I think I think it I guess there's some risk to that. Yes. I think one would hope that one would hope that's not that that is not how things get deployed, and I'm I'm I guess I would hope more more that there are enough intermediate sized, entities that that that doesn't work. But, yes, if that's if basically if basically what happens is that that no one wants to be scraped by anybody but, you know, the the five big sites, you know, and those guys all stand up their own anchors, then you're then you're host. My suspicion is actually that, like, that is not what we're trying to do here because those sites actually have relatively old identified IP addresses. Right? So it's not it's not, like, that much that much lack of clarity about whether you're being scraped by a giant by one of the by one of the giants.

[01:12:49] **Raffat**: Okay. Yeah. Okay. Thanks. Ted?

[01:12:55] **Ted Hardie**: Ted Hardy. No relevant affiliation. Thanks very much for both the presentation and for the conversation earlier this morning on the questions I had. I think there are two things I like about it, but I think you're very much correct when you said that this is largely a set of questions about political economy rather than technology. One thing I very much like about it is the opportunity to have a bot that can kind of work up its own individual reputation by first proving things to an an an anchor, where it's intractable for you to prove these things to every single website. If a website can trust a set of anchors, the fact that a bot went and proved itself to one or more of these anchors can help it develop the reputation it needs, possibly then to shift to a non pseudonymous attestation based on its own identity. So I think that kind of stair stepping is very valuable. I do have very strong concern about the centralization of power in the anchors themselves, especially because the incentives to run one, as as you suggest, are somewhat limited unless you're a CDN or somebody in in a position like that. I also went through the the discussion you and Dennis had about the ability to use anchor hiding to to kind of give you your yourself an opportunity to push away against that that centralization. And the difficult thing I have is that many of the actual desires here is to use anchor reputation as a proxy for the individual bot reputation. And so the fact that it's possible cryptographically doesn't actually fit within the political economy. And and I'm kind of wondering, from the point of view of the working group, is there any way to structure our use of this technology that encourages the ability of bots to to prove themselves in this system without necessarily enabling that that centralization in a way that kind of restores us into you you really have to go to one of these six anchors and and nobody else matters. And I wonder if you or or or Richard have really kind of thought through that and have any thoughts about it.

[01:15:09] **Eric Rescorla**: I don't think any you'd find acceptable at this point, but I agree it's a real problem.

[01:15:15] **Raffat**: Okay. Martin.

[01:15:16] **Eric Rescorla**: Yeah. I mean, yes, I thought about it and I have some answers, but not but probably more one we have to sit down for to to because they're gonna be sound incoherent.

[01:15:25] **Martin Thomson**: This thing's terrible. Alright. Martin Thompson. So I I think this is this is very interesting. Obviously, I think that the Moll thing is also very useful. There's a bunch of different things that came up during the discussion as I was waiting in line. To Ted's point, I I did wanna ask whether the the way you presented the anchor endorsement thing was deliberately only one, and why it didn't take advantage of the mechanisms in to to take multiple anchors and say that I just have something from one of them? And you seem to concentrate on the anchor identity being critical here. Would it be possible to say that I that the bot coming in is endorsed by DMP and g or g s one or or or?

[01:16:15] **Eric Rescorla**: Yeah. Yeah. I that's really technically possible. So I think what you're seeing is an artifact of my presentation choices. And, also, when I originally wrote this up, it was designed to work with slightly different set of technologies and and and was it was a little more closely tied to the anchor, idea. So I think, like, if I present this again, I may very well do what you what you said. But, no, there's there's far as I know, you can do you can do any set of these.

[01:16:39] **Martin Thomson**: Yeah. Okay. That's that's good. I I think that partly addresses Ted's concerns, but I think we still have the same basic political economy questions that Molly also has to has to contend with. The other one was that Jonathan pointed out that you could simply have an anchor and a unitary anchor that that that corresponds to, say, one big entity and only issues to a particular entity, and and that's the end of it. That just means that this design reduces to the design that Thibault presented. I don't know that we necessarily have a way to stop that. The only concern there is that that's the only way it's used, at which point it would have been much easier to do what Thibault was describing. So I I don't know that that's something we need to worry about, especially. I think it is something we need to worry about, but it is not something that we can necessarily do a lot about in the in the technical design. It's just something to be aware of. And the final thing I've forgotten.

[01:17:44] **Raffat**: K.

[01:17:47] **Eric Nygren**: Hey. It's Eric Houghton from Google. I I guess so I'm generally supportive of the approach here, and I I love where we're going here. But I I my question would be, like, what types of bots are we considering? Are we looking at crawlers or agents? And are those agents, like, local agents or remote agents? The real reason I'm asking is, like, because of how do we set appropriate rate limits for each each bot if you don't know who it is? There might like, maybe for crawlers, it doesn't matter what what rate limits you're setting. But if it's, like, a large agent, it might have millions of users behind it versus a smaller one might have a much fewer. So how do you decide what the appropriate rate limits are? Is this something we wanna consider as, like, a per client, you know, reputation signal as instead? And so there's sort of an agent provider reputation and then a per client reputation. So I I'm would love to hear how you're, like, thinking about that.

[01:18:37] **Eric Rescorla**: Yeah. I'm gonna wave my hands vigorously for a moment and say that's a question for the working group afterwards. But I think I think you're I think some of the ideas you're saying makes sense. I think probably, you know, this there there's a there's kind of a I I would say I guess I I'll I'll just say two things. Right? One is that it is the case that because you get to issue, and and and and a CCM is right behind you, so, he may say more about this because you get to issue a refund and and and and and how how much how much how much you decrement, you get to do some some discrimination of, like, what client behavior is like. And so someone's doing a thing that looks like a crawl for some it's, like, asking for, like, an audit inference, you can charge them more. So that gives you some ability to do things. But, obviously, if rag looks like crawling, then you don't get to do very I think so this is a combination of, like, of differential response in terms of, like, what kind of things we're asking for and also, you know, some maybe some per anchor discrimination where it's like, there's, like, a banker for, like, you're a giant crawler versus the anchor for your rag person. And, you know, if you if and if if you and if your credential was endorsed by, like, a giant crawler, but you appear to be doing raggy stuff, then we're like, wait a second. And, I mean, I think, you know, with with it within the safety of this room, I think it's it's it's worth it's worth noting that, you know, people are not able to consider IP address entirely. So it's not like actually you know, if if I have 20 request in a row, you are gonna be able to link them up no matter what what I do, no matter what crypto we use. And so you can also use that for some kind of, like, what this thing actually is behaving like like it's not supposed to be. So I don't think any of those are complete answers, but I think there's, like, stuff to be done.

[01:20:02] **Eric Nygren**: Got it. I think that makes sense. I think certainly something to figure out. I guess maybe just finally, because I know in the past, you've mentioned, like, hesitation around using web bot auth for local agent, and then and I agree with that completely. I'm kinda curious of, like, do you think that this would be useful for for browser based or on device based agents?

[01:20:19] **Eric Rescorla**: I'm okay. I'm gonna jump off the chair here. For the chair.

[01:20:23] **Eric Nygren**: Or yeah. It's out of scope. That would be I just wanna know.

[01:20:25] **Eric Rescorla**: It's

[01:20:25] **David Schinazi**: fine. That is explicitly outside of scope of our charter. However, it isn't it is potentially in scope for the hypothetical charter of Moll. So keep those thoughts. We might have a solution, but not in web bot auth. Okay. Thanks.

[01:20:43] **Sam**: Hey, Ecker. I had a few things to say in in response to a lot of different things. I think there's been a lot of discussion around the anchors and their role. The way I see it is that the moderator credentials, when bootstrapped, should actually provide a lot more of the rate limit for such a system. There's a lot of focus on, like, the anchor imputing a rate limit being deserved to that entity, but I think that the anchor just enters you into that moderator's ecosystem. And once you're in there, if you can, somehow prove to that moderator that you're providing value to the sites that it's protecting, then it's totally conceivable that most of the rate limit in the system comes from the reputation that you accrued interacting with the site. And so that involves sort of proving somehow that you're providing value to that site, and this is sort of one of the main sociopolitical problems that we have or sort of economic problems problems that we have is bots proving that they're providing value to the site. So for me, I see the anchors actually as not being as load bearing a part of this system as everybody has been really discussing. Oh, sorry. Coauthor of of the Moll drafts. Sorry. And and really the moderators potentially being a much larger and more important point of centralization to be concerned about in the system as the people who decide whether or not you get additional rate limit or how much of your rate limit gets taken away. The other point that was mentioned is, how does an anchor and it was actually explicitly mentioned, but I think it's important to make it explicit. How does an anchor know to endorse a bot when they cannot observe the activity of the bot? And I think an important thing there is we've thought a lot about this because it's it's a key part of having an open ecosystem of anchors and moderators and bots. And I think that, like, some sort of privacy preserving sort of distributed feedback mechanism where events that take place downstream can somehow be aggregated and sent back to the anchors such that they can actually know how to change their endorsement decisions is, like, a really important part of this to make sure that that endorsement actually is meaningful. And then there was this quite oh, no. I'm gonna skip that one. And then Martin mentioned this, but I wanna say it again. Like, the reducing to the identified version, I think the answer is, like, those entities will just use the identified version. And the hypothesis is that there will be many cloud agents which provide a lot of value to sites and that they won't want to just accept the agents from, you know, three entities. They'll want to accept a broad set of agents that can prove that they provide economic value. So I don't really see it as, definite that they'll there will be only three entities, that will be accepted.

[01:23:12] **Eric Rescorla**: Thanks.

[01:23:13] **Raffat**: Okay. Thank you. Al Lisa?

[01:23:19] **Alissa Cooper**: That was a good setup because I think I disagree with the last thing that you said, which is sort of, like, leading to some of the conversation in the chat. I don't really understand how you will end up with an anchor who's endorsing multiple different kinds of bots, and that feels like what you would need. Because otherwise, you end up with this bifurcation between the ones that the sites want and the ones that they don't want, but that we are trying to allow to continue to exist. So I don't that that's the part that I don't understand is, like, how that's going to come about. There's an adversarial relationship here, and there's I think the mechanism is designed to facilitate the continued access by some bots that sites either don't care about or maybe they they don't love, but they're willing to accept. But I don't understand how that those will be part of this system.

[01:24:17] **Eric Rescorla**: So I think I think if it's the case that, like, that all sites do not like bots of category a and only likes us of category b, then I think you're absolutely right. The question is, but if if if it's more fine grained than that, then, I think the expectation would be that, you know, certain certain bots don't want certain sites don't like some bots, but like others and other others like other bots and others. And as long as, like, there's, like, a large enough set of people who, you know, are willing to accept your your bot, then you then the anchor can can can support it. Right? So I think that I was pretty hand wavy. I'm going to I'm not gonna give you that right now. I think that this is, the one of big political conquestions that have

[01:24:54] **Raffat**: rush out. But, yeah,

[01:24:54] **Eric Rescorla**: if if, like, nobody if, like, everybody's like, I don't want, like, to scrape my site, then the anchor's, like, not gonna endorse me. Right? No one not gonna endorse me. But

[01:25:03] **Alissa Cooper**: it also feels like if you are in that sort of liminal bot space, the thing that you need is to is to find the anchor that's endorsing Google bot and attach yourself to it. Right? Like, you need that anchor to to endorse you too, and that will become the objective of of anybody who wants this to work for them if they're small, is that they have to they have to be endorsed by an anchor who's also endorsing somebody large that sites can't reject.

[01:25:30] **Eric Rescorla**: Or or at least some or or or the union of sites or a union of anchors. A union is of course, it's just big enough to to add up. Okay. Thank you. I I think that that's right. Yes.

[01:25:43] **Raffat**: Okay. Martin?

[01:25:45] **Martin Thomson**: I remembered there was two more things. The first one, I think, is probably a question for Echo. The design seems to deliberately not use the the moderator delegation thing from the Moll design. Is that intentional?

[01:26:04] **Eric Rescorla**: No. It's a it's it's a presentation artifact of, like, I thought I was that's what my slides look like before. I thought I actually I I I mean, just candidly, I find that I find that a little hard to explain to people, and so I and so I just try trying to make these easy version. But yeah.

[01:26:20] **Martin Thomson**: That carries its own interesting questions about centralization and and and whatnot on top of the other ones that we've talked about. The other thing was that a question that DKG asked about the semantics associated with the one bit of information that comes from the anchor. If that can carry different semantic values, then you can potentially accumulate a whole bunch of of of different attributes about a thing over time. And, obviously, at at the point that you have, like, 32, 45 bits of of information, you now have an identifier instead. The way that Moll proposes to deal with this is to only the the the client is only gonna offer one of these things, and that's it. And that may that that's exactly a choice that the the bot has in this case as well. They can only offer only offer one. Or if they choose to offer multiple, then that would be on them. And that becomes an interesting option in this space because then you can partition the space of bots more finely than than just the sort of am a bot, am not a bot sort of sort of scenario you contemplate.

[01:27:26] **Eric Rescorla**: Yeah. And I I see Maria asking a question in the chat too. I, you know, I don't wanna get too deep into technical questions here, but, you know, Moll Moll was really designed, I think, around I hat or something like especially like I hat. And I think probably in this case, we're looking much saying much more like this, like, long follow-up per system. And those systems, you can prove anything you want. And so you certainly could you certainly can have, you know, the anchor to say you know, the anchor say, your credential says, you know, you have a d m b know, you you you know, you gave me a million dollars, and you have verified, you know, $2,000,000,000 in the bank. And then you could be and then you could demonstrate exactly exactly those facts about yourself on the site. Now, of course, that has obvious privacy problems. But, like, they're this a lot we we can technically slice the baby incredibly finely, and

[01:28:08] **Raffat**: the questions and the and the

[01:28:09] **Eric Rescorla**: questions to ask are are what should we allow people to slice that does not create real problems? So on the one hand

[01:28:16] **Martin Thomson**: That's a whole new problem.

[01:28:17] **Eric Rescorla**: I know. It's more powerful and hence more difficult.

[01:28:20] **Raffat**: Justin.

[01:28:21] **Justin Richer**: Hey. Justin Richer again. So this line of conversation and especially that last bit really has raised to me what I think is an existential question for this working group. And that's, are we using identity and pseudonymity as proxies for the things that we actually care about? I think we really are because we really wanna care about, like, you know, what what do I do with this connection over over time? And in a lot of identity based systems, we use identity as a proxy for things like authorization because it's easy to build it that way. And one of the things that I think is interesting about this is, like Ecker was just describing, I I was about to ask if you could basically carry a an arbitrary claim through the system that says, I I hit flag x, then as long as there's a, you know, there's an ontology for that that you understand, then everything's good. So, yeah, I think that, like, this is closer to what I feel the fundamental problem the group is talking about is doing. And the other presentation is using identification as a proxy to answer that same question in a different in a different kind of way. And so I think that when looking at these, two drafts and whether we wanna take them on, I think that we have to be very deliberate about, is that a proxy that we want to have? Do we want to strictly stay in the reputation only camp? Can we stay in the strictly reputation only camp? Because, you know, this type of pseudonymity when it's asserted by multiple parties and all of that carries its own type of identification. And and then there's the whole group privacy thing that that comes into this. Yes. Bots don't have privacy. I get that. But, you know, re identification of things based on based on other other patterns and things like that and and especially the economic incentives that Alyssa brought up. It's a very long way of saying that I'm still not sure exactly the problem we're solving fundamentally here. Maybe that's just me, but I do think that there is this that that there is a bit of an existential crisis at the base of what this working group was founded for.

[01:30:50] **Eric Rescorla**: Interesting. I agree with that that last statement, I think, is a 100% true, and I think that's how we're kind of in this in this hole a little bit. I'm not sure how that but, luckily, the people at the front of the room get paid more to tell us how to get out of the hole.

[01:31:04] **Dick Hardt**: The cart yeah. I don't think the people in the front of the room get paid any more than the rest of us today. Building on the previous comments and on Justin's comment, but from a different angle,

[01:31:19] **Raffat**: The

[01:31:21] **Dick Hardt**: that we started off with was there's lots of it's really hard to identify a bot coming in. Right? It's sort of tied very much to a client identity type of problem. It's hard for me to have the client identity at a site. The reason I want client identity at a site, and if I'm the site, is that I wanna observe the behavior of that client, and I build up my own reputation with such contextual for the kind of behavior me as this one particular site I'm looking for. And so I'm not necessarily looking for what does somebody else say about the bot. I'm looking to see, is this a well behaved bot for my site, for the kind of behavior that I want in my site, which is not necessarily useful or applied to any other type of site. And so for that, we really just need an identifier that's durable for the site to be able to go and know it's the same bot again so that then any reputation earned is able to be applied to the same bot. Otherwise, I don't know who the bot is, and I'm gonna treat every request as unknown and nobody gets to earn anything. So we want as a site owner, we want somebody to be able to earn a reputation. And if they're bad, they burn it. And if they're good, they get a bunch of extra capabilities they would not normally get.

[01:32:39] **Eric Rescorla**: Yeah. So the yeah. Go ahead.

[01:32:41] **Dick Hardt**: Yeah. So that's one dimension around what that's what happens today with bots with sites. Right? And now we're thinking like, oh, well, if we start to go and add in other claims and endorsements, then sites could operate differently. Right? That there's a statement that, oh, they have a D and B number or they're registered nonprofit or there's some other attribute from a third party being said about this bot, right, which is now, you know, some statement. And that if you have that statement, I will treat you differently than people that don't have that statement. Right. Does that all make sense? Yeah. So if we're gonna do that and, of course, one of those statements could be, well, this bot has been a good bot, whatever that means, at other sites. And so, you know, they've they've behaved robots like text in other sites, so they come to my site. I know they're well behaved that some anchor has made a decision. But so that this all implies that as a site, I'm gonna trust some third party to make a statement about this bot so I can make a trust decision with a bot I have never seen before, which is very different than I have seen this bot before, and I've built up behavior and reputation on this bot before. And so I'm gonna apply my own metric around what I wanna do. So those are really quite two different things. The second one's a brand new capability that's never existed before. And as a brand new capability, it's nested that hasn't existed before. Before we design something to do that, I think we want much more crisp use cases on what those other signals and what those other endorsements are instead of just waving our hands in the air that somebody might care. Because if the sites don't care and if they're not gonna change their behavior based off of what a third party says, then we're designing something that's not gonna really get used.

[01:34:42] **Eric Rescorla**: Yeah. I think that's a thank you. I don't disagree with any of that. I I do wanna yes and it maybe a little bit. So as Sam was pointing out, this mechanism does support a limited version of the kind of reputation system you're talking about. You know, and all that requires is a very loose kind of anchor story. The name we that the anchors don't do don't issue duplicate identities, basically. So it does support some of that material, but, like, not not as rich not as clearly not as rich a reputation system as one where you have a full full identifier. Name namely what you you're allowed to basically say, like, you like, I've I've given you a bunch of repetition, and I've taken some away. That's basically all you can do. Right? So but

[01:35:22] **Dick Hardt**: Yeah. But if it's just an identifier, there's way simpler ways of me having a random identifier, and I use a different random identifier at each site that the sites don't correlate me. That just could be based off of the key at this random identifier. Right? That's Correct. A lot simpler to go and do. And, of course, I can just spin up a new identifier and the problem you know, in any of these identity systems, what you wanna do is you build up a reputation and identifier from good behavior, and then that enables you to do things that you couldn't do if you didn't have the reputation. And so then you behave yourself to keep your reputation.

[01:36:00] **David Schinazi**: Yeah.

[01:36:02] **Eric Rescorla**: Thanks.

[01:36:03] **Raffat**: Thanks, Dick. Marwan. Oh.

[01:36:06] **Dick Hardt**: But super interesting tech hacker. Thank you.

[01:36:11] **Raffat**: Thanks. Marwan.

[01:36:12] **Marwan Fayed**: Alright. So I'll do two as quick as I can. I didn't anticipate responding to Dick's. So I wanna point out, sometimes it helps to to think in concrete terms, of course. If we think about the kinds of relationships in the world, there are bilateral relationships one to one. I view that as being the web bot auth case, and it and it suits both parties.

[01:36:27] **Raffat**: Get closer a little bit to to Yeah.

[01:36:29] **Marwan Fayed**: Yeah. Sorry. So and it suits both parties. They actually need to know who each other are, and that's one case. There are the set of relationships in the world where you have one to many that you know something about, and I'll come back to that in a moment. And then there's the mole case of, like, one to a whole slew of people you know nothing about them. So I wanna take Alyssa's comment and tie it back to Sam's about incentives and the and the and the political economy things. Something like this is so incredibly valuable. I could build up a reputation, and then I don't want my reputation tarnished by others. And I migrate up to a WebBot Authent case because now I've become important enough that I build bilateral relationships. But fundamentally, even better than that, maybe this builds systems of accountability. Couple of simple examples. You can imagine there is an anchor that represents an association of libraries or the United Nations anchor that represents a set of NGOs. And and you can imagine, not only does this help those build reputation, but also enables people to say when when they're being mistreated, if they're being blocked, if they're being right? It it does create some visibility in the system, I think, that can be used both ways.

[01:37:37] **Raffat**: Next, Marwan? Ted.

[01:37:41] **Ted Hardie**: Ted Hardy. I think we we're kinda pointing at a couple of different problems here about how reputation is built up and about how the anchors act as proxies for this. And I think we may want to go back to something that Dick mentioned in just passing, which is the ability to spin up new identifiers. And one of the traditional problems we have in reputation based systems, like for email or other things, is that the baseline reputation you get has to be high enough to allow you to communicate. But it is trivial to mint a new identifier so that you can be a bad actor over and over and over again by minting new identifiers that get you that baseline. In in this system, the advantage is you can change what the baseline is by saying this is not a pre minted or recently minted identity. Somebody went through some process with the anchor, to prove who they were or what characteristics they had to the anchor so that you know, at minimum, if you're a website operator, this was not an identifier that was minted on the fly or faked. And both of those allow you to give a different baseline. And that's valuable from the point of view of both of the the website. As a as a site operator, you you say, okay. Good. I know this isn't bad actor's sixth mask for the day or seven hundred and fifty fifth mask for the day or whatever. And it's it's useful for the smaller bot because they haven't yet gotten the reputation of one of the larger ones. So I I continue to see a value in this as a stepping stone toward that kind of long lived reputation that a a well behaved bot wants and intends to earn, because it gives you an ability to to to ratchet your way toward that from without without starting from zero and without the risk that somebody else is going to reuse your reputation. I think that that limits its utility, frankly, to a particular part of the of the process of developing a reputation, but that it's a it's a useful enough part that I think the working group should continue to to work on this document and to track Moll to see if there are particular ways we can go forward. Because I think if we just put it aside and say we're just gonna stick to the identified portion, we're gonna fall into the reputation trap we've had many other times before. The people already have well deserved reputations. Get them. And websites will have a tremendous problem working out what the the resources they're willing to offer to those with zero reputation are going to be. And I think this is a useful partial step. Thanks.

[01:40:28] **Raffat**: Okay. Thanks. Okay. So thanks, Edgar. The feeling we're getting here is that people like the approach, but two points were raised, and and maybe just let us know if we are if we missed or misinterpret this. So the people people like the approach. There is two concerns. The first one is maybe we need a a CRISPR use cases to make sure we are clear on what what problem we are trying to solve with this with this mechanism. And the other one is around concentration of power. Is that something that need to be addressed before we kind of take this and adopt this as a as a Wix doc document. Is did did we get this right? Any any comments? Anybody has any question? Make sense? Go ahead, Dick. Good.

[01:41:37] **David Schinazi**: And and one thing I'll add is this has a dependency on Moll, which is still completely brand new. So it's we think it's a little premature to see where we're going. And so, like, we'll keep watching that space closely over the coming months. But go ahead, Dick.

[01:41:54] **Eric Rescorla**: And to be clear, I'm not asking for adoption at this time. Yeah. Of course. Yeah. Yeah. Okay.

[01:41:59] **Dick Hardt**: Descartes, I I think we want I like the idea of endorsements, but that's a theoretical high level concept of endorsements. I think we need to double click down as to what kinds of endorsements might be useful. You know, Ted brought up one kind of endorsement would be, this is when it was registered. Right? And so you have a how long is this, like how long has this identifier been around? Super simple endorsement, but means that you could come into a website and it would know that, oh, you had registered two years ago. Now is that useful? That's a whole other debate. But I think in the working group, if we're going to investigate endorsements, which are whole new mechanism that's never been used before in bot traffic, we need to double click down as to what kinds of endorsements might a website actually use because if a website's not gonna use them, there's no point designing architectures for endorsements.

[01:42:57] **Raffat**: Yep. Yep.

[01:42:58] **David Schinazi**: Thanks. Alyssa?

[01:43:02] **Alissa Cooper**: Yeah. Was I gonna say something a little bit more general along the same lines, which is maybe this is what you meant by use cases, but I feel like what we need is to understand, like, what would need to be true in order for this to serve the purpose for which it was intended.

[01:43:16] **David Schinazi**: Yep. Yep.

[01:43:16] **Alissa Cooper**: And and the the and, like, the this is includes, like, who will serve as the in these different functions. Like Yep. You know, what's the population of those? Do we actually think those are going to arise? And then I think it'll be easier to understand whether this is worth pursuing beyond just it being, like, a neat mechanism.

[01:43:34] **Eric Rescorla**: Yep. Thanks.

[01:43:37] **David Schinazi**: Alright.

[01:43:37] **Raffat**: Yep. Go ahead. Hi. I am Rashid Bouzin from. What I like is this approach of this this approach of anchor. But my question, why since since also exist, why credential still exist?

[01:44:08] **Eric Rescorla**: It's a tactical limitation of the way these the the crypto is designed. Like, it just turns out that you need it just turns out that you need the multistage credentials to get efficient behavior.

[01:44:19] **Raffat**: Okay. Thanks.

[01:44:20] **David Schinazi**: Alright. Thanks everyone for the great discussion. I'm gonna say for those of you that are interested, please join the Moll mailing list. I think there's gonna be a lot of progress there. And in terms of this, I think, you know, Ecker kinda sharpening those use cases, examples of who is in what role, and how all this ties together, plus having more progress will allow us to have more clarity. And, hopefully, by the November ITF, we'll we'll have something more crisp. Okay. I think we can close this topic. Thank you very much for the presentation, Eker. And we can now have Gary's presentation on crawler best practices.

[01:45:11] **Gary**: Hello. I might be Gary, and I have a very short presentation because well, we are not asking for adoption. We basically just want to see some discussion happening on this. During the previous presentation, it came up quite a few times how and also on chat, how bots behave on the Internet. And, basically, the problem right now and and I know I'm going to shock a few people in the room that there are or a significant portion of the Internet traffic is bots nowadays. But the behavior of those bots diverge quite a bit, so it's very hard to say that one bot acts exactly as another bot, which creates a bunch of operational challenges. These bots create high infrastructure costs, and it makes it hard to provision resources for a site, especially if the site is large. And for is that the real Gary as seen for us on Well, I don't have cryptographic identification yet, but I'm working on it. But, basically, what we are trying to do is to document the de facto operational conventions of bots. And then from there, we can ask bots to or we can show bots new bots how can they be trusted on the Internet. So why are we working on this crawler best practices? Basically, we just want operational hygiene and good client behavior on the Internet. This basically boils down into respecting robots. T x t, for example, some minimal identification and how origins are accessed. So what are we trying to codify is basically compliance with robots. Txt or their or RFC ninety three zero nine. We are asking bots to have some sort of rate control and respect back off signals. And, in some ways, be more transparent about who they are. We are documenting existing things, for example, IP addresses, and how they should be distributed. We are not currently, talking about other cryptographic, identifications. We think we need, crawler best practices because, it establishes some sort of trust in the human sense, not in machine sense, and because origins require predictable traffic patterns because then they can provision for humans better. And for the bots, this is good because if they are complying with these behaviors then or their patterns are expected, then, it's less likely that they are going to be blocked by, w a WAFs and so on. So our questions are relatively simple. One is whether we should discuss this further in the web without group. And the second one is whether you see any other thing that we should document in this document.

[01:49:33] **David Schinazi**: Alright. Thanks, Gary. So in terms of our charter, we the chairs don't think this is in scope for web bot auth, so we wouldn't necessarily consider adoption here. But our questions for the working group are, do you think this work is useful? Do you think it should progress? And if so, do you have thoughts on where it should be dispatched within the IETF? So the floor is open. Justin.

[01:50:03] **Justin Richer**: Hi, Justin Richer. This is the most sensible and immediately useful draft that's been presented today, and it should be in this working group. So here's so we we had a similar draft in in Whimsy that's just gone to the IESG that set out specifically to document existing practices, say where the sharp edges are, not try to fix them because like if you're loading a your access token in a Kubernetes volume, you you know, you're you're making some decisions in life. But the fact remains that people do this. And so Whimsy as a community decided that it was better to write down the practices and say, like, here's here's what you need to look out for if you're gonna go do this anyway. This to me feels a lot like that. And that, I think, is a very useful type of document to have in the world. I think also because it's not trying to invent and solve problems, it can be progressed much more quickly because it has a very sort of narrow scope and focus. I didn't pull up the charter text, but I would recommend that the that the chairs and AD look at the charter and see if this is not actually doing something that is useful to the web bot auth community.

[01:51:31] **David Schinazi**: Thanks. And we'll invite our AD to come to the mic at some point maybe to provide their thoughts on on the charter question.

[01:51:41] **Raffat**: Yeah.

[01:51:43] **David Schinazi**: Ecker?

[01:51:46] **Eric Rescorla**: Yeah. I I think some of this is potentially good, but there's I'm concerned that the uses to which is going to be put. And in particular, I, like, look, and you're sure, like, oh, you should identify yourself. But this is actually a very contested question. And in fact, if you just go look at this New York, you know, caller stealth caller bill to see how contested it is. And, you know, bots are in a somewhat adversarial position with spread to sites. And so what I'm very concerned about is a document like this being used as a club to hit bots with to enforce behavior the sites would like, but bots would not. And so I think if we can narrow it down to the subset that everyone agrees on, then may maybe that's cool. But if, like, what it turns out to be said is the clubs needed to hit the bots with, then I'm not I thought I'd just about it.

[01:52:32] **Gary**: Yeah. That's a very good point. I think what we are trying to do is documenting existing practices. Because what we are seeing from what I'm seeing on some honey traps that I have on the Internet is that new bots are behaving wildly differently than existing bots. And I don't think that is because of malice. I think it's because they purely don't know how to behave.

[01:53:09] **Raffat**: Okay. Go ahead.

[01:53:11] **Mark Nottingham**: Mark Nottingham. Yeah. I think that if this were to be in an IETF working group, this would certainly be the most logical place to have the discussion. I do think that if if minding what what Ecker said, you know, finding the places where there are consensus, it does seem like there are ways we could improve the world, and it would be useful to have that consensus documented. There may be parts of it that are contentious. Chairs should have their eyes open about taking on such items. But I think it's more likely that, you know, in in this kind of document, if if you have a truly contentious recommendation, perhaps you just avoid documenting that and focus on the things you can't agree on.

[01:53:59] **Eric Rescorla**: Mhmm.

[01:53:59] **Mark Nottingham**: So I'd I'd say, yeah, let's talk about charter modification maybe if you know, what what once there's a bit more time for people to digest this and understand the scope and and comment on

[01:54:08] **David Schinazi**: the project. And and for what it's worth, we can keep discussing it in this working group even if it's not perfectly in the charter like we did today at future sessions, pending our charter or, you know, ID sponsorship. There are plenty of options. Thibault?

[01:54:24] **Thibault Meunier**: Yes. Thibault, Cloudflare. So thanks for the presentation, and thanks for the work and iteration on the document. I think it's, like, a pretty good set of, like like, relevant for, like, current practices, which, like, actually seem to help at least, like, some bot to achieve, like, what they want because, like, there's, like, a lot of, like, that same intent for a lot of bots, like, it might not be recognized uniformly at least across website. And I do think this really captures, like, the good set of, like, trend practices. Are these best practices? I think it's, like, something which is a different question, and I would, like, really value it. I think it's, like, really useful to, like, have this discussion in this working group because I think it's useful to, like, inform what are, like, the practices that, like, might be defined down the line. So thank you.

[01:55:13] **Mike Bishop**: So Mike Bishop is responsible a d. I'm noticing one of the deliverables in the current charter, BCP and or informational documents describing operational considerations. If you squint, the the current state of of how things are done and it doesn't specifically say operational considerations of the protocol you build. This is operational consideration of the world as it is today and why we need to fix it. I think it's probably close enough we can at least discuss it. And if we need to do a charter tweak as we get close to publication, go for it.

[01:55:52] **Raffat**: Yep. Makes sense.

[01:55:54] **David Schinazi**: Thanks, Bank. Alright then. We're happy to keep discussing this on the web bot off list for sure. Myria, and if anyone wants to say anything, get in the queue now. We're gonna lock it because we're almost at the end of the meeting.

[01:56:08] **Mirja Kühlewind**: Yeah. Just very quickly, if we wanna adopt it, I think we should recharter. It's not, like, that hard to recharter, and I don't want to have a discussion at IETF last call if this was in charter or not.

[01:56:20] **David Schinazi**: Alright. Thank you. Alright. I think we've joined the queue. Thank you, Gary, for the presentation and the discussion. Alright. Thanks, everyone, for coming to Web Auth. I think we made some good progress today. We have two proposals for two different scopes that I think we're gonna keep working on in kinda different directions, but more work is needed for sure. But there is interest in keeping those conversations going and doing that work. But, yeah, let's please join us on the list. And similar to last time, we might do an interim if it helps us make more progress between now and the San Francisco IETF. Anything else?

[01:56:59] **Raffat**: No. Oh, thank you, all. Yeah. Good. Yeah. It oh, no. It's good. I think we are now from the back.

[01:57:15] **David Schinazi**: There you go.