**Session Date/Time:** 21 Sep 2026 17:00

[00:00:04] **Rifaat Shekh-Yusef**: Yeah. Hi, Emelia. Can you hear Okay. Hi there. Hey, Hannes. Hey. Hey, Hannes.

[00:04:31] **Hannes Tschofenig**: How you doing?

[00:04:34] **Rifaat Shekh-Yusef**: Okay. Hang on.

[00:04:40] **Dick Hardt**: It's

[00:04:43] **Rifaat Shekh-Yusef**: almost there. So maybe get sorted in few seconds here. Emelia, can you hear us now?

[00:04:55] **Hannes Tschofenig**: I can hear you.

[00:04:57] **Emelia Smith**: Yeah. I know. Yeah. I can hear you now.

[00:05:01] **Rifaat Shekh-Yusef**: Yep. Okay. Perfect.

[00:05:02] **Emelia Smith**: Don't know if it was audio drivers or Internet connections or Zulip, but

[00:05:06] **Rifaat Shekh-Yusef**: Mhmm.

[00:05:07] **Hannes Tschofenig**: Whatever.

[00:05:08] **Emelia Smith**: Internet gremlins. Yeah. Okay.

[00:05:12] **Rifaat Shekh-Yusef**: Awesome. Let's get going. Hannes, will you be able to take notes?

[00:05:21] **Hannes Tschofenig**: Yes. Of course. I'm already logged in.

[00:05:23] **Rifaat Shekh-Yusef**: Okay. Thank you. Okay. Let's get get going. So as a reminder, the Note Well applies here. As you know, the Note Well defines how we conduct business at the IETF that includes how we interact with with each other. We debate things and respectfully and IPR related stuff. So if if you're not familiar with this, yeah, highly recommend that you take a look at this. What is this? Why is it it's I don't see the full slide here for some reason. Anyway, so we have and this is a very old one. Sorry, guys. This is the old slide deck. Oh gosh. Okay. We have let me see. Just one second here. I don't know if I can. I

[00:06:51] **Deb Cooley**: don't see it on the meeting agenda page or the meeting material page. It just this particular version. So I think you just move on without it.

[00:07:00] **Rifaat Shekh-Yusef**: I don't know. Yeah. I have uploaded, I guess, the old the old material for latest here.

[00:07:05] **Hannes Tschofenig**: I don't think you have too many sort of details on the slides anyway. Right?

[00:07:10] **Rifaat Shekh-Yusef**: Correct. So we we we're gonna talk about OAuth protected authorization, this week. We still have, we have another meeting next week. So we'll talk about this next week, what what next step. Okay? So I'm gonna stop sharing and share text slides. And let me hand it hand you that control tech. There you go. You can drive.

