Session Date/Time: 14 Sep 2026 17:00
[00:02:46] Rifaat Shekh-Yusef: Yeah. We'll give people few more minutes and get maybe started at 01:05. Okay. Let's get going. Okay. Welcome everyone to the first of a series of interim virtual interim me... Meetings. So Hannes will be taking notes this time. Thank you, Hannes. Let's get going. This is a reminder that Note Well applies. So this covers everything that we do at the IETF. This covers topics like IPRs, like behavior, how we kind of conduct our business. So if you're not familiar with this, please take a look and it is important to understand this. So today, we have HTTP message signatures for OAuth. Justin will walk us through this and discuss it. But we still have a series of five more interims for the coming few weeks. And you can see the list here, OAuth-protected authorization, and that's next week. And then Anthropic and OpenAI agent tech use cases, OAuth agent authorization use cases, and the last one, still the the the topic is TBD. We'll clarify this next time. So that's what we have. Any comments, questions about this? If not, I'm gonna stop sharing, and I share the slides here. And do you have do you have control there? Or
[00:06:58] Justin Richer: No. Not yet. You're gonna have to pass the control over to me.
[00:07:02] Rifaat Shekh-Yusef: See if that works. Hold on.
[00:07:07] Justin Richer: Yep. I don't see it yet.
[00:07:09] Rifaat Shekh-Yusef: Hold on.
[00:07:10] Justin Richer: Oh, you know, I can stop asking for slides. It might work that way. There we go. I've got it. Yep. I've got it. Thank you so much.
[00:07:20] Rifaat Shekh-Yusef: Okay. Yep.
[00:07:22] Justin Richer: Alright. Hey, everybody. First off, thanks to the OAuth chairs for pulling this together. The annual, schedule was, very packed, so it's, it'll be good to have a chance to discuss this in a little bit more depth. So today, I am talking about a proposal that I first pulled up a few years ago, and there wasn't an audience for that yet. But it's come up again in recent conversations, And that's using HTTP message signatures for OAuth proof of possession. Now HTTP Bis, just very quickly, I'm not gonna go into a ton of details here, defined in RFC nine four two one, and it's a detached signature mechanism for HTTP. It's got all sorts of really neat features on it. The most important thing is that it is very HTTP native because this came out of the HTTP working group. And, know a bunch of the folks that are on the call, had, had a hand at poking at that while it was under development as well. So thanks to everyone who provided feedback and implementations and whatnot. And you can check it out, most importantly at htbsig.org and play around with it. See see what it looks like. Throw some messages and keys at it and see see what's going on. Though caveat on tool there, that is still running off of the, the slightly janky, Python implementation that I wrote myself a few years ago now. So, you may find some edge cases, and if you do, on htsig.org. And if you do, let me know. File up, like, report. Anyway, h t b sig, works by basically taking the message, either request a response as input in general and creating a general normalized, signature base to actually do your crypto operations over. Importantly here, there's a couple of things that it doesn't specify, and that's choosing what to sign and choosing your key material. We'll come back to that and why that's important in just a bit. So if you take an HTTP message, one of the, one quick aside here is that, HTTP Bis works across the, sort of the the headers and the envelope in the message, not the body. So if you wanna cover the body, you can use the, content digest or any of the digest header fields to get, transitive coverage on that. So, here, we've added that, and then we create through a deterministic, process what's called the signature based string. So we've decided to sign the method, the target URI, and the content digest. This is, what you see on the screen. This is the set of bytes that actually gets chucked into the actual crypto primitives. And when you add it to the message, you do it as two different headers. One of them is that signature input line that we saw at the bottom of the signature base string. That basically lets the other side reconstruct the, the signature base, based on these inputs because HTTP can get all sorts of chopped up in transit, and the bottom line is the signature. The reason that it's two separate things like this is that HTTP Bis had as a core requirement the ability to, to carry multiple signatures on a given message, and this gave us the, the cleanest... Parallel headers gave us the, cleanest syntax to be able to do that. On the verification side, just like before, there's a bunch of stuff that h t v sig requires your application to know, but the core spec itself doesn't actually specify. So figuring out which signatures are yours in case somebody else has another signature on that, and you may or may not care about that depending on your application. It doesn't tell you how to get the keys. It doesn't tell you how to figure out whether the parts of the message that are covered are sufficiently covered for your application. That is up for your application to define. But what you basically do is you take that signature... You take that message and the signature input line. You, recreate that signature base string, again, using this, deterministic process to create that generalized, input string, run that through whatever crypto primitive, verifier function against the keys that you found, and, and figure it out from there. See whether or not the signature validates and, it makes you happy. So we created HTTPSIG, and all of this is in the, you know, the annals of the IATF, because HTTP is super, super, super, super weird. And there were all kinds of very peculiar cases and data encoding deals and stuff like that that, need to be covered in a general purpose HTTP bound, signing mechanism. There are encapsulation and replication, practices that you can, you can use to sign an HTTP message. Those exist. They have their uses, but there are a lot of use cases for, I just need to sign this message. I need to prove possession of something that's bound to this message that those are not really a great fit for. So here's the real topic of today's meeting. How do we take this and apply it to OAuth? All those things that I had started on the previous slide, basically, we we we decide those. We figure out, what we require, in the signature, how we associate keys to the message and the token being presented, and how we decide on algorithms and required parameters and all that other stuff. This has all been... A a proposal for this has all been hashed out in, the draft draft-richer-oauth-httpsig. Huge thanks to, my coauthors, some of which are new since the Vienna meeting. So big thanks to, Aaron, Paul, Filip, and Christian, and we, all kind of dug into this to figure out, like, what what would be a good starting point for this. So I'm gonna roll through what what we actually have here. First off, we are looking at how we sign, for presenting access tokens to an RS. So, clearly, we wanna sign the authorization header. We're pretty sure we wanna always sign the method and the target URI. There might be other things, but this is the kind of thing that we, as a working group, should, should debate how we want to how we want to do that. The current draft leaves this as a, as an open question for discussion if there's anything beyond that list. Now in working through the use cases that people have been talking about for this, we're, we've come up with two different ways to introduce keys, and we do think that this is important. The first one is that if you have keys registered to your client because a lot of clients have a whole bunch of other reasons to use cryptographic keys, well, we can reuse that. So there's the HTTP Bis bound access token metadata, and there's there's all sorts of stuff that you can do that. And there's this preregistered thing, that you can do. And, I'm realizing that might actually have drifted since the latest, draft because Filip had a good comment on that one. So this might not be precisely accurate, for the parameter name, but the basic deal is that you tell the AS what your key is ahead of time or tell the AS how do you fetch that key with, like, a JWKS URI. And, then when you're signing the message, you choose the key and move on with your life. At runtime, we also have plenty of cases where we want to, introduce a key in line just like DPoP does. To me, this is one of the most brilliant things of DPoP is that it allows this dynamic key introduction that is then strongly bound to the token downstream. So we are going to, like DPoP, pass the key by value. But unlike DPoP, we're going to lean on the, the power in, HTTP, structured fields. And instead of, having this tightly tied to, JOSE algorithms and, JOSE key types and whatnot, we wanna be able to pass the public key value as just a simple signature input parameter. And, so that's specified in the, in the text itself. And, the draft uses a, sort of a base 64 encoded raw raw public key value with some transformations on on how to get that for various key types. We love feedback about, how that works. Importantly, this, this sort of splits the world between sort of more traditional OAuth JOSE type of validation system and a more dynamic HTTP Bis type of validation method. After a small amount of debate among the team, we think that this is a reasonable trade off. But, again, this is something that if we bring this in as a working group item, we would wanna figure out. So to request a token, yep, just like with DPoP, you have to sign the request with the key that you're using to, to bind the token to, and, you include your parameters, including the tag of h t b sig OAuth token request in the signature itself. If you're using a preregistered key, you identify it, and you, identify, you find out which algorithm, is supposed to be used based on the key information. If you instead are passing the key at runtime, you include the key by value, and you include the algorithm, by value in the presentation signature. The h t p six spec, discourages use of the algorithm parameter, but because this key is being presented in a trust on first use model that also might include client authentication and other client level things, this is a, this is a pretty reasonable way to, to tie these bits together. We think anyway. That's that's sort of our opening proposition here. For the AS to issue a token, you gotta validate the client's request, including validating signature and, digest and all that other stuff. Make sure that the key maps to the client or that the key being presented at runtime is the key that was used to sign the message. All pretty basic stuff here. And then just like you would do with DPoP, MTLS, or any other proof of possession key mechanism, you attach the token to the key. And what that means to you as an AS depends on your deployment. Yeah. You could have it as a pointer into a key store or keep a URL around or bunch of different things. I wanna point out here that the token can still be absolutely anything, but it has a new token type of HTTP Bis. So the response looks like this. You get your access token just like normal. Token type is HTTP Bis, following what DPoP did here, and don't get me started on MTLS not inventing its own thing. That's a rant for, hopefully, another conversation. Anyway, to use an HTTP Bis token at an RS, you present it in the authorization header, and you sign the request. And this is where one of the interesting debates comes, and we saw this when, FAPI Group was profiling this work is, whether or not and how you include other parts of the request in the signature. So, yeah, this this would be a great place to have some input into, how that could actually be structured. To... This this is what a, an RS request could look like. We've got the authorization header, and then in the signature input line, I highlighted here that the tag is this fixed value of h t v sig OAuth. That's how the RS's processing stack can basically pluck the signature off of the incoming message and validate it to figure out what's actually going on here. To do that, you read the token off the message, figure out what key you're using. So is this token supposed to have a preregistered key? Is it supposed to be tied to something that we saw at runtime or whatever? We are leaning heavily on using the confirmation claim that's in... That's defined for both JWT and introspection. And if you have some internal proprietary way to do key lookup, go do that. We kinda don't care. To do the new HTTP sig algorithm method for the runtime key presentation, we are proposing a new subclaim for confirmation so that the keys there can can share a format, and there's no confusion with JOSE algorithms. Then, yeah, you validate the signature. Make sure the stuff that you need covered is covered and, do the math. So confirmation for a preregistered key, looks like you would expect, any type of JOSE based system. So DPoP can use something similar here, or, client authentication, bunch of other stuff could use that. Runtime key confirmation instead of using, JWK as the format, we use the two h d b sig parameters of algorithm and the public key value. These inherit the format and, encodings that are used, in the h two b sig spec itself. There's also... We realized when kind of digging into this, there's a whole bunch of different places where we could apply h t b sig to OAuth, but we didn't wanna step out of the gate and do everything all at once. Just like MTLS, we could use this with a pre placed key for client authentication. It could be used as part of registration. You can do... Is already profiling parts of this for, using a non, nonrepudiation. You can introduce keys, during registration time. There's probably a good way to loop in the accepts... The accept signature semantics for an RS to be able to say, like, okay. Yes. Your token is fine, but your signature also needs to cover other things in order for me to actually process it. That's all built into h t p six, so it's up... It would be up to the spec to decide how we actually wanna use that negotiation mechanism. And there's probably a bunch of other stuff. We didn't want to pile all of that in on one and have this be a what if wish list of, of half baked ideas. So all of the half baked ideas are in the appendix to determine whether or not we actually want to complete baking them. That metaphor got weird. So now to address the elephant in the room. What about DPoP? Honestly, DPoP is great. Yeah. DPoP works very well, for a whole lot of different use cases, but it's got limited coverage by design because of the use cases that Deepop was designed to actually cover and carry. And, any Deepop implementer will, tell you that JOSE is not a good fit for HTTP. DPoP is probably the best, the best crack at it that I've seen, to date. And I say this is someone who's responsible for at least a couple of other, iterations on, on using JOSE for HTTP before before DPoP, made its way out of the IETf. But because JOSE is designed as a, really sort of a a contained cryptographic envelope type of mechanism, you have to have everything internal. And that's not a good fit for messages they're gonna be changing, messages that need to be sort of stacked and carried and all of this other stuff. So at the end of the day, if DPoP works for you, that's awesome. However, we have a whole bunch of people, out there that DPoP's not working so great, and there are people that are already building out their own variations on using HTTP Bis to protect OAuth or OAuth like things in the wild. And, I really think that they can, exist side by side. And quite honestly, I think that this work can really apply a lot of the learnings from, DPoP and MTLS deployments that we've seen over the last number of years in order to make sure that this is, chosen by engineers in use cases where it makes the most sense. So we're proposing this. We'd like to see it, come to the working group, in an adoption call. We wanna pull in a whole bunch of learnings from people who have built out deep op, MTLS, and all of these other systems, especially, you know, key management type of things, key distribution systems, and whatnot. This is this is where systems like this tend to fall over in practice. So let's take those learnings in and then figure out if we wanna do any of the weird stuff in the appendix also either in this draft or something else. That's all I have for content today. And, yeah, happy to take questions and continue the conversation.
[00:24:05] Rifaat Shekh-Yusef: Great. Thanks. Thanks, Justin. So so it seems that you have still a few open issues that you want a feedback from the... With group. So... But before,
[00:24:17] Justin Richer: no. To be to be... I... Just just to be clear, we would love feedback, but I don't consider any of those open issues before this would go, up for an adoption call. I think that everything that we've identified is stuff that could be done as a working group item.
[00:24:33] Rifaat Shekh-Yusef: Yeah. Exactly. So so that's that's the reason I was was about to complete my sentence. So so that Sorry. Sorry. No worries. No worries. So so maybe, like, before we kind of dig into those, anybody has any thoughts about the the draft and the idea at the high level? Yeah. Yaroslav.
[00:24:58] Yaroslav Rosomakho: Hi. Great work. Big fan. I think that this is a really large problem space, and perhaps it's worth to maybe not try and do everything all at once in a single draft, but Mhmm. Somehow split it in individual building blocks that will be built on top of HTTP message signatures and kinda second piece of feedback. I personally find kinda... It overlaps with DPoP, but not really a little bit confusing. Maybe it's worth just say that this will deprecate DPoP eventually and figure out what's the best way to do that because there is an overlap, and I'm not sure if that's a good thing.
[00:25:52] Rifaat Shekh-Yusef: Okay.
[00:25:52] Justin Richer: I I will say that from my perspective from the beginning, this wouldn't deprecate DPoP, because I think DPoP absolutely will continue to have a a home in, in Jose heavy deployments, especially, where that's the toolbox that you have. It's a really easy thing to be able to apply it in that space. Not everything is is Jose native, though.
[00:26:21] Rifaat Shekh-Yusef: Okay. Christian?
[00:26:24] Christian Bormann: That would have been pretty much my comment as well. I I don't think the goal is is to do the deprecate DPoP, but to have... I think in the long run, we will likely have more than one proof of possession mechanism, and and this is basically another approach to this. And it has or provides other features and properties, and I think that is valuable. So, for example, one of the things where where I'm interested in it, one of the feedbacks we... We've gotten with is it would be really nice if you can also start protecting the payload, the HTTP body. And, yeah, for the use cases where where you want that DPoP is probably not the best fit right now. Maybe this is.
[00:27:05] Rifaat Shekh-Yusef: Okay. Pieter?
[00:27:10] Pieter Kasselman: Yeah. A similar comment to, I think, the the previous one, and, Justin, to your thoughts as well. I would be careful about signaling deprecation of anything because it might... You know, this is where we get to the perfecting enemy of good kind of story. And so I don't I don't think it's a signal about deprecation. I think the way Christian talked about it is is much more... I I I do think it it solves different classes of problems in different circumstances, but I I think we don't... Token theft is a big enough problem. We shouldn't discourage people from using some of the tools that's already available.
[00:27:50] Rifaat Shekh-Yusef: Yeah. Thanks, Pieter. Brian, you have a comment in the chat there. Do you wanna talk to that comment? Brian?
[00:28:06] Brian Campbell: I mean, most... Mostly just what it says there, like, I'm... I haven't really heard these use cases that need this more power and coverage articulated in a meaningful way other than people want it. And I'm I'm not convinced that it warrants the confusion of introducing yet another way of doing something similar to the same kind of confusion we've even seen in the last couple of minutes talking about this, like, whether this is deprecating, whether it's... Exist on... Alongside, whether it's... There's more than one, to my point. There... Like, there's already more than one. So it just... It it feels like, an unnecessary thing at this stage and and probably ever, but that's, but one man's opinion.
[00:29:14] Hannes Tschofenig: Yeah. So... Go go ahead, Justin. No. Go ahead. Go ahead, Rifaat.
[00:29:19] Rifaat Shekh-Yusef: Yeah. I just... Maybe maybe it is it is worth kind of spending a little bit more time since we still have time here to talk about the use cases that you see that is really not covered by the other use cases. So forget about, like, the details of that mechanism. I think people probably got the the idea. But, like, why is it is it... What use cases this cover that others don't cover, really?
[00:29:46] Justin Richer: Yeah. So we've actually seen a few calls to the OAuth working group to add stuff to the DPoP envelope, things like a a body hash or a header coverage or things like that. And the OAuth working group has correctly, I would say, been hesitant to add more things to that envelope for a lot of good reasons. You know, you've got data replication problems, which has its own issue of you need to make sure that the replicated data actually matches, in the crypto envelope matches the canonical value that was passed in outside the envelope. So you've got a normalization problem there, that we would then have to invent, the appropriate machinery for. And so I think that it makes more sense for us to have a a proof of possession mechanism that ties to something that already solves those fundamental problems, which is HTTP SIG, and say how that applies to OAuth. The other reason for this is that people are just already doing this kind of thing out in the wild, and I feel like the OAuth... This is something the OAuth working group ought to have an opinion about. What I've largely seen is people just doing the very, very simple thing of saying, I'm gonna put an HTTP signature on a message with an OAuth bearer token, and then my system just kind of goes and and picks it up, and and says the bearer token is not really a bearer token. So I think that we can do better than that. I think that we can apply, a lot of the lessons from DPoP and whatnot into those into those use cases that we're already seeing out there.
[00:31:33] Rifaat Shekh-Yusef: Yaroslav.
[00:31:36] Yaroslav Rosomakho: Right. One of the use cases, and I'm sure Brian will smack me in a minute, is proof of possession for refresh tokens, especially for badly implemented confidential clients where deep hop is not applicable. So this is this is, for example, an area that I would really like to explore.
[00:32:01] Rifaat Shekh-Yusef: Brian?
[00:32:03] Brian Campbell: Happy to smack you, Yaroslav. I... I'm... I I am curious how you think that badly implemented confidential clients will somehow be able to get this right in a way that solves your problem. But maybe... I don't know. Maybe I'm missing the bigger picture. Justin has done a great job of working with the difficulties of an increase... Intricacies of of HTTP and and getting that into something that is an RFC around HTTP message signatures, but it... It's still not simple. Like, there's a lot there. It's complicated. And so the idea that somehow already badly implemented things will will just, like, get it right with this. I don't know. Maybe AI solves it or it'll be great. That that just doesn't kinda track for me. But I wanted to step back to, again, use cases. Like, I hear you're saying people are asking for headers. They're asking for body. And I know I've heard some of those things. But what I haven't heard articulated is a meaningful reason for wanting those things that's actually necessary. And so I I do sort of agree we shouldn't be overloading DPoP with a bunch of other stuff for the number of reasons that you pointed out, but I'm I'm still not convinced that there are or what these... What the real need is behind these apps.
[00:33:33] Rifaat Shekh-Yusef: So, Brian
[00:33:34] Pieter Kasselman: I can...
[00:33:35] Rifaat Shekh-Yusef: Versus, like, improving the existing mechanisms. Is that what you're saying? Or you're saying you don't understand the the new... If if there is a new requirement either.
[00:33:45] Brian Campbell: Yeah. The the the real new new or whatever requirements behind things like having the the body or content or whatever we're calling it these days covered in in the signature as part of the proof. Okay.
[00:34:00] Justin Richer: Yeah. I can actually speak to that. So the the reasons tend to be twofold. It's either the shape of the API itself that's being protected, requires differentiation of functionality based on those things. So having those outside of the protection envelope limits the security applicability of the protection mechanism. And so being able to bind something to a request that has different header values or that has different entity body values is is something that people, in my direct experience deploying this with with different folks, have directly asked for. The other thing, and this is actually related, is that how do we expect people to actually get this right? Because, yeah, it is really, really complicated. I think that that is actually an argument for not inventing more ways to add that into something like DPoP. DPoP, I think, hits that line between the sort of good enough to get done a lot of things and easy enough to probably get it right, assuming that you've got something that implements Jose correctly in the first place. By leaning on a different mechanism in the same way that MTLS leans on a different defined mechanism for the details of protecting and binding the message, that's what I would wanna see this really do. So, I I hear and I I agree with your concern. Where I differ is the conclusion that I draw from it because I see that as a... As one of the motivating factors here.
[00:35:40] Rifaat Shekh-Yusef: Brian, are you still in the queue? Or... Okay. Okay. Aaron.
[00:35:49] Aaron Parecki: Justin kinda hit on some of the things I wanted to say, but I think the, to me, the implementation difficulty of this, it... It's definitely high. I have written codes to influence the earlier cabbage h t b signatures from scratch, and it... It's not it's not easy. However, I think that's exactly the point of doing this, which is this can... This will end up being done at an actual act... Actual HTTP layer. So curl already implemented HTTP signatures now, which means if you want to apply this profile and you're using CURL, you no longer write any of the actual HTTP message bits. You tell the library what to do. And, yes, this is only one library out of many that exist, but that is the direction that I think the libraries will go. And to me, that makes it significantly easier to implement for someone even compared to DPoP where you have to kind of do a little bit more of it by hand, assuming you are still using a JWT library, which I hope you are. But, yeah, I guess the point is I agree that implementation is difficult, but this lets us push that difficult part into a layer that most application developers won't be dealing with. And that seems like the correct, layering to me.
[00:37:18] Rifaat Shekh-Yusef: Okay. Thanks, Aaron. Filip?
[00:37:23] Filip Skokan: Aaron sort of stole stole my thoughts here. Nevertheless, I would like to draw a parallel to MTLS. We're not implementing MTLS if we have MTLS under constraining or MTLS client auth in our libraries anyway, or we're not implementing those complicated MTLS and TLS bits neither. We rely on the m t... On the TLS stack, on the HTTP stack to do that for us. And with the adoption of RFC ninety four twenty one by curl, we see... We start to see more of that sort of trend finally appearing so that HTTP message signatures being complicated, I don't see as an obstacle anymore.
[00:38:10] Rifaat Shekh-Yusef: Okay. Thanks, Filip. Christian?
[00:38:14] Christian Bormann: Aaron made quite a few of the points I wanted to make, and I would like to add. One of the things that I... And I'm I'm rather new to HTTP message signatures. One of the things I learned to somewhat like is also how easy it is to configure what to sign over because it is rather difficult to do, like, a decent extension point. So so if you would decide we we want to extend deep hop and then gives the possibility to also sign over certain headers because you probably don't want to sign over all headers. It becomes quite a mess. And I... Like, from the tools we have right now, this this feels the the least messy, I would say, if we agree that this is a problem we want to solve.
[00:38:56] Rifaat Shekh-Yusef: Okay. Thanks, Christian. I don't know how to pronounce that name. Are you gonna...
[00:39:03] krooj: Sorry. It's just it's just the handle. So... Hey. This is Michael. Hey, Justin. I have a question for you just from glancing at this. So with DPoP, you... Client, sort of, it it provides us intent through the through the authorization by providing that DPoP, thumbprint. If you have some sort of, like, ill behaved client or something, there's a conflict between DPoP and this approach. So let's say they they initiate an authorization with the with the DPoP thumbprint, then they come back and they're starting to use this message signature mechanism on the code
[00:39:35] Yaroslav Rosomakho: to token
[00:39:35] krooj: exchange. Is there is there some guidance that's gonna be provided on sort of, like, what supersedes what or, you know, whether or not that just presents an error state?
[00:39:46] Justin Richer: Yeah. That's a great question. So the DPoP equivalent where you're presenting things at at runtime like this, you... If you could not... And nothing in HTTP is stopping you from sending both this and a DPoP proof at the same time, and the HTTP layer doesn't care. I do think that that's the kind of thing that we would need to figure out. I personally don't see a lot of value in there being some sort of ordered precedence. I do think that that would be kind of a failed error state because you would basically be saying, give me a token that's bound to two different keys over two different presentation mechanisms. And I don't think we wanna be in the business of defining what that is in combination. That's my take on it, but, yeah, great great call out.
[00:40:36] Filip Skokan: I believe I I believe this is already distinctly prohibited. You cannot have a confirmation claim that describes two different keys, or rather you cannot have two different confirmation claims inside CNF bound to different keys. The caveat there, what if it's the same key? I don't know. I just prohibited it.
[00:41:00] Rifaat Shekh-Yusef: Okay. Sorry, Michael. Is that your name, Michael? Is that... What... What's your Yeah.
[00:41:06] krooj: Yeah. I... I'm sorry. I just... When it goes through, like, the... Through... When it goes through the sign in process, I... I'll I'll I'll fix, like, the whatever, like, the profile information looks like. Yeah. Sorry. Yeah. It's krooj.
[00:41:19] Rifaat Shekh-Yusef: Michael what? Like...
[00:41:20] krooj: Had a... The Kruger. Kruger.
[00:41:23] Justin Richer: Just just for the notes, I'm I'm guessing. Yeah.
[00:41:26] Rifaat Shekh-Yusef: Thank you, Michael. Dick?
[00:41:30] Dick Hardt: I'm excited to see some use of, HP message signatures, hitting into Oauth. You know, I was pessimistic about HP message signatures when you started the work, and feel you guys did a great job of addressing what have been issues around detached signatures, around canonicalization stuff. And I think that's been proven out. You know, we're using HP message signatures and the signature key, auth stuff. You know, WebAuthn is using HP message signatures. So Some easy work doing that. HP messages are in the email verification protocol, and people have been able to deploy stuff that interops pretty well. So I think that says a lot for the, HP signature spec for interop. I'm wondering how with this work and how this... Know, you there's a bunch of other places where suddenly using HP message signatures has become fairly popular. How are all these things going to fit together? You know, I proposed the signature key spec in HP BIS, and then I view that a generic mechanism for signing things and move... Well, for how do you get the key would be useful. You know, that built upon the experience that people had in the WebAuthn work, which is why he joined me as a coauthor on that work. You know, we're using that in the email verification protocol. You were pessimistic about it being, adopted in HTTPbis, but it seems like it would be more useful for this to be more like an MTLS thing that could be used for how can any client make a call and authenticate similar to how... You know, we now have DNSSEC and TLS and let's encrypt that have ripped out the friction for... In an HP point of view, know who the server is, then we could do the same thing for knowing who the client is. The application of this is much, much broader than just OAuth. So maybe you could speak a bit to why you think that OAuth needs something specific and why general tools wouldn't be better because we had more general mechanisms that would go and verify the signature and nowhere to get the key, then that would be widely deployed and reused in many places.
[00:44:05] Justin Richer: Yeah. Happy to talk to that. The key distribution is one of the hardest problems of any signing based system, especially when you're dealing with, proving the I... The effective identity of a piece of software. And so, one of the things that I think...
[00:44:26] Rifaat Shekh-Yusef: Uh-oh. Oh, we lost...
[00:44:30] Justin Richer: Yeah. My...
[00:44:31] Rifaat Shekh-Yusef: Okay. Try again.
[00:44:33] Justin Richer: Yeah. Not sure where I cut off.
[00:44:37] Rifaat Shekh-Yusef: Yeah. Start start from the beginning.
[00:44:39] Justin Richer: Yeah.
[00:44:39] Rifaat Shekh-Yusef: Yeah.
[00:44:39] Aaron Parecki: So
[00:44:42] Justin Richer: so in any case, the key distribution is one of the hardest one of the hardest problems with something like this. And the association of the key to the right piece of software, the right source material, I think, is really foundational, and that is something that the semantics of which are bound to the protocol that is defining what that relationship is because that's defining what the entities are. We're not trying to, have something here that is generic HTTP client signs a message. We already have that. That's HTTP Message Signatures. What we're trying to say is that in this... In the OAuth protocol, there are a few different places where you can introduce the key, either as part of the client registration, because that's a concept that exists in the OAuth world, we can use that, and as part of a token request, because, again, that is part of something that makes sense in the OAuth world. I believe that I have posted to the HTTP list at length about the signature key proposal and and what's going on there. And so, yeah, I don't think that there is actually a good place to, genericize this because that would, divorce it of the semantic meaning, the teeth that really make the key introductions make sense and be trustable.
[00:46:09] Dick Hardt: But we have generic mechanisms for key for the server for HTTP.
[00:46:14] Justin Richer: No. We don't. We have mechanisms that are tied to TLS. Yeah. And that's not part of HTTP. That's part of the TLS handshake and WebPKI because that's at a different layer. That's that's at a more foundational socket layer. This is about tying the things that are at the that are up at the higher layer.
[00:46:39] Dick Hardt: Yeah. I realize that. I'm saying from a developer, we're just gonna find out. Oh, if you just wanna dismiss it without talking about it, Justin, you you can.
[00:46:50] Justin Richer: But I'm not sure why you're saying that because, we are talking about it, Dick.
[00:46:55] Dick Hardt: Well, from a developer perspective, TLS solves that problem around knowing the identity, and we've just got a standardized mechanism for key delivery. And so a standardized mechanism for key delivery for a client seems like that would be something useful as opposed to it being bespoke for each protocol.
[00:47:19] Hannes Tschofenig: I think what... This is Hannes here. I think what we have in in in HTTP is a mechanism with ACME, the mechanism to get to request a certificate for a server automatically. It's a good question whether that can be extended or generalized also to what we are doing here Because the the the interesting aspect... There is obviously a relationship because the one piece which is common here is we are requesting kind of a in a in our case, the token. But... So that's the common part. But what differs is the... In ACME, there's an authorization step to verify whether I'm actually owner of the domain. So that's that's a little different. So interesting thought, Dick, which we probably should think of a little bit more about.
[00:48:29] Dick Hardt: Yeah. I'm just saying that and that, you know, if from a... When you rise up to what a developer wants to do, they wanna be able to prove their particular client, which means they wanna be able to say it's a particular durable identifier, and we wanna be able to use proof of possession to do that. And they don't really care about the key or how the key moves around. Right? They just would like to have that. And that's what they get when they go to a server as they put in the server with HTTPS, and they know that they're talking to that server. And they don't need to worry about all the other layers. So my argument is I think we... You know, MTLS doesn't work given how infrastructure works. So having the client using it on that side is not there, and that there seems like there's maybe an opportunity as people are using HTTPSIG in a number of ways that there's... Seems like there is a general pattern. You know, there's a number of key distribution mechanisms for how to prove who signed something using that well known and JWK S URIs, and we could use those mechanisms for how do you get the key. You know? Web Auth is doing that.
[00:49:44] Justin Richer: Yeah. Except that, Oauth clients, most of them don't have a domain, and you can't expand them to. Some do, and I think Aaron's got a lot of thoughts about that.
[00:49:56] Aaron Parecki: Yeah. I was gonna say, can I jump in here? It sounds to me like that what I'm hearing is one of the use cases that's described in the appendix, or if it's not, it should be. But it... That feels like fundamentally different than just access token proof of possession. But I a 100% agree. Solving client identity with HTTP message message signatures is also very useful. And if you take the approach of... That client ID metadata does where you say, this is how clients represent themselves on the Internet the same way this is how an OAuth server represents itself on the Internet, then things do fall into place pretty well, and you could very easily slot HTTP message signing into that to prove client identity. And I do think that would be useful, and I would like to do that. It does feel like a slightly different problem than just straight access token proof of possession with self introduced keys. But I think that's why Justin mentioned at the beginning that there's, like, a bunch of different places where this... Where message signatures can apply in the OAuth stack, and we should decide which of those are worth tackling and and how many different kinds of documents.
[00:51:08] Dick Hardt: Yeah. So I agree. You know, there's definitely a number of specific big things because of how OAuth works. And when you use the word client, I don't think of just OAuth client. I think of any HTTP client. And, you know, there's a lot of work going in a number of different places where a client is proving who it is by saying, go back here to get my key.
[00:51:33] Aaron Parecki: Yeah. And I agree that's a useful thing, and it's a, I would like to do that with message signing, but it does feel like it's a different scope of problem than the bulk of this draft right now.
[00:51:54] Hannes Tschofenig: One thing in in this contact that came to my mind is in in the early decades when the work on the CSR, the certificate signing request started, there was a debate on whether it's useful to include a signature when you actually, in a runtime setting, establish the key because you're obviously just minting the the public private key pair, and then you are using your own private key to sign the message. And so there, if you omit that signature, you you do not demonstrate that you own the private key, but then even if if you just pretend you would be doing so, you wouldn't be able to use the token afterwards or the certificate in the PKI sense. Now, obviously, history went a different path. But very recently, with the work on PQC, it turns out that signatures are more costly than just like like in the past. And so, again, this debate was resurrected and people were wondering, like, is it actually a good idea to do that signature on the CSR? Could we just omit that altogether? And maybe that's also worthwhile to think about that design decision which which was made also in DPoP in terms of performance optimization of not signing the the initial request in in that way. Just a just a thought, another item in the to do list, but yeah. So there are a couple of interesting open questions as we just realized.
[00:53:37] Justin Richer: Yeah. And I think that there's a lot of there's a lot of important details like that that we wanna have a lot of people weighing in on for this to to go forward in an interoperable way.
[00:53:54] Hannes Tschofenig: Rifaat. Yeah. I think, like, obviously, great discussion. Thank you all for the input. Rifaat, should we check what the people on the call think about sort of an adoption call. But, like, I know that there are lots of design question that need to be resolved, but the working group itself would be a good place to resolve this... The details. I want to get a sense of the group.
[00:54:29] Rifaat Shekh-Yusef: Yeah. We could we could do that here. Obviously, the official one will be on the on the mailing list. Right? So I'm going to... Let's see. I'm gonna write a question here and start it in a second.
[00:55:14] Hannes Tschofenig: And we can always later find out on, like, how many documents this would be as some people proposed. There's obviously a lot of different different pieces, components in there. So it's a document management issue.
[00:55:31] Rifaat Shekh-Yusef: Okay. I've started a poll here. Please take a look and chime in. Obviously, we have a very limited number of people here. So okay. Okay. Few more seconds. I'm gonna close it. Okay. We have ten years, three no, and two no opinion. We we are running out of time, but, like, if if the the people that says no would like to say a word or two before before close here. Obviously, this will go to the list. Right? So what the... Go ahead, Dick.
[00:56:49] Dick Hardt: I'm a big fan of using this to solve the problems that are very OAuth specific that would not be able to be used generically anywhere else. I worry about the... It leading into a generic, way for clients to authenticate, and then I think that I don't know that that actually fits into OAuth, or that should be a separate document. So those are two two very different things.
[00:57:20] Rifaat Shekh-Yusef: Okay. Okay. Anybody else? Okay. Well, we'll text this to the list, but that that was a really great discussion here, guys. It's it's it's an interesting problem, and it's an interesting idea. But let's see how it goes. We'll start our call for adoption on the on the list and see how it goes. Okay?
[00:57:58] Hannes Tschofenig: Yeah. And please continue discussion on some of the the raised open issues as well. Right. There was some
[00:58:07] Rifaat Shekh-Yusef: good stuff there. Exactly. So so if we can start that discussion on the list and be ready also to talk about this in in San Francisco, that that... That'd be great. Okay. That's all we have. Anybody else have any comments before we close here? Okay. Thank you all, and see you next week.
[00:58:36] Hannes Tschofenig: Thank you all. Bye. Bye.
[00:58:40] Christian Bormann: Bye.