Session Date/Time: 23 Jul 2026 12:00
[00:00:32] Rifaat Shekh-Yusef: Okay. Let's get going. Welcome, everyone. This is Oauth. Let's get going. A note well, a reminder that note well applies. This covers everything that we do at the IETf. And so please be respectful, be professional, and make sure to read more about this because this important for IPR related stuff beyond the the behavior that that we expect from everyone here. Right? Tips, please make sure that you log in to the data tracker that helps us evaluate how many people show up to those meetings and plan for future meetings. It will also help you get into the queue and ask questions if you need to. For remote participants, please make sure that audio and video are off, and use headset, please, if you can. And if you speak up, please make sure you state your name. Okay. Quick update on the from the working group. So we have the first-party-apps is waiting for the we we've done that workgroup last call, and we're waiting for the Shepard write up. So that's gonna happen, after Vienna. Transactions token or transaction tokens will start, I think, a third work group last call. Is that Peter, is that correct? Yeah. Okay. So, hopefully, we'll start that after Vienna. Another document that is really important, and we would like to make progress on it, and we haven't been doing much on that document, is oauth-v2-1. So we are looking for volunteers or people to review it. Here is in the there you go. So you wanna capture. Okay. We have four people. So we have Nick. We have, Yaron Sheffer. Yeah. K. Perfect. Thank you all. Appreciate that. Aaron, do you wanna say anything about this? It's good?
[00:03:06] Aaron Parecki: Yes. Hi, Aaron Parecki. Yes, please. All the help with OAuth 2.1 would be appreciated. But I also wanted to update on the browser based apps draft, which is another one that has been long long in progress and is an input into OAuth 2.1. It is in the RFC editor queue now, and I've been working on processing their feedback. So it is, in fact, already has its RFC number assigned, which is very exciting. But, yes, it's in the queue. So k. I'm I'm excited for that one to be Awesome. Moving forward as well.
[00:03:39] Rifaat Shekh-Yusef: Perfect. Thanks, Aaron. Okay. So I wanna talk about the the number of requests that we got this time because it was really massive number of requests for presentations. So and this we expect this challenge to stay with us for a year or two. So we're trying to manage this. We will also discuss this on Friday, but I just wanna give you a heads up that we we will need to kind of filter lots of those and and and reject some of those requests just because of the sheer amount of requests that's coming our way. From from a church perspective, like, it it's just impossible to accommodate everyone. Right? So if you want a request, if you want something to present, then you need to do a few things to help us kind of get you time on the on the on the work group. Right? So you need to have discussion on the mailing list. Right? So start a thread on the mailing list and engage the working group and the team. You need to show that that there are multiple parties interested in this topic. It's not just one person or or one one party. Right? That that shows that the the community is interested in this work, so we'll prioritize this work. Right? And, obviously, interest from from the community to to to deploy and and implement and deploy this work. Right? So so these are important things that you could do to kind of help us kind of prioritize that work. Right? Ani, is there anything else?
[00:05:30] Hannes Tschofenig: No. I just reiterating what you
[00:05:33] Aaron Parecki: said, like, it's important not just to write the document, but also have other people care about the document. Because after all, we care about interoperability. We want we need to have other people convinced that this is actually something useful because, like, it's not just a conference where
[00:05:51] Hannes Tschofenig: we present stuff. We actually want to make some some forward progress. And while many of you do that, you reach out to other companies, you see whether the industry has a problem and that needs to be solved, but not everyone does. And now we see more requests for whatever reason than before. Yeah.
[00:06:11] Rifaat Shekh-Yusef: Yeah. Okay. Awesome. Thank you. Any anybody has any comments, questions about this topic? This is again, we will discuss this in in we'll spend more time on this on Friday. But, Doug, if anybody has any question, comment right now, just go to the mic, please. Okay. Good. Okay. So, we have to this to this session, and we have still another session tomorrow. So today, we have a number of work group drafts. So we'll start with the Erin and or or Brian or both talking about identity assertion JWT authorizing grant. Then Erin will talk about the Client ID Metadata Document. I think Pedram Hosseini will be talking about the Updates to OAuth 2.0 Security Best Current Practice, and Arndt will be talking about the SPIFFE client application. So these are the work group drafts that we'll be discussing today. There is one more that we'll discuss on Friday. Individual drafts, Yaroslav is he here? Yeah. Perfect. Good. So he's gonna be talking about OAuth Transaction Authorization Challenge. So these are the drafts that we're gonna start with, and then we have kind of allocated some time to talk about agent authorization use cases and gaps. Dick Hardt will start kick us off with with. Mike Jones will be talking about a KYAPay Technologies, And then a Mailing Huang will be talking about Agent Authorization use cases and gap analysis. So we'll do those presentations first, and then we'll get all the authors here in the front of the room, and then you can ask questions to any one of them. Okay? And have a discussion after that. Okay? Okay. Good? Any okay. And that's our agenda for Friday. We'll talk about that on Friday. Okay? Any agenda bashing? We good? Okay. Aaron or Brian? Just let me see if this works. Clicker. Let's try this.
[00:08:41] Aaron Parecki: That works. Yeah. Great. Hi. Aaron Parecki - First up, Identity Assertion JWT Authorization Grant. So I've got a couple of particular points I wanna discuss here, so I'm gonna go really quickly through the background. So if you're not familiar with that, I'm gonna try to set a little bit of the stage, but hopefully, enough of you have seen this already. This is a profile of the Oauth identity and authorization training draft, which is now submitted to IESG for publication. This profiles the draft further for a more specific use case than that draft. In particular, the idea is to extend the concept of single sign on into API access that Oauth provides. The two main benefits this provides is reduced user friction because we can similar to how single sign on reduces the number of login pages, single sign on for API access reduces the number of times you have to approve OAuth consent screens. And in particular, in enterprise environments, it moves that idea of is this app allowed to do this thing into the enterprise IDP where the admins want it to be to configure configure it. It is built on two building blocks, token exchange and the JWT authorization grant. So it is describing the use of these two together to achieve this goal. So, basically, the app the first app that's trying to get access to some API has the user log in through its normal SSO, which could be OpenID Connect or SAML. And then it that application exchanges that token for a cross domain ID JAG for short. It's the identity JWT authorization grant, which is a JWT that I'll talk about in a second, which it then takes and uses in a JWT authorization grant as described in 7523 to get an access token for the resource. This is what the JWT looks like. It is got similar claims to an ID token because it serves a similar similar purpose, but it also includes specifically the information about who which party this is it's being it's requesting an access token for, including optional scopes for what part of that account is trying to be accessed. Okay. So what's new since the last time we met? There are a lot of new implementations of this. I am actually super, super excited about this. A bunch of them are actually live now. There's a bunch still in progress. Some are open source. Some are closed source, and it actually spans the entire range of all the different roles involved in the flow. So there's a bunch of new clients. There's, quite a lot more resources that support this. There are standalone authorization server products that support this. There's a couple of IDPs, some in progress. And then there's also, really usefully, a bunch of testing tools and blog posts and tutorials explaining how to how this all comes together and how to use it. Rather than mentioning them all by name on the slide, because I'm sure I would forget a couple, I have put a link to the oauth.net page about the spec where I'm trying to collect links out to those implementations. So if you're curious, you can find them there. But, yeah, there's, like, the big the big the big milestone between last time we talked and now is there's just been a ton of community interest in this. So takes me to changes since the last version. Based on the feedback of last time we talked, there's now quite a lot more clarification of terms and background and intro in the spec, in particular, better defining what the name cross app access refers to versus the name ID JAG and the acronym or the not acronym, the short name XAA. Based on some of the discussions, the hallway track discussions at the last IETF, it turns out that there's this is not actually limited to enterprise use cases. That's just how I've been coming at it. But there's actually a couple of use cases that are have nothing to do with the enterprise IDP that could apply this as well. So there was nothing that needed to change about the protocol. So it's really just a bunch of the phrasing and descriptions of the roles we've updated so that it's clear that it applies to these the trust relationships rather than the like, what they actually are. And then there's a new metadata parameter that helps with discovery on both ends for advertising support for this.
[00:13:20] Rifaat Shekh-Yusef: Yeah.
[00:13:23] Aaron Parecki: Let me yeah. We can take questions before I go on.
[00:13:28] Yaron Sheffer: No. No. I I can wait until the end.
[00:13:30] Yaroslav Dobryakov: Okay. One
[00:13:33] Aaron Parecki: of the other big changes was when the resource app that is trying trying to be accessed has a SSO relationship that is SAML based, it is assuming it's going to get SAML shaped things and values in in a SAML SSO, which we needed to reflect in this token that is now being used in place of SSO. So what we did for that was essentially created a JSON structure that represents the same values that you would have in a SAML assertion so that this application can receive the SAML name ID, whatever that might be configured as, which it turns out is wildly all over the place in practice. But this shows up as a new claim in the IDJAG, and this was essentially the blocker for people who were trying to actually build this into products that exist already versus greenfield applications. So with this, it was able to then actually get deployed at a resource server because they can now map users correctly without having to deal with out of band mapping of users. So there's a whole section in the in the spec that talks about how this works and the background for it and how the and the processing rules about it. So it's this is in, I would say, decent shape for the current feature sets. There's a couple of priorities for things that I would consider to be pretty important next steps for this that it's debatable whether we wanna consider them blockers for the draft itself or whether these are extensions, but these are essentially the priorities that are based on, again, what we've been seeing as we were working with everyone who's building this out. The two main priorities are how do we ensure that the users that are showing up at these resource applications can be JIT created because typically they are when they do SSO. And now they may not have an SSO opportunity to create that user, so they need to be created when this API request comes in. And the second one is how do we do key binding in this in this ecosystem, where we wanna actually make sure that not only the IDJAG, but also the final access token is bound to a proof of possession key, like, for example, using Depop. So those are the two main priorities. I have some slides on some suggestions for them, and I want feedback on the direction of those those those topics. So first on JIT provisioning, there is so technically, it already says that custom claims are allowed in the IDJAG, which does enable an IDP to put anything it wants in there that can be useful for the resource. And it would work, but it won't necessarily be interoperable. So the question, and this is a question question for the room, is should this actually be described in a way that makes it more interoperable and and reusable? There's an open issue, 83, that talks about a particular mechanism. And, again, we can pursue that mechanism or look for something else. But that mechanism essentially adds a negotiation step to the flow where if the resource AS receives a token that doesn't have enough claims to create a user, it can respond with a challenge that says, I need these claims. And then the client can include those claims in the token exchange request so that the new IDJI created will contain those claims. This is a there's a lot of things that are not described by this mechanism, like, is it okay for this to happen? Things like that. That's all I would consider out of band, like, internal policy. So this is really just the minimal on the wire protocol to make this work. The one thing this does is it would mean that the the client doesn't have to always ask for these claims and the claims don't always have to be included, which is generally beneficial for security considerations and and and other things. But, like, it's debatable whether the how, like, important that is in this context. Possibly in non enterprise context, it's a little bit more important, but it's debatable. So the question is really, do other people agree with this as a priority to solve either in this draft or as an extension, or is it better just sort of left to fend for themselves in an ecosystem? And I will since we have a queue building up, I will invite some discussion on this before I go to the second topic.
[00:18:19] Rifaat Shekh-Yusef: Some people are saying that they have some, like, some issues with mic your mic. I'm not sure. Do you wanna try and
[00:18:27] Hannes Tschofenig: check check
[00:18:28] Aaron Parecki: Do I need to just speak even closer?
[00:18:31] Rifaat Shekh-Yusef: Is that better, Emilia? Okay. Let's
[00:18:40] Yaroslav Dobryakov: let's ah, okay. Okay.
[00:18:44] Rifaat Shekh-Yusef: Okay. Good. Okay. Yaron.
[00:18:48] Yaron Sheffer: Hello. Yaron Zeravi. I think it's a very good draft, and I really like the architectural layering in the sense that the IDP has a connection to the user within its organization, can reach out to it for approvals or other parties that need to approve. I gave this feedback a couple days ago on the mailing list, but maybe it was not seen yet. But Karl engaged with it, and this is when you include support for authorization details. I think you need some more metadata here for the client to know what to request because those are remote authorization details of the resource AS. So how are they structured, what to request, for the IDP to enforce from, first of all, an interoperability point of view. Are these the right authorization details that can be processed by the resource AS? And the moment that you do some importing and setup by an administrator authorization details, that's the place to put governance. Like, you're trying to talk to Atlassian as the resource AS. If the user is gonna ask for delete rights of tickets, woah, then I wanna trigger these policies, otherwise, other policies. So I think metadata, which I'm gonna talk about tomorrow, really fits in and supports this, and Karl is engaged, the discussion goes on there. Yeah.
[00:19:57] Rifaat Shekh-Yusef: Thank you. Okay. Thanks. It's good. Okay. Justin.
[00:20:04] Justin Richer: Hi, Justin. Richard. So this is more of a sort of, you know, document presence station and structure as opposed to the technical content. Because this document uses two very similar looking processes, JWT assertion grants and token exchange, Some people, as latest this morning, got backwards when they were explaining to somebody else which one is used where. Please help me. I I genuinely I keep forgetting which one is used first and which one is used second. It it to me, I don't have a good intuition for why they are in that order.
[00:20:42] Presenter: Yep.
[00:20:43] Justin Richer: I know that that's covered in the cross domain draft better. I can give you the short version. I would love the short version in the document. Yep. And if the honestly, having the diagram labeled as to which one you're doing where would go a long way to helping that as well.
[00:21:00] Aaron Parecki: Yes. Excellent point.
[00:21:01] Justin Richer: But yes. Okay. If you have the short version now, that's great also.
[00:21:04] Aaron Parecki: But The the short version is the second request that actually gets the access token Yep. Is a conceptually an authorization grant because that's the result of an authorization grant is an access token.
[00:21:15] Yaroslav Dobryakov: Mhmm.
[00:21:16] Aaron Parecki: So that uses the JWT authorization grant spec. But you can get that out of a token exchange too? You can, but you it you don't that's not necessarily the outcome of a token exchange. Yeah.
[00:21:26] Justin Richer: But if you ask for one. So I we we don't need to debate this here, but that Yeah. Yeah. But the debate has already happened. Type of pathing that
[00:21:35] Aaron Parecki: The the the debate has already happened in the identity chaining draft.
[00:21:37] Justin Richer: Totally understand that. I ex and I accept that that that's the structure. I'm I'm asking for more help to remember and understand that structure with the document as as it moves forward. I do think this is great work and very needed.
[00:21:49] Rifaat Shekh-Yusef: Yeah. K. Thanks. Art?
[00:21:52] Arndt Schwenkler: Yeah. I have a bit little context. I did not see the issue, but you have three different authorization service at play.
[00:22:01] Justin Richer: Right?
[00:22:02] Aaron Parecki: Two.
[00:22:03] Arndt Schwenkler: Two. And the enterprise one or, like, IDP?
[00:22:06] Aaron Parecki: The IDP and the resource authorization server.
[00:22:08] Arndt Schwenkler: Okay. And they may have different understanding of the claims. How do you solve that?
[00:22:14] Aaron Parecki: So well, this is yeah. They so similar to scope, they would have to have the same understanding of claims. So the scopes are resource defined. These claims would be resource AS defined. And, yes, the enterprise IDP needs to be aware of both in order to do anything useful with it.
[00:22:32] George Fletcher: Okay.
[00:22:32] Yaroslav Dobryakov: Yeah. Thank you. K.
[00:22:34] Aaron Parecki: It's just a it's just a constraint.
[00:22:36] Yaroslav Dobryakov: Yeah.
[00:22:37] Rifaat Shekh-Yusef: K. Max, keep it quick.
[00:22:40] Max Gerber: Max Gerber, I just wanted to say that the JIT provisioning is a problem for us. We get a certain set of claims back with an ID token that we use to create the user. And if we don't get the same set of claims through this flow, then we're missing information we'd otherwise have.
[00:22:56] Rifaat Shekh-Yusef: Yep. Okay. I see Paul in the queue. Quickly,
[00:23:01] Tony Nadalin: please.
[00:23:02] Rifaat Shekh-Yusef: I I've closed the queue, so what pay attention to the queue, guys.
[00:23:06] Max Gerber: Hi. I'm Paul. Working on topic and work on model context protocol. I wanted to say we adopted this with model context protocol. It's been super useful. And then the two pieces that would be helpful for us is which we've already talked about a bit on the issues is the more granular error codes when you have invalid grant because you can't tell if it's the if you've sent if if user doesn't have a seat or if the if you've messed up the the token. And then the second one is if we could mention it somewhere in there, the corporate personal crossover account linkage, that would be super useful so that when people are implementing it, they note that they have the option to disable the authorization code flow on their normal flow is, like, a really good prevention there.
[00:23:56] Yaroslav Dobryakov: Yep. Okay.
[00:23:58] Rifaat Shekh-Yusef: Do you wanna introduce the other topic?
[00:24:00] Aaron Parecki: Let me introduce the
[00:24:01] Rifaat Shekh-Yusef: other topic. Yeah.
[00:24:02] Aaron Parecki: Okay? So the I'm gonna throw two new drafts at you in this one slide. So in I've been we've been looking at the key binding story end to end for this, and it's already solved in a couple of places, but there's gaps in other parts of the flow. So there's two new documents that talk about how to solve those for the miss the the steps where it's not yet defined in the spec. One is the token exchange step. You technically can do it, but you can't tell that it's happened unless you add a cnf claim to the response of the token exchange. So that's that draft. And the other one which I mentioned, I think, last meeting or the meeting before was the JWT depop grant, where if we're using a bound JWT as an authorization grant, technically, it's not a bare JWT anymore, so we kinda need to say it's a bound JWT. So that is described in this other link. I'm planning on just, like, pursuing these and eventually bringing them back to the working group with more detail, but I wanted to point people at these because these are the gaps that we've found for actually making the end to end key binding all the way through actually possible. Those are what it looks like. The end. Okay.
[00:25:22] Rifaat Shekh-Yusef: Okay. Anybody has any questions, comments about this?
[00:25:28] Hannes Tschofenig: Go ahead.
[00:25:35] Presenter: Thank you for the presentation, and I appreciate that. So my question is that since since the clients since the clients is identify is identify clients before they before it register, how how does authorization server establish trust especially with the first URL.
[00:26:00] Aaron Parecki: So I didn't mention most of the background that I've talked about in previous IETF meetings, but this all assumes that there are preestablished relationships between the parties. However, you could also add CIMD into the picture to establish the client at an authorization server at either of the legs. But that's kind of out of band. Not it's not part of this protocol. It's just assumed to have already happened in some other way.
[00:26:27] Presenter: Okay. Thank you. Okay.
[00:26:30] Peter Kussleman: Peter Kussleman. Fantastic to see the key binding work. We did a lot of soul searching on this in the original identity training draft. Something that I'd say might be helpful is to be very clear about, what do you mean by end to end binding, whose keys because there are multiple folks involved or multiple parties involved. And, yeah, having that clearly written out will help you fill out this matrix very nicely in Keene.
[00:27:00] Yaroslav Dobryakov: Thank you.
[00:27:01] Aaron Parecki: Yeah. This is only talking about the client key, like the client's access token and the client's the client binding from SSO all the way through the access token.
[00:27:11] Peter Kussleman: And it assumes that it is the same client all the time.
[00:27:14] Aaron Parecki: It does. You wanna write that out? Yep.
[00:27:17] Rifaat Shekh-Yusef: Mhmm. Tony, quickly.
[00:27:23] Tony Nadalin: Yeah. Tony, Natalie, what do you do with a SAML name ID unspecified?
[00:27:30] Aaron Parecki: Sorry. What was the question?
[00:27:31] Tony Nadalin: What do you do with a SAML ID or SAML name ID on that's unspecified? You know, there's a parameter for unspecified.
[00:27:39] Aaron Parecki: That just means the format is unspecified.
[00:27:41] Tony Nadalin: So we just What do you I I just totally understand that. What are you gonna do with it?
[00:27:45] Aaron Parecki: So it's basically, there is no string transformation done with the values that are in the SAML assertion. It's just representing the SAML XML name ID in JSON. So it's Okay. Says it's unspecified. Here is a value just the same as it would have in SAML in XML. Yeah.
[00:28:06] Rifaat Shekh-Yusef: Okay. Any last minutes? Anything else for now?
[00:28:11] Aaron Parecki: Nope. Yeah. Those are the two main things, priorities that I wanna tackle on this. Okay. Again, feedback on whether these make sense as an extension or in in this document is welcome. So
[00:28:22] Rifaat Shekh-Yusef: Awesome. Yeah. Yeah. And feedback on the mailing list also. Great. Right? Okay. Thanks, Aaron. Are you was it the next one? Okay. Okay. I need to take the clicker from you first, which is annoying. It was point to the metadata. Yeah. And but I need every time I need to take away the clicker and then after wait. Yeah. Okay. Go ahead.
[00:28:54] Aaron Parecki: Great. Alright. Hi. Me again. Client ID metadata document. This is on draft number two. First, very briefly, what this is. This is the idea that a client can publish its metadata at a URL instead of it being preregistered or provided in a dynamic client registration request. It uses the same registry as DCR. And then that URL that hosts this document is used as a client ID in any part of the OAuth flows that require a client ID. Why? Because sometimes it's not possible to preregister clients. This is very common in cases where you have either open source apps that are going to be talking to arbitrary servers that are configured by people who are not the client developer. So things like WordPress installs or Mastodon or now Model Context Protocol clients, where the Model Context Protocol client does not the the developer of that client does not preregister client IDs at every Model Context Protocol server it's going to talk So this is really enables us more open ecosystem of using OAuth clients with servers that didn't know about it before. This is this is what's new since last time we talked. Justin, thank you for the review. Justin sent a very long review into the list. It was very helpful. Thank you. Lots of editorial clarifications made it a lot easier to read, I hope. One of the big changes that was a good suggestion was split the idea of what is in this document from how to fetch the documents. So that those are now separate top level sections. I think they were kind of managed together somewhere else before. So great. The whole idea of the using this for development environments, which have some different considerations where you can kinda you have to relax some things that you would otherwise check for in production, That's all now moved into an appendix and is non normative. And in particular, that the exception for avoiding checking for SSRF for local hostings is really only applicable for dev and testing when you know you're running on you're running your AS on local host also. So really mostly just editorial and cleanup, but, yes, thank you, Justin, for the review. There are still a handful of open issues. And, again, I wanted to point out a couple here for discussion, but I've kind of grouped them into related concepts. One of them is this ISS parameter. So in last IETF, we agreed that in OAuth 2.1, the authorization server is required to send the ISS parameter, and that enables clients that support it to check for it, and that's used to prevent certain mix up attacks. I'm not getting into the mix up attack script description because it's very complicated. However, that attack can be solved in two ways. One is the ISS parameter, and one is using distinct redirect URIs per AS that the client talks to. As you can imagine, a spec that is designed for clients to talk to arbitrary servers is likely to talk to more than one AS. It is unlikely that it will ever talk to only one. So this mix of attack is more prevalent here compared to other places in the OAuth ecosystem. So the proposal here is basically copy OAuth 2.1 even though this is not a direct extension of 2.1 and also require ASs that support this spec to return the ISS parameter because it is more likely that those clients will encounter this this attack possibility using client-id-metadata-document anywhere. So it's hopefully not a huge it's it's not a huge burden on the AS, and, again, it's meant to be just provide the tools for the client to protect itself. How many slides do I have? I have a couple. This is part of a larger story, which is about about how clients can represent them themselves to different authorization servers, I I do think this is useful regardless of the other things I'm about to discuss. But any discussions on this, Any strong opinions one way or the other about adding this requirement? I see Emilia in the queue.
[00:33:35] Rifaat Shekh-Yusef: Yeah. Emilia, I think, was waiting for the end of this discussion. I I don't know if they have a comment about this specific topic. Emilia, do you wanna speak about this?
[00:33:49] Emelia: Yeah. I can give what I just said in chat, which is the other protection mechanism that we have here. Sorry. I think I'm getting looped back. The other protection mechanism that we have here is that we are essentially considering requiring, like, a dot dot JSON extension in the URL of the client-id-metadata-document. And by having that in the URL, you essentially avoid the issue of mix up attack entirely because you you won't have an issue with string that is dot JSON at the end, essentially.
[00:34:29] Aaron Parecki: I think that's a different attack that's what I talking about. Think that's a different I think you're talking about a different attack there.
[00:34:34] Emelia: There there were two attacks with similar mechanisms. Okay.
[00:34:39] Yaroslav Dobryakov: Okay.
[00:34:44] Rifaat Shekh-Yusef: Justin, you you wanted to say something? You good? Okay. Okay.
[00:34:49] Aaron Parecki: Okay. So this one is stems from the same underlying problem, but essentially the what's what's happened in in practice as people have been deploying this is that a client has found that certain authorization servers have certain quirks to them, and it needs to modify things in the client ID doc based on what server it's talking to. So this is this is if the client can only host a single copy of the document, then it doesn't have the opportunity to change anything about what's in the metadata. Right? Or it would have to use different URLs for different authorization servers, which isn't really practical. So the the the suggestion here is basically enable the authorization server to tell the client about itself when fetching the documents so that the client has the opportunity to vary the metadata. I'm not tied to this particular method. So the client ID URL, again, just to be clear, is the same URL, but when the AS fetches it, it would include either a query string parameter or it could put in the header the AS issuer. But basically, identify itself somehow to the client when fetching. This enables a couple of things. Again, one which has another slide, which is updating client behavior per AS. So if a client wants to change, like, add client auth, for example. A client's not doing client auth today, wants to start doing client auth tomorrow, but it knows that this particular server is going to fail if it even says it has the option of doing client auth, then it needs to serve a particular document to that server. So this basically allows us to do this either progressive progressive rollout of updates, slight variations per server, and enables the other option of solving their mix up attack, is distinct redirect URLs per AS, which it can use this way. Because, again, the other option is using distinct client IDs per AS, which is a worse option. So thoughts on this. Again, the mechanism of query string, I'm not tied to, but any thoughts?
[00:37:14] Justin Richer: Justin Richer, this is very clever, and I hate it. And I do I think it it feels like this is, like, the best of the worst options kind of thing. I can absolutely see the reasoning that that leads to this. One of the reasons that I don't like it is that it basically starts to create an enumeration attack against the client's configurations if any of that information should be seen as sensitive, which it shouldn't be because it's a public URL. Totally get that. But, you know, somebody's gonna put something dumb in there. So if this gets added, I think it needs to have a very robust security considerations and privacy considerations of what you do in here and, you know, what what it means to to put information in this document that, like, this this obfuscation is not actually, like, any kind of privacy. Assume that issuers are guessable. Like, all of that is addressable. It's it is a minor foot gun is what I'm
[00:38:15] Aaron Parecki: Yep. And I think actually your to your point there, I think that's enough of an argument to me to make this be a header rather than a query string because then at least I can't share a link to it. Yeah.
[00:38:26] Justin Richer: It makes it less fishable, which is great. Yeah. And yeah.
[00:38:36] Nick Watson: Nick Watson here. So, yeah, I mean, I definitely support doing this. Again, I'm also not specifically tied to the mechanism, but we we live in a sadly impure world and stuff is gonna diverge over time. And building in this flexibility from day zero is very helpful. I think it will avoid lots of problems down the road like we have today with AS metadata. Also, shout out to my draft in the mailing list. So, yeah, definitely support doing something like this. I agree with Justin. Yes. Don't put sensitive information in. It is a mini foot gun. I think it's a we have sort of it's sort you know, it's the lesser of two evils, I think, in this case. Otherwise, you're gonna end up with people coming up with their own solutions for non interoperability. I'll also add because I've seen this disc in discussion that, like, just change your client ID doesn't work for lots of other reasons. Like, you'll, in many cases, invalidate all your existing grants. Like, authorization servers are gonna be, new client ID, who this so that stuff like that isn't gonna work to version.
[00:39:44] Yaroslav Dobryakov: Okay.
[00:39:45] Rifaat Shekh-Yusef: Thanks. Emilia?
[00:39:48] Emelia: So I would probably or against having a query parameter for this, but I would be in favor of having a header for this. The reason why I'd or against the query parameter is because it would potentially need us for need us to like, at the moment, a client ID URL can contain query parameters. It's discouraged, but they can happen. And the reason why we do this is because the entire URL of the client ID URL is the client identity. So if that was to change, then we'd have to like, if if we add in this issue ISS parameter, then we'd essentially have to strip that parameter out of the URL, which changes the URL.
[00:40:32] Nick Watson: Just to be
[00:40:32] Aaron Parecki: clear, this is not the client sending the ISS in its outbound.
[00:40:36] Rifaat Shekh-Yusef: No. No.
[00:40:36] Emelia: This is this is the authorization server requesting So if it was reflected back, we'd still have to do some sort of cleanup on that. So I'd be hesitant to use a query parameter, but I would be in favor of using a header. Maybe there is a standard, like, refer header or something like that that we could use in this place.
[00:40:57] Aaron Parecki: Happy to happy to switch it to a header. Yeah.
[00:41:00] Max Gerber: Okay. K. Thanks. Paul. Hi. Paul Carlton. The two times that I've wanted to reach for this is when rolling out private key job support. Two alternatives to this that would, I think, also help there would be if you can have multiple token endpoint auth methods in the client ID metadata. And then another one that would be super useful here for the the same, like, progressive rollout situation is if you can authenticate like, check on the status of your, like, quote, unquote, registration with the AS with just your client authentication. Because right now, if I want to check if the privacy key job is gonna work, I basically have to subject some user to that or get an account myself to to go through the flow. I can't I can't check if it's gonna work ahead of time.
[00:41:51] Rifaat Shekh-Yusef: K. Thanks. On?
[00:41:53] Arndt Schwenkler: Yeah. Two things. So what Emilia said, I think that's very valid because I don't want the authorization server to have to, like, kind of reason much about the client identifier and start cutting things out because that will be a mess quite a big mess. So plus one on the header. The other thing is I think we need to clearly describe when to use this compared to a different client identifier, right, to kind of have clear rules. Only use this if you want to use it for credit roll rollouts and all sorts of things and when to not use it because otherwise yeah.
[00:42:29] Yaroslav Dobryakov: Thank you. I know I
[00:42:33] Vittorio Bertocci: got in after the queue closed. Sorry. I'll be quick.
[00:42:35] Rifaat Shekh-Yusef: No worries. Yeah.
[00:42:36] Vittorio Bertocci: This does scare me a bit, to be honest, when people talk about using it for interoperability reasons. There's better ways to achieve interoperability, probably, than adding a lot of complexity to a system and making it more difficult to debug. And some of the cases people are talking about, like, having private key job roll out progressively are things that are already solved in the federation spec with some of the extensions there. So I we should push people in that direction for those kind of problems, I think.
[00:43:06] Yaroslav Dobryakov: Yeah. So
[00:43:13] Vittorio Bertocci: when I say so I wasn't suggesting using federation. I was suggesting using the extensions that are in federation, like being able specify multiple token endpoint auth methods in the client ID metadata. That that's a much better solution than trying to customize it per authorization server for all.
[00:43:30] Aaron Parecki: I didn't I didn't put it in the slides because it's already, as far as I'm concerned, solved. There's a GitHub thread about the token endpoint auth method specifically that now says, oh, there's an open ID spec that adds a property that has a list of methods supported. Yes. We're gonna use that. They should also put it into the DCI registry, which it isn't yet.
[00:43:51] Fredrik: Yep. Yep.
[00:43:52] Aaron Parecki: Thanks. Okay. The last thing I wanna talk about, we don't have time for a discussion on this, but I wanted to this is also somewhat complicated. There's many there's multiple different solutions to this, but I wanted to set the stage for the problem. This is a problem that multiple people have told me that they need a solution to, so it feels like it's critical to get this right early. Essentially, it's, again, related to the other things I talked about, but it's specifically about actually versioning the metadata document itself. There's different ways to solve it. So we can talk about that on the list or on the couple GitHub threads that are open. But, essentially, the options are either doing things like how do we take multiple different URLs and link them together into the concept of a client so that if the AS doesn't want to revoke consents, it doesn't have to. Or you you somehow need to be able to very there's different ways to address it. Not I can't go into it all here. Some of it's on the slide. Please chime in on the GitHub threads or the mailing list about the client version problem. And
[00:45:06] Rifaat Shekh-Yusef: maybe also you you send them a mail to that list and and list those problems or issues. Open issues, let them reply to this.
[00:45:16] Aaron Parecki: I can definitely do that.
[00:45:17] Rifaat Shekh-Yusef: And, Justin, very quickly.
[00:45:18] Justin Richer: Super quick software version that's already in there doesn't solve this. It it does,
[00:45:23] Aaron Parecki: but we need additional language to describe how to use it how to use it for
[00:45:28] Justin Richer: the okay. Yep. That's great.
[00:45:29] Yaroslav Dobryakov: Yeah.
[00:45:30] Rifaat Shekh-Yusef: Okay. Thank you. Yep. Thanks. Okay. Let's take this away. Pedram? Yep. Okay. Let me hand you that. Okay. Can you control the slides from your side?
[00:46:00] Pedram Hosseini: Yep. Perfect. That works.
[00:46:02] Rifaat Shekh-Yusef: Okay.
[00:46:03] Pedram Hosseini: Alright. Thank you very much. We want to briefly talk about the status of the security BCP updates that Daniel Fett, and I are working on. And we also have some discussion points. To give an overview, the current draft covers four attacks. We added the last attack pretty recently, which I will describe briefly in a moment. But before that, let me give a brief overview on the first three attacks. So the first attack that we describe in the document are audience injection attacks, which have been or are currently being mitigated for different specifications, for example, also in the 7523 BIS document. And our goal was not only to document the attack as part of the security BCP, but also to give a more detailed description of the attack, provide additional countermeasures, and also discuss some implementation considerations. The second attack is a variant of the mix up attack called cross toolkit or the count takeover. And the usual defense against AS mix ups uses the issuer identifier of the AS, either in the ISS value of the authorization response or by the client using different re redirect URIs for different issuers. But at some ecosystems, the issuer identifier might not might not be available. And in the updates to the VCP, we describe an alternative defense.
[00:47:42] Yaroslav Dobryakov: And
[00:47:43] Pedram Hosseini: then the third attack that we describe in the document is called cross user OAuth session fixation. Now session fixation is a known kind of attack, and in the OAuth space, this goes back to even OAuth 1.0. And the security BCP does describe mitigations for some kinds of session fixation attacks, but in some settings, these mitigations are not enough, especially when the user agent session is not directly available to the client. For example, if the actual client is the back end of a native app, as in the back end for front end pattern. Yeah. We also describe the attack and also provide countermeasures. Now, as I said, we added a new attack to the updates, which was contributed to by Louis Janet from the University of Buchen. And this attack can happen in brokered OAuth deployments. And, yeah, we show the setting here. So we have a broker that mediates between the so called downstream clients upstream authorization servers. And towards the upstream AS, the broker is just a normal OAuth client, and the broker can, for example, be an authorization server towards the downstream clients. Now the problem is that when the end user wants to authorize one of the downstream clients, they will actually authorize the broker. So the user consent is based on the client ID of the broker and not on the individual clients. And the upstream AS cannot even distinguish between the different downstream clients of one broker, which means that all the downstream clients and even malicious ones would get access to the resources of the user.
[00:49:40] Yaroslav Dobryakov: And,
[00:49:42] Pedram Hosseini: yeah, the setting has also been been observed in practice. And in the current draft, we also describe countermeasures. Yep. So there are two things that we would like to discuss with the working group. One question is what the title of the document should be. Right now, as a working title, that is updates to OAuth 2.0 secondurity best current practice. And then the next question is about the RFCs that should be listed as being updated. So definitely, seventy five twenty one to 23 should be listed because of audience injection attacks. Maybe also the RFC 9,700 because of the updates, the mix up attacks, although this is already, like, part of the security BCP, and, yeah, maybe some some more RFCs. So before opening the discussion, a quick outlook from our side, the document is stable, And it would be great to get feedback from the working group. And we think the goal should be to go to working group last call as soon as possible. With that being said, thank you very much. And let me go back to the discussion slide again.
[00:50:55] Hannes Tschofenig: Pedram, a question on the on sort of the new attack that you brought up because I think it also highlights some of the challenges, namely, strictly speaking, the deployment figure architecture that you just showed with the program between isn't really classical OWASP. This is sort of like a homegrown variant. And so we are not really fixing OAuth. We are, in fact, actually documenting some new deployment models, some new use cases where people are doing this. And the question is, of course, should there be a broker in this place to begin with? And I've had that sort of question in, for example, also at the OAuth Security Workshop when similar presentations were given about other sort of attacks. And I'm not sure how to best deal with this because it also has an impact on the title of the document and how we frame the discussion and what we recommend to some of the companies sort of modifying OAuth on the fly and then, of course, later on regretting that they introduced some bugs in their effort.
[00:52:18] Pedram Hosseini: Yes. So that's a very good point. I would I would like to hear some some other opinions on that, but that's a very good point. That's yes.
[00:52:26] Rifaat Shekh-Yusef: Okay. Hey, Emilia.
[00:52:30] Emelia: I've seen the broker pattern deployed quite a bit with various success. Perhaps maybe what might be needed is a document that actually describes the broker pattern in as a deployment pattern. So, like, an explainer document or something, not necessarily a security BCP update, but a document that actually describes this broker pattern and describes the common issues that people hit into when deploying this sort of setup. Would that make sense?
[00:53:01] Hannes Tschofenig: Yeah. Like, it makes definitely sense to me, specifically since we had published a couple of other documents. Like, if I think about the browser based document where we essentially the OS in the browser, we essentially recommended, like, you would assume that it talks about, like, how do I run OS in JavaScript on in the browser itself? But instead, it says, no. Don't don't do that. And I think that's I could envision a similar document for those type of deployments if they indeed are common. Like, of course, recommendation being whatever.
[00:53:42] Rifaat Shekh-Yusef: Justin.
[00:53:43] Justin Richer: Justin Richer. So one of the things that I found when I was teaching a lot of, like, Oauth seminars is that a lot of people miss the fact that all of the things that we name in the Oauth specifications are roles that are played by one or more entities each, and an entity can play multiple roles. And that's where we get into weird stuff where the broker is as far as the client knows, it's calling if it's doing OAuth to the broker, the broker is the AS because from the client's perspective, it is. And so being able to say that, yes, an AS can have multiple parts to it. And if that AS is following a particular pattern in its deployment, then these are the considerations around it and stuff like that. That fits very much with the OAuth for in browser apps specification and how that's organized and how the attacks are described there and stuff like that. I'd be supportive of something like that, talking more about how different AS deployments are you know, how they affect that story. Right? Because ultimately, at the end of the day, the the AS is a role that is not this is not gonna be deployed the same way that it was in 2012 when server meant an actual physical computer on a shelf somewhere. We don't have those anymore. We have Jeff Bezos' computers on a shelf somewhere or a tiny slice of it. And and that that changes how we view we view some of these considerations because it adds additional layers, it adds additional entities without adding additional roles. And so, yeah, I'd be in favor of splitting it something like that. Second bit, and this is to the chairs for our security BCP 9,700. Do we have a BCP number assigned to that, or is it just an RFC number today? This is also kind of a question for Deb.
[00:55:35] Rifaat Shekh-Yusef: It's a good question.
[00:55:37] Justin Richer: We do have a BCP number? I'm seeing some nods. Okay.
[00:55:40] Hannes Tschofenig: I I thought there was, but we need to look it up. But, yeah, plus one on the on the former point. I think I like the way how you spin that story.
[00:55:50] Justin Richer: Okay. Deb's interjecting. Oh, okay.
[00:55:55] Deb Cooley: It's BCP two forty. And when we did the browser based draft, talked about adding it to b c p one forty, but the 240. 240. 240. But we decided not to. Right?
[00:56:06] Yaroslav Dobryakov: Yep. Yep.
[00:56:09] Justin Richer: Okay. The something like this seems like it should definitely be in there. Yep. And also to the authors, would consider updating the the JWT security practices docs as well. So the the JWT access token doc. Yeah. Yes. Exactly. Alright.
[00:56:27] Pedram Hosseini: Thanks for the feedback.
[00:56:29] Arndt Schwenkler: Aren't here. I'm also seeing this pattern being used more and more in the industry for various reasons, and I believe there's broader thing to it. It doesn't stop at the consent. There's all sorts of every aspect of OAuth plays a role here. So I believe it justifies a separate document. I'm also very interested in that.
[00:56:51] Hannes Tschofenig: We'll bring it up in the discussion and figure it out. Thanks for the feedback. And thank you, Pedro, for bringing this up.
[00:57:01] Rifaat Shekh-Yusef: You want me to use the queue? Can you join the queue?
[00:57:06] Hannes Tschofenig: Did you join the queue? Because otherwise, we don't have your name.
[00:57:10] Rifaat Shekh-Yusef: His name is.
[00:57:12] Presenter: From Morocco. Thank for for your presentation. That I want to clarify is that in your drafts into section two, you have described the core of of the attacks. Is and this analysis is to have signals there of of different type of attacks or classification of what?
[00:57:42] Pedram Hosseini: Sorry. The question was if if the goal is to have, like, different kinds of attacks in there?
[00:57:46] Presenter: The the purpose of this analysis of attacks is in order to have signature or what?
[00:57:54] Pedram Hosseini: Sorry. I didn't didn't catch the question.
[00:57:58] Presenter: The purpose of analyze of the attacks Mhmm. That describes that describe that's is describes in your in your drafts?
[00:58:09] Pedram Hosseini: You mean what the goal of the attacks is? So the these the goal of the attacks are all described?
[00:58:13] Hannes Tschofenig: No. No. No. I I understood your question. So what we tried so, typically, the starting point is often sort of an existing publication of academic publication for some of those attacks in many cases. And so that is true for the things in this document. So there are actual papers describing those. The documents summarize those attacks, but they don't go into all the details. So you actually have to read up on the references. You have to read through the reference to really understand the details. Okay. So, that's the way how we did it today because, otherwise, the documents grow quite a bit.
[00:58:58] Presenter: So, okay. Another clarification, if I'll do the threat model. The threat model?
[00:59:07] Rifaat Shekh-Yusef: Threat model?
[00:59:08] Presenter: Yeah.
[00:59:09] Rifaat Shekh-Yusef: What about it?
[00:59:10] Presenter: It does not describe in his section.
[00:59:15] Hannes Tschofenig: So in the so this is a work in progress document. So if if there's something missing, you need to point this out. But in the previous version of this document, the security PCP, we had an extensive threat model.
[00:59:30] Presenter: Okay. Thank you. Thank you.
[00:59:32] Pedram Hosseini: So just to comment on that, we also have, like, for each individual attack, there should be, like, the overall setting and assumptions. But if that something is missing, please please let us know. Yeah.
[00:59:44] Rifaat Shekh-Yusef: And and you can chime also on the list. Right? So review the document, provide feedback on the list. That'll be great. K? Awesome. Okay. Anything else? Oh, sorry. Emilia.
[00:59:56] Emelia: Yeah. Very quickly, the the broker pattern that we just saw on screen in the slides here, that is actually the exact same sort of architecture that was in the attack that Aaron mentioned for client-id-metadata-document back at the very start where he said that it was a very complicated attack. It was basically one of these sort of architectures with a broker, and a the broker was using a client-id-metadata-document in order to identify itself to the upstream AS. So maybe there's a thread commonality between those that's worth exploring.
[01:00:35] Rifaat Shekh-Yusef: Okay. Thanks a million. But anything else?
[01:00:41] Pedram Hosseini: No. So I guess one of the key takeaways is to, like, remove this brokered setting. And, like, the goal would be to have a separate, like, document. Right? Like, describing this in more detail and Do
[01:00:57] Rifaat Shekh-Yusef: wanna discuss it on document.
[01:00:58] Hannes Tschofenig: Yeah. We discussed this on the list.
[01:01:00] Rifaat Shekh-Yusef: Okay. Let let's have that discussion on the list
[01:01:03] Pedram Hosseini: there, Patron. Sounds good. Alright. Thank you very much.
[01:01:06] Mike Jones: Thanks, Petrone.
[01:01:31] Yaroslav Dobryakov: Yeah. Thank
[01:01:33] Arndt Schwenkler: you. I'm Arndt. On behalf of the my co authors, I'm giving an update on the OAuth- client authentication. Okay. So at a glance, the draft profiles two other specification three other specifications. R r FC7521, which is the assertion flow, eighty seven zero five for mutual TLS authentication, and the draft-ietf-oauth-attestation-based-client-auth, which is gonna be presented tomorrow for the workload identity token. This is all about client authentication for workload identity using SPIFFE. Yeah. SPIFFE has identifiers. They're very more or less the same as WIMSE identifiers. There's SPIFFE schemed URIs, and they are often used to encode infrastructure identifiers. So here's an example. You would have a trust domain, and then you have a path that is hierarchical. And in the specific example, it can be anything. You would see a location in there, specific cluster, specific service, and potentially the instance as in hierarchy. Yeah. It's deployment specific. It can be anything. But what's important is that most cases, it's infrastructure identifiers. Comparing this to OAuth client identifiers, they're traditionally more like on the service level. Right? You would not encode infrastructure information in there. And a common practice, for example, is to have multiple workloads act as the same client behind a load balancer or kind of have them separate. Threw this picture here. Right? You have one off client and you have various services. They may be in different geolocations, availability zones. You may put one down behind the load balancer, spin one up. And you don't want users that come in through the load balancer having to re consent every time they hit a different instance. Yeah. And for this draft, this is starting to be a thing because in the existing off landscape, they are sometimes supposed to be the same. So in eighty seven zero five, it says expected subject configured, and they are allowed to kind of differ, which I believe is due to the fact that the PKI environment and the auth environment are most of the time completely separate, and it's very difficult to change the PKI environment. Whereas 07/05/2021 and the draft-ietf-oauth-attestation-based-client-auth expect the subject, like the subject of an assertion of client authentication, to be exactly the client identifier. And that is where this part breaks. I personally believe this is the reason that they tend to be either self generated, that the claims are in control of the client and the client can just put its client ID there, and that the chart infrastructure tends maybe a bit more closer to the OAuth infrastructure than with the PKI infrastructure. Anyway, for this draft, eighty seven zero five works, but 21 and draft-ietf-oauth-attestation-based-client-auth. Yeah. There's a mismatch. Yeah. So in the current draft, we aim to release that restriction for the context of specific client authentication. So we kind of have their wording something like the subject claim or in the case of certificates match or is associated with a recognised client identifier. We've had conversation on the mailing list. I believe there's somewhat consensus on this, but I just wanted to hear the room and see if there's opinions on this.
[01:05:23] Hannes Tschofenig: In some other cases, we've rather gone the opposite. We had very loose matching rules and then we tightened it up and made an equality match. And you go the other way around. There's a risk with
[01:05:38] Arndt Schwenkler: that, right? What is the risk you're seeing?
[01:05:42] Hannes Tschofenig: Well, if you make it fuzzy and say, Oh, it kind of matches and only match subparts, authorization decisions may be impacted? Did you think so, sir?
[01:05:59] Arndt Schwenkler: Theoretically, yes. Practically, I don't see it. Yeah, I I of course. Right? Like, loosen that up, there's all sorts of things that come with it. Right? It's not an exact match anymore. Yeah.
[01:06:12] Aaron Parecki: Aaron? So, generally, I agree with your statement, Hans, but I think in this case, it's this there's a thread that keeps coming up in a lot of our discussions in this group, which is separate teasing out this idea of a client instance from a class of client. And I think this is essentially opening up the definition to allow it to identify the class, which feels to me still in the spirit of what the identifier was supposed to be. And we need to better specify what we actually mean by client instance and what things are actually managed by the instance of of a client. So I think this is a okay reason to to kind of open up this definition.
[01:07:00] Hannes Tschofenig: I hope I don't have to remind you because, like, two things that come to my mind, redirect URI matching sort of like rings a bell, or if I look at BKI, there's sort of the certificates, star, sort of the wild card sort of matching and so on and so on. So just saying, and I'm confident you guys looked at this and worked this out.
[01:07:28] Arndt Schwenkler: This is SPIFFE specific. Right? So if you if you would look at it from a broader PKI environment, I would agree. But SPIFFE is very tightly confined and defined on how these things act together. But, of course, we
[01:07:41] Yaroslav Dobryakov: need to
[01:07:41] Arndt Schwenkler: look at it. Agree.
[01:07:43] Yaroslav Dobryakov: Okay.
[01:07:45] Christian: Yeah. I fully agree with with beforehand. I think in general, in this working group, we should somehow solve the this problem between client as a service and client instance because it will be coming up more and more. It's very relevant for workloads. It's becoming more and more relevant for agent stuff. It's gonna keep happening, and we need to figure out how to deal with that, in my opinion.
[01:08:07] Rifaat Shekh-Yusef: I see.
[01:08:08] Hannes Tschofenig: Yep. I Precisely confined workloads, SPIFFE workloads, agents.
[01:08:14] Arndt Schwenkler: But- Yeah. It it in my opinion, it's a broader conversation. Right? Similar, if you if you're deploying Kubernetes and you use OAuth to authenticate users, you have the exact same problem. Right? The subject describes your infrastructure, and that's not gonna be your your OAuth client identifier. Yeah. And particularly when we you add client-id-metadata-document to it where the client ID needs to be an HTTPS schemed URI, you're out and you're back to almost using client secrets for client authentication again. Okay. That's the second. Oh, sorry. I'm skipping.
[01:08:53] Giuseppe De Marco: I just wanted to add to this. Agreeing with Christian, from the wallet context, we see the client ID as the wallet solution. But we, in the attestation based client authentication, we talk about client instances because we needed this differentiation. We basically have the same problem. And we're thinking about introducing a client instance ID as a separate parameter in the client annotation shop. We can discuss it also tomorrow. The solution that we have now in the draft is basically that we we didn't want to solve this problem for the whole of OAuth in our draft, and I think that was also the feedback from the working group that we got when we discussed this the last time. So if we can find a solution for this, great. Then we can also apply it to attestation based authentication. I just wanted to explain what's why it is as it is right now.
[01:09:55] Fredrik: This is Fredrik. So I agree that it's fine in the SPIFFE situation. The problem I have with this is that it requires you to add language into other drafts or other specs that will access the restriction. So for instance, in, attestation based client authentication, you would have to say something like, okay. Well, basically, what you what you write here. Right? And only then in SPIFFE, though, you then constrain it to something specific. And this means that I mean, the suggested language that you wrote, and I know that's just a random suggestion, but in the issue in attestation based client authentication basically says, oh, the AIS needs to have some mapping. And that then immediately reads as, you know, to naive people, you can do whatever you want, which is exactly what we want to avoid. So I think the problem is not that you're doing it in SPIFFE. The problem is that it requires normative changes and other specifications that open things up that we don't wanna open up.
[01:10:56] Arndt Schwenkler: I agree. However, just a quick follow-up thing on this. This is already an eighty seven zero five. The clear mapping is already there loosened up. Right? Yep.
[01:11:09] Rifaat Shekh-Yusef: George? Yeah.
[01:11:11] George Fletcher: So the other piece that comes to mind here is that it's creating this undefined way of determining what the correct set is. And if you have a geo distributed environment, how do you keep that correct set in sync? So there's a whole bunch of other complexities that come when you start creating these sets of things that kind of represent the same thing that I think we have to be really careful about just adding it in there because people will not likely do it correctly.
[01:11:43] Arndt Schwenkler: Yeah. Thank you because that introduces my next slide. Yeah. And that is actually how do you map a SPIFFE ID to a client ID. And in this example, same as before, you have the region cluster service and instance encoded in the SPIFFE ID as an example, and there's multiple opinions and approaches to actually define that policy on how to actually agree on that mapping. So, for example, there's direct mapping to say I put a list of SPIFFE IDs in associate them with the client, and every time I scale out, I have a new instance coming up, I need to update my client. The other thing that is currently in the draft is an open ended prefix mapping where you can actually wildcard the end away, for example, the instance. However, every time you spin up a new cluster or deploy into a different geolocation, you have to update the client. And then last but not least is also kind of to say past segmented wildcards where you say in this specific segment, I'm adding a wildcard. But as you said, George, right, like, it gets open ended, people may implement it differently. Yeah. It's it's it's a thing. I think I wanted to hear opinions on this slide.
[01:13:12] Rifaat Shekh-Yusef: Yeah. I think Pam. Hi.
[01:13:23] Pam Dingle: I'm Pam Dingle from Microsoft. Justin mentioned enumeration attacks or enumeration in general that might not be an attack, and that have you considered the fact that you're if you're using this SPIFFE ID, for example, to federate across from one platform provider to another platform provider, that then that destination platform provider learns perhaps information about how big the competitors' regions or clusters for that customer might be.
[01:13:53] Arndt Schwenkler: I agree. If you if you put all that information into client-id-metadata-document, then you get to know and to learn a lot about the infrastructure.
[01:14:08] Yaroslav Dobryakov: Yeah.
[01:14:11] Arndt Schwenkler: The road ahead. Please continue to review and provide feedback. We had a couple of discussions yesterday and the day prior on it, and we continue to receive issues. So please keep that up. There's a dependency with the workload identity token, which is defined in WIMSE that is currently in working group last call. So we are kind of waiting for that to finalize before we can move this work further. And that sort of mapping schematics, client ID versus client instance is so far the last remaining big item, and we'll continue to work on that.
[01:14:49] Yaroslav Dobryakov: Okay. Andrew? Andrew.
[01:14:54] Andrew: Just a quick comment. I don't have strong feelings on how to solve this. Sounds like there's multiple solutions, and I I kinda need to look at the different drafts involved. But I do think this is a problem that we need to think about solving. I I do see this scenario with customers frequently.
[01:15:09] Yaroslav Dobryakov: Thank you.
[01:15:13] Rifaat Shekh-Yusef: Okay. K. Thank you. Thanks.
[01:15:15] Hannes Tschofenig: Thanks, Adam.
[01:15:19] Rifaat Shekh-Yusef: Need to take this away. Think is next. Right?
[01:15:38] Yaroslav Dobryakov: Hello, everyone. Yaroslav here. On behalf of group of authors, I would like to present transaction authorization challenge proposal. But first, thanks, cheers, to accommodating my personal circumstances and adjusting schedule so that I could present today.
[01:15:56] Hannes Tschofenig: We are happy to help.
[01:15:57] Yaroslav Dobryakov: Thanks. Right. So what is it about? What's the core use case we are trying to solve here? One of missing, arguably, missing building blocks of using existing set of OAuth, WIMSE, and other technologies for AgenTeC AI is human in the loop. There is there are some proprietary solutions out there, but for step up authorization, that is ability of protected resource to challenge a specific transaction, get confirmation from the human that this transaction indeed should be going through, we couldn't relocate any kind of standard technology. So this is what this proposal is ultimately designed to address. So the setup is we have a client that is human driven, that has relationships with authorization server, that is running zero or more agents. So it could be one agent, could be no agents, could be many agents in the chain, and those agents are communicating with protected resource. So client is obtaining access token from their AS, and then granting agents to perform some operations by providing them with this X token. And then agents are using access token to authorize themselves as the protected resource. And one of the challenges with AgenTeKii, as we all know, they are mysterious, and they have sometimes intrusive thoughts, such as, should they drop the database? Sometimes they behave somewhat unpredictably. And these intrusive thoughts, for some reasons, in the agents can take over, and they result in actions. So they can say to the protected resource, I would like to drop the database, or some other potentially dangerous activity, which could be in scope of authorization that was provided to the agent. So the what we're trying to address here is to provide a mechanism for protected resource to challenge this request, to challenge this transaction based on certain heuristics or baselining, or its own AI, or other, some other trigger, protected resource could say that I better confirm this. I don't really trust this particular request, even though it is authenticated and authorized. This is still a risky operation. So we define transaction authorization request that protected resource could generate. It's a job that is signed by a protected resource. Agents could look into that JWT. But because it is signed, they cannot modify it, they cannot hallucinate it. So they could either potentially drop it, so back off, figure out that, yes, this is something that we shouldn't have asked for, or they could relate to the client. The client could take a look at this request, will either, again, decide that this request should not go forwards. We don't want to drop the database. That was some kind of hallucination malfunction of the agent. But because humans are bad at clicking buttons, giving their consent, we are pro pro proposing that this transaction authorization request should be then relayed to authorization server, which would make an ultimate decision, could potentially just automatically approve it, or potentially consult with approving party, or go into some form of deployment specific authorization process to generate a new access token that would be transaction specific and authorize this challenged transaction.
[01:19:51] Hannes Tschofenig: So there are a
[01:19:52] Yaroslav Dobryakov: few specific steps that we're going going through. Keep in mind, this is individual zero zero draft, so I don't want to spend way too much time on nuts and bolts of all the all the details. We'll iron them out as we go. But the idea that we have first have defined a discovery mechanism. The discovery mechanism is currently defined as a capability signal in HTTP request header that is signaled by the agent that is that is interacting with a protected resource, because it needs to be aware, it needs to be compatible with transaction authorization requests. Otherwise, if it's not, then it will not be able to react to them and relay them correctly. And so it cannot be just client metadata because everyone in authorization chain needs to support this capability. Then challenge, it's up to protected resource to decide what to challenge under which conditions. As I mentioned, the challenge is signed so that agents and clients cannot modify it with by mistake or malicious intent or whatever or hallucinate it. There are a few relatively boring claims that are included there that we would all expect, and there are some exciting claims that are included. TXN, which is transaction identifier for the specification perspective, it's opaque string, but identifies a specific transaction to be authorized. Authorization details are reason, which is human readable string, and reason URI optional claim that would allow client to present it in a web browser if there is some more explanation required why is this being challenged. And then finally, actor claim that would provide identifier of agent that is responsible for this for this action. So in sophisticated environments where you have multiple agents creating another agents, would be good to understand which one is actually malfunctioning. So, we have an example of this transaction challenge, again, jot with all those claims that I've just listed. And then authorization server validates and processes the challenge, may approve immediately if it feels like it, may delay approval, may involve step up authentication. So, maybe it's sending some kind of outbance push notification to the client to, again, confirm identity, could potentially involve external parties. So if, for example, an engineer wants to drop the production database, maybe some kind of manager should approve that, not just an engineer, even if engineer technically somehow is authorized for such a destructive action. There is a certain flow that we've proposed, deferred flow for interaction between client and authorization server that allows authorization server to defer generation decision, potential generation of minting of new access token, and providing to the client information about how often should author authorization server be pinged or, well, verified status if this is approved or not yet, depending on the interactions with external approved part. And if it's approved, authorization server means new access token that includes transaction identifier from the transaction challenge. So when it arrives at the protected resource, it would know that this is authorized and this is the transaction that that this authorization is for. So there was a bit of feedback. The few folks identified that there is overlap with few other proposals, not like complete overlap, but there are certain building blocks that we could reuse. So we're planning to collaborate with proponents of other solutions to identify those building blocks that could be generalized and reused, and also maybe perhaps more cleanly defined scope in those proposals that do overlap. So, example, there is a separate proposal for deferred token response. Clearly, we don't need to create our own custom deferred solution if there is common pattern that we could follow. And then there is also a plan to strengthen key binding and delegation properties. So oh, there is quite a
[01:24:11] Rifaat Shekh-Yusef: queue. I'm gonna one of the queue first, and then Peter.
[01:24:17] Peter: Hi. This is Peter. I have two questions, actually. Number one is that I was I suppose that I I thought that in this IETF, we're not going to discuss specific proposals. We're going to discuss use case. I thought we're going to discuss use cases, but I can let it slide. The the next question is that can you go back to the the flow, the first page? My question is so your red arrows, why it has to be initiated from the protected resource side? Is it okay for the agent to directly initiate a request?
[01:25:06] Yaroslav Dobryakov: Because protected resource is the one that is challenging the transaction. So it's protected resource that finds that transaction risky and would like step up authorization.
[01:25:15] Peter: The I can think about the number of round trips and the lags that may and and all the number of the requests that may keep the clients oh, sorry, the users bothered. I'm thinking that is that the request should be could be initiated from the agent's side When it's deciding to access some kind of protected resource, should that be given some initiate some request back to the client first for authorizations? I'm not really sure you actually access the protected resource.
[01:25:51] Yaroslav Dobryakov: Sorry. Who should be author initiating the agent on your
[01:25:56] Peter: is on your on your diagram. The agent on your diagram Yes. And is deciding to
[01:26:03] Rifaat Shekh-Yusef: Yeah.
[01:26:03] Peter: Access some protected resource. Right. Should it look for client's authorization or approval before it actually tries to do the drop the database thing?
[01:26:16] Yaroslav Dobryakov: Well, yes. If it doesn't have an access token that could grant access to protected resource, it will not be able to make the first transactions in the first place. The proposal is to give protected resource an ability to challenge a specific transaction that falls within the scope of already existing access token. If access token doesn't exist in the first place, then that's not what this proposal is about.
[01:26:44] Rifaat Shekh-Yusef: Time out. Okay. So I'm gonna stop this discussion, and I'm gonna stop like you finished the presentation. Right?
[01:26:52] Yaroslav Dobryakov: Yep.
[01:26:52] Rifaat Shekh-Yusef: So we're gonna give the agent, like, the other presentations, and then we can go back to this discussion. Okay? So I'm gonna drain the queue. Like, we're not gonna give the queue and like, please drop from the queue right now, and we will come back later to discuss all this topic. Okay?
[01:27:14] Hannes Tschofenig: Yeah. It looks like we already having the discussion ahead of the actual agenda item discussion. So, it wasn't meant to be that way. We'll fix it.
[01:27:25] Rifaat Shekh-Yusef: Yeah. Dick.
[01:27:47] Dick Hardt: Good afternoon. I'm gonna talk about just one gap around OAuth. OAuth is the workhorse. It's the most popular workhorse for solving authorization just like the Ford f one fifties.
[01:28:02] Hannes Tschofenig: Take the mic.
[01:28:03] Dick Hardt: What? Sedar?
[01:28:04] Yaroslav Dobryakov: You're too tall for the microphone.
[01:28:12] Rifaat Shekh-Yusef: Is that better?
[01:28:12] Dick Hardt: Is that better?
[01:28:13] Rifaat Shekh-Yusef: Okay.
[01:28:17] Dick Hardt: I have to start over. Can I just keep going? Keep going. Okay. OS, the workhorse for
[01:28:25] Yaroslav Dobryakov: it's a
[01:28:25] Dick Hardt: tool everybody goes to for authorization things. That's you know, just like the Ford f-one 50 is the best selling vehicle in America for all the Europeans here. Haven't explained that. Other presenters gonna present a bunch of the gaps. I'm just gonna focus on one gap, which is how do we enable self driving software? So software has changed. I think we all know that. Software is operating very differently. It's no longer deterministic. And so when resources you know, what resources an agent needs is now often determined at runtime, and what access the agent need is often determined at runtime as well, and the authorization still in almost all these models is deterministic. But irreversible actions, work of consequence, we don't trust agents. Right? Right now, nobody enables delete databases tool for the agent or anybody that read news and saw a table get deleted that was production has disabled that functionality thinking, don't want that to happen to me. And so delete that database, you know, we we don't want to enable it to happen. Right? And so but, you know, if we were deleting we do, at times, though, do wanna delete a database. Right? So if it's a scratch copy, if we're creating a database, deleting a database, creating a database, deleting a we do testing, we do things like that, that's all fine. But if that's a production database that, you know, we've been running, it's got millions of records in it, that's horrible. But if it's actually that production database and it's after we've verified a whole migration and so we expect that to actually happen, then that's okay. Right? So same database, different things, like all of this is very dependent on the context of what it is. Right? The scotch one's fine. Production just being production is catastrophic unless, of course, it was part of a whole larger picture around what's happening. And so no scope separates these types of actions. Right? We're really dependent on the context. Right? The the mechanisms we had before around what's allowed to happen, not allowed to happen are no longer available, particularly in a dynamic world where we're trying to make these decisions. It's that context. And so, you know, in that context, it's like, what's the mission? What are we trying to set out to do? Right? What else has happened? Right? And so in this one for deleting the production database, right, it's like, well, the migration's already happened. Right? We've already done this, and so now it is okay to delete that database. And so today, right, we want to make a have a human make that call. We want to flow all that back to a human, but if a human can make the call, so could AI. And so AI making these decisions of consequence is happening already in self driving cars, and so I'm using that as an analogy, which, of course, isn't perfect, for self driving software. So, you know, there's an artificial brain making decisions of consequence in these self driving cars. Right? So we have been doing these things, having separate brains that are making decisions that are things of consequence in a nondeterministic world. And so it's not the agent that's doing the work, it's a separate agent that's evaluating that context, the governance agent. And so in a self driving car, we need the destination, we need inputs, we need control for that brain to make all that decision. And so in self driving software, I say, well, we need a mission. We need context. We need control. Right? We need to have all of that stuff together so we can do it. And so I'm saying that's a gap. That's where we want to get to is self driving software. And the question for the working group is, do we do that on the Ford f one fifty with mechanical linkage and all the stuff we've been building and have that was designed for something else, or do we start with a different platform, the battery electric vehicle, the Rivian, or and Eoth? I have a side meeting on Eoth in the room next door after this meeting.
[01:32:32] Rifaat Shekh-Yusef: Okay. Jeff. We so so yeah. Yeah. Yeah. Yeah. Jeff. So so we're gonna have that discussion at the end of the Okay. Presentation three presentations. Okay? I
[01:32:58] Mike Jones: got ten minutes, not five.
[01:33:04] Rifaat Shekh-Yusef: Go fast.
[01:33:05] Mike Jones: Hi. I'm Mike Jones. Did you see Dick? Dick was fast. See Dick run. I'm gonna talk about some interesting work I'm doing with Skyfire and some coauthors from Akamai, Experian, Okta, and Ori. So we're trying to enable agentic commerce on the actual web we have and with the APIs we already have. And that's the goal informing all of what follows. So, in this presentation, I will derive information that we've learned and experiences from building this out and then talk about, well, what does this mean for Oauth and what did we have to build to build it on top of Oauth, the f-one 150 of the identity world? That was your joke, Dick. So, what properties do we want first before I get into the gaps? We want parties involved in the interactions to be able to decide whether to let an agent through just like they would let you through as opposed to blocking an agent. We want to eliminate for the agents working for you the are you human tests, which they're going to fail. We want to be able to use agentic access to website and APIs without having to set up an account at every place you go. It should just be seamless. And of course, standards are a necessity. I've made my living off of that. But it's what enables open cooperation and open ecosystems. So, the next section, I'm going to talk about the gaps that we've learned about by building a real system. So, the first gap is being able to represent information about the human being or organization that's authorizing the access of the agent on its behalf along the way. And this would end up being used or is in our use case used by content distribution networks, fraud managers, bot managers, all these infrastructure players as well as the identity systems that we're familiar with. We want to enable your agent to get the same access that you would get as a human without you having to do it yourself. So, one of the gaps then is how do you identify the person or the organization that is authorizing the agent's access? And we're actually being agnostic about that. We're not saying we must define the identity representation. We recognize that that's an unsettled piece of work, which is itself a gap that you know, you might use a SPIFFE identifier, a client-id-metadata-document URL, you might use a lot of things. But you still want to convey them and have that be recognized. We're also enabling payments, that's not the focus of this working group, but that's a gap. Then there's three different sets of claims. This is informed by some work with Experian that has a lot of information that's used to identify fraud and whatnot. So, one of the interesting things is I wrote with some of you a draft nine years ago to list authentication methods. Well, it turns out we've done a lot as an industry in the last nine years. There's a bunch of new authentication methods. There's pass keys, those didn't exist. There's facial recognition with liveness check. There's a whole bunch of authentication methods we don't have representations for. We have a draft for that. Another gap is identifying how the person was proofed, we have a draft for that. There's anti money laundering, which again, in finance and some of these use cases that matters. We don't have a claim for that yet. We need a token or a representation for this and we need ways of conveying this. Where the clicker is really stochastic.
[01:38:22] Rifaat Shekh-Yusef: Do you want me to take it from here?
[01:38:24] Mike Jones: I may at this point. Yeah. So, in Shenzhen four months ago, Ecker asked everyone and then I'll do my best Ecker. Do you have a bunch of people who want to interoperably use your thing, in which case you need a standard? Or are you just presenting your project? In which case, why are you here? And a lot of people were unprepared for this question. And indeed, you used a different version of that question when introducing our session. I'm here partly happy to be here because we are doing this work with a whole bunch of other people and I won't belabor that. You can follow the URL next.
[01:39:12] Rifaat Shekh-Yusef: Okay.
[01:39:16] Mike Jones: So the main artifact that we have is something called a KYA token. KYA pay token. Know your agent. It's a jot. I know some things about jots. We carry claims about the things above.
[01:39:31] Rifaat Shekh-Yusef: So we wanna give mailing a chance also.
[01:39:37] Presenter: Yeah. Yeah.
[01:39:37] Rifaat Shekh-Yusef: Okay? So can you wrap up here?
[01:39:40] Mike Jones: Yeah. Let's go to the next to last slide because my clicker stopped working. So we have a bunch of specs filling these gaps to a point that George Fletcher made. Most of these pieces of functionality are independently useful. So, for instance, the AMR claims, the KYA pay token might be used with other systems. We do want to collaborate with other people. Last slide. So, you can contact me. I'm going to do the normal OAuth thing though and ask, are there people willing to read some of these drafts? I'm not asking you to take agenda time, but if you're willing to read them, go to the chat and say that you're willing to and I'll work with you. Thank you very much. Awesome.
[01:40:39] Rifaat Shekh-Yusef: Thanks, Mike. Okay. Give it a shot and see if it works. Right?
[01:40:58] Yaroslav Dobryakov: Yep. Okay. Okay. Okay.
[01:41:03] Mailing Huang: And the last one for the presentation is about the core use case and gap analysis for AI agents. And the the URL here is our individual draft, and second line is the GitHub repo here. And we also have several issues haven't been solved, and we welcome the experts to help us to make it clear. Okay. Next. Okay. Our use case have divided into three parts. The first is the personal and consumer scenarios. We almost have a five use case here. Okay. The first use case is for the personal digital assistant. Is it now it's very popular now. So the scenario is is very simple, so I I don't explain it in more detail. So we come to the second is the authorization requirements. So it need to intend to permission mapping and translate the abstract go into specific, minor, adjusting time permissions, dimeth dimethically. And second is interactive consent rules, like human in loop. And the third is task level revocation. Enable one click revocation of all permissions tied to our single task context. So the game plan is is that the pairing mismatch and also no inter interactive for all standards and also our we need to create the relocation here. And the second is for our smart home or and automation, although some experts, commerce that it has to be slowed up. I also list the use case here. So the current case is that in smart home and automation scenario, there is really how scope explosion. So all all a consent screens become usable when presenting of device specific codes to users. And second is missing the policy context. And it also have no back location standard. It because maybe it's like a group. No. We cannot relocate one by one. So and the use case three is for agent as users representative to third party tools. So the requirements is here. Agent user distinction. Which one is user? I mean, the human base and which one is agent? Who delegated their task to which agent? And second is that agent take specific policies apply weaker rate limits to codes to agents without impacting human user experience. And set the requirements that constrained delegation are granted limited scope permission instead of full use access. So there is the gate here is that no standard agent in identity maybe like SPIFFE ID and and and see like that can do that, but I'm not sure. And second is binary scope limitation. Yes or no? All is too narrow. And third is set gate is that to confuse the program. Okay. I will more quick. A use case for its agent accessing all our resources as users proxy. Okay. The gate here is that architecture misalignment and the missing intended to permission breach and also risk of over authorization. A use case five is the first connection to our service with no pre authorization channel is from okay. I don't remember her his name. So the as also, I think, is that they need a preacher, Erno, last bootstrapping and the user in the shirt and the constraint and also re revocable by design have touched in other use case. So the game analysis also have devices also authorization follows the or accumulative accessible verification page access exist, which is not sure not sure for many handlers or isolate isolated service. And second is missing standard for cold starts and insecure anti purges. And the the second part is and for enterprise and the business process scenarios. So use case six is for complex business process automation on, like like like, ensure client process processing. It needs invoke agent, verification agent, and justification agent or payout agent. Each step depends on their secure secure handoff of the prior agent's output. So the game plan here is no native multi hub support. And the second is missing context, the stand stand standardization.
[01:47:08] Rifaat Shekh-Yusef: So Okay. Many I I see that you still have about
[01:47:12] Mailing Huang: Oh, no. This not the last one. It's for okay. Perfect. Okay. I will
[01:47:19] Rifaat Shekh-Yusef: We wanna just get to that discussion level. You don't have to be exhaustive with all the use cases. Right? So Mhmm. Wanna be able to get that discussion for with the work group. Right? So
[01:47:31] Mailing Huang: Okay. So I will I cannot answer your use case and
[01:47:36] Arndt Schwenkler: Yep.
[01:47:36] Mailing Huang: Your summary of the common requirements here. Finally, we think there are five requirements here is first, the dynamic scope and intent expression. Second is flexible and diverse interaction measures. And the third is native agent and the group identity support. The third is secure multi hub and cross domain delegation. The last is dynamic lifestyle and advanced relocation. As a response to drafts comments that we have to analyze the existing author extensions for agent authorization, which which we can use as the broad building blocks, which we need to do the optimization. And the the first is RAR. So we we know it it's useful, but the game here is that static by design unable to natively adapt to their dynamic, deterministic actions of autonomous agent. And, also, DPOP, the game is that assumes fix the key employers making it in capital ways agent modification or dynamic sub sub agent creation. Answer is for transaction tokens. The desire for trusted in in internal net force networks not suitable for untrusted part third party agent interactions. And the four is for client-id-metadata-document. So the game lock is lock of agent context, public UI dependency, and missing delegation trustability. And I list three question here. The first one is, do we think there we know there are many use case for AI agents, And we do the use case and gap analysis is useful or is or not. And second is, are there any unique new use case that need to be added? Is that all and the requirements have covered our order new use case. And so is that if if we think the use case is useful, do we need to quickly polish the use case? Maybe we can join the biweekly online meetings to polish the use case to help other solutions to develop.
[01:50:38] Rifaat Shekh-Yusef: Okay. Thank you. So can I get Mike and Dick here at the front? And we wanna have a discussion, but I just wanna remind everyone that this is just the beginning of the discussion, and we are like, Hannes and I would chat about this. We're thinking about scheduling an interim meeting to continue this discussion. So but, hopefully, that gives you a flavor of what people are thinking here, and we wanna get that that that feedback from the community here.
[01:51:12] Hannes Tschofenig: But as you've seen from even those three presentations, you also or the presenters believe that there are a number of gaps from, expressing the mission intent all the way to sort of very specific details that Mike presented on AMR. And you brought up a couple of many gaps as well. So we probably have to discuss them a little bit more. Well, we will have to discuss them a little bit more because there's almost too many things that you brought forward. Those who were previously in the queue, I encourage you to join again because I'm sure your question is still unanswered by now. So don't be shy, and let's get it going. Dapeng Liu?
[01:51:59] Dapeng Liu: Dapeng from Alibaba Group. So I have a comments to the k by pay draft to to Mac. So I I think the proposal is is very interesting. I I can see it's could bring value to the ecommerce ecosystem very much.
[01:52:20] Mike Jones: So,
[01:52:20] Dapeng Liu: yeah, I just want to have a couple of clarification questions. First is, for example, if we as a ecommerce platform, we see a token come in, and it says that the users already authorized one agent to do something for him. So how can we trust the the users is actually is some valid user in our platform? How can we do the authentication for the user? Yeah.
[01:52:53] Mike Jones: The the token is signed by a token issuer, and there's open questions about what token issuers you wanna trust. I understand that. But assuming it's signed
[01:55:07] Yaron: know, it's gonna spend money if it ends up booking a flight on United, for example, and and I tell it, you know, I don't like first class. It's too expensive. And it goes and it hits the booking API on United, and it books me a first class ticket. That's not refundable. That's bad. In this case, I want to allow it to access United, but I want a human in the loop approval for the specific details that it's going to invoke in a way that it is hallucination safe. So I'm not relying on the LLM in any way. 100% guarantee the tool call that it makes, which is book flight, is done. I'm not sure. I I honestly, I'm not sure whether this use case is addressed by any of the three. I've been trying to read, and that's still not clear. But that's the use case I'm interested in. There's a bunch more.
[01:55:53] Rifaat Shekh-Yusef: Okay. Thank you. Thanks, John. Go ahead, Dave.
[01:55:56] Dick Hardt: That use case I gave as a talk at a auth night in San Francisco three weeks ago, and there's a video online of that, which is I wanna go and have an agent book me a trip to Japan and book all the stuff.
[01:56:09] Yaron: Everyone loves travel agent use cases. Yes.
[01:56:11] Yaroslav Dobryakov: Yeah. And
[01:56:14] Dick Hardt: which is why I view like, I want that travel agent to actually do all the booking, which is why we in the AIoTh architecture, you have a separation between the governance agent that makes that decision that's independent of the mission agent that's trying to book. But
[01:56:31] Yaron: does the AIOps specs you've written cover a human in the loop at the time of API call human in the loop approval or not? I thought it actually said it's not covering that use case.
[01:56:41] Dick Hardt: You you could have a human we'll we can talk about it more in the AI session.
[01:56:45] Yaron: That's the use case I'm interested in if
[01:56:47] Mike Jones: anyone is interested in that. Those are good use cases. I some of our examples follow flows like that.
[01:56:54] Mailing Huang: Yeah. I think it can aid to their open insurers.
[01:56:59] Rifaat Shekh-Yusef: Okay. Thanks, Jonathan.
[01:57:01] Peter: Peter. Speaking of as an author of the use case document, and we have run several site meetings, actually, we have a real use case of a security incident response. So in our cases, an operator usually handles security probes and response systems from various vendors, so that's very heterogeneous. So when there's a response, usually, the probe detects it and the SOC analyze it and the PEP will enforce it. So my message is, number one, the of the requirements that our workflow certain workflows requires cross domain user stories and workflows, and resources in different domains must coordinate. So that's number one requirement. Number two is that human in the loop may has its limitations because we it may trigger your fatiguing operation. It may trigger it may make makes the user being bothered many times. So what I'm thinking is that the requirements also in the document is a batch authorization or intent based authorization that actually authorizes a batch of authorizations at the same time to complete the work. So that's why I asked the question for yourself. So those are the two one use case to requirements. Thanks.
[01:58:19] Rifaat Shekh-Yusef: Thanks, Peter. Rashid?
[01:58:28] Presenter: In indoor flow, when we have our clients and
[01:58:30] Rifaat Shekh-Yusef: Get get closer to the mic. Yep.
[01:58:33] Presenter: Okay. And then when we have the the the clients and agents and the origin. So when when the agents act, for instance, to delete the database or something, that's how how the intermediary know this action from agents. So so in in use case And, like In the workflow that's
[01:58:58] Rifaat Shekh-Yusef: I think I think these are a little bit more detailed. We we're talking about use cases for now. So when we get to that those details maybe in the future. Okay?
[01:59:07] Presenter: Thank you.
[01:59:07] Rifaat Shekh-Yusef: Thanks, Christian.
[01:59:12] Rashid: Hi. I'll try to you tomorrow.
[01:59:13] Rifaat Shekh-Yusef: Go ahead.
[01:59:14] Deb Cooley: So Go ahead.
[01:59:14] Rashid: Yes. The question is that I do see a a snippet on interactive consent in this in the use cases that you show, but I do not see any section on user preference. For example, I want to say that you can save my date like, through my agent. You can save my data on your third party agent, but do not give to any other agent, you know, things like that. Is there any intention to expand the use cases for that? I can give more examples of why user preference is important if you if you like.
[01:59:52] Mailing Huang: Sorry. I don't get
[01:59:53] Hannes Tschofenig: User or course case. Use cases on user preferences.
[01:59:57] Mailing Huang: For what?
[01:59:58] Rifaat Shekh-Yusef: User preference.
[01:59:59] Mailing Huang: User preference.
[02:00:00] Yaroslav Dobryakov: Yeah. Okay.
[02:00:04] Mailing Huang: To these questions, I'm not so clear about their user profiles,
[02:00:09] Yaroslav Dobryakov: I think.
[02:00:10] Mailing Huang: But I I mean,
[02:00:13] Mike Jones: to the extent that we talked about the travel booking use case
[02:00:18] Rashid: Mhmm.
[02:00:18] Mike Jones: It's certainly the case that there's gonna be application specific preference databases and whether I wanna book United or Delta or Yeah. And there's a lot of contextual stuff and it's gonna be real. Yep. Okay. Whether it's in our protocols or at the application layer is yet to be decided.
[02:00:38] Rifaat Shekh-Yusef: Yep. Joseph. Joseph's Holloway? No? Where's okay. Okay. No worries. We are out of time, but you're on quickly.
[02:00:54] Yaron Sheffer: Yeah. This has to do with Yauroslav's draft and mine. I think part of the solution would be some consent negotiation, which would require raw metadata, so it can be as fine grained as a specific transaction or action. Sometimes that's too fine grained and causes a lot of friction. So me and some others think there will be maybe some more high level negotiation of guardrails that define the interaction and can be agreed upon. So that requires metadata in order to discuss and have a back and forth until based on some published schema representing a domain specific taxonomy. An agent or LLM can fill it and then put it up for approval. And still, in some points, I think there will be this step up pattern that Yauroslav showed, and I'm speaking about tomorrow, where we both agree that the resource server that enforces RAR can also be a good point of saying that's the missing piece. That's the missing shape. If you step up on that, I'm gonna allow you the next thing, so make things that are remediable.
[02:01:56] Hannes Tschofenig: Yeah. So it's obviously a start of the conversation, not the end. The impression I get is, like, we are all over the map here. Like, I almost see no overlap in in in like, from the different presentations. Like, it's almost, like, huge, and it's like a wish list to Santa Claus on what we all want to have. So it's going to be interesting to work this out. I'm sure we will succeed, but, yeah, I'm curious where we end up in the at the end of the day. But, yeah, with that, I'm looking forward to the next meeting, and to continue that conversation.
[02:02:36] Rifaat Shekh-Yusef: Yeah. And and look for us to schedule an interim on this topic. Okay? Thank you all. Appreciate it. See you tomorrow.
[02:03:02] Max Gerber: Thank you. But I'm not quite sure.
Session Date/Time: 24 Jul 2026 07:00
[00:00:33] Rifaat Shekh-Yusef: Okay. Good morning, everyone. Welcome to the last day of the IDF and the second session of OAuth. I'm looking for volunteers to take notes. Any volunteers, any takers, please? Just the highlights. You don't have to take a note of every word. Thank you. So remind me of your name. Sorry. Paul. Thank you, Paul. Appreciate it. Okay. Okay. Let's get going. So the reminder that the Note Well applies here. I'm assuming by by now you've seen this multiple times, so, make sure you're familiar with this if you're not. A few tips. Same thing. I'm sure some you've seen this already. Please make sure to log in. This will help us know how many people attend and plan for future sessions and allows you to join the queue if you need
[00:01:47] Yaron Sheffer: to.
[00:01:51] Rifaat Shekh-Yusef: And for remote participants, please make sure to mute your audio and video unless you wanna speak up. And if you join the queue, please state your name before you start talking. We've talked about update. This is a Friday agenda. So we'll start with our work group draft, which is attestation-based client authentication. We had an interim on this one, but hopefully we can wrap this soon. And then we have a number of individual drafts. So we kindly ask those presenters to allocate some time for q and a at the end of don't take the full ten minutes presentation, but allocate some time for q and a. So maybe five, six minutes presentation and then some q and a. And then we we're gonna switch and talk about policy language in OAuth. We're allocating about thirty minutes for that. And at the end, we'll have a discussion about clustering of OAuth work. This is, as we mentioned, with tons of requests coming our way. So we're gonna kind of try to get a handle of the control over this or handle of this. George and Aaron have been doing great work, and we'll we'll we'll be discussing this and see how we're gonna progress on this. So that's, that's our agenda for today. Any any bashing of that agenda? Okay. Thank you. Let's get going.
[00:03:45] Daniel Fett: Good morning. So I'm gonna present the latest updates on attestation based client authentication that I'm doing together with Christian and Tobias. When we cut the last draft two weeks ago, we thought we're pretty much done. Until then, a few new things popped up that we wanna discuss and bring it up. But in general, we're hopefully very close to working group last call. So, hopefully, we can discuss this by the end. Three things that came up, originate to the OAuth SPIFFE client authentication draft. Arlie and Pieter approached us and said, hey. We're using your draft. That's very cool. We see, like, a few things that, yeah, we struggle a little bit with, and they're thinking about whether would they need to basically override certain rules in our standard, or maybe we can find some common ground to to modify things in our draft. And I'll go into these three things. The first one is, yeah, the discussion, I think, that we also had yesterday. Basically, what does the subclaim means right out right now in our draft, we basically say that the sub subject value in the client attestation JWT is the client ID. And, yeah, as I said yesterday, we basically did this to circumvent the broader discussion of what client ID really means in OAuth. I think there was a lot of discussion also, for example, by Justin. And yeah. So we didn't wanna solve this issue in our draft, so we just said, well, it's it's the client ID. But, yeah, somehow for the SPIFFE draft, that may be a problem. I think we're not totally sure to bias things. Maybe it's not
[00:05:47] Rifaat Shekh-Yusef: a
[00:05:47] Daniel Fett: problem. So, yeah, I think the two proposals here can be either we we relax our language and say the the subject claim can be the client ID or something that's kind of adequate for the authorization server, or we just don't say anything and either if you, you know, makes the statement in their draft, and what the authorization server has kind of like a mapping, certain SPIFFE IDs match to client IDs, and that's kind of authorization server mapping logic. So that's the first one. The second one is that the workload identity tokens are kind of rotated very frequently, I think kind of hourly or something like this, and and they wanna use refresh tokens for this. The problem with this one is that in, client attestation, we have a statement that the refresh tokens are bound to the client instance key, so the the CNF claim in the client attestation JWT. And I think this is also something that we've been thinking a lot about whether, yeah, this is really the best choice. So the options that we have here is either we relax our text in our draft, We leave it as it is, or we introduce a new, yeah, client instance ID as a claim, which is also, related to the first issue that maybe could also help in certain situations because what we also see is in in some scenarios that it it may be limiting to to bind to this key because it prevents you to doing key rotations later on. Yeah. So that's issue number two. And issue number three is that the workload identity tokens define a new job type. Client attestation basically fixes the JWT type because we also wanted to follow the JWT BCP. So, yeah, I think the question here is, if some other drafts profile client attestation, should they be able to pick a new JWT type, or should they stick to the job type that's defined by client attestation and have another way, maybe with content type or, another claim, which would actually be my my favorite. Is there any feedback to this one until here? Because I think the three ones here are the the most important ones. We have two more issues that are rather minor, so I think that would be, the the main input that I'm hoping for.
[00:09:09] Rifaat Shekh-Yusef: Go ahead.
[00:09:10] Arndt Schwenk-Schuster: Yeah. I'm on Schenk Schuster. Can you go back to the first? Yeah. So being practical here, I believe your current draft matches what is defined in RFC 7521, '22, and '23. So I think
[00:09:24] Rifaat Shekh-Yusef: You can also turn, Mike. Yeah.
[00:09:26] Arndt Schwenk-Schuster: I can make the argument.
[00:09:28] Rifaat Shekh-Yusef: You can adjust it too.
[00:09:30] Hannes Tschofenig: Adjust it because you you keep talking.
[00:09:33] Arndt Schwenk-Schuster: Yeah. Perfect.
[00:09:35] Rifaat Shekh-Yusef: There you go.
[00:09:36] Justin Richer: Kid in this entire room. Swear. Yep. Okay.
[00:09:45] Arndt Schwenk-Schuster: I can make the argument to leave what you've currently written because it's and it's a broader problem, and I don't want to offload that on your draft. Right? So I think keeping that as is, I think, is consistent with the other specification, and I think that's not a blocking issue. Don't have any opinions on the refresh token so far. But on the third one, we are seeing a lot of workload platforms, and that is not just SPIFFE, but Kubernetes. There's gonna be agent platforms. They're all gonna be issuing sort of platform attested credentials. And I don't think we can assume that they're gonna be using this specific type to authenticate authorization servers. So I really think we need to loosen that up a bit so we allow for other types that are also key bound.
[00:10:37] Rifaat Shekh-Yusef: Okay.
[00:10:39] Justin Richer: Hi, Justin Richer. And so mostly, I wanted to comment on the client ID thing because there's this implied notion in OAuth that the client ID is a single value tied to a single client and that's not actually true and it's never actually been true because, in fact, what the client ID really means is that it is a value by which the authorization server can recognize the software that it's calling. So, it, like, is the client ID doesn't actually mean string comparison if you dig into the semantics of the spec. So I think it's totally fine to say this is the client ID, but you gotta be careful about calling out the fact that, hey, a client ID could be several actual different string values for a single instance and all that kind of stuff like that. And if you wanna dig up a really weird interpretation of that that kind of pushes this to extreme, John and I, very, very many years ago, had a JWT based client ID to do some stuff. Thankfully, it never went anywhere because it was weird. But but it's based on that semantic notion that the client ID is for the AS to recognize, not necessarily a static value. So I think that this, with appropriate explanation, would be fine to say it's the client ID. And by client ID, we don't mean necessarily a string.
[00:12:02] Daniel Fett: Right. So client ID is context specific. The authorization server may have some logic there. Okay. Thanks.
[00:12:09] Joseph Heenan: Yeah. So I think with the client oh, sorry. Joseph Heenan, Auth-let. With the client ID one, I think we just have to be careful to make sure the semantics are clear because that's used in tokens the authorization server produces as well and that the client then has to check the value that comes back, so we need to be clear on the semantics there. And on the refresh token binding, I agree that there's a problem there. Could we not do it as a key rotation, though, where you have the old key signed by the new key, and then I think you don't need a client instance ID? Because client instance ID seems to get a bit odd, and maybe it's
[00:12:44] Daniel Fett: a secret. Maybe it's not otherwise. I think the idea of the client instance ID here was basically the the client attester kind of has the logic how the key rotation would happen or that he makes sure the client instance is the same client instance that it was before. So then the authorization server only needs to, yeah, store the client instance ID and make that comparison. Yeah. Let's that's something that Tobias has experimented with, and I think they're kind of actually using this already.
[00:13:19] Christian Bacher: Okay. Yeah. That could work.
[00:13:23] Philip: Hi, Philips. Think it's fine for profiles to change the tip of of the assertion. But when they do so, they shouldn't keep on relying on the same name of the client authentication method.
[00:13:37] Daniel Fett: Sorry. I didn't get it acoustically. Can you say again?
[00:13:40] Philip: The client authentication method name should also change. If you change the tip, change the method name, which sort of gives you a problem when you think about the the way of using the draft that isn't a client auth method. Because then how do you distinguish between the two? If it's a closed ecosystem topic, fine. You just sorry. Fine. You just hard code it. But if you want this to be interoperable, it needs to be identifiable over the wire which profile is being used. Mhmm.
[00:14:15] Daniel Fett: And maybe for this one also, Arnd, I was I was wondering where are you, Arnd? Yeah. There. Because I think you were not worried about changing the type on the client attestation pop chart, but only on the client attestation chart. Would you change the type value on the pop chart as well, or why are you not worried about this one? Or is it kind of like legacy you chose the type already?
[00:14:41] Arndt Schwenk-Schuster: I'm I'm I don't have an opinion on it. It's it's self produced, so whatever the workload puts in there, they have it under their control.
[00:14:54] Rifaat Shekh-Yusef: Christian? You're good. Okay.
[00:14:58] Daniel Fett: Then, very quickly, the last two ones. The client metadata, this was something that was requested and was not in there in the latest draft. If, if someone wants, he can can review this one. Aaron, maybe. And the very last one is we're gonna request from people to say what's our relation to RFC 7521, because some people are using this already, and it would make it easier for them to to transition to a client attestation. The problem here is that RFC 7,521 always uses the HTTP body, and we have everything now in the HTTP header. And seven five twenty one uses the client at assertion type, but also the client assertion value. So it's unclear what the client assertion value would be, and that could lead to, yeah, confusion and bugs. So I think our proposal is here to to not say anything about RFC 7521 and not use it at all. Is there anyone thinking differently?
[00:16:15] Rifaat Shekh-Yusef: Sorry. We we run out of time here, but, yeah, go ahead.
[00:16:19] Anton: Talk
[00:16:21] Arndt Schwenk-Schuster: to Brian. He's gonna have opinions on it. I believe it makes sense to reference it because the way I understand it, seven five twenty one is meant as an umbrella draft for client assertions. They call it client assertion framework or assertion framework. So I think not talking about it seems bad. Maybe talk about why you're not using it. Okay.
[00:16:45] Gareth: Okay. Thanks.
[00:16:47] Rifaat Shekh-Yusef: You hear Okay. Thank you. Thanks. Okay.
[00:17:04] Co-Chairperson: Who's next?
[00:17:04] Rifaat Shekh-Yusef: Hey, Justin. Yeah. Okay.
[00:17:13] Justin Richer: Alright. Good morning, everybody. It's Friday on IETF. Let's all wake up. I am here today to talk about HTTP message signatures and how we can use them in OAuth, and I just added Aaron's name to the slides, so it's his responsibility too. I'm gonna go really quick through what HTTP message SIG actually is and how it works, but mostly I wanna talk about how it applies to sort of the OAuth space. That's a really big echo. I think I'm just too loud for the compressors. Anyway, h t p seg is a general mechanism for signing HTTP requests and responses. It's a detached message, system, which means that detached signature system, which means that you don't actually replicate contents in the, in the signature carrier to go across unlike Jose, which is made to be a self contained cryptographic system. And it's all defined in RFC nine four two one. Oh, and you can play around with it at h2dvsig.org, which I do recommend you going and playing around with it because it's a really great way to see how it works. So when you're signing a message, you have to pick what you wanna sign, choose your keys, normalize the message, generate a base string to sign over because it's a detached because it's a detached mechanism, you do have to do some normalization and then sign it and shove that in the message and you're on your way. The important thing here is that there's a couple of bits and for the folks online, I'm laser pointing at the things with asterisks. There's a couple of things here that the signing spec does not actually specify and that's important because we deliberately left that open for applications of message signatures to decide what was needed there. So let's take an example message. We're gonna figure out that, hey, we wanna sign the method, the target URI, and content digest. To do that, first, we have to calculate the content digest because you don't get that for free in HTTP. And then we create what's called the signature base string. And you can see here, we have the three bits that we're signing, the method, target URI, content digest, and this last line, and it's always the last line, has all the parameters that tell you what was signed, it's got some tags in it, stuff like that. Once you sign that, you get a bunch of bytes and you shove that bunch of bytes onto your message along with, as you'll notice, the contents of that last line. This says, this is what I signed, in this message and this is the signature for it. Couple of important things here. One, you'll notice that it doesn't actually replicate, oh, the method that I signed was post in, any of this right here. None of that's copied over because HTTP is weird. It gets reconfigured all sorts of different ways in transit and so you have to be very careful about what you're actually deciding to sign. And if you're copying things over into the base of the signature, that means you have to verify them that they are actually the same in the message that you're verifying against. Keep all of that in mind. But anyway, this is what it looks like. This is a signed HTTP message. To verify, we pop that off the wire on the other end where the server receiving this post request in this example and then we gotta figure out which signatures apply to our application because you can have multiple signatures, by the way, on a message. You can stack them up as high as you want. You validate that the things that were covered in the signature are the things that your application needs and you resolve which key material you're validating against and then you go and verify it. So what you do is you actually regenerate that message base string based on the message that you received. And this is where the detach part really, really kicks in because you were not told, unlike with Jose, where it is defined as, you know, the base URL protected bytes the body of the payload, you are not told that because HTTP shuffles things around in some predictable and some unpredictable ways. So anyway, you regenerate that message, base string, verify against it. That's all pretty boring crypto. And the reason for this is that think how weird HTTP is. You're wrong. It's a lot worse than that. HTTP changes in ways that are just mind boggling. Did you know that there's not really an encoding assigned to HTTP? It's sometimes ISO Latin one. Maybe. It's just weird corner case stuff like that is really important to get right, and that's why we developed h t p sig in the HTTP working group so that the HTTP experts could throw lots of rocks at it and make sure that we got this bit right. There are a lot of use cases for general signing and there are other methods to get some of this behavior. You can encapsulate the message. You can replicate, bits of the message using something like Jose. And there are, those have some undesirable side effects. So the real question today, how do we take this and apply it to OAuth? Well, all those asterisk. We gotta decide what's required to sign. We gotta decide how to associate a key and decide what algorithms and parameters are tied to that. So I wrote that down and that is now h p sig version o two. Aaron helped with the latest version of the draft. So like I said, you can blame him also for this now. And if you're presenting an OAuth access token, it makes a lot of sense to sign the authorization header and and that includes the token value and then method and target URI seem pretty reasonable. Is there anything else? Maybe. I think that's something that we gotta discuss. In order to get the key associated, OAuth gives us two really interesting opportunities right out of the box. We could introduce them at registration time, meaning that the client just registers, hey, this is the key that I'm gonna use for binding tokens to and for especially static clients and things like that, that makes a lot of sense. Could also introduce it at runtime just like Depop. This is one of the most interesting parts of Depop that I've always loved is the dynamic, key introduction at runtime. It fits a lot of use cases really well, especially if your registered keys and your runtime keys might be different for some reason. So anyway, you you figure out which one of these that you wanna use and there are probably other ways to do key introduction. That's something we should talk about as a working group. In my draft, I effectively limited it to JWK. Maybe we don't wanna do that. I don't actually know. We'll get there. In order to introduce a JWK over the wire runtime, I did the really dumb caveman thing in that I serialized the JWK and base 64 encoded the JSON serialization and called it a day. This, I'm I don't like it, but it works. You know? It's it's pretty robust, but it's it is definitely dumb. Anyway, to to present a token, we sign the request, include the parameters, and if you're also presenting the, the key, if you're doing a dynamic key, you present the key at the same time and sign over the key. When you issue a token, just like with any other thing, you set your token type, you ensure that it maps to the correct client and do all of that stuff and the token here could be opaque, could be a chart, could be really anything here. This draft doesn't actually care. But I do think it does need to be a new token type because we have a new presentation mechanism for that token. With the Jot, we would probably have a a new confirmation claim or some flag in there to say that this is how you're gonna do this. To use it, you sign it and you send it. Pretty straightforward. That's what h t v sig is there for. This is what it looks like. That's pretty boring. To verify it, you pop it off the wire, make sure that all the bits that are supposed to be signed are signed, You look for the right tag, and then you verify the signature against the key that you resolved. That's like, the the way that these things stack together, that OAuth and h t sig stack together is really is simple. You apply h t b sig to OAuth messages. But there's a bunch of other things we could do as well. We could use it for client authentication like we did with OAuth m t e l s. Have two sections about that. We can actually use this in server responses. Do y'all remember the Jose signed introspection response we did a few years ago? You could do an h b sig signed response and not have the encapsulation problems that that comes up with. FAPI has a really neat non repudiation case. We could use it with par. We could use accept signature to do negotiation, especially for RS needs. There's probably a whole bunch of other stuff that I haven't thought of. This is the stuff that I put into the appendix that said I don't wanna fill out all these ideas in the draft right now. But there are a lot of different directions we could do in addition to this base piece. So to address the elephant in the room, what is Depop all about and what does this have in relation to Depop? Depop was designed for a limited use case by design and I think it's great for that. I think that this addresses a different set of use cases. Different key management, different presentation, tactics. And Jose's not a good fit for signing HTTP. Anybody who's implemented Depop will know how weird it gets when you're trying to cram all those bits together. HTTP doesn't play nice. It works fine. And if it works for you, yeah, keep doing it. But I think that we need to define a more general mechanism that works in other different spaces and we can do that here. So I'd like to propose that we work on this here in the working group. This is the right place to do it, and I think it's a legitimate option next to Depop and MTLS.
[00:27:12] Rifaat Shekh-Yusef: Okay. Thank you, Justin. We have ran out of time, so I'm gonna give two people a chance to two people only, and the rest will unfortunately, we'll have to go ahead, Kathleen.
[00:27:23] Justin Richer: Sorry. I tried to go fast.
[00:27:25] Kathleen Moriarty: Lucky I hit the button quickly. I have a lot of questions.
[00:27:29] Justin Richer: I don't think we have time for them.
[00:27:31] Kathleen Moriarty: I know. So we also so gosh. I have too many questions. I'll have to go through the draft. Maybe I can meet up with you. We live in the same town. We have use of HTTP signatures for authentication Mhmm. Two other working groups. Yes. That's different. Is is this OAuth, right, when you're going into this whole space, or are you branching it off too much?
[00:28:06] Justin Richer: To me, this should very, very specifically be how do you apply it to an oauth access token? An oauth oauth access access To oauth access tokens and the things that get dragged along screaming when you grab an OAuth access token.
[00:28:19] Kathleen Moriarty: Okay. It it feels like the scope is really going bigger and bigger.
[00:28:24] Justin Richer: I really don't want the scope to go bigger. I I don't think it should here.
[00:28:27] Kathleen Moriarty: I mean,
[00:28:27] Hannes Tschofenig: I Maybe I should provide a little bit of context because this has a long history. So Justin has been working on this, like, in this group initially, and then it moved away. And then we said, oh, we look at it later. Again, now it is the later, but many years have passed. Some of you weren't even born at that time. So Almost. Almost. Alright.
[00:28:50] Kathleen Moriarty: So maybe an interim with a deeper dive would be useful?
[00:28:54] Justin Richer: I'd be happy to do this in an interim.
[00:28:56] Hannes Tschofenig: Yeah. Yeah. We we should definitely do that, but Yeah. Thank big thanks for sort of, like, doing all this work and and battling things through and coming back. So I really appreciate it.
[00:29:08] Rifaat Shekh-Yusef: Yeah.
[00:29:08] Justin Richer: There are already several protocols that do almost exactly this. We just don't have the OAuth version.
[00:29:14] Rifaat Shekh-Yusef: Okay. Philip. And and that's it. After Philip, I'm not sure if agree. The queue.
[00:29:19] Co-Chairperson: Sorry.
[00:29:19] Philip: The JWK is already encoded. Let's not encode it again for the sake of the signature key.
[00:29:26] Justin Richer: Oh, yeah. No. That part's dumb. Let's make that better.
[00:29:28] Philip: HTTP signatures already carries with it the algorithm, the key ID. The only thing we need is a is is the bit string of the public key. Let's do that instead. I'll sync up with you after.
[00:29:39] Justin Richer: Yeah. I've seen some other worse ideas to how to do that, but I would love to work on a better idea.
[00:29:45] Rifaat Shekh-Yusef: Thank you. Thanks, Justin. Go for it.
[00:29:54] Yaron Sheffer: Thank you, and happy to have you all here in Vienna. Let's do this again soon. Very comfortable for me. This work stems from a draft I presented together with Jeff from AWS and Alex Beveneau last year in Madrid, and now it's taken a bit different path. But still, the core problem is RAR is, in some environments, very widely used. It's very efficient. It carries fine grained authorization context, but there's a lack in how clients discover what are the RAR schemas. All these agreements are out of band, And if you consider large deployments like HealthID Norway, you have, like, a national health health care provider with 300 clients that need to consume it. How do they find out what are the route types to request? And so the idea was, can we add an explicit metadata of what's the documentation, what's the schema? When RAL was born, LLMs were not the thing, but now such a schema can be consumed in runtime by an LLM, negotiating with an end user, constructing the RAR type, and presenting it for approval. That's another use case. Looking at ID-JAG, it can definitely benefit from the RAR schema just for interoperability reasons, or to do governance on it. The second use case that it tackles is, can we leverage the resource server to when it's rejecting, so there's no normative language how to reject on insufficient authority. Can it reject on insufficient authority while providing the shape for remediation in case remediation is possible and possible by the end user? So that HealthID patient logged in and saw his blood test results and other things, and he wants to apply for an MRI test for his leg. And that requires additional authority. So you can't do that with a login token. You have to file a request, but the resource server is the place where RAR is evaluated. Right? It's a place that says that's not sufficient. So can it turn this incoming request into the remediable body and basically use this domain knowledge that it already has without changing the RAR trust boundaries, meaning it's still a request semantic. It's still being served by the client. So so these are the challenges these tackles. And so the draft proposes a new endpoint for metadata and schemas, and the normative error response in the dot dot dot authenticate header with a clear error message and the remediable object. So let's look at it. This is the metadata endpoint. It provides schema documentation, either in line or as a URI, which could be helpful in ID-JAG situations where the IDP can serve as a proxy and proxy remote schemas for discovery and usage. Let's see. That's a discussion ongoing on the mailing list. There has been some discussion whether this part merits its own draft. I think it's it's a valid point. And whether this should be on the main metadata document or in an endpoint of its own. Currently, it's in an endpoint of its own. Makes sense to me because the R types are gonna be so verbose, and the metadata is so concise, and some geeks like me like to look at the metadata when we debug and not to overload it, but it's it's a discussion we should have. The second part is the normative error. So when it fails, you see there where's my laser? You see there the error is Dot401 with A dot Dot authenticate error. This is the error you have insufficient authorization and a description that's human readable, and then the remediation. This is a base 64 encoded JSON that carries the content. In case this is a single use, like this MRI permission is one time, or in this case, a payment, then error remediation is going to contain authorization details with exactly the raw objects. As I said, leveraging resource server knowledge into the raw it needs to evaluate when it decides it's not enough to turn the input into the shape that's remediable. We see this as a great interoperability improvement for clients. So if you consider Helsaedi Norway with 300 clients, so the knowledge to construct the correct RAR is now developed in 300 clients. Right? So without changing the fact that it's without changing the trust boundaries of this being a client responsibility, can we make it more interoperable and say, for what you've asked, this is the shape that remediates it. If you'll go and ask for this and the and you get all the authority, either the end user needs to consent or some policies govern it, and someone in the organization needs to consent, this may work the next time. The second parameter is a GNAP inspired authorization reference. So the idea is maybe the client again, this comes from discussions in MCP. Thanks, Max. A valid point. Clients need to be simple. Clients need to be stupid. They don't want to navigate raw semantics of different trust domains. So if the client has already asked something before that is multi use, in this case, a direct debit mandate, the the resource server can calculate the handle, a reference. This is Spirebike NAP, and and this handle can assist the client. Maybe the client has already obtained previously a token that can satisfy the request. Instead of navigating the the raw semantics, they just do a string comparison and say, oh, I've got the token. I've been challenged before. I've got this token before. I'm gonna retry that before I take the user to another consent journey. So this is seeing interest and adoption. There's a SEP in MCP. Based on this, we brought this from an active use case we have. So Raiffeisen Bank International, we we use this in our systems in order to move the onus of constructing the RAR from the clients to the resource server as an interoperability an interoperability boost. HealthID, health care provider is interested in it, It's gotten some discussion interaction on the working group. So thanks to Justin and Jeff and Judith, if you're if you're here. And, yeah, we've done some changes and improvements. And I think due to the interest it's shown and the interoperability it puts, and I think it's perhaps ready for adoption, I think this is work the working group should consider working
[00:36:12] Rifaat Shekh-Yusef: on. Thank you. Thanks. Thanks, Yaron. So just one one comment about presentations here. I know it's not specifically about your presentation, but, like, when when you present and and I'm talking to all presenters. Please don't use that pointer because we have we have remote people that can't see that pointer. Right? Like, you point at at the screen here.
[00:36:36] Yaron Sheffer: But they don't see it online.
[00:36:37] Rifaat Shekh-Yusef: They don't see it online. Okay. So please avoid doing that.
[00:36:40] Yaron Sheffer: Honestly, when I'm sitting there, I also don't see it when I'm in the room, but
[00:36:43] Rifaat Shekh-Yusef: There you go. That's just me. Okay. So now, go ahead, Nick. Hi. Nick Watson here.
[00:36:50] Nick Watson: So two things. First, I think insufficient authorization and providing RAR, excellent. It solves a gap that we very much need. And then draft also doing something similar. Would love to make those two kiss. Next thing, authorization reference. I'm maybe mildly skeptical of this in practice because of the potentially hierarchical nature of RARs. Like, you have one there for authorizing a €100. If you had one for authorizing €120, presumably, that could also be used for €100 transactions, but that authorization reference is not gonna match. So I'd be curious in any kind of implementation whether this ends up being useful in practice or whether it's just hyper specific and LLMs in particular are better off just trying to read RAR and make their best guess. I don't know. It might it might be something that I would consider splitting just to keep the scope smaller because I don't I don't know. Anyway.
[00:37:51] Yaron Sheffer: Yeah. I'll just say I think that's a very valid point. About the Yaroslav's draft, we had draft alignment and layering, and so we tried to understand, and we we reached some consensus. We're gonna put it up and write it about what to use when, what applies when. So but we're both very happy that this pattern resonates that the resource server can help in remediation.
[00:38:15] Arndt Schwenk-Schuster: On Shankh-two, I agree on the problem, but I believe we need to debate the solution space. Right? Particularly, as I said, with the draft and yours. But plus one on the problem space.
[00:38:26] Yaron Sheffer: Thank you.
[00:38:29] Justin Richer: Justin Richard, this is definitely a gap in the ecosystem because we have insufficient scope. We didn't dive into this with the RAR draft specifically because it's kinda hard to get it right and so we wanted to make sure RAR could get out the door without having to solve the whole ecosystem. So, yeah, let's go let's go solve this part. This makes sense. I do really strongly believe in being able to pass by value and by reference for this because so to to the previous point, it's not the agent or LLM or client or anybody that needs to make sense of the reference. It's the AS.
[00:39:04] Rifaat Shekh-Yusef: The queue.
[00:39:05] Justin Richer: And so the AS can basically figure out, oh, you asked for these two things and I can actually subsume them. That happens today with scopes. If I ask for read and write in most APIs, I didn't have to do that. I only had to ask for write. But that doesn't break anything, and the AS can figure out how to subsume those and give you the right bits when it needs to.
[00:39:30] Rifaat Shekh-Yusef: Thank you. Mike, sorry. We've locked the queue already, Mike. We've locked the queue, and we have run out of time. So I'm gonna call for adoption here and see if the work group is interested in kind of adopting this doc document as a starting point. So I'm gonna start a poll, and please reply.
[00:39:59] Hannes Tschofenig: Now you should
[00:40:00] Yaron Sheffer: This happens now live?
[00:40:01] Daniel Fett: Yes. So exciting. Yeah.
[00:40:05] Hannes Tschofenig: We we are high-tech group here. We are high-tech group.
[00:40:10] Rifaat Shekh-Yusef: You can see the results live. Without
[00:40:13] Yaron Sheffer: my glasses? No.
[00:40:15] Co-Chairperson: It's a good good result so far. Okay.
[00:40:19] Yaron Sheffer: I cast your votes.
[00:40:21] Rifaat Shekh-Yusef: Thank you. Hold on. Yeah. Okay. I think I'm gonna lock it now. Oh, it's still coming.
[00:40:34] Hannes Tschofenig: Yeah. But it's But
[00:40:36] Rifaat Shekh-Yusef: yeah. Perfect. Let's let's end it here. So we we got 28 yes, two three nos, and 12 no opinion. I think we have a clear consensus here to to go and adopt this document. Thank you. And, obviously, we we'll do that, on the mailing list too. K? Thank you. Okay. Next. Okay. Who's next? Judith.
[00:41:17] Judith: Yes. That's me. Sorry for being remote.
[00:41:21] Rifaat Shekh-Yusef: Yeah. No worries. I gave you control so you can drive
[00:41:24] Judith: Thank you.
[00:41:25] Rifaat Shekh-Yusef: From your side. Go ahead.
[00:41:26] Judith: Yes. Seems to work. Yeah. My name is Tobias. I submitted a proposal that I called OAuth client challenge protocol. And the use case I see, I called it out of band approval for clients, but I don't think it's limited to that. So if you come up with any other use cases, feel free to to share them with me. But the idea I had is that you have a resource owner, a user that gives grants a client access. And we had this before just in the in the chat. I saw that normally, often clients just request all permissions they can get. Right? But that doesn't mean that the authorization server needs to issue an access token that reflects all the whole grant. So I assume that the authorization server just has the logic that knows, well, this client gets as a base these these scopes or these, yeah, authorization. And but that also means that the client probably needs to step up later on based on a challenge from the research server. And the we have often you then have the user to approve that. But in my mental model and the, like, use case, I looked at, the user is not present anymore, so the user is left. So you can't you can't have, like, authorization code flow where you get interactive, and you can't have a deferral either because the user is not, as I said, not present anymore. So my my idea is that you could have the user or the resource earner approve a transaction or an action upfront out of band and then allow the client to provide a proof that, yeah, that proves that it has the authorization, it has the delegate or the mandate to do this thing. So, yeah, if you want to look at the flow, this is so the the client has an access token. It does its things, and at some point, it gets an unauthorized response with a scope or RAR or whatever artifact that indicates that it needs to request a new access token. And the since it already has an access token, it could do a token exchange and request the escalated privileges or the higher privileges. And the question now here is, if the user is not present, how can we approve that request? How can we know that the user actually intends the client to do that? So you can see here or you get an indication that this is like an agent use case, but I try to avoid because the term agent because I think it's it's maybe bigger than that. But the the initial the question is, does a client have the mandate? Does a user really approve that, or is does the client just confabulate the the action? And the way I picture it is, as I said before, that the user upfront provides an artifact to the client, not the agent, but the client. So when the agent does its things and it needs to step up, the user disappears, gets us unauthorized, it can then do a token exchange, and the authorization server can challenge the client to provide a proof saying, well, you're not authorized to do that. I need more more information. Please provide a proof that you're allowed to do that. And then the client provides a proof, the authorization server validates. And if everything is successful, it returns a new access token, and, the client can continue on or the agent can then continue with the new access token. And the way I think this could work is to provide or define a new error code for the token response that I called insufficient client authorization with an authorization requirement that defines what kind of artifact the client needs to provide for the authorization server to approve the request and issue a new access token. Yeah. So I would like to discuss it further, if that's actually a good idea to add this kind of logic on the token response, if this is a problem you're facing, if yeah. Eventually, if you want to continue this work to evolve or if it's just some academic problem that we should evolve.
[00:46:19] Rifaat Shekh-Yusef: Thanks, Judith. We have a few people in the queue here. So, Aaron?
[00:46:29] Aaron Parecki: Hi. Aaron Parecki. Can you go back to the beginning of the the idea here? If I understand this correctly, this is the client is already authorized to do this broadly by the user, but the particular token that it has at the moment may not be sufficient. Is that the right starting point?
[00:46:53] Judith: Exactly. Exactly. And if you think about the AI use case and yeah. The first step could be the initialization connection step, where the user says, well, I eventually want this client to be able to do all these kind of things. But when it actually gets Yep. Instruction, it doesn't the action the requested action doesn't cover or may may or may not cover all of it. So you may need to check later if you re if the user now really wants the client to do that.
[00:47:22] Aaron Parecki: Yeah. So so this is already all possible to do in vanilla OAuth. So the client does the initial authorization request, and it gets the limited scope access token and a refresh token that represents the larger scope. And then you can go and exchange the refresh token for a new down scoped access token at any time. And this is all already spelled out in sixty seven forty nine, actually. So, like, you don't need to do anything beyond that. You just have to use you just have to not implement simplistic access token and refresh token mechanisms. You have to be a little bit fancier about it, but it's all already allowed in in Vanilla OAuth.
[00:48:00] Judith: It's a lot. This just gives you an extra check to avoid the client doing something that the user does not intended to do at the moment.
[00:48:13] Aaron Parecki: So No. I I'm I'm saying you you can already do that with like, the client can go back and exchange a refresh token for a particularly scoped access token, and that's the point that the AS can do that check. So you already have the mechanism for it. You don't need to do it differently.
[00:48:32] Judith: I think the difference here yeah. I mean, it's it's partly covered. I agree on that. The difference here is that you have this, how do say, separation between the authentication and the action authorization.
[00:48:54] Rifaat Shekh-Yusef: Okay. Yeah.
[00:48:55] Hannes Tschofenig: You're on.
[00:49:01] Yaron Sheffer: Yeah. Hi. Yaron Zavvi. I think bits and pieces of the draft can you reuse existing building blocks. So the ability to step up authorization, we just discussed now in my draft in Yaroslav's, The ability to delay and reach out to the user will be discussed in DTR and delayed token response. And I think the core problem that we discussed in May on the mailing list is that does the client authentication itself is a step up, which some, including me, said we're not sure if this is the challenge at hand, if the, you know, the client might be technologically sufficiently authenticated. The challenge is about authority and consent of the user or other governing bodies. But I did acknowledge the problem of stepping up and giving different profiles of client authentication is a real gap. If that has a use case, I think it could be solved with the help of RFC nine seven two eight, so the resource server metadata document. So so that draft and and Aaron is here. He can confirm that draft allows a resource to expose different resource metadata endpoints. So imagine one for a low value resource and one for a high value resource, and these can specify different authorization servers, which don't have to be different ones. It can be the same technical host with different paths. Like, you'd have a path for a low value and a high value, and these would have different policies on how to authenticate the client. So I think you can look at these building blocks how to solve the the challenge at hand.
[00:50:31] Judith: Yes.
[00:50:31] Rifaat Shekh-Yusef: Okay. Thank you, Aaron. Pam.
[00:50:34] Pam Dingle: Hello. Pam Dingle, Microsoft. In your diagram, you're exchanging a token called a t one with a scope of buy for a token of a t two with a scope of buy. So what is it about those two tokens that are different? And, I mean, is it is that part of what the design or the intention of this is?
[00:50:55] Judith: If you're in this request, it exchanges an access token to with a less less privileged scope to get the highest scope, the scope buy in this example. Okay. But you
[00:51:11] Pam Dingle: if you're trying to buy something, can you reduce the buy scope in that case? There has to be something about it that's different, but I assume the scope of buy is required for the actual action, which is buying the thing.
[00:51:26] Judith: Exactly. Exactly. And that's not covered by the access token one, so you need a new scope.
[00:51:34] Pam Dingle: Do need an additional scope or they
[00:51:36] Judith: need Yeah. Yeah. Exactly. Exactly. So the the access token one does not cover the buy scope. So in this in this request that you can see here, it exchanges or it exchange it's a token exchange with the access to it's a step up authorization. So the access token one does not cover the scope. So it requests a new scope a new access token with the help of the AT1 to get this buy scope. That's what this request shows.
[00:52:06] Pam Dingle: Okay.
[00:52:10] Hannes Tschofenig: Thank you, Judith. What I hear is we need to sharpen the scope of the document a little bit. I think we have to sort of follow-up on the feedback that was provided here at this meeting, and then we'll take a a new new round to it.
[00:52:27] Rifaat Shekh-Yusef: Yeah. And and continue that discussion on the list, that'll be great. Okay? Yes. Thanks, Judith.
[00:52:33] Judith: Thank you. Thanks.
[00:52:44] Co-Chairperson: Think that's is this yours? Right?
[00:52:48] Rifaat Shekh-Yusef: Yep.
[00:52:51] Co-Chairperson: Okay. Hi.
[00:52:54] Max Gerber: Max Gerber here to talk about deferred token response. So DTR started out as an OIDC draft last year. Then we we met. We discussed that the last IIW, and we said, hey. This is useful for things outside of OIDC. This is something that should be a general thing and rewrote it as an IETF draft. Now we're here. So we have a lot of different use cases that we were considering when we wrote this draft. We have a use case around high risk banking transactions. So let's say I want to send a million dollars to Aaron over there. I can go and approve that transaction. Aaron can approve that transaction. He'll be happy. But the bank might want to, perform additional checks, as part of processing that transaction. The bank might wanna have a risk auditor take a look at my account, take a look at my my history, make sure I'm not doing anything that looks like money laundering. Sometimes the bank might want to go and pick up the phone and call me and say, hey. Did you mean to approve this? Was your account hacked? And so this is a something that's difficult to do inside an authorization flow today. We also have a use case around physical document ID verification. So if in the course of a user going through a login flow or a a step up flow, they need to present a passport, then the user will go and take a picture of the passport, attach that, send it into the AS, and then there are a lot of vendors today that will use ML models, take a look at this picture and say, hey. This is good or not good. And the ML models can return a result fairly quickly. But if the ML model can't come to a decision, a human needs to go and take a look at that picture, and that's something that takes a longer period of time. I got locked out of LinkedIn a couple years ago, and I sent them a picture of my passport. It took them four days to verify it. And that's very difficult to do inside the confines of a authorization grant today. And then we wanna look at complex authorization workflows like human in the loop or multi party approvals or a lot of enterprises use identity governments administration systems to manage access to resources. So if I request access to an application that makes a ticket, that ticket goes into a queue, and the business has rules for who can look at that ticket and approve it. And you can't bind that to an OAuth flow today. So all of these use cases are pointing to the same gap, which is around asynchronous mechanisms in OAuth. Most OAuth grants are synchronous, and you cannot wrap an asynchronous process with a synchronous one. If the client makes a request and expects an immediate result, then the authorization server cannot defer that result to a later time. It needs to give a answer today. And there are existing asynchronous grants. There's DeviceOFT and there's CEBA, but those only apply in extremely specific circumstances. They're not broadly available. So we're really looking at a mechanism for AS determined, asynchronous deferral of grants. And that AS determined piece is really important. We want the authorization server to be able to make the decision during processing of a grant that it needs more time or wants to reach out to an external system and then can tell the client, please come back later. We also wanna make sure that this is applicable to all grant types. So we don't wanna define a bunch of new grant types like async auth code, async token exchange. We wanna define a a common substrate that can be used in a variety of places. We also want to make sure this is easy to roll out to existing deployments so people can opt in and roll this out ten, twenty, 30% of the time similar to a feature flagging mechanism instead of a a big bang cutover release. And since we're issuing new artifacts that are potentially long lived, we also wanna make sure it's compatible with Depop. So our proposed solution is called deferred token response. The client opts in to this by passing a new parameter, completion mode equals deferred in the token endpoint. And then this lets the AS know that the client is capable of handling this new mechanism. If the AS decides during processing of the authorization grant that it needs more time, then it can return a new authorization pending error, and this error contains a deferral code. Then we're very much inspired by the ping and pull mechanisms in CEBA. The client can now use that deferral code to pull the token endpoint and wait for the authorization server to say a response is available for it. So the authorization server will continue to return errors saying try again later, try again later, try again later. And then when the AS finally reaches a decision, it can return a set of tokens to the client. So next steps. There was an earlier draft around OAuth transaction challenges presented yesterday that also had a deferral and polling mechanism. We wanna make sure that our polling mechanism works for them so they can build on top of us. And then there's also a draft around JWT grant interaction responses. We think that we can merge these two drafts together and produce one that satisfies both use cases. So we wanna do that. We wanna collect more feedback and hopefully solve problems for people.
[00:58:29] Hannes Tschofenig: Perfect. Yaron?
[00:58:32] Yaron Sheffer: Yeah. Thanks, Max. I think this is a valid draft and an important addition. We see as we discuss different grant flows, how it can fit into various mechanisms, even those that were not imagined initially. I gave my feedback on the mailing list, and then we discussed the topics and agreed, you know, that the decisions made were sensible and and the right ones. Coming from banking, you know, this has so many use cases it can fit into. Like, imagine shared accounts. Right? Whether it's husband and wife, spouses, or company decisions, you have this idea of quorum of people who need to decide or organizational policies. So this can fit into many use cases, and I think it's a very good addition. Thank you.
[00:59:15] Max Gerber: Yeah. Thank you.
[00:59:21] Nick Watson: Nick Watson. So, yeah, I agree. It's a good problem to solve. Use case is real. Thank you for your deployment considerations. I think all drafts should have that section. And sort of along those lines, one thing we had discussed yesterday, I'm now sharing it for the group, is the idea of saying rather than having the client opt in explicitly, simply returning a deferral URL alongside your existing error that you would have returned for clients that don't support it such that clients that do can use it and clients that don't continue on their merry way or error path. And then you don't need clients to opt in with a feature flag. You just kind of and it's still backwards compatible for existing deployments.
[01:00:05] Max Gerber: Yeah. We have some language in the the full draft around the auth code flow where we change the UI that's presented to the user based on whether or not we can defer later. So if the client signals that it accepts it, we can present a different user experience in some cases. Hi.
[01:00:28] Paul Carlton: Paul Carlton. I just wanted to say I I also support this this draft. I think it's a super useful problem. I like that it will let you be able to decide how to Stop the problem. How the authorization server can resolve the the issue, whether it's an it's a classifier, an agent, or a human, or a text, three humans, you know, again, that that's all it's nice that it's flexible in that way. And then one other use case we were talking about recently was on the workload case where you're often trying to get a token. You could defer that as well if you needed to do some some just in time provisioning. Yeah, very in favor.
[01:01:06] Co-Chairperson: Thank you. Yeah,
[01:01:10] Rifaat Shekh-Yusef: Andre. Sorry. We have a long list of people here, so please keep the comments short.
[01:01:15] Arndt Schwenk-Schuster: I support this draft. I see more use cases to it. They are more like technical, particularly that you decouple time decouple the issuance and the authorization and the actual issuance. And I haven't worked I haven't worked in a team that operates all at a huge scale. There's, like, a lot of deployment benefits that can bring this work. Yeah.
[01:01:37] Presenter from Alibaba Group: From Alibaba Group. So we support this draft. Also, I want to bring the use cases. I haven't finished yesterday. It's asynchronized confirmation from the user, especially very useful for agentic based, for example, ecommerce, policy based fund granted authorization. Sometimes need users to make especially consent and a confirmation about this and even some regulation requirement as point out by our draft. So a procedural question, see the strong interest here, whether it's a good time to ask to adopt this combined, merge this two draft together and call for adoption.
[01:02:16] Co-Chairperson: Okay.
[01:02:17] Rifaat Shekh-Yusef: Thank you.
[01:02:18] Hannes Tschofenig: Go ahead. Well, just to respond to that one really quick. So, obviously, as you have on your slide,
[01:02:24] Arndt Schwenk-Schuster: there are
[01:02:24] Hannes Tschofenig: a number of documents that fall under the same sort of category. There's a lot of pick and choosing and so on, but I think that's a secondary step.
[01:02:34] Rifaat Shekh-Yusef: Yeah. Justin.
[01:02:36] Justin Richer: Justin, Richard. Yeah. I think that this is a valuable mechanism and obviously a bunch of people are trying to solve it from slightly different dimensions. I also wanna make sure that the authors as this go forward are aware of previous work that has solved this, particularly user managed access in GNAP and also SITA to an extent, which I know you already referenced. Like, this isn't new. Agents didn't make this new and OAuth does make this hard though so I wanna make sure that as we're layering this in, we're considering things like par and device flow and all of these other weird ways that you can start OAuth to be able to tie this all together. This is obviously the place to have that conversation. So, yeah, I support it. Modulo, a lot of comments about the actual way this draft does it, but that's that's for the working group discussion.
[01:03:25] Rifaat Shekh-Yusef: Thanks, Justin. George, short, please.
[01:03:28] George Fletcher: Absolutely. Let's just make sure if it's not there already that you can basically center constrain the deferral code, bind it to a specific client instance. Yeah.
[01:03:40] Rifaat Shekh-Yusef: Gareth.
[01:03:41] Gareth: Hi, Gareth. Just supportive of this. Wanted to note that OpenID for VCI had to do, like, an application specific version of essentially this problem. It'd be really nice to have a first class support, no auth, rather than the weird well, an hour and application specific one. Yeah. I'd to it.
[01:03:57] Rifaat Shekh-Yusef: Okay. Thank you. We're gonna start you stay here. We're gonna start a poll for this, and please reply on on the
[01:04:22] Hannes Tschofenig: Give you a few more seconds. But it looks good. So we'll obviously have to confirm it on the mailing list as we always do, and we'll work with you, Max, and also from some of the other documents to see how we get a sort of like a concise story worked out here. So thanks a lot for that.
[01:04:45] Rifaat Shekh-Yusef: Thank you.
[01:05:00] Hannes Tschofenig: Oh. No. No. No.
[01:05:01] Rifaat Shekh-Yusef: That was done.
[01:05:04] Co-Chairperson: I thought we removed that. Oh gosh. Still there. What's going on here? Oh, this guy.
[01:05:18] Rifaat Shekh-Yusef: Yep. Ashwin, yeah, I think.
[01:05:21] Ashwin Abhakar: Yes. Thank you.
[01:05:25] Rifaat Shekh-Yusef: Hold on. Let me give you control. You can drive now.
[01:05:31] Ashwin Abhakar: Okay. Alright. Thank you. Hello, everyone. My name is Ashwin Abhakar, and I'm presenting today the envelope proof of position. So why have an another proof of position semantics? Right? So the motivation of this was essentially originating from the wider option of OAuth across, different systems. Lot of research servers which are non HTTP bound are accepting, access tokens and are, working with Oauth. The other challenge we saw was priority around the, around carrying two different headers, which were often getting dropped during during the interactions across mesh, across gateways, across load balancers. The other friction point was resource servers, are not HTTP, have a challenge across handling the nonce the way it is handled so far in in OAuth, specifically for HTTP. This was a pertinent problem because there's no way to give a error response back, and then expect client to send an answer back as a as a response. Also, the wider adoption of, service mesh, particularly SPIFI, the adoption of zero trust for the workloads is introducing cryptographic identities, which means that clients are already aware of or are already having cryptographic keys as an identity. And they are ephemeral in nature, which means that it requires a frequent rotation. And this is a problem that we wanted to solve, how we can have a seamless rotation of the cryptographic keys, which are essentially used for proof of position. So, essentially, the con at a at a high level, the concept is enveloping, which is taking the existing access token, embedding it as a nested token, and then using the cryptographic keys to create an envelope for attestation purposes. This basically creates a single instrument, which is both credential as well as proof. To address the issue of nonce, we are introducing a c nonce, which is a client generated nonce. These nonce are generated with several metadata along with the client cryptographic key, along with the time step. So this basically ensures the freshness. This ensures that the replay and the pre created tokens cannot be used. And lastly, during the token refresh cycle, we are introducing the key rotation as well. Semantically, the enveloping concept is very similar to matryoshka doll problem, which is essentially you're looking at tokens as as an abstract structure, but cryptographically bound. In terms of the actual layout of the structure layout of the token, we are essentially looking at type being introduced to indicate what kind of a token it is. Along with that, a CNF claim continues to stay the same. The HTU and HTM claims are being replaced by resource context or r c RCTX claim, which includes the resource name, method, and ID along with the Siemens, which is not shown here in the example. In terms of the usage across different OAuth profiles and different interactions, there are three variations of the token that you essentially look at. The first one is for the authorization code and for bad usage where you're binding the token to the key, and, essentially, this is the binding EPoP token. The next one is essentially a credential epoch, which is carried typically to the resource server or to introspection endpoint or to a revocation endpoint. And the last one is essentially for the key rotation, which is a nested proof for the existing key as well as the new key, which with with with mobile chain kind of an implementation. So key normative flow departures, I'll focus on PKCE first, which is the change from recommended to required. The HTU and HTM claims have been replaced by resource method and IT. Besides that, the authorization request key binding, which is the fifth one, is explicitly not supported, and this is a question for everyone here to decide if we need this or supporting it during the authorization code present presentation to the token endpoint is sufficient, which is what normally has been done. In terms of the c nuns versus nuns, the departure in behavior is because of the nature of the workloads which are to be supported, essentially, to support both HTTP and non HTTP kind of workloads. Here, the client nuns, instead of the, you know, the the flow initiating from the server side, initiates from the client side. Client essentially looks at the server metadata, looks at the seeds, and essentially uses time stamp counter along with the server's key information to generate a client nudge, which essentially sent to the server, which server can validate. In this this case, the servers we are referring to can be authorization server, can be resource server, but, essentially, the implementation is known to both parties and includes the factors coming originating from both client and servers. Trade offs, being an envelope token, essentially adds latency, and the latency numbers would differ depending on the type of the token being used. OPIC tokens are shorter or smaller after the after the as part of the EPoP token. But JARC tokens are essentially 6% to 40% larger. The larger portion is primarily for RSA bound tokens, and the Edward curve curve based tokens are significantly shorter. In terms of the validation pipeline, the ordering is strict, with the key binding check being the last one, and the rest of the, auth or or checks happening, before that. Also, the error disclosure does not deliberately include the why a specific step failed due to the validation rather than it tries to keep the same context of errors that that that that are being used today. The nested proof, especially for the key rotation, is a two way handshake. The inner the inner EPoP token is essentially bound to the old key. The EPoP token the inner EPoP token contains as part of CNS claim the newer key, and the outer EPoP token is signed using the in using the newer key to represent the proof of position for both the keys and showing a atomic rotation from a client perspective. So this essentially takes care of a a atomic rotation aspect from server's point of view as well because server is able to validate both the keys in a single step and is able to establish the new keys for the future interactions or or future access tokens. So with that, I will open the floor for questions. There are open questions specifically around four areas for which I've already responded to some of the mailing group questions. Looking for alignment opportunities across Lindsay, Spiffe, and a agent working groups, and I will, love to hear a feedback on all these aspects.
[01:13:44] Rifaat Shekh-Yusef: Okay. Thank you. Paul?
[01:13:50] Co-Chairperson: I
[01:13:53] Daniel Fett: think removing this from HTTP is too far a stretch for the OAuth working group. The base draft six point seven point four nine is based on HTTP, and removing this is for me, this draft is out of scope for for the OAuth working group. I see a lot of reasons that DPoP should be replaced. I think I've I've said them oftentimes enough, and I'm really looking forward to work together with Justin on on the HTTP signature based pop mechanism, but I think HTTP signature based mechanism is a better evolution away from DPoP than EPoP.
[01:14:34] Co-Chairperson: K. Thanks. Justin.
[01:14:36] Justin Richer: Hi. Justin Richer, and I still bear still bear scars from the soap wars, which is what this is really making me feel like we're seeing again. Something this transport agnostic or trying to be this transport agnostic ends up reinventing a lot of things that the transports provide in order to sort of, you know, get over the line. And while there are examples where that can be that can be successful to an extent, thinking of things like DIDComm, and I say that slightly tongue in cheek, I I don't think that this is something that we ought to do. Both for the reason that Paul brought up, Oauth is an HTTP based protocol, full stop. Yeah. If you wanna go to non HTTP, go look at ACE. They reinvented Oauth for for core and stuff like that. Right? Also, a lot of the stuff that's being discussed here is already being worked on and solved in WIMSE with the service to service draft authentication and carrying keys and binding to dynamic identities and stuff like that. So I suggest you take a look at what's going on in WIMSE as well. I don't think that this is appropriate work for OAuth.
[01:15:48] Rifaat Shekh-Yusef: Thanks, Justin. Anton?
[01:15:50] Anton: Yeah. Just a remark on the nested pop for curation, in particular, on the nested pop wireline overhead. You may look at work on past privacy protocols because those guys are using nested encryption to protect privacy from one end to the other, and the capacity was a major aspect in their design decisions.
[01:16:16] Rifaat Shekh-Yusef: Okay. Thank you.
[01:16:18] Hannes Tschofenig: Okay. Yeah. I've also been watching the chat and I saw a few others who said, hey, let's have a look at WIMSE and how that fits into there or at least it relates to the work that is going on there with the service to service communication. So, actually, I would recommend you have a look at that and see whether that's a good fit or whether you can inject some requirements there or some of the work you're doing. And with that, thanks a lot.
[01:16:55] Rifaat Shekh-Yusef: Thank you. Okay. Alright.
[01:16:59] Gareth: Hey, folk. So I'm Gareth, and this is about delegate- Closer to the mic. Closer to the mic. Sorry. I'm always too
[01:17:08] Rifaat Shekh-Yusef: Can adjust it? Yeah. Adjust it.
[01:17:09] Gareth: I'm not a theater kid. So it went away. Why has it gone?
[01:17:18] Co-Chairperson: Hold on.
[01:17:20] Gareth: Yeah. So for the delegation JWTs, like thousand foot view, it's a relatively straightforward extension to SD JWTs to allow for delegation. It has applications in agentic use cases and non agentic ones. Alright. So this is what I will talk about. But first of all, like, what is delegation? So it's a three party model, which people are probably familiar with, is the idea of an issuer, issues a credential to a holder, and binds it to some sort of key that the holder has. Sometime in the future, the holder makes a presentation to a verifier by signing over and transaction binding it, as well as potentially making choices around things like selective disclosure. The verifier has no trust relationship with the holder but has a trust relationship with the issuer and can verify down the chain that the issuer has information hasn't been tampered with and that the holder binding still holds. We use this is the terminology we're using from from SD JWT. Holder can be anything even though it's quite well coded. Delegation is saying, hey. I want some other entity or delegate holder to be able to do that final presentation. So that might be your AI agent doing on your behalf, or I have another person who I want to be able to do this on my behalf in the future. And so you add an extra step in the middle. Issuance happened as per normal. Then you have a delegation step where you pass this credential onto the delegate holder and bind it to something in that position as well as potentially adding extra claims and disclosures, like policies that need to be enforced. And then the deleg holder access the holder when it finally presents to the verifier. This can also be repeated indefinitely because once you can do one delegation, you can do it infinite times. So why do this? Well, it a lot of the reasons are the same reasons why you want a three party model in the first place. There's a nice privacy aspect if I can do the delegation without going back to the issuer to issue a new credential. There's availability problems for the holder where I can't necessarily go to the holder at that point in time, whether that's because my AI agent's acting autonomously and I can't get back to my device or because I've given it to somebody else and they're out in the real world presenting it. The last two are more specific to my initial use case where it can help with scaling and interoperability. But so my starting motivation, why I was looking into this in the first place, was agentic payments. So this is a case where we have a digital credential that represents a payment instrument, and I want to be able to delegate the authority to pay to an autonomous AI agent and add some constraints to it. When I'm doing that and it's gonna act autonomously, I don't know who the final merchant is going to be, and so I will have multiple different merchants within the policy of who they're allowed. And that means I want to be able to have selective disclosure so that I don't reveal to the end merchant who else I might want to purchase from. And so that sort of started looking into this, and it turns out SD Jot is really ill elegant for doing this particular solution. This has become a APIP, identity payments protocol, along with Mastercard's verify intent, now looks over in FIDO as, like, the application layer thing. Now this is not just an agentic use case, which is nice. Turns out there's a lot of other ones that are useful too. In the real world, things like if I have a vehicle registration certificate and I want to be able to give it to my friend to drive their car, this is a useful delegation one. If I wanna do power of attorney or my real estate agent is able to sell my house on my behalf, these are use the same sorts of mechanisms. And there's potential other agentic use cases outside of payments because they all follow a similar sort of trend. Alright. So that's, like, why. The how for SD JWTs, so this is like your standard compact serialization of an SD JWT where you have an issuer JWT, you have zero or more disclosures, and then you have a KB JWT which is signed by the holder's key. So how we can make this extend? We can use that KB JWT as the start of a new SD JWT, and then we're done, which is nice. So the kb JWT now has got a new set of disclosures, has a new confirmation claim of the delegate holder, who can then go and find a final kb JWT that belongs to the next one. And this obviously trends indefinitely. So a little bit more of a worked example to see how this, like, looks in terms of the JSON y objects. So, like, the holder would initially get this SD JWT, which is a signed issuer JWT, a CNF claim for the holder, whatever else you want in there, and a bunch of hashes, as well as any all the disclosures. Then when they pass it on, this is the sort of net new thing that's happening, which is you create a new KB JWT, which binds it back to the initial one, and you can exclude some of these disclosures so they never get revealed to the delegate holder. The SD hash claim binds you to the initial SD JWT, and the CNF claim binds it to the delegate one. And then you add in your own new disclosures, which could be policy statements or anything from a principal perspective, as well as the CNF claim that now applies to the delegate holder. And so you could keep doing this in the future, but eventually, when you get to a verifier that you want to be able to sort of prove possession, you create a KB JWT exactly like you would have with a normal SD JWT plus KB, which binds it backwards, has a nonstiprue transaction binding, all those good things. So that's, like, thousand foot view of how this all works. A few other details in the draft, which is interesting, but, yeah, why IATF- SD Jot is here, SD Jot VC is here. It's also at the same level from a layering perspective. It's it should be application layer, so application agnostic. And if you use SD jobs today, then you might want to use this. The why now, agentic does provide a really nice convenient delegate holder use case, But the other part here is that we are seeing more people use wallets and use digital credentials. Once you have those, these sorts of use cases start to become more appealing. So having a mechanism for doing it would be nice and not having people sort of trying to reinvent their own way of doing so. Yeah. There's there's some open questions that, as a draft moves forward, would be good to answer, particularly things like common delegation policy. Right now, that's all just in, like, the application land. There's probably nice to standardize, those so people don't have to reinvent the wheel. There's replication questions. It's less relevant in the agent case because you probably have control of your agent at least sporadically. But if I give my credential away to someone, I might want to be able to revoke it. Probably, we can reuse existing things like status lists and those sort of things that are revoke just the delegated portion. Most of the interesting questions will come from a deployment question because I'm have a application which doesn't necessarily have an easy way to host it. Those all come to, like, the delegation channel, which I think isn't really in scope in this layer. It's sort of the equivalent of your issuance protocol and presentation protocols, which aren't necessarily an ITF. Like, aren't directly inside SD Jop, but there are considerations that we'll need to think about and develop. So yep. That is my
[01:25:04] Rifaat Shekh-Yusef: quick Okay. Thank you. Go ahead, Anton. Yeah.
[01:25:12] Anton: Can you go back on your slide 12, please? Yeah. Yeah. So I'm wondering I was wondering looking at the added order disclosures, what is information that you carry with this added order? Because as I understand it, it's the users that gets the the WT that add it before delegating. So what are you what is the kind of information you can pay with this older added older disclosures?
[01:25:41] Gareth: I'm not entirely sure I understand. So the user would add the disclosures into the delegate holder, and then the delegate holder could remove some of those when it does the final presentation. And so it will reveal only a subset. So I could imagine those disclosures were, like, merchant one, merchant two, merchant three. The delegate holder would have all of those, and then when it presents it to the verifier, it says, oh, only merchant a b c is the one that's inside there. Is that what you were asking?
[01:26:09] Hannes Tschofenig: I think the question was what are the additionally added disclosures beyond the ones that you initially had because you're not adding new content to the
[01:26:20] Gareth: So you are adding so, like, yeah, the added disclosures are not the same. So this is the entire thing that comes. So the initial disclosures still apply with the initial JWT. As a JWT, the disclosure h one is different to disclosure one. So, like Ah. So these these are these are added ones. These are actual net new, and so you get both the initially revealed ones, so, like, disclosure I one, and you get the disclosure h2 so that you can see, hey. This was this credit card or this person, and the policy says that I'm allowed to So add a
[01:26:58] Anton: So indeed, you recontextualize the ways the token was issued before delegating, and then you reduce the scope.
[01:27:06] Rifaat Shekh-Yusef: Okay. So let's continue that on the list. Sorry. We're running out of time here. Frederic.
[01:27:14] Frederic: Yeah. Hi, Frederic from Maduro. I just want to say we have many use cases for this, and there's a lot of demand for solutions to this. And if it doesn't get adopted, we'll just implement proprietary versions of it. So please adopt it.
[01:27:30] Rifaat Shekh-Yusef: K. Thank you. Christian?
[01:27:33] Christian Bacher: Yeah. You mentioned the authentic use cases. I think there's a lot of other use cases as well. Like, on behalf of flows, like, giving some delegation to your tax accounts so so they can do stuff on behalf of you. Think it's kind of a natural evolution. That makes sense to me. Yeah.
[01:27:49] Rifaat Shekh-Yusef: Okay. Thanks, Christian. And, Nai? Nai? I
[01:27:59] Na: have one question. It seems that every entity in the chain must sign the token. So this means the resource server needs to access all the public keys from the chain. I think it's it changed the trust model and need great modification. Moreover, from my perspective, we haven't handled the multi delegation model in all us. So maybe it's too early to combine multi delegation with SD Jot? So it's I I it seems like two two questions.
[01:28:38] Gareth: So it you don't need to access new public keys. It's one of the nice things about the, like, SD Jot plus KB that's building on top of. The public key is included inside the credential, and so your it's been endorsed by the issuer and then endorsed by next one down. And so to do the verification, your verifier's trust is only needs to be in the initial issuer, and then it just takes the sort of wrapped key for the next one down and uses that for the verification. And so your anchor is still just one.
[01:29:12] Ashwin Abhakar: K.
[01:29:13] Rifaat Shekh-Yusef: Sorry. Daniel, very quickly, because we've closed the queue, just one comment. Okay. Thank you. Because we're in a rush time. It seems that there's good interest in this document, so let's keep there are some questions. So let's continue that on the mailing list and see if we can clarify those questions and see if we can progress it maybe next time. Okay? Or even on the mailing list. We'll see how it goes. Right?
[01:29:45] Hannes Tschofenig: Yeah. So, we are going to ask on the mailing list whether there's interest for adoption on this document? Yeah. So, it looks like also looking at the chat, I see plus ones on adoption.
[01:29:59] Max Gerber: I see
[01:29:59] Hannes Tschofenig: feedback here, people sort of raising their hand here.
[01:30:06] Co-Chairperson: So looks
[01:30:09] Hannes Tschofenig: like you're onto something here with the delegation.
[01:30:13] Rifaat Shekh-Yusef: Okay. Thank you. Jeff?
[01:30:25] Co-Chairperson: Thank you.
[01:30:26] Yaroslav: So today, I'm Yaroslav, AWS. So this was initially rego policy for access token, was a draft. Then we decided to elevate the discussion to talk about whatever policy language binding for us because I'm one of the vendor into the ecosystem for some such policy language. That was a way, like, to discuss what could be done. But the whole discussion went differently, so don't expect a draft debate over here, but more about what is the synthesis about the analysis we have done of
[01:31:12] Anton: it's not working.
[01:31:13] Co-Chairperson: It's not working.
[01:31:14] Yaroslav: Sorry.
[01:31:17] Rifaat Shekh-Yusef: Try now?
[01:31:19] Judith: Yep.
[01:31:20] Yaroslav: Here we are. So more of the analysis of should we have a policy language training for OAuth. So just to wrap a little bit, you already all know that, but for those who do not, when we are dealing with application today, it's no longer just a single client. It can be like a multiple client that will allow, like, a transaction to be able to progress for whatever initial goal you gave to the first client and into the way that he can orchestrate his movement moving forward. And now if it's the only time where we will cite AI and LLM into it, it just means that the business logic of such client are coded live by a developer that lies somewhere in the cloud to be able to decide what are the next step exactly into this transaction. So that's reveal like multiple thing is that we went from a deterministic pass to a probabilistic pass. So maybe we didn't plan ahead of time for everything that needs to be done. The goal is decomposed into multiple task. Then for each task, we want to be sure that we are intentional about the fact that this is least privilege. So we need to be able to define this least privilege credential or token that we will give to each of the client. And finally, because we don't know effectively how we will reach this end goal, there will be negotiation in between the different party, whatever it is the client, DIS, or DRS. So from there, we decided to to try to wrap all the problematic into five different pillar. The first pillar is to be able to define what is this transaction goal. What do we want to achieve effectively at the end? And because we know that the goal will be decomposing to task, we need to be able to talk the same language. So to use like a domain specific schema to be able to express what we want and to be able to express what we will receive. The way to make those specific request and to receive the result of that, that would be defining the envelope for the exchange. Like we said, there will be negotiation along the way. So we need the different parties and especially the heiress, which is the the poor child of the family at the moment on this aspect to be able to signal back if there is not enough information available for it to be able to perform the right access control into the mechanism. And finally, because, like, the resource owner if there is a resource owner needs to provide more information or to be able to guide how the transaction needs to be able to move forward, we want to have the ability to asynchronously confirm with this entity how we should move forward. So like I said, initially, this lot was for the debate around the proposition from my peer here, Max, around the usage of Rego policy into access token. So I just want to, like, respect the fact that this proposal was made into the first place. So as you can see, this is just like a standard change in between a client and authorization server and the resource server to be able to obtain an access token. But the details on how we are expressing those requirement of what we might want to have into the access token in the end, what we will receive. All of that will be returned in the form of a policy language and in this case, into the proposal of Max, into the recall language. So let's take a look about is it good or not? There was, like, multiple attempt into that. Like, Max is not the first one. We, AWS, tried that with you before it was in Coira, if I remember, sorry. If I remember properly, this did not get too much traction. But the results that we came to, if we can just summarize that over here and sorry for the fact that this slide is broken in term of format into that. So what we see is that if we start to pass policies inside the request and the token, that can lead to some policy provisioning. So that means that the entity on the other side of the traffic, whatever it is the AES or DRS, may be confused into exactly what it should achieve achieve as a result, and we don't want that to happen. Generally, the policy language is some things that live into the back end behind those AS and ARRs. And the client when he's talking to those other entity, the AS and ARRs, knows that he needs to talk into all those two language and he might not be even aware about what are like the policy language that are supported into the back end. So we should not ship code. We should just ship context. So if you bring that back to the p star p model, that's mostly like adding a whole of a PIP once we want to communicate from the client to the AS and the MS. So if we look at what are the the result of this specific draft of having like a policy language into OS token based on to those five pillars, what we see is that, anyway, the policy only describe a task, not defining a goal. It's very difficult from a policy document to be able to express if the task related or express who this policy document is part of a larger element which would be the goal. Polysis needs the schema anyway. So maybe we we should stick again with what OS two is providing to us and try to find the right schema over there. And we will need profiling along the way onto those different element. The the proposal so far did not propose like any envelope mechanisms. They were piggybacking on the heart. So if they are piggybacking on R, maybe that's a signal that R is effectively the mechanism we should really try to fit to fit into. And finally, onto the signaling, there might be more than one reason that an AS and an ARRs might say this thing is not possible. And there is this much policy we can packed into a token. So for sure, there will be a limited visibility onto the signaling that will happen and therefore will increase the confused state that may happen whatever at the AES or DRS when this will be evaluated. So the conclusion we came to into our analysis is that we should effectively be more o two friendly for one big reason is that we already have a very strong envelope capability, which is hard, which has also looking to way to improve with higher assurance way of exchanging those authorization details, whatever it is, who power UJAR. So this is established. This is a pillar, and there is not so much to add to that. But on to the other aspect, yes, we need to start to work onto that. So we heard a lot about mission. We need to recognize that some of it came through the AOS protocol, which is a larger trying to shift to to to shift to a new stack. But we see that there are already some draft that has been published by Carl. For example, as I try to bring those ID, those specific elements that I might have a sense back into the OS two worlds that we all know and share about. Onto the discovery schema earlier, Yaron presented that to us. And I think someone made a comment on the mic that this is a one big element of this proposal. So we need to recognize this work. There was a vote for adoption. So now we should continue build onto that. For the signaling, that's the other part of your own draft. So maybe like I said, the comment of slight splitting the two to be able to represent and to have the right discussion based onto the right pillar needs to happen over there. Max has also draft a specific draft onto these aspects. So maybe there is, like, some connection to make onto that. And finally, for the async confirmation, yes, yesterday, presented his own draft for the transaction token challenge, and we saw the deferred token response element. So we see that we already draft on the floor to discuss that are more aligned with with us. And the conclude oh, sorry. So so that's what we want to talk about. Now there is a question still. Is there no hope for policy into an OAuth ecosystem? We found two specific sub use cases for that. The first one is that if we need to talk to an heiress, which has very limited capability to talk to the external world, like, think about a very low bandwidth IoT devices, there might be a sense to maybe pack a policy into the token so that these specific areas could validate the token, unpack the policy, and evaluate locally the policy that is inside it. The other part was the other Yaron bringing the points that maybe some clients and especially especially like client powered by LLMs that can understand more context might want the exact reason on why resource server decided to decline the release of the resource and therefore to return the policy that exist into the PDP behind DRS so that he could he could have, like, a better understanding and make better attempt next time. But we think that those are still, like, very edge cases, and we can, like, really put that aside. Even for the return of policy to the clients, there might be, like, disclosure unexpected disclosure of information that might lead to recon into an attack supply chain. So where I'm going with all of that? So from this analysis, we see that we already have a lot of draft on the floor. I we think that formalizing that along those five pillar give us like a a set of gathering to our discussion and how we could handle all those draft moving forward. So what we are proposing is that, do you agree that we could create within DOS working group some kind of design sub team that could review each of the new drafts that are proposing so that we can ensure that they fit along those five pillars. And that's all I got. Arnd, please.
[01:43:36] Arndt Schwenk-Schuster: Hi, Arnd. I have a clarifying question. Do you want to defer the authorization decision by putting the policy into the token and let it evaluate at the resource server? Or is the result of the authorization decision a basically different encoding by encoding the result as a policy language like?
[01:44:03] Yaroslav: Okay. So I will restate. So there is no draft into Okay. This specific presentation.
[01:44:08] Justin Richer: Okay. Yeah.
[01:44:09] Yaroslav: Okay. So we were just coming from, do we need this kind of capability from a general standpoint?
[01:44:15] Gareth: Okay.
[01:44:15] Jeff Lombardo: And the decision was no. We should not have a policy inside a token or an authorization request or or those kind of things. We should be able to formalize authorization request and result of those authorization request. We use the mechanism we already have today, which are OAuth two native. But we still wanted to recognize that there was, like, one small edge use case for that.
[01:44:40] Rifaat Shekh-Yusef: Okay. We we're gonna be running out of time soon. I'm gonna let you guys go through that, but but please keep it short. And if we see lots of interest, we would happy to schedule an interim to discuss this further. Okay? So, George.
[01:44:55] George Fletcher: Yes. Two things. One, there's a
[01:44:58] Gareth: One Sorry.
[01:44:59] Rifaat Shekh-Yusef: George. Daniel, I think, is ahead of you in the queue. Daniel.
[01:45:05] Frederic: So, yeah, I do support the expression of policies and especially to ensure that the end user is still in the loop of the decisions. That was my fear of the previous presentation. Okay. But I just support that kind of
[01:45:22] Rifaat Shekh-Yusef: Okay. Thanks, Daniel. George?
[01:45:24] George Fletcher: Yeah. Two things. One, we need to explore the other individual drafts because there's a bunch that probably touch on this besides the ones that you've highlighted here.
[01:45:34] Co-Chairperson: And
[01:45:36] George Fletcher: then two, I think if you start thinking about constraints, the users define constraints, you could potentially represent those as policies. So I think it gets a little nebulous as to what should be in and what shouldn't be in when we start talking about representing this in a token.
[01:45:54] Justin Richer: Thanks, George.
[01:45:55] Yaroslav: So I recognize that I just want to to answer that. I I recognize that that we need to pass information from the subject resource owner upstream. But formalizing it as a policy might have some dangerous consequences. Into what we we have looked with RIGO, for example, the draft was saying, you need as a first line default hello equal false. And if you forget this line, the into the legal language, it goes to a default to low equal true, meaning that by default, I will authorize the things to move forward. This is very dangerous. And that's what we call policy provisioning, and we want to prevent that. By by saying that anything that needs to be expressed needs to be expressed in the form of a PIP intent. Okay. That mean we are not providing a policy, and therefore, we cannot poison the policy into the back end.
[01:46:51] Justin Richer: Yeah. Max?
[01:46:52] Presenter from Alibaba Group: Yeah. So I support forming this to solve this problem. So although we don't necessarily, at this time, have agreement on the solution, but we do think this is a very important problem need to be solved. As I mentioned in previous comments, in ecommerce, identity use cases, we need a policy based authorization that is very important for us to do the authorization whether or not we we we need this kind of very fine grade to to authorization. Thank you.
[01:47:24] Rifaat Shekh-Yusef: Thank you. And, Tom?
[01:47:27] Anton: Yeah. On your third pillar about the scope envelope, do you believe that mechanisms to force scope to be done scoped along the transfer belong to this envelope or it should be added or it doesn't belong?
[01:47:44] Yaroslav: So so what you want in the details, if you want to done scope or translate scopes, which is something that is hardly mentioned, All of that can go into the envelope. What you want to do is just like how you can carry over. Now now, sometimes you don't just want to downscope. Downscope is like the easiest use case at the top that everyone has in mind, but sometime you want more some dynamic scoping based exactly on to the transaction you have. And that's why we wanted the point number two, which is like the ability to discover the schema. How to express what you want into a forms that both the client DIS and DRS can understand. And that's why we want to be to be able to have like a that Okay. Data domain schemas that can be discovered.
[01:48:37] Rifaat Shekh-Yusef: Okay, thank you. You're
[01:48:41] Co-Chairperson: You're Shiff. In pillars one and two, there is an implicit assumption that we can represent the user's intent or goal in a formal way, probably through a raw object. I think this is true for many domains, but not for all of them. And still, this is a use useful work.
[01:49:06] Yaroslav: Thank you, Jan.
[01:49:08] Rifaat Shekh-Yusef: Okay. Thank you. I'm gonna start a quick poll, but thank you, and and let's get going. So I just started a poll quickly. George and Aaron, can you come here, please? Okay. And I'm gonna hand hand you the clicker here.
[01:49:34] Hannes Tschofenig: So there looks like there are a number of people interested in what we would like to find out is like, have a specific problem statement because this is a little bit fussy and nebulous to me at least on the policy work. Also explain in
[01:49:53] Max Gerber: such
[01:49:53] Hannes Tschofenig: an interim meeting what precisely the interoperability challenge would be on where we need to do this because people have been using policy all along, but they did it locally on their premises and nobody else cared, of course. But we have enough people, so it looks exciting. And we'll schedule this and we will have a good discussion and see how we move forward with this. Thank you.
[01:50:18] Rifaat Shekh-Yusef: And thank you to Jeff and team. Been doing lots of work behind the scenes to get this ready. Thank you, guys. George and Aaron.
[01:50:29] George Fletcher: Okay. So we are going to go quick. There's there might not be time for discussion. Alright. Here we go. First thing, this is a proposal, and the reason there's a proposal for, like, how do we think about all the work in the OAuth working group is because there's over 70 individual drafts currently in OAuth. So some thought process Aaron and I and other people have been talking about is can we sort of group all of our existing work into some sort of subgroupings or we call them clusters in this particular case? And and then basically map new individual drafts into those clusters. So I'm going to since we can go back to the slides so anyway sorry. Go ahead. Please jump in.
[01:51:27] Aaron Parecki: So the part of the problem is that there have been there are more drafts submitted to the working group as individual drafts than any one or even 50 people can possibly review at this point. So we need some sort of systematic way to better filter these before we bring them to meetings because it is not productive to just randomly select them and try to discuss them here. So we're trying to come up with some sort of framework for this, something that is gonna be a little bit more sustainable, including a sort of initial self selection process, which is this idea of then creating these categories to be able to better evaluate where your work fits in. So can you go to the next slide?
[01:52:13] Rifaat Shekh-Yusef: Yeah.
[01:52:14] Aaron Parecki: So the idea would be that if you would be if you're thinking about presenting a draft, obviously, submit it to the data tracker as soon as you can, but try to figure out where it fits within the existing body of OAuth work. We will we can ask the chairs to schedule an interim meeting to discuss maybe that group of of drafts in that cluster, and then that can determine, you know, what what drafts actually get time. And maybe we can do some of that sort of combining work before a meeting like this. Like, there's already been a couple drafts here where we've talked about combining them. Maybe we can kind of front load some of that work.
[01:52:51] Gareth: Right.
[01:52:52] Aaron Parecki: So okay. So this group of nine clusters is based on some review that we have been doing of taking a look at all of the existing RFCs and adopted drafts in the group. So, basically, every RFC or adopted document fits into one of these nine categories. This is not necessarily perfect. Feel free to bike shed this, but this does currently capture in some way all of the existing work. I don't think we're gonna go through all of them, but we have slides if you're curious about how all the docs fit in after this so you can look at the meeting materials for that. But just as an example, like, let's take the client identity authentication and registration bucket. There's a bunch of work there. This is all the existing drafts. And then if you go and look at a lot of the new documents, a lot of them fall into this as well. And we've done this for all like, all the nine categories have this all broken out.
[01:53:52] George Fletcher: So the only other thing, a little bit to Jeff's point Jeff's previous talk, is we may need to add another group. So as Aaron said, right, these nine aren't necessarily set in stone, right, initial proposal, but I do think that some sort of grouping like this is going to be necessary for us to be able to sort of analyze and process all of the all of the new work. So we may need a complex delegation kind of a bucket. If you add that and you start looking at at drafts, I think I ended up with, like, 21 draft potential of the individual of the existing individual drafts, 21 of them might fall in that complex delegation bucket. So, again, a lot more work here to sort of do this. And then I think, to Erin's point earlier, we need to start looking at if multiple individual drafts are covering the same sort of semantic topic. Can we combine them, or can we merge an individual draft into an existing working group draft if there's mapping there?
[01:55:08] Rifaat Shekh-Yusef: Keep going.
[01:55:09] George Fletcher: Oh, okay. Well, I think that was it. It was basically discussion. So we just wanted to throw this out there as an initial proposal and then figure out how to process. So
[01:55:22] Deb Cooley: I think this is a good idea because you have a lot of work, and you need to organize the work and approach it from a systematic point of view. And this does that. I my question to you all is where do you document the categories? You do, as it turns out, have a wiki. I pulled up the wiki and Justin said, oh, never seen that before. But it is there. It is there and you can use it. Right? So you could you could this would allow people to attempt to bucket their Ben, the feedback's crazy. Bucket their ideas into particular categories. Right? So it allows you to organize it. You obviously aren't gonna put drafts for categories. Like, that seems sort of silly. But I would encourage you to to think about using the wiki for this because you have it. Yeah? Does that make Yeah.
[01:56:25] Hannes Tschofenig: Great idea. The line of what Deb said, I would like to thank you guys because we see a lot of documents, we are excited, and I are excited that you spent so much energy on OWASP. I think that's a sign of success of the technology industry, looking at these protocols, extensions, deploying them. That's why we see all of this. So this a good feature to have. Right? This not a failure, but we need to somehow deal with the side effects of all of this. And this is we tried. We will sort of, like, follow the sort of what for the next intra meetings, next ITF meeting. We'll see how well that works. And if it doesn't, we do something else.
[01:57:17] Deb Cooley: So let me let me say one more thing. So I've gotten a fair bit of pressure to open additional working groups for agentic AI authentication cases, which I have pushed back and said, I have working groups already. Thank you very much. Mhmm. Which means that you have that's why you have this huge influx of work. So if if you believe that's the wrong decision, you should come talk to me because it just it seems just just purely from a logical point of view, it made no sense to me to to to basically silo the community into different pieces like that. So
[01:57:58] Aaron Parecki: so I we very intentionally did not create a category for agents or AI in these nine. And the challenge is, can you fit can you describe your draft in terms of not AI of what you're doing to figure out what it's actually doing and where it slots in?
[01:58:16] Deb Cooley: I still have not seen what the gap is between what you already have and do, especially between Oauth and WIMSE, and what you perceive that you need.
[01:58:32] Aaron Parecki: So that's part of the that's part of the goal here is to get people to frame their document in terms of the body of work that already exists Mhmm. Rather than saying, it's AI. We need to do it in an AI working group.
[01:58:47] Deb Cooley: Right. So I will continue to push back on that. If you find at some point that you think that's the wrong decision, you need to come say something to me. You have between now and March, by the way.
[01:58:58] Rifaat Shekh-Yusef: Okay. Hey, Pam. Thanks, Deb.
[01:59:01] Pam Dingle: So everything you've described so far is really about how we organize the work for our review and all of the working group stuff. I do think that there is a problem for for people trying to consume it. Do you have any expectation or is it in scope to talk about having those classifications be consumable by the readers of these specifications?
[01:59:25] Aaron Parecki: I hadn't got that far yet, but that's a great idea.
[01:59:29] Rifaat Shekh-Yusef: But would wouldn't that help? That just the the cliff is classification itself wouldn't
[01:59:37] Pam Dingle: I think it might because, I mean, right now, we we number everyone to death. Right? Oh, you don't know what ninety two zero seven is? So maybe this is a way to sort of help create phrasing for the numbers.
[01:59:48] Aaron Parecki: Yeah. No. I I totally agree. And one of the things that I I think the wiki is a good place for this, but one of the goals is if someone who's got either an idea for a new draft or wanting to implement something, if they have this kind of map to follow, it can help them learn the the space better. So I think that can accomplish both both goals.
[02:00:08] Ashwin Abhakar: Yeah. Okay.
[02:00:09] Jeff Lombardo: Thanks. Jeff. Jeff Lombardo. So I think on top of what you said where you put a little bit more of pressure onto the people writing the draft, and that's completely fair into that. With respect to the chairs and you hold the the actual writer of stuff, maybe having, a capability, like, to act as a first gate of review before it is effectively pushed or presented into those kind of meetings could help.
[02:00:40] Rifaat Shekh-Yusef: Okay. Good. Thanks, Jeff. So thank you, Aaron and and George. They they put lots of effort into this work, like, and and and presented in five minutes, but the effort that they put into this, this massive amount of effort is not easy. So appreciate that. Thank you, and we'll try it. And that concludes our session here. And thank you all, and hope to see you in San Francisco.
[02:01:15] Hannes Tschofenig: And at the interim meetings.
[02:01:17] Arndt Schwenk-Schuster: Oh, yes.
[02:01:18] Co-Chairperson: For sure.
[02:01:23] Rifaat Shekh-Yusef: Awesome. K. You stay in here. Settings.