[00:07:48] **Dick Hardt**: Hooray. Where is the control? Oh, there we go. Okay. Figured it out. Oh, I can put my camera on too. So gonna talk about OAuth protected authorization, agenda, start off some history around what the problem is, go through how it works, and then whether this group's interested in adopting it. Brought this first to the Oauth group, you know, almost a year ago. It was motivated by the IATF meeting before that where there have been talk about the attacks of the authorization code being taken out of the authorization response from the AS back to the client. And so I drafted that up. I thought, you know, this could be viewed as something general purpose, presented at httpbis. The outcome of that was that the HTTPBIS group wasn't super interested in it generally, and so it's like seems like the main thing group that's interested about this in Cares is OAuth. And so I'm now bringing this to the Oauth working group to see if the Oauth group wants to take this on, which is where most of the energy for this was when I was first talking about So at a high level, the problem is that the authorization code coming from the, AS back to the client is used to be able to obtain the access token or in the case of OpenID Connect, the ID token as well. It gets exposed in lots of places. Jonas presented at IETF 124 about that. Helps to some degree. And then related problem is the AS doesn't really have a reliable way of knowing, you know, where did this come from. And, similarly, the, client doesn't necessarily have a reliable way of knowing that it came from the the the response it got came from the AS. And, you know, this is because for, you know, a core part of OAuth is, like, well, the users there in the browser, and so we'll have the user mediating the communication between the client and AS, going through the browser, and we, you know, essentially use query parameters as a mechanism for the API about, you know, how do we move information between those two instead of them talking directly to each other. Form post is was proposed as a partial solution for that. You know, one of the challenges is that the query response is the default in libraries. We chat about this on the list to some degree. I sent my agent to go look at all the libraries and see what the default was, and the the default is query for many libraries. So the challenge for many people to move to post is, you know, one that the library defaults need to change. You know? Do people wanna do that? But in changing that, it also, potentially requires a change in their infrastructure that their, you know, reverse proxy is set up to do get, not post. And so they would do that. And if they don't really know what they're doing, then it breaks, and they can't figure out why, and then they just roll back to something else. And then, you know, the form body is still visible to, you know, Page JS and, extensions. So the proposal is let's move the credential to an HP header so that the browser mediates that when it isn't available to all the things in the browser that might get it. So we had it from the JS, JavaScript, and extensions, and the browser relays that parameter but not going through the redirect. So it's one header field proposing OAuth authorization is the name of that header. That's a structured field dictionary, you know, three different fields, query, origin, path. The query is the same query string that would be on the URL. It's not turned into parameters or anything. So the parsing of that is the same as the parsing would be a query, also keeps it separated from the other parameters. Origin is set by the browser when it's sending it back as to what was the origin that it sent us. And path is something that, allows more isolation if the client is if it's a multitenant client, and so the origin be the same, enables you to differentiate between different clients. So the how the protocol works starts with the client redirecting over, and the client set is setting both the it's sending the URL. So it's sending the message two ways. One as a query parameter and two in the header. If the browser understands it, it adds origin, and it delivers it to the AS. The AS process it, verifies that the query and the header match, and it knows the client's origin and authenticates user. And then now it knows that the both the client and the browser support it, and so it redirects back but without using the parameters in the query. And so the parameters are now only in the header. Browser adds origin again, delivers it once, and the client parses the query that's in the header, verifies the origin. So here's here's what the code looks in the request. You know, you just basically have the same thing for the query string as you have in location, and then you have a potential path. The browser adds origin, sends that over. So, you know, all of this, like, walks through essentially what does a AS need to do, which we've covered before. And then when it sends its response, you notice now it doesn't have a query path and location. All of that is in the o a o auth authorization header, and the browser gets that, sends that over, and sets a region. And then the browser is really just okay. Is was the 302 there? Is that header there? And does some checks to make sure that it would be so a bunch of stuff in this that the browser needs to do. The browser needs to make sure. Like, it wouldn't be we wouldn't be solving anything if the header was available to JavaScript and available to extensions. And so the browser needs to lock down that nothing in the you know, no extension or JavaScript can go and access this because, of course, that's the whole point is hiding it from things that are, might be bad in getting access to this. So if the browser can't do that, then they shouldn't implement it. Of course, this is requiring update to the fetch work that the browsers work on. You know, one of the questions like, well, does everybody have to change all at once? The way this works is it doesn't. You know, you know, the the client starts sending it. And, you know, I chatted to a couple of library vendors, and it's like, oh, yeah. We could go and do this. It's what they said. You know, they haven't done it yet, but they said that they would. And so as you roll it out in the libraries, it just starts working for anyone using those libraries. You know, if anybody's hand rolled it, their client, they'd have to, of course, do the update themselves. So the client sends it. The browser, if it sees it, detects it, knows to go and send it over to the AS. And the AS, if it sees it from the browser, it knows that the client must support and the browser must support. So it knows that now it can send the response just in the header, and it'll get back to the client. Variety of sort of security considerations around doing it. And, you know, if people wanna go into any of these things, I talked about the forum post already. Things like native apps, a number of other things are out of scope. You know, this is really trying to solve the, you know, web browser redirect problem. Change the name of the header, went from being generic to being just OAuth, changed from a a few headers to just one header. You know? So we the the changes from the last draft of this, you know, I ripped out a bunch of stuff because there didn't seem to be interest in a generic mechanism, and so we can make it just OAuth just for this one thing and just the only way for it to work is is incremental where there's no discovery or anything else. Open questions. You know, was the working group interested in this? You know, is it just in BAM? We don't change any metadata or anything else. You know, any concerns about the origin check? You know? Is it gonna blow out the header size? Everyone's okay with native flows being out of scope. Think that's you know, I'd say, I think, like, next steps. Like, I think we're now to discussion time.

[00:18:33] **Rifaat Shekh-Yusef**: Okay. Thanks, Dick. I see Emelia in the the queue there. Go ahead.

[00:18:39] **Emelia Smith**: Yeah. I wanted to ask about if you go back and slide to the open questions, question four specifically, because I did note when I was looking through the spec briefly last night that the origin member is, it says, should verify that the origin member is consistent with the client's registered redirect URI values, which to me implies that you would be either pausing the redirect URI values and extracting their origins and comparing that to the origin that was sent. Or you would be doing something else here, and I don't really understand this part of the spec.

[00:19:18] **Dick Hardt**: This is so, yeah, this is the AS doing the check. Right? Yes. And so the AS is already should already be checking that the redirect it got maps to a registered one. And so it's adding that, like, do we, you know, do we check your work as well? Yeah. The origin of

[00:19:39] **Emelia Smith**: the request may not be the redirect URI.

[00:19:45] **Dick Hardt**: Correct. That's why it's a question.

[00:19:48] **Emelia Smith**: So that's, yeah, why I'm also asking this question. I think the origin check against the redirecturize makes any sense considering that, a, we advocate for exact string comparison for redirecturize now. I think that's in 9200. And the origin isn't the redirect URI. It's the where you came from in order to start the flow, which is usually your login page, and you don't have your login page in the redirect URIs.

[00:20:19] **Dick Hardt**: Remember, we're just talking about origin. So this is the host?

[00:20:23] **Emelia Smith**: Right. But redirect URIs specifically are using exact string comparison or simple string comparison.

[00:20:31] **Dick Hardt**: So you'd only be checking the host part in the origin. Obviously, like, the the redirect URI cannot be just the origin.

[00:20:39] **Emelia Smith**: So you'd be adding parsing onto the redirect URIs?

[00:20:43] **Dick Hardt**: You'd be yeah. You would be checking to see is the origin is the origin of the redirect URI the same as the origin you had in the header using, you know, a standard parse of the URI.

[00:20:59] **Emelia Smith**: This may break cases where you're doing brokering of OAuth requests where you have an intermediary server. So, like, say, you have an accounts.app.example and you're on app.example and you click log in, then that does the redirect across to the authorization server. But there, the origin would be app.example, not accounts.app.example or vice versa.

[00:21:30] **Dick Hardt**: Yeah. I mean, the the but also a so a number of things like that that I've built, the redirect your eye is actually going back to the origin even though it didn't start at the at the you started somewhere else. You went to some intermediary, but often I I've written them till the written intermediary comes back.

[00:21:47] **Emelia Smith**: Oh, yeah. The origin.

