Session Date/Time: 26 Oct 2026 17:00
[00:00:06] Hannes Tschofenig: Let's give folks a few more minutes to join. Hi, Deb.
[00:01:55] Deb Cooley: Hi, Hannes. How are you?
[00:01:57] Hannes Tschofenig: Good. Good. I want to give folks a few more minutes to try. Do we have anyone who could take a few notes during the meeting? Because, today, I'm alone. I'm kind of, alone. Rifat is, not available today. Not everyone is excited to take notes, I guess. I I could volunteer as a notetaker for this session. That would be great. Do you know how to to do that? So there's there's the note taking tool which requires you to log in to data tracker, and then it's a regular piece of that. Okay. Great. I'll I'll do that. I'll look. Yeah. Okay. Trying to turn on my camera. I couldn't recognize the right camera. So... Hi, everyone. Hope you can see me. Yeah. So this is the the last virtual intro meeting in the series, that, Riff- and I organized on sort of in an attempt to spend a little bit more time on AI agent authorization and related topics since our last IETF meeting was a little bit flooded with requests. And so we wanted to give everyone a chance to have enough presentation time, enough discussion time. And I hope that worked out well. You got some... Something out of it. I... At least I enjoyed the presentations. Okay. As you know, so since you have all been here before, just the note well slide, and it points you to a number of IETF documents that describe the process. And quite importantly, we want to make sure that everyone reacts or responds, in discussions civilized and tries to help us make forward progress. If you are not familiar with any of the documents, please have a look. They are in the chair slide deck. Just, click on the link. As said earlier, we've managed to go through the virtual intro meetings that we had hoped to organize before the next IETF meeting, and I would say we have been successful. Except for one meeting slots, we we didn't manage to get the the presenters lined up, we got to where we are today and have Karl on a presentation today. And, of course, the show continues with the upcoming IETF meeting. We'll have more presentations, so this was just a warm up in some sense. And unless you have any agenda pressing questions, I I would like to switch over to Karl's slide and stop talking here. Karl, can you see the slides? Your slide? Okay. Perfect. Just let me know when I should switch, or should I hand you over the
[00:06:51] Karl McGuinness: Yeah. Do you mind handing it to me?
[00:06:52] Hannes Tschofenig: Clicker. I give you the clicker.
[00:06:54] Karl McGuinness: Thank you. Perfect. That's what looking for.
[00:06:57] Hannes Tschofenig: Okay.
[00:06:57] Karl McGuinness: Cool. I think, ready to go. Cool. Thanks, everyone, for, taking the time this morning to talk about, some of the work I've been, exploring for the past year around mission bound authorization. Been talking to folks in the industry, collaborating with folks like George and others, and trying to explore a different way to think about evolving OAuth to support some agent scenarios. And so I'm gonna talk a little bit about mission bound authorization. I'm gonna try to... A lot of content. So I'm gonna try to blow through a lot of slides to give the background and then leave about twenty minutes for discussion at the end. So I would prefer, if we can, to keep momentum on the slides to get through without interrupting with the questions and then follow-up with the questions. There's a lot of backup content. If you go to the data tracker... Or not data tracker, but the the website for the for the interim, you can get a copy of this. You can look at a lot of backup slides that may be helpful to answer some questions as well. There's a lot here to cover, so let's get in. Nope. That's not the right slide. Slide two. So why does OAuth need a mission? And, primarily, it comes from thinking about authorization today with Oauth is primarily allow... Center around credential and grant. It's not really centered around the work to be done. So if Alice asked an agent to reconcile invoices, review q three invoices, post the adjustments up to $500 each, What is Alice actually trying to approve? It's a read for the invoices during q three. It's a rate for the journal adjustments up to $500. There's potentially a time window for when it's allowed. There's potentially some accountability pieces to it, and it needs to be carried across multiple tokens, whether they're issued, they're refreshed, or token exchange, or or retired. And so we need one, approved unit of work with, and the question really is how do we map that to OAuth? From a cancellation perspective, if if Alice wants to cancel the job, what can she stop? Well, she can today revoke the client. She can revoke tokens using, existing, mechanisms that Oauth provides. She can revoke the grant with the grant management spec, or she can wait for the tokens to TTL. She doesn't have a handle to really stop the job by name. So I can't say I wanna stop, you know, this this job I submitted by name and have it carry out across code refresh token exchanges, and potentially multiple authorization servers. And so OAuth doesn't really have an interoperable object for the approved work. We have a bunch of specs, a lot of good work in progress around who is acting, whether it's from the work coming out of Whimsy, some of the actor stuff, identity chaining. There's multiple ways to talk about what a principal holds and when, whether that's through standard entitlements and SCIM and provisioning or just in time. The authority of what was issued, whether that's RAR, profiles of RAR, token exchange, grant management spec, is the credential or grant still good, a lot of good work with token status list, shared signals. We have good ways to start talking about distributed ways to do revocation. And may this specific request proceed? Good work happening in the all send working group around this. Good work with Max and folks around deferred token response and transaction challenges to try to provide more granularity here. But we have a missing object, which is what was this work approved to do, and is it still approved? There's no sort of common contract across, the OAuth specs that gives us a way to to bind this. And approval enumerates as agents discover. Agents operate, as we know, in more of an open world deployment model where they discover things at runtime. So instead of a traditional OAuth deployment where a client is registered advanced, The developer reads the developer docs and knows what scopes, writes, you know, software to request those scopes with a specific set of resources. User can consent at grant time to issue those, works within a known sort of boundary. Agents kind of as as we've been exploring kinda inverts that around. Right? So with MCP, you can talk to a dynamic tool at runtime. You can use client instance metadata to interact with authorization servers that you've never had a previous relationship with. With. You can compose, tools across servers. You can touch, many things, after approval has happened. And so the observation really is that authority starts to accumulate as we start seeing consent moving further and further away from the operation. And so IDJAG, for example, is a good example of this where, we've... We're starting to shift where the the consent... Traditional auth consent has happened. And as more of these operations happen, downstream, we we don't really have a way to bind that back to approved authority. So what is a mission? Well, a mission is a durable approved... Approval backed governance object. It's held by a mission issuer. The approved work has a life cycle. Authorities derive for, bound to, and gated on the mission. So approved work made addressable, so every later derivation sounds bound to it and gated by it. So the handle that in the... In our example, if Alan's was missing, the one object for the approved work would be the mission. Where does it sit in OAuth? Two potential different ways to think about it. One is co locate it with an authorization server. So the authorization server acts as a mission issuer. It will issue the mission and buying tokens to the mission. We're gonna go into a lot of detail about these later, so don't worry about too much of the steps. And then there's another role where you could consider the mission authority server to be a net new role that's a complement to the authorization server and can interrupt by by issuing an issuance grant to an authorization server in order to get tokens out. And so we can evolve a a role out of an authorization server into a standalone role over time as we see the need for mission to be a a layer potentially across multiple authorization servers. So from intent to resource, this is really what we're gonna, walk through for the majority of the slide to help, make this more real. So there's really, you know, sort of five key steps here. First is the intent. What is the the job? What is the work that wants to be done? Often, it starts with pros of, you know, a prompt. I want to do something. Intent, is not, trusted by the authority layer. It has to go through a process to to get shaped and turned into an approval that the agent actually agrees what is actually the, agent can do. And the mission captures this approval and the authority that was actually granted from the intent. So the intent is untrusted input. The approval is what binds the actual authority that grant it to a particular mission. Tokens then carry that forward, and then resources then can inspect the mission to make sure that the request is still within the mission context. So review q three invoices, that's the intent. Approval is what are the actual permissions that that's translated to. Mission will capture that authority, the owner, the consent around it, forward it... Or carry it forward in a token, and then the resource server can choose to either have a runtime inspection of it or rely on the the token issuance as the gate, which we'll we'll talk about The magic really is in mission shaping. Mission shaping is how you go from undeterministic to deterministic. It's a, again, a role that can be executed either client side or server side, but the key part is that it crosses a trust boundary. So mission shaping, there's lots of interesting research in the space right now here. This is where I expect a lot of the innovation to happen in the next twelve to eighteen months as folks start digging into how do you map, you know, free text prompted by human into something that is machine executable. Right? And so the mission shaping process can happen, again, within a harness. Lots of interesting stuff there. It could happen again with an LLM as judge on the server side. But the key point here is the the user is approving the translated, authority. It is not, directly executing the intent. And so this is, there's a fidelity here of, like, how do I actually know what resources? How do I bind it? That is not inside the mission specs. This is sort of something that is left outside. But what can carry forward is evidence about how it made those decisions, which, again, can refine a bit about how this process works, and this can also be iterative. Right? So mission shaping is not a one and done. We'll go into a bit of a loop here about how it can can be an iterative process. But the key, architectural separation here is that mission intent is sort of the goal, the bounds, the expiry. You can think of mission intent as, like, what you wanna tell when you're, you know, doing a remodel of a house. You wanna tell your contractor, you know, what is the the the set of constraints for the mission, what are the budget, what's the boundaries of it. And then you want to approve some aspect of it because you don't want to have to make every decision at runtime or the asset... Every decision down the road. You want it to be bound to the authority that you've given in sort of the contract. And so authority proposal can also be proposed by the by the client. So the key part here is whether it's traditional RAR as a proposal, whether it's goal and targets as intent, it gets approved as a proposal into... And turned into authority, and that's crossing that sort of the trust boundary. So it also approves the permissions and not the pros. It tracks who's accountable, the decision, what are the triggers to validate it, their standing consent. Initially, the sort of the smallest use case is direct consent. You could also have a a end user approve a template so that agents can execute with inside the parameters of a template. It could be a governed organization policy. There's multiple models for how we can map the the approval layer to this thing. And then with it, a bunch of evidence again on on the decision piece. And the key part is a model refuses, a model is not doing the decision. The human, the policy, or the template is is what's making the decision, so it's deterministic. So it has an identifier, has an authority set of what are the actual, permissions. It's hashed over, so it's preserved with evidence, as a, as a hash. There's accountability, and there's a life cycle and state to it, and that's gonna be important from a a management perspective. And the key part is approved authority is an envelope. It's not a particular script, so it's a ceiling. And so an agent lives within the approved ceiling, And then tokens can be subsets of that that are audience bound to particular resources or authorization servers, all with... Scoped within the context of the mission. And then there's a whole bunch of extensions that can can dial up how this authority can can change over time, when it's checked, when it's approved, different ways to track consumption. These would all be, from an architecture perspective, of different use cases that you can layer on top to provide more granularity around the narrowing and extending of of authority. And that what we really were trying to get to is what the agents improvise sort of how they do the work, but not never improvise the authority because the authority is bounded. And this gets us to sort of a common governance model for whether it's human in the loop, human on the loop, or human out of the loop, because the mission gives us a common anchor to anchor the approved work to, whether decisions need human in the loop or whether there's enough risk signals and other correlations or other evidence to support on the loop or out of the loop becomes a deployment decision for how these how these decisions get elevated. But the core architecture sort of remains the same whether it's in the loop, out of loop, or or, on the loop. And then the... That is really the the ability to help manage scale that sort of consent approval layer that we have a challenge with today, because there isn't really a way to find the work across all these, use cases. Tokens, obviously flow from it. So whether it's an authorization code, a refresh token, a token exchange, it can gate on issuance, whether, the token... The mission is still active or still valid. All of them can be, revoked so that then, you know, a redemption of a refresh token or a token exchange, if the mission is no longer valid, can gate the, the issuance of the next call. So it has to work inside the approval only while the work is live. Tokens are bound to each call. Runtimes can check at action levels. So the core sort of gives you what you expect today with OAuth tokens. You know, you can validate the token. You can get the RARs out of the token. Tokens were issued by the issuer within the context of the mission scoped, to that particular resource. You can do introspection. And then there would be a support for an optional sort of depth of of use case around runtime or a PDP... PEP can get context around the mission, can do lots of in-depth use cases around binding time of check, time of use, binding evidence, binding approvals to act... To action layer, consequential actions, how do wanna bind all this together, a lot of complexity in there that, you know, folks can... We can talk about. But the the core is is really follows the OAuth model, and the runtime model is really leveraging work around OSN and a bunch of other pieces around how to think about a, data model and evidence model for for actions that happens inside the resource server. Three things that we don't wanna confuse with the mission is it's definitely not the agent identity, who or what is acting. We're using all the other OAuth layers and Whimsy layers to to describe those pieces. It's not the intent meeting or what the words mean. Intent explains the work. The mission is the approved work. And the key part here is it's not session. It's not execution state of a harness. Execution state belongs at more of a runtime or execution runtime layer. Mission needs to integrate potentially to that layer, but it is not the sort of agent session. Agent session is really built for execution. It can be paused, replayed, or restarted across surfaces, across, you know, different cloud cloud engines or cloud run times. So the mission is not trying to track agent harness execution state. It's really trying to capture the authority and bind that in. Why standard? Standard lets the parts really agree on the work, whether it's across resource servers, across parties, across client work through derivation, and potentially... Or... And more importantly, probably for for some folks, even across authorization servers. And so because we're crossing a lot of these boundaries, we need an interoperable concept that can flow across. It can't just be a single private AS deployment internal details to the authorization server, to enable the interoperability. And so that's really the the the question for mission is that that I kinda got to, which was as you start looking at a lot of the MCP deployments, a lot of the cross domain use cases, a lot of the agentic need to sort of manage consent fatigue and human in the loop, standardizing a a mission object and how it gets bound into OAuth, provided a broad sort of interoperability surface for a bunch of use cases going forward. And then additional extensions over time can layer, depth of use case and complexity. So, the question you obviously have to ask is why can't we just solve this off the shelf RAR and and the grant management spec? And so they can model a lot of this again for a single, deployment deployment where you want to just in time create grants on the fly. The challenge is that the grant... A mission often is one to many grants, and the the grant needs to to go across and be introspectable across boundaries and authorization servers. And so you could sort of approximate this in a in a very controlled environment where I sort of just create a grant per job, manage it, make some extensions for some of the life cycle concerns, but it wouldn't really flow and and the narrowing rules and how the the need to make sure that missions are the upper bound and only, authority can only narrow, and some of these pieces will all have to get defined. And by defining all these things, you end up getting to something closer to what I have as a as a mission concept. And the two task test is really what we're trying to get to, which is a single client can have two tasks concurrently, two sort of missions. And if one ends from the... How do you stop one from the other without revoking the client or revoking a particular refresh token? Right? That's sort of what we wanna be able to enable so that you could have long running clients doing multiple sort of work. Alright. So that covered the background. Let's talk about the MVP. Again, I'm going fast. There's a lot we'll come back to, I'm sure, with questions. If we think that this mission concept's useful, a lot of the feedback I got over the year has been sort of, well, where's really the the MVP or the starting point for how we could think about this? It gets pretty large and complex with the, the number of sort of extensions to cover the breadth of the architecture. So part one is really just more, why mission, what is sort of the general premise of the architecture. Part two is really just trying to make it a little more concrete for folks in the room here, sort of what might the shape of an m v... MVP look like. So the MVP is really, a narrow, definition around commit, narrow, and gate. So the commit is approval fixes the authority set. You can't, no whining. So authority, serves an approved task, anchors commit. Every derived authority must be a subset of the approval, and every issuance must check that the mission is active. And so outside the MVP is a bunch of really valuable use cases, which would be how do we do approval without Alice at screen, which gets into a bit some of that, which I mentioned about sort of policy and governance layers, automating the approval. We get into the life cycle and changing the definition of the work that was approved. So you get into expansion, progressive, iterative, back and forth to sort of refine the mission. Those would all be sort of separate components that can be layered on top. You get into delegation beyond token exchange. You get into sub agents and child delegations and attenuation paths. These can all sort of be layered on top. And from a narrowing of permissions at scope, there's, you know, pieces at runtime, whether it's we wanna use shared signals and we wanna use status lists and other mechanisms like that to further, increase the resolution of revocation or changes to mission. Some of the, action models, whether they're transactional, metered, go all into the runtime pieces. The MVP really is just sort of staying back to that original OAuth diagram I I showed in the earlier slides of adding a a mission issuer role to an authorization server and and gating issuance of tokens and binding the authority. So going back to intent approval, mission tokens, and resource, high level, the client sends a new parameter called mission intent in a par. This is not the authority. This is the proposal for the work. The authorization server is going to turn that into authority and provide the end user direct approval in the form of consent. The mission's gonna capture that, create a governed object that's referenced by mission ID that it holds on to. The tokens then contain a mission ID claim, and then the resource server can either, knows that the... It's mission bound because it has a mission ID claim to it. It can, do token introspection if it wants to... Or it can do introspection against the mission if it wants to determine, more information or the issuance is the... And and lifetime of the token is is governed by the the authorization server. And then there is a, new revocation mechanism to revoke by by mission ID. So the request agent proposes through... Right now, the sort of the smallest surface area is through par. We can talk a little bit all about different ways to to send these things, whether they're device authorization or device code flow or or other back channel mechanisms to to send these. Right now, I just sort of started the simplest, which is... Let's just start with par. Past the mission intent has goals, which is sort of what the prompt of the agent typed in or or what it determine, what its goal is, some potentially hints around the things it wants to interact with, potential lifetime of what it wants. It could also then, through using metadata of resources that it it discovered, what are some of the RORs it thinks it wants, and pass that into a Para request. And so this is the, intent being separated out from proposed, authority, clearly separating the the intent piece from the authority piece... Or requested authority piece. Then the shaping, so probabilistic, we take that prompt. We run it through a shaper, which, again, could be a rules engine. It could be a model. It could be combinations of things. We get to a actual proposal. The proposal is then... Crosses that trust boundary. We then derive a set of authority for it, whether, again, expecting policy and deterministic pieces here to be how this is done. And then turned into an authority set, and Ellis is consenting then to the authority because... And we hash over the bit of authority that was granted. And so the approval is not just the prompt. The approval screen for the end user is the translated set of sort of authority that we're actually granting. They'll hit approve, and that's when the mission gets active, turned active at runtime now. And so we've committed the mission. This is in... The internal piece of the... This is the mission on the authorization server. There's a whole bunch of data here that the governed object owns. This is sort of the the bare minimum pieces to to make it real. We got the ID, the issuer, the state, the authority that was granted, hash over it, expires, carry forward the intent that that that came from it with sort of the history and the hashing of it and how it got approved. This is a stable record, that can be used, for evidence audit, introspection, but it can, it contains that sort of ceiling of authority. Again, each token, each resource server, each resource domain would have a particular resource or audience scope view of the mission. This is sort of the... Goes across multiple domains, multiple authorization servers. So this is more of the central view of it, not the audience scope view of it. Tokens carry the reference. I have the ID and the issuer. I have the actual, you know, authorization details that was granted to that particular audience. Gives me providence so I can then know that it came from this mission. I can go check it. I can check the status, see if it's been revoked. So every new token stays with inside the approval. So on the next action, we can determine, whether we issue or refratus. So if we want to cap each adjustment at $250, great. We can just keep issuing tokens for it. We wanna do a token exchange that, for a $250 token for 400. The AS would refuse it because it's broader than the presented token because it'll evaluate that against the mission authority that was approved. We wanna try to raise the cap to $600. Again, the... It'll get refused because it'll go against the granted authority that's captured in the mission. Remove the cap, similar constraint, you know, just, trying to change a constraint. Again, the mission captured the the the authority set, which is how it's using to evaluate whether it's a token exchange call or refresh token or another request. So part that kind of makes this work together is the the the core mission layer doesn't define, what an authority RAR, is. It work... Can work with any particular RAR type, but there's interoperability challenges if we don't, address some of the gaps of narrowing and matching and how to talk about some of the, evaluation pieces. So there's a proposal for a a particular type of RAR. Again, there's alignment work here with some of the interesting metadata work that other folks here on the call and in the working group are doing to, figure out where some of this should live, whether some of this lives directly just in AS metadata, some of this lives within, rules around processing of a RAR type. But we need... Over time, we need a way to talk about resource selection, actions, some constraints, how to talk about subsets, fail closed, how to map sort of MCP tools and scopes, into this. So there's a proposal right now just for a a a RAR type that gives me the ability right now to keep, you know, the architecture and use cases and demos and things working. This, I expect, to evolve over time, as we figure out where some of the roles and responsibilities end up. But at the core mission intent proposal approval layer, again, isn't specific to a RAR type. It just... We need a way to talk about subsetting. And so how do I know if a particular request is within an approved ceiling? I need some way to evaluate that. And so that ceiling is the interoperable piece that we need to understand a bit about the relationships between the permissions. On the call here, it shouldn't be weird. We pass the token. It makes the, action. In the action, it can evaluate against it, and, it checks. And then there's extensions for error codes here to determine, to the client, you know, is the mission... Even though the token may be valid, the... Or the token doesn't have, the right scope, it's really about the authority from the mission that is needs to get re approved. And so some signaling requirements, obviously, to extend some of the air codes to enable recoverability remediation or understanding that the mission doesn't allow this to happen. And there's a lot of bike shedding on how that stuff can work out. And so from a a life cycle perspective, I can revoke the mission. There's a new endpoint. Again, bike shedding what... How we wanna go about doing this. Right now, I didn't model it in a restful way, but it's more of a RPC. There's a revoke operation to the mission ID. There is a way... Now whether this is the, you know, client doing this, whether it's the end user and a console, you could think of almost a mission control panel that could be surfaced over time of active running missions, be able to do administrative operations on missions, metadata about it, auditors, security teams, all interacting around sort of mission life cycle and mission review. And that piece then, gives you the ability to revoke the mission, which then going back to our gating check, would stop new tokens from being gated. So mission status, right, right now has, some operations, revoke, suspend, resume, and complete, with different effects. There is some, extensions here to add more complexity, but the core really is just revoked by ID is, again, trying to surface back to what an MVP, may need. Kinda just right now, thinking about it as just starting with revoke some of the suspend resume pieces and the reapproval loops and pieces around those are, you know, very nice properties, but trying to sort of phase out some of the complexity, in the MVP right now. So one core extensions when needed. The core is really the binding, the OAuth binding, to... That I mentioned, which is proposal approval, bounded authority, passing the mission is inside the mission bound tokens with our revocation status. There's a set here that sort of increases the interoperability if we have a common RAR type that talks a little bit about the subsetting and narrowing and some of the rules, they'll have to talk about constraints and and interoperability and registry of constraints, as well as the rest of the verbs for managing mission status. That kinda kinda rounds out a bit to sort of, I think, gets a... An MVP, like, a deployment that's potentially interoperable or interoperable. There's a bunch of new recent specs by folks that I need to work with to try to figure out, again, how much of this belongs in RAR as an actual type versus how much of this is is metadata and can be expressed as metadata. There's a lot of extensions that right now are really just experimental to explore the full end of complexity of problem space that folks can dig into. And then sort of teasing out use cases, started a use case document with, with Max, on trying to talk a little bit higher level just about bounded work. This is more of an end to end concrete solution around of creating a framework to then layer a bunch of complexity and mapping of a lot of use cases of, that the working group's been exploring. There's alignment work to be done as as folks have seen. There's so... Every week, there's a new draft being published that touches a bit or pieces to it. I think the initial thinking here was how to kind of architect a a framing of how to think about the problem, and then we can then map complexity of use cases around it if there was this bounded work concept. And so if we can sort of dual track the investment or sort of keep going on use cases, but also have something to tie it all together and validate it against, I think we can make more progress. And the questions for the working group really are, do folks see this as a inter... Interoperability gap that is important for us to address? Where do they see the MVP? And where should we be focusing on standardizing and extension models and layering, and how do we go about, finding the work? That's really kind of the question for the working group. As I said, there's a lot here. There is a whole bunch of backup slides. I glossed over a lot. But in the interest of trying to keep to giving the the room twenty minutes, I will stop here for a second and review all the chats and see if anyone has any questions.
[00:38:56] Hannes Tschofenig: Thank you, Karl. Thanks for the presentation. Okay.
[00:39:04] Karl McGuinness: So your your mission feels conceptually a bit like translating search query into results. Yeah. I mean, there... It's an intent problem. So how do you translate intent to to something is is... Their searches has a similar problem statement done with a different set of technical backgrounds. I think... Again, I think a lot of innovation will happen with mission shaping. I don't think Oauth should determine all the details of that. I've already seen interesting research papers come out about how to think about some of these problems. So I would agree with that. Yaron saying is... Karl,
[00:39:41] Hannes Tschofenig: wait a second. I... Yeah. Pieter jumped in because I think he wants to respond to his Okay. Comment on that. Yeah. Go for it.
[00:39:49] Pieter Kasselman: Yeah. Thanks, Karl. This is really enlightening. I think the mission shaping piece, it almost feels like that is not really the in scope for standard so much. It's more about how do you communicate that that these steps have happened. Right? There is some Yep. Maybe some proprietary mechanism that changes the intent into a mission. And then... And I think what you're really talking about is, okay. How do I signal to all the downstream systems that there were... You know, this process happened, a mission identifier was assigned, a set of auth... Authorizations took place. Here's those, you know, shaped to... Or used to execute this mission. But I think you're not... Like, none of this is about, okay. How do I turn intent into a mission? Right? It's just about the second one, really.
[00:40:42] Karl McGuinness: Yeah. It's it's out of scope intentionally, as you mentioned. I don't think OS should standardize it. I do think there's role for evidence and attestations and other evidence to be applied through the shaping process for how you've determined truth, how do... What's the providence of how the information that be... Can be useful. So there is a a structure to some of the data, but it is not a component that OAuth should specify the how. So the output of it is, here's where you put it into the request, here's where you supply potential evidence, and then the AS needs to evaluate that and turn that into a proposed authority that the user consents to or policy is determined. Right? And so I'm intentionally separating out the determinist from the nondeterministic part, and keeping Oauth deterministic.
[00:41:31] Hannes Tschofenig: Yaron, please go ahead.
[00:41:34] Yaron Zehavi: Thanks. Yeah. Thanks, Karl. This is great stuff. Very enlightening. I have two questions. First is, does the client need to ask... I mean, is the clients ask in the beginning for proposal authority? Is that, like, the ultimate ceiling, or can the the client later or the agent later discover they need more authority and discover it and ask for it dynamically? And the second question would be, does the resource server... Do the resource server processing rules change? Must the resource server ask for the mission, or is that an extension?
[00:42:06] Karl McGuinness: Yep. So both both answers are extensions. So, again, I try to keep... The the broader view is the mission is an is an approval and a version and a life cycle of authority. You can version that and change that and get reapproval. Right? And determining when the human needs to do approval versus when policy can automatically approve, again, is a deployment. So the model supports that. Containment, expansion, progressive, doing iterative where I learn a bit and I wanna go back. The key part is when you amend the mission, it is a life cycle governance change to the mission. And so you'll get another event that happens that has to get approved to amend the mission. And then those would be different protocol surface area and sort of pieces to do because to do amendments and things like that adds a little bit more complexity to the core. So that's covered through some of the expansion and progressive pieces in here and some of the policy pieces with templates and other things inside the extensions that I'm exploring that address that first part. So it it is a ceiling, but that can change, and there's a way for that to change. So it's not... You know, it's intended to be something that... The whole part of it is that it's a point in time of a versioned piece of government assigned over it. The second question was around... What? Sorry. What's the second question again?
[00:43:31] Yaron Zehavi: Before the second question, so on the on the ceiling Yep. I mean, the authorization server or the mission authorization server, I mean, when you consider IDJ and identity chaining, you know, the agent might might need resources that are not in the view of the, first IDP. Right? It's a line of sight question. So if you think about... Or or the agent might discover later, you know, if it's searching for flights, I should check another engine. So I need I need more resources. But it might might still sit with the intent and the mission. So, you know, it gets a bit more fluid to decide, if if additional resources and authority should maybe be allowed if if not declared up front.
[00:44:09] Karl McGuinness: Right. So, again, I agree with you that there's a complexity here. I think, again, the deployment models of mapping it to how OAuth is deployed today versus, again, this sort of standalone mission authority layer that kinda sits potentially outside the authorization servers, how it is authoritative for issuing a bounded authority and who trusts that. Right? It's still a trust problem, and there's still a discovery problem on discovering what's available and then packaging that as far as do I trust the proposal coming from the client, again, versus do I have hard coded or fixed rules to evaluate subsets against that for what other alternative resources that could potentially be used. But the client can discover and add hints into the proposal that you mentioned, and that can be a part of a mission amendment. Right? It's... I've discovered these other things. I wanna do these other things. I wanna amend the mission for it. And so you're... The... It may, again, fall back to, again, a human having to make a concrete decision in doing direct approval of that expansion to talk to another resource, and that... Is that resource in another trust domain would have to trust the mission issuer, right, that it is authority for it. The second question really was the resource servers needing to to be mission aware. No. That's a a depth of functionality. As I showed the gating... In issuance and gating of the mission on issuing an access token that has bounded authority in that with a set of RARs that scope to that audience is sufficient enough to... Within the lifetime, as long as a resource server is willing to be okay for the freshness of the the lifetime of that token. The only need... The the need to use a runtime profile is really getting into sort of advanced use cases around checking, you know, the actual bounded request and action, and is that at at invocation time bound to the mission at the right level with the right evidence? Those gets into sort of depth of of evidence and and then run time profile. So you don't need them to get a basic deployment going, starting with just getting at issuance works. And then over time, individual PEPs or individual actions or consequential boundaries, you can sort of turn the dial up to be more mission aware and pull in some of this additional context and layer the context on top to get to that depth. So adopt... Adapting bill... Adoption is is definitely something, you know, I think it's primary concern.
[00:46:43] Yaron Zehavi: Okay. That's clear. Thank you very much.
[00:46:49] Hannes Tschofenig: Khan, could you jump back to slide Yep. 31
[00:46:55] Karl McGuinness: Sure.
[00:46:55] Hannes Tschofenig: Where you talk about revocation? Because I... So there's an interesting thing here. I think you talk about two separate issues in in your deck. One is you want to have another identifier in the different tokens and requests and so on to bind a couple of them together, so to reference them individually. And then the other part is the revocation aspect, and this slide speaks to that. So for some reason, you have identified that, like, here in this in this timeline, that a token would be valid for five minutes. Mhmm. And then the... Alice, in this case, revokes it after two minutes, and and that's sort of representative for a problem that, obviously, if you... If it's valid for five minutes and you revoke it after two, that's an issue. So now the question is obviously, who who figured out that a token should be valid for five minutes in the first place? And if that's a... If that is a problem now that someone suddenly made that decision that this is the the the wrong time, it's definitely not the user, the end user who is going to say, oh, I want my tokens to be valid for five minutes because how the heck is it going to or she going to make that number up?
[00:48:18] Karl McGuinness: Yeah. So good question. I'm tracking. Okay. The way it's currently talked about is really about relationship back to the resource server or AS on the other side and the contract you wanna put in place against freshness of the authority. So do I need a freshness of a runtime? Like, does the resource server even understand missions? Is the first question. If it doesn't, then I may have a different granting of the mission issuer and the policy behind it and how it gets bound into the authorization server would determine at issuance what the window is that I want to issue that authority for that's deployment specific. And then as resource servers and runtime profiles and consequential actions and metadata around action classes and effect boundaries and all these other problem statements that you get into the action layer, those may need different freshness requirements that that could, over time, get expressed as metadata that could be consumed by the mission server. You're getting into a negotiation layer here between the sort of policy and and execution and and effects layer of the runtime and where the freshness needs to live. How do you express your freshness requirements? I have experimental drafts talking about all those things, but this was really on the MVP, which was, like, it's just more how all this works today.
[00:49:38] Hannes Tschofenig: Yeah. But I'm wondering whether the revocation aspect is really tied to your other aspect, which you call mission, or is that... Could that be also treated separately? Like, do we have gaps in the authorization... Revocation mechanisms regardless of the mission aspect? Or do you...
[00:49:59] Karl McGuinness: Today today, token based. Right? Today today, revocation's token based on the token endpoint.
[00:50:04] Hannes Tschofenig: Well, there are different revocation mechanisms. But... So for example, the shared signal framework, it would be very different to the token revocation we worked on in the OS working group. A long time ago did that work. Very different concepts. Both useful, but but Right.
[00:50:24] Karl McGuinness: So I agree. So so if you know if you know the JTIs of all the tokens Yeah. You can send that downstream. But back to sort of the question of the multiple tasks approved work and having that flow is there's nothing on the RS side or AS side on the... If it's a cross domain outside of a JTI to correlate a set... A series of tokens against. Right? You just have subject client and a JTI. There's no way to correlate back to the work to know what what downstream replications need to happen. So to put it inside of an SSF signal or something.
[00:51:01] Hannes Tschofenig: On that...
[00:51:01] Karl McGuinness: It's it's token centric is what I'm trying to say that that they offer. But... Yeah.
[00:51:05] Hannes Tschofenig: But is that still... Okay. So even... So so it sounds like this would only... The this need for the revocation mechanism you are talking about comes up since you introduced the the mission concept.
[00:51:24] Karl McGuinness: Yes. Because you're you're going... You're... What you're trying to create is a boundary that lives outside a token lifetime. So n number of tokens are pro... Come from a mission. And so Yeah. There's... Today, trying to correlate and infer that is how folks have to deal with it today. It's like, if you're a security operations team and you're trying to understand the activity and you're trying to understand, is this all correlated to the same work or not? All you have is, like, to try to piece together JTIs and other evidence that it is all part of the same bounded work. Right?
[00:51:59] Hannes Tschofenig: Mhmm. Did you see that some other people in the in the group sort of created a similar sort of layer... Meta... Metadata layer as you did? They just called it differently. They gave it a different name. They didn't call it mission.
[00:52:16] Karl McGuinness: Did you
[00:52:16] Hannes Tschofenig: look at some of the...
[00:52:17] Karl McGuinness: I I mapped it... I've... I have a mapping of most of the work in the working group. Not most. Sorry. For some of the ones that are proposed, and they're all solving pieces of this problem statement. And so there's a lot of overlapping concepts across it. So this is, some examples, not authoritative list, but from the proposed side, there's some drafts around our pros. There's some drafts that deal with approve and record, some drafts that are dealing with sort of the governance piece to it, some of the enforcement of the action piece to it, how delegation should happen, how going across trust domains should happen, and how you make evidence of it. Again, the the the the first part of the presentation really is about mission bound authorization as, a reference architecture where you have these verbs and this framework to tie these things together. The individual pieces to it are, like, actual specs that have to actually have implementation, interoperability requirements around them. I think a lot of the work kind of all relates. My observation from the working group was that there really wasn't this unifying layer across it, and so it made it difficult to tie all these pieces together.
[00:53:28] Hannes Tschofenig: I see.
[00:53:29] Karl McGuinness: That was just my premise.
[00:53:31] Deb Cooley: Mhmm.
[00:53:32] Karl McGuinness: Now whether this... These individual drafts fit, like, there's lots of ties in it, whether it's intent evidence, whether it's shaping evidence, whether... Again, thinking about this from multi authorization server perspective where a mission can span multiple authorization servers, how to deal with continuity across trust domains, how to bind this back, attenuation only within a single trust domain, needed agreement as you cross trust domains. Again, how do we bind these things to the approved work, and what's the governance piece? What's the sort of admin end user pieces and consent pieces to it separated from here. I think there's lots of ways we could slice this, which is sort of the call to action is how do we wanna go about as a working group tying these things together.
[00:54:17] Hannes Tschofenig: Okay. Are there further questions? I don't see a note. Anyone?
[00:54:34] Karl McGuinness: So... Mhmm. Yeah. I guess, I still would like to know if there... People feel that this is an interoperability gap that we should be putting more energy towards? Or if current course and speed of lots of submissions, and I'm not clear, from the working group how how to move the conversation forward?
[00:54:57] Hannes Tschofenig: Yeah. I think, in general, like, very good presentation, and and the slide deck is pretty packed. I I could imagine that some people need a little bit
[00:55:08] Karl McGuinness: of time. No. And there's... Offline, can send, like, a white paper. There's a... Again, there's a whole bunch of content here that I can package up.
[00:55:14] Hannes Tschofenig: Even better.
[00:55:15] Karl McGuinness: Yeah. I I I don't I don't assume that everyone's gonna walk away right now with with clarity. I'm just trying to... Going into IETf, this is sort of why I was excited to be able to present to the working group ahead of time is that I I feel needing a framework around some of these concepts, is useful to move forward, without sort of tying some of these pieces together. I'm afraid that we're gonna rehash a lot of decisions at individual problem statement level.
[00:55:42] Hannes Tschofenig: Got it. Pieter?
[00:55:47] Pieter Kasselman: Alright. Karl, thanks for all of the... All of this, and it's... I think it's great that we have this before IETF, so we can actually, have some time to digest some of it as well. Something that might help is to sort of clearly separate out, you know, here are the things that changes in the protocol or is needed to change in the protocol from all of the sort of things that's maybe nondeterministic or things that doesn't necessarily change protocol or data formats, but they're really just, yep. There you go. I think this kind of helps perhaps to get... Help people sort of get their heads around what needs to change. Right? Because, like, I think you had a slide up previously which had, like, 20
[00:56:41] Karl McGuinness: Yeah. That that... Like I said, there's there's a lot to the problem statement, and then the the the slide deck was part one. Here's the, like, general concept. Part two, what I think narrows an MVP. That was the part that was trying to be more actionable to something that's more tangible. And then the... As you dig into all the use cases, you start going down the tree of all the other pieces that, you know, can be layered over time. But I do think there's value in trying to stay focused on what an MVP is.
[00:57:07] Pieter Kasselman: Yes. And I and I think that, like, something like this might help, and and maybe there is, just so that... Yeah. Because it's... There's a lot. Right? And I'm just trying to think about ways in which we can sort of get enough focus. Because otherwise, it just becomes overwhelming for folks.
[00:57:27] Karl McGuinness: Agree completely.
[00:57:32] Hannes Tschofenig: Yaron, please.
[00:57:33] Yaron Zehavi: Thank you. So, yeah, as said before, this is very helpful. We are now trying to take a Lagentic IAM, and I've come across mission and then exchange with you, Karl, to the last couple months. And this is the first time I got a full picture of it. So really, really helpful. What I'm missing is a bit more layering because there's so many proposals on the working group. So this is very clear, but I'm a bit getting lost on how the others layer in and shape. Also, there's one coming from you and, Liu about bounded work authorization. So... There's one on use cases only. Mhmm.
[00:58:13] Karl McGuinness: Just use cases. Turning some of this into a use case doc. That's... That should be the only one that my name attached. Okay. I'll I'll follow-up.
[00:58:20] Yaron Zehavi: Yeah. Yeah. But, I I think this needs more clarity, fully support. So in our mental model on how to do on behalf of human delegation, how to control it, how to prevent consent fatigue, this is, exactly the missing piece in shape.
[00:58:36] Karl McGuinness: Cool. I appreciate that. Yeah. No. I appreciate that. Flemming?
[00:58:48] Flemming Andreasen: Yep. Thank you, Karl. This is very helpful. I think it's it's definitely an interesting problem. I think one of the things that I struggle with is... Previously, at least when I look at the document that's submitted, and this is a little bit along the lines of what Pieter was just saying. I I see a 178 pages, and there's just so much stuff, like, coming at us from all sides. Having something more targeted, you know, more focused, you know, maybe trying to break it up, you know, clarify between use cases, requirements, what are we trying to do. This makes it more consumable for everybody. Certainly, me, I think this presentation helps a lot, but I still think having the accompanying documents mimic that, I think, would be be helpful to ensure forward progress.
[00:59:34] Karl McGuinness: Well, understood. It's been a journey, and I'm still on the journey. And then trying to break it up, simplify it, explore it, come back up for error. And so meetings like this are helpful as a checkpoint to to just, again, forcing function to come up for error, figure out the next target, and, again, simplify, simplify, simplify. I think there's... That's kind of the journey I'm on. So, again, any feedback there would help, but I agree completely with the goal. Alright. Thanks.
[01:00:04] Hannes Tschofenig: Yeah. In the the overwhelmness... I think in in general, like, with all the presentations we have had from last IATF meeting and also during this during this fall, one observation that I made was we obviously see so much more content, and and it requires us a little bit of time to or more time than before to process it. Like, for example, I don't want to pick a new card, but if you pick slide 38, I could imagine... I think it was slide 38.
[01:00:40] Karl McGuinness: No. This is this is overwhelming. I understand it's overwhelming.
[01:00:42] Hannes Tschofenig: Yeah. No. No. It's it's fine. We... Like, we had, like, the same the same type of thing before. It's like it has... Obviously, it's a super rich slide and and... But we could probably spend an an entire meeting just to talk about this. Mhmm.
[01:00:58] Karl McGuinness: And... Yeah. And and again, these are hyperlinks there. This is also again as a backup. You guys can find... Click it. The the TLDR was really trying to think of this as OWAF is just one type of binding. There could be n number of bindings, how to think of mission. Again, I was I was starting with the premise of mission is a missing layer, and OAuth is one binding, and then there's different verbs that come over time across an architecture and how to think through it holistically. That's the intention of the slide. The the spec details are tremendously detailed, and folks, I don't expect to grab all the details. But the intention here was just to provide a map to... Again, for folks to dig in as they...
[01:01:31] Hannes Tschofenig: But it... It's definitely, like... I could imagine, like, Brian, he would probably click on any any doc... In any of the document and read it and try to follow along. So probably I would do the same because because I want to understand it. Right? Uh-huh. So so there's definitely a lot of good stuff there in your slide deck, but it takes a little bit of time to digest. But really great that you put this together. I think I have a much better understanding now than I had before, and I hope the same is true for the participants on the call as well. No. We definitely have to continue this conversation because we've seen this sort of... As you showed with different contributions in the group, there are some... Different people propose aspects in this similar space, so there seems to be something.
[01:02:27] Karl McGuinness: Sounds great.
[01:02:28] Hannes Tschofenig: You're onto something. That's what I'm trying to say in
[01:02:31] Karl McGuinness: my Yeah. I I mean, I... Again, I wanna be very, very transparent to folks in the group too. This is all just trying to help push the working group forward. I don't have any product or commercial. I don't work for anybody. This is all just trying to take what I'm seeing and trying to organize it and work through problems and work with the community to do that. And I don't not... I don't care if any any one of these things lives long term. It's really just trying to take my insights and try to help formulate and and compose what I'm seeing across conversations around agents. So happy to collaborate with anybody that wants to evolve it, change it, rip it up. Let's do it.
[01:03:04] Hannes Tschofenig: Yeah. And I I expect that people on the call and and, of course, on the list are interested to collaborate with you on different aspects because there's obviously a lot of work that needs to get...
[01:03:14] Karl McGuinness: Course. This is way more than one person.
[01:03:18] Hannes Tschofenig: Cool. Okay.
[01:03:19] Karl McGuinness: Right. Thanks, everybody.
[01:03:21] Hannes Tschofenig: We are out of time. I would like to thank you all for joining this conference call series, and, yeah, we see each other at the next IETF meeting. You will see me virtually, but you will see Deb in person. Right, Deb?
[01:03:39] Deb Cooley: K. For one of the meetings, yes.
[01:03:42] Hannes Tschofenig: Yep.
[01:03:43] Deb Cooley: I think I have Perfect. Scheduling has been a nightmare.
[01:03:47] Hannes Tschofenig: Yeah. Good. Okay. So talk to you soon, and have a good evening or a good day wherever you are. Thanks. Thanks, George.