[00:21:48] **Dick Hardt**: Once once again, it's an open question. You're you're bringing up a great point, which is does this make sense or not? You know, is it adding much value? Is it gonna are a bunch of things gonna break if AS has enforced this? Yeah.

[00:22:04] **Emelia Smith**: Yeah. I think the origin here would be the intermediary, in which case, the redirect URI would be the end client. So it'd be breaking at that stage of the intermediary to the AS because that origin wouldn't match the redirect URI's origin.

[00:22:22] **Dick Hardt**: Right. But what I was saying is a number of things where I've got something in the middle to redirect URI is intermediary.

[00:22:29] **Emelia Smith**: Okay.

[00:22:30] **Dick Hardt**: Yeah. Even though I started somewhere else. I've I've sort of often, what I've I've done a number of these things, it's like, okay. I want one place to manage all of the OAuth flows and the redirect URIs and everything. I might start at a bunch of other places. And so then the origin and the redirect would match. But how is it out in the real world? I don't know. Right? So this is this is one of those things where you could deploy, get some real world experience of, you know, how is the origin and the origin, the redirect UI not a match a bunch of times, and so trying to match those is gonna be problematic. But right now, we don't really know what's widely deployed. So, anyway, that's why it's one of the questions here. Right?

[00:23:20] **Emelia Smith**: Yeah. That's a good thing. It it would be good to get that question answered. I don't see it on the issue tracker at the moment, though.

[00:23:31] **Dick Hardt**: There's probably quite a few things that aren't in the issue tracker yet.

[00:23:35] **Emelia Smith**: Okay. So it would be good to see each of these quest open questions added to the issue tracker such that we can follow their progress.

[00:23:42] **Dick Hardt**: Fully agree. First, I'd like to know whether the working group wants to work on it or not.

[00:23:51] **Rifaat Shekh-Yusef**: There are comments in the chat. Michael, is that you wanna talk about that comment?

[00:24:00] **Atlassian Representative**: Yeah. Hey. Can you hear me?

[00:24:03] **Rifaat Shekh-Yusef**: Yes.

[00:24:04] **Atlassian Representative**: Yeah. No. No. Just I know, Dick, like, you mentioned the the header size issue. Like, we do see it pretty regularly with at least, like, with Atlassian. So it's been something that's that's been of concern. So, like, any sort of duplication, you know, is yeah. Yeah. It it's just something it's something to be to be aware of.

[00:24:25] **Dick Hardt**: Yeah. Yeah. I mean, yeah, the challenge in something like this where you're changing how things work that people have for a decade and everything's kinda worked, you know, it's gonna it's gonna push a few things in in ways that no one expected before.

[00:24:46] **Atlassian Representative**: Yeah. Yeah. For sure. Like, if at least for us, we have, we have an issue of, of, like, you know, JWTs combined with poor scope governance, which I'm pretty sure is not uncommon out there. So any sort of, like, you know, encoding or packing of of, you know, extensive amounts of information in those in those JWTs, even if it's an off code JWT, is gonna is gonna Yeah. Blow things up.

[00:25:10] **Dick Hardt**: Yeah. And so in some of those, it could be that, you know, when that's happening, the the, you know, the client shouldn't use us. Right? Like, this is an extra security as opposed to required security. Right? We're we're not gonna get the world to change. It just lowers the vulnerability to clients that have, well, to clients that have adopted where the browser has it and the AS supports it. So I think AS support, likely is not really gonna be a a huge challenge for AS as the support, but I'd love to anybody that's works in an AS to chat about that. And, you know, Chrome is interested in supporting that. And, you know, even if we don't get the other browsers, Chrome, I that's gonna have a has a big swath of the Internet that we've improved the security of. Yep. Head headers is is people are are sending crazy stuff over on the redirect now, and putting that all in the header as well could blow it up. Philip?

[00:26:12] **Filip Skokan**: Hello, Dick.

[00:26:14] **Dick Hardt**: You Hello, Filip.

[00:26:16] **Filip Skokan**: Hello. It's also late in here, so apologies. This might this this may very well be a silly question. You mentioned that this is entirely opt in at every single layer. So it is entirely possible a client supports this. The AI supports it, but the user is using a browser that doesn't as is usually the case. You mentioned the client as the header, as the query, optionally the path. No. Just the query. The browser is then responsible for enriching it with the origin and the path, and the authorization server that supports this.

[00:26:56] **Dick Hardt**: The the path comes from the client.

[00:26:59] **Filip Skokan**: Okay. That's fine.

[00:27:00] **Dick Hardt**: Yeah. The

[00:27:01] **Filip Skokan**: Path comes from the client.

[00:27:02] **Dick Hardt**: The the origin Origin Only

[00:27:04] **Filip Skokan**: the origin is enriched, and the client the the browser must do this. Yeah. And the server is responsible for optionally checking the origin to match something. But if the browser in this scenario doesn't support this, the header goes through.

[00:27:23] **Dick Hardt**: No. No. They find the the the

[00:27:26] **Filip Skokan**: If the browser doesn't support this, the the header goes through. No. Why?

[00:27:32] **Dick Hardt**: Because Because

[00:27:33] **Emelia Smith**: browser is attaching the header.

[00:27:34] **Dick Hardt**: Right. The browser is generating the header. The header remember, the header is coming from the client to the browser, and then the browser decides what headers it's gonna send to the AS.

[00:27:47] **Filip Skokan**: So the client's doing a three zero three with the header and then Yep. Sorry. The client is doing the three zero three with the with the header that the browser then takes and says, hey. I wanna enrich this header

[00:27:59] **Dick Hardt**: Yeah.

[00:27:59] **Filip Skokan**: Or I'm gonna drop this. Or or not recognize it.

[00:28:03] **Dick Hardt**: Right. If the browser doesn't support the protocol, it doesn't add the header. Mhmm. Remember remember, the the client isn't talk the the browsers don't send the headers they got from a client to the server. Right? They only send Yeah. Yeah. Yeah. URL. Right?

[00:28:26] **Filip Skokan**: And so how would okay. So that answers my question, sort of, but I have another one immediately. How would this work for public clients that work entirely in JavaScript, and they don't do a three zero three?

[00:28:40] **Dick Hardt**: It won't work.

[00:28:42] **Filip Skokan**: So why are we doing it? Or why are we talking about it since public client leaking its authorization code is the whole reason Jonas brought brought brought this up. Because for confidential clients, we sort of don't have a bigger big of an issue. If it doesn't work for public clients, why?

[00:29:12] **Dick Hardt**: Well, my understanding of his talk was that the there is still a big issue in, you know, the logs things being logged. So when you're saying a public client, you're saying one that's running in the browser? Or

[00:29:30] **Filip Skokan**: A browser based application. Yes.

[00:29:33] **Dick Hardt**: Okay. Because public clients can also be server side. They just don't have a client secret.

[00:29:38] **Filip Skokan**: Fair enough. Browser based applications.

[00:29:41] **Dick Hardt**: Yeah. So if it's a not a confidential client that's running on the server, this definitely helps.

[00:29:53] **Emelia Smith**: I may have a partial solution for the JavaScript clients route, which is the FedCM stuff that I mentioned in chat. But, also, there is a FedCM spec that is in the community group, which is IDP initiated FedCM, where the authorization server can send a header, and the browser will automatically upgrade a OAuth request to a FedCM request. It's a little bit weird, but it's something that is being proposed. So it might be worth a look.

[00:30:33] **Rifaat Shekh-Yusef**: Okay.

[00:30:36] **Dick Hardt**: Yeah. I mean, that's a I mean, that you know, I I I I think that's a great thing to also look at, but it's a separate a separate solution to a related problem.

[00:30:46] **Emelia Smith**: Yeah. It's Yeah. The other side of server side based stuff. It's the client side based stuff.

[00:30:56] **Rifaat Shekh-Yusef**: Hannes, you have a comment?

[00:30:57] **Hannes Tschofenig**: Yeah. Since the FedCM stuff was brought up, we some time ago, we talked about it in the group and it looked like a very promising thing, but then I didn't hear anything for a while. Was that just me or did that not the well, wasn't it picked up by lots of companies and that's why it's sort of, like, fading fading somewhere in the in some community group?

[00:31:26] **Emelia Smith**: The FedCM working oh, the FedID working group is still actively working on FedCM. We meet every two weeks, and we've actually done a lot of work to improve support for decentralized ecosystems, which are fairly common in OAuth deployments. And the other thing here is Chrome has implemented most of FEDCM, but other browsers have not yet. And the blocker for other browsers to implement the other part implement FedCM, as far as I understand it, is that they are wanting a core profile of FedCM because FedCM is quite large. So we've got one item that we're trying to get into core before we can sort of say this is what core FedCM is, and this is what you have to implement in order to have interoperability. Does that help?

[00:32:26] **Hannes Tschofenig**: Okay. Thanks a lot. Thanks for the update.

[00:32:29] **Emelia Smith**: Yeah. Feel free to reach out via email or anything else if you wanna know more about FedCM.

[00:32:38] **Rifaat Shekh-Yusef**: Okay. There is a comment from Max. Dick, do you wanna take a look at this? Oh, yeah. I can you hear us?

[00:32:49] **Maxwell Gerber**: Yeah. Yeah. I can hear

[00:32:50] **Hannes Tschofenig**: you. Yeah.

[00:32:50] **Emelia Smith**: Yeah. Go ahead.

[00:32:52] **Maxwell Gerber**: Yeah. I'm sorry if I missed this. I have trouble understanding why this is not a generic change to HTTP and why we're saying, hey, browsers. You need to treat OAuth as as something special, different from other protocols. Here is the specific OAuth header for you. And if it's, like, a pragmatic, this seems like the best way to to make the change to the ecosystem, then sure. But I I wonder like, if we're saying redirects are broken in some use cases and there are times where we need different behavior, like, that seems to me like there should be something done in HTTP BIS.

[00:33:32] **Dick Hardt**: Yep. That was where I started this. And there was an interest in HTTP BIS in working on it. And they said this seems like something that only the OAuth people care about. So And

[00:33:53] **Maxwell Gerber**: there's no other protocol that's passing, you know, credentials around and and redirects that would be affected or or could benefit from something like this?

[00:34:02] **Dick Hardt**: It's only us. Potentially. But, I mean, if I I can't make the working group wanna work on something they don't wanna work on. So Yeah. Cool. Alright.

[00:34:20] **Rifaat Shekh-Yusef**: Okay. Emelia.

[00:34:22] **Dick Hardt**: Yeah. I I I had the same thoughts. I thought, this seems like it could be useful. You know, this seems like a general purpose thing. But I

[00:34:32] **Emelia Smith**: do agree about it potentially being useful as general purpose. There is a line in the section 10.5 about moving parameters out of URLs removes them from default URL logging. Header logging is a condition configuration choice that servers must make deliberately. That line doesn't really hold true in the era of open telemetry and automatic sampling where headers are actually captured.

[00:35:04] **Dick Hardt**: Could be. I'm I'm trying to see if I've got something with the actual draft open anywhere on my machine for looking at that. If if you could file that as an issue, I'd appreciate that.

[00:35:20] **Emelia Smith**: I just put the link in the chat. So it's that section. But it seemed like maybe one of the security reasons for this was to get rid of the authorization code from the URL in the idea that having it in the headers would mean that it wasn't logged by intermediaries. And that doesn't end up being the case because if the intermediary or anyone else down the chain is using something like OpenTelemetry, then they're most likely sampling or logging some small percentage of request headers that their servers are receiving. So you're not really gaining a security benefit here with that.

[00:36:11] **Dick Hardt**: Yeah. I mean, if you wouldn't wanna wouldn't wanna say that, oh, for sure, there's a security But for anything that's logging if you're logging everything, then, of course, it's included. A lot of logging would log for, you know, analytics of who's doing what and stuff like that, they tend those types that type of logging typically doesn't log the headers. They log the URLs to see what was the traffic. Like, so your typical web server log would be logging the URLs, not the headers.

[00:36:50] **Emelia Smith**: Yeah. So OpenTelemetry will log absolutely everything.

[00:36:53] **Dick Hardt**: Oh, I yeah. That that's that's a different that's that's that's a that's telemetry as opposed to the logging used for traffic analysis.

[00:37:05] **Emelia Smith**: Right. But it still ends up somewhere that is not the intended recipient. Yeah. I'm not not

[00:37:12] **Dick Hardt**: not disagreeing with you at all, but the idea is that if it was the the systems where you're logging for, you know, visitor records, you log in the URL and not the headers. And so now you don't have to code there.

[00:37:28] **Emelia Smith**: Yes. But, like I said, in the case where headers are being captured for some purpose, which is usually some sort of debugging purpose, In that case, the only field that I know is regularly omitted from there are the authorization and set cookie headers.

[00:37:51] **Deb Cooley**: Mhmm.

[00:37:53] **Emelia Smith**: So I don't know how or why those are omitted, but you would have to try and find a way to get this header also omitted from those by library default.

[00:38:06] **Hannes Tschofenig**: Yep.

[00:38:12] **Rifaat Shekh-Yusef**: Okay. Hannes?

[00:38:15] **Hannes Tschofenig**: Yeah. I was wondering whether you thought about the use of encryption, Dick, for this purpose because that would obviously solve the logging issue. Right? You could obviously log the encrypted information, but, like, it would only be processed or processable by the authorization so when it when it's when it uses the key or it has the key and not by some intermediary, some some load balance or what whatever.

[00:38:50] **Dick Hardt**: I mean, the Justin made this comment, the HEB best meeting, which is, like, you know, the the best way of solving this problem is essentially don't sending not to send the data back and forth this way through the browser. And

[00:39:09] **Hannes Tschofenig**: so Which which is not what I'm saying. I'm I'm still okay to pick Yeah.

[00:39:14] **Dick Hardt**: If I could just other reasons. Just if I if I could just finish. Right? So

[00:39:18] **Rifaat Shekh-Yusef**: Mhmm.

[00:39:18] **Dick Hardt**: If you're if you're working on making a number of changes, right, well, then let's just fix a bunch of things. As soon as you work on the there being a key for the client, right, you've sort of changed what is widely deployed. And so that, you know, that's a that's a much heavier barrier to adoption.

[00:39:41] **Hannes Tschofenig**: I agree. Yep. Yeah. Yeah. For sure. Yeah. Sure. But if you want I

[00:39:47] **Dick Hardt**: don't care I don't care about the name of the header. We we we could go back to some other name. Sure.

[00:39:50] **Hannes Tschofenig**: No. No. That's fine.

[00:39:52] **Dick Hardt**: Oh, no. I was just I was I was responding to Max's question in the chat.

[00:39:56] **Rifaat Shekh-Yusef**: Oh. Yeah.

[00:40:00] **Dick Hardt**: So there's probably other ways we could we could there's we could do this better in a number of other ways, but they every everything I sort of thought about required a much bigger lift for the client, where currently, the client can just the client doesn't even need to know they're doing it if it's rolled into the libraries. Right? There's no infrastructure change. Yeah.

[00:40:27] **Rifaat Shekh-Yusef**: Okay. Aaron, can you hit us? I think he's having some audio issues. He might not, but, like, he has a comment in the chat. Do you wanna take a look at that?

[00:40:42] **Dick Hardt**: Aaron? Yeah. He said he was in the airport. Yeah. What? The one about the BCP?

[00:40:52] **Rifaat Shekh-Yusef**: The one before that too.

[00:40:55] **Emelia Smith**: They're going, yeah, going through crawl space.

[00:40:58] **Hannes Tschofenig**: Yes. Through basically. Yes. Yes.

[00:41:00] **Rifaat Shekh-Yusef**: Yeah. Which one? Yeah. That's all.

[00:41:04] **Emelia Smith**: Which ones are the same comment?

[00:41:06] **Hannes Tschofenig**: The call sheet.

[00:41:06] **Dick Hardt**: Yeah. It'd be useful to go through the BCC. Yeah. Correct. Yes. Yeah. Sure. Yeah.

[00:41:12] **Rifaat Shekh-Yusef**: Okay. Emelia. Go ahead.

[00:41:16] **Emelia Smith**: So we already have PKCE, which is mandatory as of OAuth two point one for all clients, and we also have Depop. Both of those provide binding of the authorization code and the token, respectively. What is the actual extra security that you're gaining here? For a server side client, the client on the JavaScript page would not have access to the the code verifier for PKCE, So it wouldn't be able to use the token in the authorization redirect anyway in the redirect your eye anyway. So what security are we gaining here? And we've already addressed I

[00:42:07] **Dick Hardt**: I I x. Yeah. There I mean, there was a bunch of discussion on this before, so I don't have sorry. I don't, like, recall exactly all the attacks, as to why we you know, the the consensus we had on the list was we need to go to pop form post to have that improve the security. And seeing how hard it would be to try to change everybody to form post was why what motivated me to think maybe there's another way of sending it, that would be better. So I don't have an answer to your question around what attacks still work when you have pixie, but and, what's his name that did the who is it that did the the Jonas. Jonas isn't on the call. I wish you you know, if he wasn't, maybe he could provide more insights into that.

[00:43:08] **Emelia Smith**: So perhaps what we could ask for here is an explainer document that explains the full history of the security risks that you're trying to fix, such that we can then take this document in context of that to understand the security risks that you actually have, and then pair that with the BCP for browser based apps, and then pair that with the spec tech draft spec in order to figure out if it actually makes sense.

[00:43:40] **Dick Hardt**: Yeah. I think the the pixie thing was the attack that Jonas had was that the attacker started the flow, and so the client had started the flow with their, code verifier, and then they got the code from somebody else and fed it through because the code, I forget the details. But there is a way that even with Pixi, it didn't you could defeat the if if you stole the code, you could an attacker could still compromise and take over an account.

[00:44:19] **Emelia Smith**: Couldn't that be solved by binding the PKCE code to the browser and IP address and other information about the client or about the server?

[00:44:32] **Dick Hardt**: I don't know. I am sorry. I I didn't come up here to sort of dive deep into what the attack vector was so much as assuming we'd all align that there was an attack and that this was a potential solution.

[00:44:49] **Emelia Smith**: Okay. Yeah. I just can't say whether I support it or not based on the information given and the SPECT text as is.

[00:45:04] **Rifaat Shekh-Yusef**: Okay. Thanks, Emelia.

[00:45:06] **Dick Hardt**: Yeah. I mean, I circulated the first draft of this with Jonas and a few other people that have been active in the discussion to see whether they felt it addressed the attack. So I wasn't I wasn't working on being the expert in attack. I was working on how can we solve it. Reading Aaron's latest comment, you know, it's like, where is this useful? You know, I think that would be carving out what you know, it it's a great question to ask, and and one that I don't have a good answer for is which of the attacks does this solve? It seemed like it solved a number of the attacks that have been brought up in the earlier talk.

[00:46:19] **Hannes Tschofenig**: But that's good feedback. We if we when you write this up, talk to some of the persons who looked into the attacks in detail, I think we can easily write this up and and have a much better understanding. I I think that's a that's a good outcome of the conversation we just had.

[00:46:42] **Dick Hardt**: Yeah. Justin had shared the links linked to the other minutes. And so a piece of feedback from Martin and David was, you know, moving bits of the headers doesn't prevent a malicious browser extension. But the, you know, the position we have is, like, if the browser can't protect, can't prevent a malicious extension from accessing it, then they shouldn't support the protocol. That's a that's a browser problem.

[00:47:18] **Hannes Tschofenig**: And and browser vendors have repeatedly changed the way how they dealt with plug ins because of security issues.

[00:47:28] **Dick Hardt**: Yeah. Yeah. There's there's

[00:47:30] **Hannes Tschofenig**: a bunch of different problem.

[00:47:32] **Dick Hardt**: Yeah. You know, the feedback from Chrome was they thought this could be useful, you know, as they looked at the problem, and and they had a interest in implementing.

[00:47:50] **Rifaat Shekh-Yusef**: Okay. So so I guess next steps for this is really to kind of look at what problems or map this to a problems that this will really solve and then discuss it next next time. Is that is that a fair kind of summary of this this point?

[00:48:13] **Dick Hardt**: So what are you suggesting, Rifaat, that we

[00:48:16] **Rifaat Shekh-Yusef**: Yeah. Like, it seems that people wanna understand what problems this is gonna solve before they make a decision whether to adopt it or not. Right? So maybe that's the right thing to do and kind of dig deeper into how does this mechanism solve the problems that were kind of discussed before and kind of talk about those next time to make sure we're on the same page and people kind of see the value of this mechanism addressing specific well defined problems. Right?

[00:49:01] **Dick Hardt**: So, I mean, I think, you know, if we wanna work on this, we should work on this as a working group. If we if we wanna solve this problem, that seems like, you know, here's an approach. We can adopt it. Along the way, we could decide, yeah, there's not enough. Now that we've worked on it for a while, we don't think that that makes sense. Right? But, you know, this is an adoption of do we wanna work on solving this problem or not. Right? If the working group's not interested in solving this, then I'm not gonna keep pushing it myself. Right? So it seemed like the working group had said, we got an issue. We need to go and figure out how to do it. This seems like a solution one of the solutions for how to potentially go and do that. And so do we wanna adopt that and work on it or

[00:49:47] **Rifaat Shekh-Yusef**: not? Yeah.

[00:49:50] **Hannes Tschofenig**: I think my takeaway from the presentation, I still remember that one, browser, the one twenty four presentation that Max posted into the chat window was that there is a problem and and we should fix it. I I think it would be a good a good question here into the room whether people even agree with that statement. I think then we can talk to they talk about the next steps. If you think you we want to solve that, whether we should work on a solution. Like, it's pointless to work on a solution if nobody thinks that well, if this problem is to obscure and to really occurs in an environment and so on. Rifa, should we can we answer that

[00:50:41] **Rifaat Shekh-Yusef**: Yeah. That's that's what I'm so I'm I'm gonna start with do people agree that there is a problem to be solved? So I'll I'll start with that. Right? And then, well, based on the asset, we'll we'll continue. Right? Okay. I've started the poll here. Yeah. We have very few people here anyways, but split in the middle here.

[00:51:36] **Emelia Smith**: I put myself as a no for now, but I would change that to a yes pending the CRISPR definitions of attacks that this would address.

[00:51:50] **Dick Hardt**: Well, that's Sorry. The question the question is, is there a problem to be solved? Because if people don't think there's a problem to solve, then there's no problem proposing a solution.

[00:51:59] **Emelia Smith**: Well, yeah, without the attacks, I can't know that there's a problem to be solved.

[00:52:12] **Hannes Tschofenig**: Well, I I will I'll record at least the the outcome. So it it seems that we we don't we are not entirely sure whether there's whether there's a problem. The the problem was presented to us in during the session at 01:24, and maybe maybe for whatever reason, it maybe was not too convincing that there is an issue, but I'm just second guessing. Does anyone want to speak about that specific part of the problem? Because so far, we spoke about the solution to the problem. Like, why why do you believe that there is no problem?

[00:53:00] **Atlassian Representative**: If I sorry. If I could just echo what Emelia was saying, I think that, like, I I voted no because I I'm not sure without without, like, an actual, like, case by case example of, like, the attack surfaces, I, you know, I wouldn't say that that there is a problem to resolve. The problem has to the problem is basically, like, proved out through through the potential attacks. Right?

[00:53:27] **Speaker 8**: Yeah. I was really jumping on the queue to say pretty much the same thing that the last two speakers have is that the problem only makes sense in the context of what is the attack, what is the, what is the surface that would be addressed by this, and, I'm not seeing that here. So are there problems to solve in the world? Yes. Sure. But that's not that's not really a useful question to answer.

[00:53:56] **Hannes Tschofenig**: No. No. That's it's not the question of, like, are there problems in the world? We know that there are problems, but but that was specifically referring to the presentation. Let me post

[00:54:10] **Rifaat Shekh-Yusef**: it to

[00:54:10] **Hannes Tschofenig**: the chat

[00:54:11] **Rifaat Shekh-Yusef**: window. Jonas is yeah.

[00:54:12] **Hannes Tschofenig**: Oh, you I mean, I've got

[00:54:13] **Dick Hardt**: the problem slide open. Right? I mean, this was the problem. I wasn't at 01:24. I only read the threads and the response after. So

[00:54:22] **Hannes Tschofenig**: yeah. Good. So it's not it it's actually Max put it quite nicely. Is the browser swapping attack from the from that IETF 124 meeting a problem to be solved? So, of course, that was a little while ago already, so maybe not maybe the details are not fresh. So maybe that's that's a challenge.

[00:54:48] **Emelia Smith**: I am looking at the slides from one twenty four, and I'm on slide nine, which is the attacker sending a AS authorized URL to the user and then redirecting them back after they've logged in with a state mismatch error. And I think the answer there is, one, the user should never see a state mismatch error. They should just see, sorry. Your authentication failed. Two, when you're as soon as you process the redirect URI on the client or on the server, you strip the query parameters and the callback URL. So you get rid of those even if you fail the authorization attempt, which prevents the attack of the attacker saying, oh, which URL are you on? Because then you don't have those parameters. The user never sees them.

[00:55:42] **Dick Hardt**: Yeah. I mean, there was a number of of things that Jonas talked about. The the the attack, the the aspect of the attack that this is focused on is where there's a theft of the authorization.

[00:55:54] **Emelia Smith**: Right. Like, there's half a dozen different attacks in here, and it's kind of hard to detangle which ones this proposed specification would be solving. So getting that clear would be my thing.

[00:56:21] **Rifaat Shekh-Yusef**: Okay. Hello?

[00:56:24] **Filip Skokan**: I I think that the the challenge with what Emelia was just talking about is if if the attack is starting with the attacker starting a flow, then copying the authorization server URL to what is it? The the URL, the authorization endpoint, sending it to the user. The user clicks on it, then that is immediately driven into the fallback scenario where the client didn't support it. So it's only if, I think, all parties support it that you actually don't have the problem. It it's it's when you don't have a fallback scenario, if you don't treat the fallback case, that you can actually get rid of all the, quote, unquote, attacks.

[00:57:20] **Emelia Smith**: Yeah. I think I'd agree based on my reading of these slides.

[00:57:32] **Dick Hardt**: Okay. I mean, it's not like the working group doesn't have a lot of other stuff to work on. So if people don't view this as a problem, then

[00:57:42] **Rifaat Shekh-Yusef**: I I think it yeah. I think that people are saying they want to see that the problems that this is solving. So maybe mapping. Yeah. But looking at that

[00:57:57] **Dick Hardt**: I I didn't do that. I didn't come to the working group saying, hey. Here's a big problem. Right?

[00:58:02] **Rifaat Shekh-Yusef**: Yeah.

[00:58:03] **Dick Hardt**: The working group was presented with a problem. There seemed to be consensus at the time that there was a problem. I'm presenting a solution.

[00:58:09] **Rifaat Shekh-Yusef**: Okay.

[00:58:10] **Dick Hardt**: Right? If people don't want the solution or if they don't even think there's a problem anymore, I'm not here trying to convince people there's a problem.

[00:58:17] **Rifaat Shekh-Yusef**: Got it. Okay. Deb.

[00:58:21] **Deb Cooley**: So just to sort of pile on a little bit. Oh, really? So restating the problem is the first part of defining the solution. Right?

[00:58:35] **Dick Hardt**: Yep. And that's I kind of had assumed the working group was already aligned on the problem from the previous meeting.

[00:58:42] **Deb Cooley**: But even if that is true, it has to be documented in the draft. Correct?

[00:58:50] **Dick Hardt**: There's I mean, somebody else had already documented that that there was a problem when the authorization code was stolen. And so I'm saying here's a way to keep the authorization code from being stolen.

[00:59:07] **Deb Cooley**: But it seems like the first part of this or maybe part of security considerations is to say, you know, here's the problem, and here's how we're fixing it. Without the statement of the problem, you're just presenting a solution without a problem that will live you know, if they take up this work and if it gets published, the question is, down the road, is anybody gonna have any idea of why this solution was being proposed if the problem is not in in the specification? Just seems logical to me. I'm just thinking logically, that you probably want the problem statement inside the specification that you're proposing a solution.

[00:59:50] **Dick Hardt**: Yeah. I think that's it it's

[00:59:56] **Hannes Tschofenig**: Yes.

[00:59:57] **Dick Hardt**: It it potentially is not as clear in in here, and people have says, like, okay. Well, what about these different use cases? Right? So I hadn't pulled together the problem. I kind of had just assumed that everyone was aligned that there was a problem here, and I think it's good feedback that we need to go. And and and if we have a final doc, right, it should be really clear why somebody has to go and do it. But if nobody thinks there's a problem, right, then there's no point working on this. Right? So I agree. The document that we produce should definitely be crisp about the about the problem so that enough people know why they're gonna implement it.

[01:00:29] **Deb Cooley**: So so the question is, do you do that now or do you wait until later? And if you don't if you do it now, then there's it's a more compelling reason for why the working group should adopt the work. If you wait and do it later, then maybe the working group doesn't understand the compelling reason for why they should do this, and it never gets adopted and never gets fixed. You've got Jonas is still around. Is that correct? He's just not on the call today. That maybe you get him to help you, like, explain the problem you're solving. And whether that's in the introduction or whether that's in security considerations, know. I don't care. It's just it seems like you can't propose a solution to a problem that has that is unstated.

[01:01:16] **Dick Hardt**: Yeah. I mean, when you phrase it like that, it sounds like I just made up a solution without anybody having any problem at all.

[01:01:24] **Rifaat Shekh-Yusef**: No. I I think Yeah. I think people understand that is like, that that there was a presentation and people talked about a problem and and maybe a bunch of problems. The question is maybe how would this solution solve which problems, which list? And because it's one problem, I think, if we remember correctly. And people don't don't remember what happened long time ago. Right?

[01:01:53] **Hannes Tschofenig**: So Yeah.

[01:01:53] **Dick Hardt**: Yeah. I mean, the the problem was, you know, the the attack we're working on is that the code is exfiltrated, and the attacker is able to take over the account. How the attacker takes over the account with the exfiltrated code, there is a bunch of different ways of doing that. Right? But the core problem was that an attacker could get access to the authorization code. Right? To me, that was a core problem I was working on solving.

[01:02:19] **Rifaat Shekh-Yusef**: Mhmm.

[01:02:20] **Dick Hardt**: Right? Because, yeah, I I think it should be clear to everybody that if somebody has access to a code they shouldn't have access to, then they could do some bad things. And somebody else had said how they could do those bad things, and I'm solving the problem around how do we how do we keep the bad guy from getting the code. So I was focused on the problem being, how do I keep the bad guy from getting the code? Not how did what is how does the bad guy do something once he's got a code?

[01:02:49] **Hannes Tschofenig**: Okay. Fair.

[01:02:50] **Dick Hardt**: Yeah. Because where most of all the questions are. It's like, okay. So they get the code. What can they do? It's like, well, I don't know. I didn't, you know, I didn't come up with all the different attacks around what you could do once you stole the code. I was figuring out how do I solve that bad guy not getting a code.

[01:03:06] **Rifaat Shekh-Yusef**: Yeah. So I guess the feedback you're getting here is that people wanna see the problem, and and maybe, saying how this mechanism solved those problems. Right? Do you wanna work with Jonas on this, or we can discuss it in San Francisco? Or like, or what's what's your take from the feedback you got so far?

[01:03:34] **Dick Hardt**: I mean, I was saw an opportunity to solve the problem. You know, we're a year later in all of it. I have a lot of other things to do, and if people don't really care about the problem, right, it doesn't really matter to me that much. You know? I I think, you know, an easier way of solving the problem as Justin had called out in the HTTPBIS meeting is, like, have a different protocol.

[01:03:58] **Rifaat Shekh-Yusef**: Okay.

[01:03:59] **Dick Hardt**: Right? Like, this this is a nonissue with GNAP.

[01:04:05] **Rifaat Shekh-Yusef**: Okay. We're we're four minutes past, so let's end it here. Okay. Thank thank you, Dick. Thank you all for joining, and we'll talk to you next week.

[01:04:18] **Dick Hardt**: Okay. Thanks.

[01:04:19] **Rifaat Shekh-Yusef**: Okay. Bye.

[01:04:24] **Hannes Tschofenig**: Thank you.