Session Date/Time: 19 Mar 2026 01:00
This is the transcript of the IETF 120 SCIM Working Group session on July 25, 2024.
Nancy Cam-Winget: I was awake for that one.
Aaron Parecki: Isn't that the last one right before Plenary?
Nancy Cam-Winget: Yeah, I fell asleep. I fell asleep. No, it must have been Tuesday though. It was Tuesday, not... I don't know. I have no idea.
Aaron Parecki: I don't know, either.
Nancy Cam-Winget: Yeah, don't just look at the days, I just look at the agenda at the hour and I'm like, okay, it's either Tuesday or Wednesday, but you know.
Aaron Parecki: It doesn't matter, right.
Speaker 1: Yes, my wife was like, "Are we doing this?" And I'm like, "It's Wednesday." She's like, "No, it's Tuesday." I'm like, "Sure, whatever, it's Wednesday."
Nancy Cam-Winget: Soon enough Thursday.
Speaker 1: It will be Thursday shortly. Is there anybody in the room, Aaron?
Aaron Parecki: We have a few people in the room.
Nancy Cam-Winget: Who is that? They're hiding out of the camera view.
Aaron Parecki: We have a couple. Can you in the room hear the remote people okay? Okay. It's just really bad audio on the stage here, so I'm having trouble hearing.
Nancy Cam-Winget: Oh, okay. Are you in that room? Are you in... is there no monitor in front of you?
Aaron Parecki: There's no stage monitor in this room.
Speaker 1: I feel like that's a lot of the rooms.
Aaron Parecki: Yeah.
Speaker 1: Huh. Yeah, I understand that.
Nancy Cam-Winget: I don't want to jinx it, I just hope this one goes smoothly.
Speaker 1: As long as the slides don't keep dropping every five minutes like they did when Aaron was doing his 45-minute thing with OAUTH.
Nancy Cam-Winget: Well, or that the clicker didn't work, or that the audio dropped, or that... I mean, I think in this room I got booted out twice. And even on the Webex on the side meetings, same thing.
Speaker 1: So Colin says there's... there's a reason for Webex not working very well here.
Nancy Cam-Winget: Uh, yes. I... I... this is not Webex's fault.
Speaker 1: It's a completely separate infrastructure in-country versus everywhere else, right?
Nancy Cam-Winget: Well, there's something about data governance and lawful intercept and, yes.
Aaron Parecki: Yeah. Shall we get started?
Speaker 1: Yeah, sorry.
Nancy Cam-Winget: Yes, please.
Aaron Parecki: Great. Okay, welcome to the SCIM session on your Thursday morning local time. We've got two hours ahead of us. First, start with a couple of intro slides from the chairs. Starting with the Note Well on the screen here, this is... please make sure you're familiar with this. The brief reminder of the key points from the Code of Conduct: make sure you are respectful and extend courtesy to your colleagues and have impersonal discussions; devise solutions for the global internet that meet the needs of diverse technical and operational environments; and be prepared to contribute to the ongoing work of the group. Quick administrative tasks: is there anybody who... we do need to take notes and we need someone to watch chat. I think I may be able to be the chat watcher from up here, so I'm willing to do that. And we do have the automated note-taker from CodiMD which I think will count as one of the note-takers, but it would be great to have somebody else, either in person or virtually, take some notes in the notepad doc linked from the tool here. Is anybody willing to volunteer for that? Mainly just, you don't need to transcribe discussions, the main goal is to capture any tasks in the item to-do items or decisions. We can't run the session... anyone? We do need at least one person to take notes manually.
Nancy Cam-Winget: So, I can try and take actions, Aaron. That just means you have to drive most... see, I'm not awake. What am I saying? Main action items, I will try. Go ahead.
Pamela Dingle: Sorry, I'll volunteer too, but I am speaking for one of them so I'm not a very useful person for that session.
Aaron Parecki: Thanks, Pam, that would be great. So when Pam is presenting, I guess we'll have Nancy take the action items down.
Nancy Cam-Winget: Yeah. Just trying to capture it in the minutes. Thanks.
Aaron Parecki: All right. With that, this has been your five-minute Chairs' Intro. We're going to have four different topics to cover today. Is there anything else anybody would like to add at the last minute here, because I think we have a couple of extra minutes available on the agenda? Any agenda gardening, as it were? If not, we will just jump right in. So we'll start with SCIM use cases, a short update from Paulo and Pam, and then Danny will cover two topics: SCIM GroupMember Resource Draft and SCIM Interoperability Profile Draft. And I believe Pam is then presenting the SCIM Agentic Draft Progress.
Paulo Casillo: Okay, so, uh, I think it's going to be really short. So, the same request as last time, right? So there isn't many changes. So me and Pam reviewed it many, many times. Eliot did the review and Dean also the review. We need more reviewers, right? So I think we need more reviewers. Now I'm questioning... so I had a conversation with Nancy when I was with her in Amsterdam. I think we need more reviewers, I don't know, opening to the group to provide feedback. Just bear in mind that this is part of the charter that we have for this group, so I think it's really important for us to finish this work. And right now me and Pam can review it again, and we can review as many times as it's needed, but without more help, I don't know.
Nancy Cam-Winget: Let's get volunteers to review besides the chairs. So can we get a couple of people?
Aaron Parecki: I was going to ask first, Paulo, the reviews that you've gotten so far, did that result in any updates or changes to the doc?
Paulo Casillo: Yes, yes, yes. So those are published in the latest version. Yes. So the last... so the first update it was a couple of IETFs ago from Eliot. Then Dean did a great job and we even talked about all the changes that Dean proposed. And I did the changes with Pam and we also open it to discussion and we didn't have more feedback, so we leave it like that. So all of this generates a couple of changes, but I think, I think we need more views on it, right?
Aaron Parecki: Okay, great. Thanks. So yes, any, any volunteers? Oh, we have Umesh.
Umesh: I was just going to ask, when do you need the reviews completed by?
Paulo Casillo: Next IETF.
Aaron Parecki: Okay. Yeah, I can help. Great. We've got four volunteers. Amazing. We've got Umesh, Maisie, Danny, and Paul. So yeah, for reviews, just make sure you post comments to the list, the mailing list, and we appreciate it.
Paulo Casillo: And that's all. Quick, less than five minutes.
Aaron Parecki: All right. With that, we'll turn it over to Danny for Group... Nancy?
Nancy Cam-Winget: Hold on. Sorry, go ahead, Nancy. I'm just trying to put that in the minutes. The volunteers were Umesh, Danny, Maisie, and Paul.
Aaron Parecki: Thank you.
Nancy Cam-Winget: Just trying to capture that in the minutes. Thanks.
Aaron Parecki: And Danny, I will share your slides and give you control.
Danny Zollner: Thank you, thank you. Okay, yeah. Hi everybody, I'm Danny Zollner. If you've been to one of these before, you've probably seen me talk about things. A couple of weeks ago I published two new drafts to the IETF Datatracker for SCIM. This is the first one. So there's a long-standing... let me go ahead and move slides forward, otherwise I'm going to talk about everything with just the title slide. So yeah, there's a long-standing problem in SCIM. Many directories have groups that are very large, and SCIM represents members of a group as values in an array, values in a multi-valued attribute. Pagination in SCIM only works for resources, so you can, you know, have a list of different users or a different group, but you cannot paginate the list of, you know, members in... values in the members attribute on a group within a single group. And then that lack of pagination requires group members to be returned in a single HTTP response. Or what a lot of implementers have done is opt to not return group members, or not return them above a certain size. It's all sorts of like weird inconsistent behavior. But if you have a group with a million members today, the only way that's spec-compliant to actually send the list of the million members is in one HTTP response. And that doesn't really hold up in practice.
So if that's the problem, this draft is proposing a solution. So the draft introduces a group members or I guess a GroupMember resource type with the corresponding /GroupMembers resource endpoint. And then to sort of help with the overall solution, I've also defined in the draft an extension that goes on to a group resource, so the existing group object, called membersMetadata that contains a few things that tell clients what's going on. Essentially it says, "Hey, this group might have members, but you're not going to see them here at /Groups. You have to go to /GroupMembers instead." And a few other things. So this helps to address that inability to paginate group memberships because it changes the list of members from being values in an array to each group membership is its own resource. Which then, you know, you can use all of the cool stuff in SCIM like two forms of pagination, whatever. And then it also sort of just by virtue of setting it up as a new resource means that you can go and create a new group membership with a POST to /GroupMembers and remove a group membership with a DELETE. In the draft, I've said that PUT and PATCH HTTP methods aren't allowed because generally a membership shouldn't really be mutable. It's sort of like either, you know, an object is a member of a group or it isn't. There's not a whole lot to update once that link is established.
So here is a JSON, you know, SCIM JSON example of a GroupMember resource. It's made up of a couple of parts. So there's an attribute called group, which then contains the value that is the ID of the, we'll call it the parent group. There is the attribute member, which, you know, a value containing the value of the member. Both have the $ref, optional to implement. And member has it also an optional type if the service provider wants to say, you know, "this is a user" or "this is another group or a device" or what have you. And then the membersMetadata extension for the group resource... it's all sort of, you know, still work in progress. This is the draft, version 00. The schema namespace, honestly the existence of some of these attributes, I'm looking for feedback more than anything. So yeah, the membersMetadata attribute has a policy attribute, which the little box here on this slide defines what each of them are. Essentially, is the membership going to be shown on the group object, in a list of group member objects, or both? And then ref is just a link with a filter to say to the /GroupMembers endpoint that if you go there, it will give a list of group members that are a member of the group. Because this membersMetadata attribute would be on the group resource rather than, you know, a... the /GroupMembers endpoint. And then there's a count thing as well because that helps to figure out what's going on. Here's just a like more JSON-y example. Y'all can look at that on your own time.
And then I have a slide here at the end, this is I think the last real slide, with a couple of the other options that have been discussed on the SCIM Working Group mailing list or just in conversations I've had over the years of other like ways to solve this problem and more. So there's at least one draft published eight or nine years ago that would add pagination for multi-valued attributes. And then I've also had discussions in the past with people on the concept of paginating essentially just the body of the SCIM resource. So it's all just like a blob until you finish paginating it. Both of them are complicated. And the second bullet here on the right of that first section is really key. The complexity means that it's probably going to take longer to get to a like broadly implementable solution because we're solving for more use cases. And today from a like practical sense, group memberships are the only thing that are ever coming close to the like size limits in an HTTP response where this is like causing actual production issues today. We're not seeing implementations of, you know, users with roles or entitlements or email addresses or anything of that sort that, you know, go to the point of a... like an HTTP response that's like in megabytes of size and, you know, causing, you know, out of memory exceptions or whatever. Also had discussions on HTTP layer solutions. I'm not an HTTP expert. I'm going to sound dumb if I try to, you know, talk about this too much. But things like streaming and chunking... they're complex to implement. They may be viable, but when you think of I guess broad implementation easier adoption and all that, to me it didn't sound like the right solution. And then another one that I know has been discussed on the SCIM mailing list in the past would be a sub-resource model. So that's something like /Groups/{id}, so the ID of the group, and then /Members. And so that wasn't chosen versus a root sort of /GroupMembers endpoint because if you have 10,000 groups, you would have to make 10,000 individual calls to /Groups/{id}/Members. And then, you know, starting to think about other things... there's, you know, been drafts like I was one of the authors on a draft for like a delta query or change detection, whichever draft a year or two ago. And I think anything that positions group members more as a top-level resource rather than something like weird and semi-bespoke, even if standard, means that it'll be able to benefit from, you know, any other improvements that the standard has over time. So that is sort of the last slide. I've already gotten one pretty comprehensive round of feedback from somebody on the SCIM mailing list for this, but I would like as much feedback as I can possibly get. If anybody has opinions right now, we've got I guess 11 minutes out of the 20 minutes allocated for this. Also happy to receive feedback on the mailing list via the GitHub repo that is in the draft. Yeah. I'll stop talking.
Aaron Parecki: Thank you, Danny. Yes, if anybody has any comments about this and would like to discuss, we do have a few minutes. Please put yourself into the queue with the little handraise button. Yes, go ahead.
Madokiu: Hi, this is Madokiu from Rakuten. Just a quick question on that last note on the final slide. I mean, it does seem like the sub-resources look like a more natural way to do this. Can you elaborate a little bit more on why is it being... not being chosen?
Danny Zollner: Sure. So the sub-resource /Groups/{id}/Members, I think is the second-place finisher in my mind. I had considered also trying to include both a /GroupMembers and a /Groups/{id}/Members into the same draft, but that like creates its own like two things competing with each other problem. But so if I guess there's implementers at scale... so I'm thinking sort of from the like enterprise desire for like I guess we'll call it identity governance and, you know, reconciling a, you know, identity store, you know, what we'll call like the identity provider with the identity directory the status of a set of applications. And if the whatever the like main provisioning synchronization engine is, if one of the goals there is to, I don't know, regularly check and track that all of the essentially that there hasn't been like drift in membership and that, you know, a new member was not added in a system that was not added intentionally, then with... a root /GroupMembers, that can potentially be done in a single call. And you may have to paginate the response, but you can call /GroupMembers using, you know, structures that exist today if, you know, the SCIM service provider supports the meta.lastModified attribute for a group. Oh, that I guess would have to be for the GroupMember object in this case. But, um, you know, like if putting some of the like, I guess syntactical stuff aside for a bit, if there was a query that was something like, you know, "give me all group members that were added or removed in the last, you know, one hour," doing that to /GroupMembers means you get it for all of the group memberships that are out there. If we do the sub-resource model with, you know, /Groups/{id}/Members, then if you have 10,000 groups, you'd have to probably end up doing 10,000, you know, HTTP GET calls with that filter. But that I guess was my the main reason why the sub-resource model ended up as second place for me when considering, like, what to write.
Madokiu: Okay, I get it. But I mean, it's like, I mean, I understand the rationale on it, it's just a little bit weird if we're... I'm not sure whether or not someone would basically just call /GroupMembers and then just try to get members of all groups. That's sort of what your intention was about, but okay. Thank you.
Aaron Parecki: Maisie's in the queue.
Maisie: Hey Danny. Um, I wrote out my feedback in the chat there. Um, one was just on member counts, since one of the goals with this is trying to handle groups with large masses of members and computing counts is generally expensive, it... I would be inclined to just omit it entirely. The other is just small nit on if the word 'policy' is the right word, and kind of related is if you thought about using Service Provider Config for the purpose of that member metadata, and then a question on why you didn't go that direction.
Danny Zollner: Sure. So I'll go through them in order. So the first feedback being counts are expensive. This draft is trying to help with, you know, efficiency performance. I agree with your feedback. I don't have a strong opinion on keeping like the member count sub-attribute. I'd be curious if the broader like opinion or broader consensus was that the an attribute of that sort should be dropped entirely or just defined as optional and a service provider could add it if they want to. There's like some benefit to that I... maybe? I don't think I have a like well-thought-out enough opinion to keep talking about the pros and cons right now, I'm just going to start rambling and that is not useful. For the membersMetadata.policy, um, yeah, the name of the anything involved there, whether it's membersMetadata, policy, open to suggestion, open to change. I do not have a strong attachment to any of them. And then to the sort of like 2b, the second part of that, of wondering why it isn't in the Service Provider Config. The scenario that came to mind that led to me to write it that way is... so like right now SCIM is effectively just users and groups, in like broad implementations. There's a devices draft that is in the RFC Editor's queue, if my memory is correct. There's, you know, work on a draft to define like an agent or AI agent or whatever resource type. And I can see a like possible future where there's going to be systems that have users, they have groups, and then they have something else, you know, devices, agents, whatever. And they may have sort of like multiple sets of groups that don't overlap with each other. There may be, you know, sort of device groups that end up, you know, applying certain policies to the devices in that system, you know, groups that allow users to be members that, you know, do user-y things. And those systems may not allow a single group to contain both a user and a device, or a user and an agent, or whichever. Um, I'm not sure that there's a whole lot of that out there today, but that was the scenario that I was I guess trying to factor in, that not all groups may be like uniformly the same and, you know, allow the same member types. Sometimes a SCIM service provider might be representing multiple sort of interconnected but separate systems that stand behind it. So it wouldn't be in Service Provider Config because it's a... it would be a per-group object or per-resource thing rather than a global thing. And then the patching, the third one was, would you want to patch any of the meta attributes in membership? So the meta attribute is defined in 7643. It's a sort of a mechanical attribute that's entirely controlled by the SCIM service provider. So the client would never be able to, you know, patch or put or whatever to modify it.
Maisie: Got it. That all makes sense.
Danny Zollner: And then Nancy had put a note also if you could echo those either in the mailing list or on the GitHub repo that I'm using for this right now. It would be appreciated.
Maisie: Yep, will do.
Aaron Parecki: Looks like we have two and a half minutes left. Nobody else is in the queue. Great. So I guess next steps on this... it would be great to get some reviews from others on this. Um, thanks Maisie for the quick review and comments. Would anybody be willing to... to do that?
Pamela Dingle: This is Pam, I can volunteer to review.
Paulo Casillo: Yeah, this is Paulo, I'm always happy to work with Dan, Danny.
Aaron Parecki: Great. That's perfect. Thanks so much. Look forward to your comments on the mailing list. And I'll just harvest our minute and a half move on to the next topic. Sounds good. Let me switch the slides here. Okay, and this one is also Danny. Let me just restart the timer. Go ahead.
Danny Zollner: Okay, there I see the timer now. I don't think I have control. Oh, yes. Sorry. There we go. Okay, maybe move a little too fast. Yeah, it's me, Danny again. So this is the other draft that I published. It's... title also maybe a work in progress, SCIM Interoperability Profile. So same general format. So my attempt at describing the problem. SCIM has a lot of features, and a good chunk of them are optional to implement, whether that's, you know, attributes in the schemas that are defined, things like, you know, support for HTTP PATCH is optional. The spec says you have to support PUT as a service provider but PATCH is optional. And then there's a whole lot of stuff that just doesn't actually say, you know, whether it's required or not, and in the real world that means people think it's optional if they don't like it or want it or need it. So the problems are actually it's a big pile of problems, not just one clean story like the group thing. But so SCIM also provides like way too many methods to accomplish some like tasks or actions. So if as a SCIM client I want to go and, like, let's say replace the first name on a user object, Danny. There's... if I'm using HTTP, I could first like it's a decision of do I use HTTP PATCH or HTTP PUT. If I'm using HTTP PATCH, then the like whole patch-op structure and with attribute filters in the path of a path and different syntactical choices... you could come up with a really, really, really long list of possible like permutations of how you could structure an update to say go update this one attribute that would all technically be valid according to the rules laid out in the spec. And that makes life really hard for SCIM service providers because of the like mainstream or whatever the like large commercially available or open-source SCIM clients that exist out there, they all have slightly different interpretations of different parts of the SCIM spec. They all choose slightly different syntaxes or combinations of syntaxes depending on if something, you know, if it's a how many attributes are being updated and are they single-valued, multi-valued, like all that. Um, so that just it's made implementing SCIM, we'll call it the SCIM tax on SaaS app vendors or just, you know, application vendors, a lot higher than it reasonably should be.
So again, you know, same structure as last time. This draft is attempting to like define a solution to this sort of problem. So the draft sets sort of, we'll call them like modern requirements... I don't know if I actually like the word modern anymore, but too late. Aiming to standardize what SCIM integration between identity providers and we'll call them B2B SaaS applications look like. In that case, generally, you know, the IDP role would be the SCIM client, B2B SaaS would be the service provider. The draft that's out there right now, the 00, has requirements that include what's listed here. So it tries to rain in the like hundreds of possible ways to go and, you know, update attributes with SCIM PATCH. It defines some minimum required attributes for users and groups in the name of interoperability. Defines minimum requirements for what service providers must support for filtering and pagination. And also puts like a corresponding requirement on clients in a bunch of cases of, you know, they will filter by these things and not other things. So like use, you know, the EQ operator and not like "starts with" or "contains." I guess the EQ versus starts with/contains, wrong category of expression stuff. But then also calls out certain requirements that are already actually present in RFC 7643 and 7644, but are not clear to most readers and are therefore commonly implemented incorrectly. So it's essentially just like erasing ambiguity. Sometimes, you know, requirements end up getting spread out over a couple of different sections of specification where, you know, there's one line in Section 4 and then a paragraph about it in Section 6, and when you join them all together, it comes out with like a different end result than if you just look at the big chunk in, you know, let's say Section 6. I'm pulling the section numbers out of thin air. And then the draft also prohibits certain features or behaviors that are in SCIM 2.0. So from the time of writing that draft and even within the last like day or so, some of my opinions based on feedback have changed a little bit on this, but we'll keep moving forward for now.
So the HTTP PATCH simplification, I'm not going to go through like line by line on this, but the goal essentially was to define certain things that either like a client should do or explicitly should not do when using PATCH. And that those requirements are spread out over single-valued attributes and then over simple and complex. And then I'll move on to the next slide, sort of the same approach for things to do and not do for multi-valued attributes. So these slides are available online, you can go read the draft. I don't want to spend the entire session going over the overly complicated PATCH stuff though. And then some of the features that are like deprecated/prohibited in the current version of the draft says: don't use the password attribute. You know, it's the year 2026. In the like B2B SaaS workforce scenario, which is where I've seen most of SCIM usage, but I also have lived in that world, federation should almost always be used. Synchronizing passwords... I guess SCIM doesn't even allow for synchronizing password hashes, but password synchronization between domains is just asking for trouble. It also explicitly calls out: don't use HTTP PUT, use PATCH instead. Don't... there's some things that are sort of implementer's choice in the SCIM spec around if the client sends a request that contains certain things that are, you know, unknown or just like invalid from the perspective of the service provider. The service provider can choose to either throw an error or to just sort of like silently ignore or, you know, silently modify in transit the things that it didn't like and return a 200 or 201 or whichever like a success response even though it turns out, "Oh, three of these attributes I didn't like or I didn't know what you were trying to tell me, so I just dropped them," which creates a whole, you know, a whole bucket of problems where like changes that were thought to be sent out by the client don't actually end up persisted on the service provider. And then it calls out a few things that are like there in the spec but I'm not sure if they've really ever seen adoption in a workforce B2B SaaS IDP-like world. So using the like E-tags and the like HTTP headers tied to like versioning and like, "I'm going to do like an HTTP PATCH and don't update this object unless the version is whatever's in this header." And then also filtering saying, you know, "PATCH users where, you know, department equals sales." Technically, the SCIM spec says you can do one PATCH and apply the same change to everybody that matches a filter. Like, you know, "change the office location for everybody in sales at once." Nobody actually has implemented that that I've seen. At least not like both sides bi-directionally or whatever, like a client and a server together.
And so we're at next steps slide. I'm actually going to go back just real quick to like gloss over one of the things I have had like a change of heart on, which also provides some context. So some of these things, I guess the second sub-bullet in the second part of the slide says, "Define, you know, minimum set of required attributes for users and groups." I am at this point leaning towards trying to rain in the scope of this draft to be about, we'll call it protocol-level interoperability. So that would be things along the lines of, you know, the PATCH syntax stuff, some of the protocol stuff that isn't here in the slides but, um, you know, how to handle case sensitivity for an attribute or between, you know, let's say conflict detection and filtering on that attribute and its value. I guess protocol-level versus defining like, "For users you must do X, for groups you must do Y." And so the like trigger for this draft getting written now was in part work that's happening in another working group, the IPS Working Group, which is attempting to define interoperability standards that align more to the... the resource data model side of things than this draft I think should. So I don't want to like overlap too much with the IPS draft. My thought process was that if IPS is targeting more of the stuff about, like, users and groups and like what attributes are supported and, you know, don't support the password attribute, that sort of thing, that that work in IPS would greatly benefit from something to fix some of the really tricky parts of like the protocol of SCIM. So my current inclination is that maybe to cut out some of the stuff in this draft in the next version and hone in more on protocol, less on data model, or whatever you want to call it. Now clicking to the last slide a bunch. Yeah. So that is sort of all I have on this. I threw out an email with a bunch of feedback on this draft that was sent to the mailing list last week. Same as before, I would appreciate as much feedback as I can get on this one though.
Aaron Parecki: Great, thank you. Anybody want to comment on this since we have some time? Pam.
Pamela Dingle: So, I remember at the end of the last plenary, Deb asked us exactly where we were on reving SCIM, because that was part of the charter. In your mind, Danny, does this feel like a step towards what a SCIM 3.0 could be?
Danny Zollner: Yes. Um, this feels like I don't know, sort of an easier-to-implement version of like a... I don't know, it's hard for me to think of like SCIM 3.0 or whatever you want to call it, SCIM 2.1, as anything other than it's like almost like a partial rewrite. Um, I have struggled to envision a like SCIM, you know, V-next that doesn't end up being a breaking change for some percentage of SCIM 2.0 implementations. And I guess this interoperability profile would also probably be a breaking change as well. Um, I yeah, I think ultimately this could be like a seed that grows into a new versioning of SCIM. I am just hesitant for like it feels a little bit like opening Pandora's box.
Aaron Parecki: Yeah, we don't need to name it right now, but I think the general sentiment was that, you know, we've chartered this group to update the core specs. There's a couple of bullet points in the charter that talk about some things that might get updated in the core specs. Whether it's called 2.5 or 3.0 or 10 or whatever, it doesn't really matter at this stage. Um, but I guess the question is just: do you think this is the the direction? The question to the group would be: is this a direction you would want to see an update to the core specs take? Yes, Paul.
Paul: Yeah, I think to answer your question directly, I think the answer for me is yes. Because we've had a decade now to see what has and hasn't worked in SCIM, and so it feels like it's an appropriate time to trim the tree a bit and focus on the things that have been implemented and simplify in the spec the things that either never gained adoption or because of subsequent changes are now sort of out of date.
Aaron Parecki: Thanks. I'll say, I think that the like this draft as a standalone, I personally am interested in seeing if that set of changes can get consensus and be moved through the IETF process in part because I think that a bigger like revision, you know, leading to V-next, is likely to take a lot longer because it's a more comprehensive like body of work. So I think that what happens with, you know, this draft, honestly with the last draft, the group members thing, a lot of the things that have happened, and I guess also what like the Christal pagination draft that's now in RFC, a lot of the decisions that get made almost in like a modular like piece-by-piece series can likely then be joined as part of one more like cohesive doc update in the future. But out of almost like selfishness, I would like to see some of the like real-world positive impact that we could get by addressing some of these problems as the individual drafts in the next year or two years, versus I'm scared that we're going to be like four years on a like a 2.1 or a 3.0 or whatever.
Nancy Cam-Winget: So I do think, um, there's obviously many ways to do this. Um, you could do a series of updates. It's... the trick is you don't want to make it hard to implement, right? You don't want to make it hard for an implementer to find all the right pieces in all the right RFCs. Um, I do understand that maybe you don't want to mean, how do you eat an elephant, right? You might not want to eat the whole thing all at one time. Um, so by doing little bits and pieces, um, you may get there easier, but the trick is going to be how do you make sure that it all stitches together properly so that it's implementable in an interoperable way, right?
Danny Zollner: Yeah, no, I agree. And then there's the like hard question of sort of like of like when is it worth it to I guess do a a set of breaking changes. There's some things in the SCIM spec that realistically should get cut, but they're probably at like less than what, one-tenth of 1% adoption. Like it's hard to measure a lot of these things, but um, like mainstream adoption can very easily be defined as like certain patterns, certain use cases. But I don't know, there's plenty of people who've been around in the SCIM standards, you know, world for a lot longer than I have who can give guidance as we travel that path.
Nancy Cam-Winget: Yeah, I think I'm going to echo what Deb is saying. Um, given that there are other areas that we want to tackle, we still need to fulfill the charter. So I think it's more important for us to first agree that the items you've identified, Danny, are ones we want to move forward with, and then we can make a late binding decision. I mean, I like the idea of having a a recommended practice, I think, um, that interoperability profile, because I think it's self-contained. Um, to Paul's point, right? It ensures the whole of SCIM from an interoperable standpoint. So I'm just echoing everybody. To Aaron's point, you know, we don't need to call it anything right now. It's really more for this group to agree that these are the right things that we need to focus on. It doesn't have to be exhaustive, but at least it allows us to make progress. Because to your point, Deb... yeah, it'll take too long. The other thing I will say is I think you need to make it clear that this is um an attempt to update the specs by trimming down the options, um, so that we don't get... so I've been having trouble with some of these drafts being um claims of being sort of marginally out of charter. And I've managed to convince Roman, basically, that they are in charter. The hardest one was the device one, but um, it... we do need to keep it in the charter. I do think it's time for a charter rewrite, and I have cleverly waited until I am no longer your responsible AD to do that. So yay me. Um, but um, you're welcome to Chris, right?
Deb: Mm-hmm. Yeah. So sorry, Chris. Um, because I meant to do this a while ago. So possibly a charter rewrite will help with this, but I think we need a plan. Once we have a plan, the charter will fall out, right?
Chris: Correct. Can I just say in the conversation, you know, like so Deb and I, Deb's been trying to ramp me up here and and she told me a little bit about kind of what needs to be done for re-chartering and, you know, kind of scope on documents. Um, I'm not there yet, but I feel like listening to this conversation, I have haven't exactly heard, um, and I know that a number of you, like you, like I've been kind of poking at where the participants from and that kind of stuff, so you have it feels like you guys have the right community here, but I haven't heard there's some interoperability problems that seems like it would be key to me, but I haven't heard, you know, what you guys think of as the next set of most important problems. And and if it's trimming down the spec or what the, you know, boy you have too many extensions, let's do some consolidation if possible. I haven't heard what like what your biggest pain points are. And um, you know, it's something I've been listening for and I haven't heard it yet. And so I don't know that you guys are quite ready, it seems to me, to to like kind of write that down.
Aaron Parecki: Just wait until the next presentation. I think we're going to hear some of that in the next session, next presentation.
Nancy Cam-Winget: Well, but that's the re-chartering piece. So Chris, to your earlier point on the contextual history, right? The dynamics for when we chartered this group has changed somewhat just because the original players have also shifted. Um, the struggle with the use cases even then is why I'm telling you the changes. Even with the use cases, we were asking those participants to go and reach out to their customer base so that we could capture those pain points. But I'm seeing the industry change very quickly, which is why I'm saying even some of the data may be stale now. Okay. Yeah. Okay. With that... and I do want to say I'm not... I'm not dropping Chris off of a cliff, right? So it's not like I've gone away. I'm still here, just SCIM. No, no, you're not. Yeah. And we... we can help Chris. I mean, this isn't my first rodeo in re-chartering either. Um, but we do need to make sure that we get consensus from the group as well, Deb, right? That um this is a direction that we want to take. So I think before we close and move on, Aaron, um, we should solicit feedback on this draft. So if we get volunteers to review this, um, I can I can get somebody from Cisco to review it. If we can get others to review would be good. Um, just so we could close on some of the earlier items that led us to the original charter.
Aaron Parecki: Yeah, and I saw a couple of comments in the chat that look generally positive, so if any of those folks want to volunteer to review it'd be great. Uh, and then we can keep this moving. Yeah. Thanks, Pam. Okay, we've got at least two reviewers. So we can move on. Okay, great. Pam, is this you presenting?
Pamela Dingle: Primarily, I think Ishmael's going to join in and some of the others may too.
Aaron Parecki: Okay, would you like the slide control?
Pamela Dingle: I would like the slide control, please. Great. Um, I'm not going to start a timer because this is the last topic and we have until the... we have the full hour, so the time is yours.
Pamela Dingle: Excellent. I will start with a historical overview of what SCIM is. I'm just kidding. Um, I think I'm sure everyone would like to get out of that room or get out of their seat, so we'll try and be very responsible here. Okay, so um let's let's actually start with history, but a concise history. At the last plenary, there were two different drafts that had the agentic title. They were, I'd like to think of them as before their time, one by Mark Wall and one by Maisie Abby, who I think is here. Um, they um they had similar approaches but different definitions and and depths to them. And so it was agreed on the mailing list that we would try to combine forces. So a group has been meeting which includes both of the the authors of those specs as well as myself, Danny Zollner, Ishmael from DeFacto, we have been meeting on this. And so we want to share with you what the progress is, knowing that there's still a lot outstanding and we want to make sure that we use the mailing list to really dig into detail. And if any of that peanut gallery wants to weigh in, go for it. All right, so here's what we have defined as goals for an agentic extension to SCIM, and I say that as the broadest way to describe it. Um, we do believe that we are looking for the RESTful standardized endpoint that SCIM is. We um are looking for an inclusive description of agent, not a an exclusive definition. We need it to work in a much broader and very fast-moving world. So it needs to be compatible with many different parts of the landscape. Um, and as we said, like we don't even know what's going to evolve next. It's guaranteed that something will. Um, and specifically we need this to work across all sorts of implementations, whether they are um in themselves generative, whether they are um, you know, workloads and workload identity, um, so it has to be something that many, many types of company can pick up and use and that can support a lot of objects.
Um, so you can see, I mean, we have some general ideas of what we think can happen. We also know what we don't think should happen. We are not looking to be a competitive specification to OAUTH client self-registration specifications that exist already, including DCR or dynamic client registration, or the client ID metadata document specification. Those are the two acronyms listed here. We um believe that there are enough other lifecycle activities needed that we don't have to um really include self-registration as one of our use cases. Does anyone, any of our peanut gallery want to add anything else? Okay, we'll all keep going. Oh, Justin's in the queue. Oh good.
Justin Richer: You say oh good, but I haven't said anything yet. Um, the uh the question that I have here, because this has kind of come up uh in my space recently, is uh is it would it be in scope uh to have relationships between agents and people, because SCIM fundamentally does most of its work around people? Uh, relationships between agents and people actually be represented here. So, the the runner of an agent is one thing, but also an agent registering for a human, uh or creating an account that a human would later be able to use or something like that. Is any of that part of this process um or sort of those kinds of weird combinatorial use cases uh part of the thinking here?
Pamela Dingle: So I think it has to be, and the the hilarious thing is that that became much clearer to me in the last two hours based on a number of discussions, um including Danny's presentation on the group members. Um, so in fact if we move to the context and use case, um the piece we don't have in here that that is really the epiphany is, yes, the intersection with /Users um is incredibly important. If agents need to request access to a group in order to get um access to a resource, then and that group is managed via SCIM, then we should uh you know implementers will need to be able to say, "Here's the 100 members of this group, and 10 of them are agents and 90 of them are are humans." So I think the answer is absolutely yes and um that the use cases are going to become more clear. But if you have specific use cases... you talked about a couple just there that um that I hadn't even thought of, I don't know about the rest of the group.
Ishmael: Yeah, one one relationship we have explicitly talked about is the relationship of a group or user to an agent as the owner of that agent, um that as one example, Justin. Right. And yeah, it I mean agents may have managers, in theory. I mean a digital coworker scenario, um the other one is the computer using agent scenario where a computer is manipulating um, you know, digital assets as if they were a human. I think all of these need to be addressed. Um, the question is whether beyond that, um this type of interface would lend itself to an agentic control plane or not. And this is where we had a lot of really interesting discussions in the group, and we'll go through some of the use cases here and talk through them. Um, one of the... I think it's actually the next slide here. Let me just make sure. Uh, I think we've got most of this. One of the one of the big questions um was discussed was um how do you know what kind of agent uh you're looking at and whether that agent can speak a specific language? So this third bullet on agentic protocol discoverability, uh we thought might be really important. So if you don't know if that agent um can use A2A, or if you don't know they can use MCP, then uh perhaps this is a way to get access for example to the agent card or to the data in the agent card in a way that's specific, that you can ask uh and not know um whether it's a human or a an agent you're talking about until you ask the question and get the answer.
Keep going. So if we look at the similarities to what happens today in the SCIM interface, um lots of things are similar. It's still an object model. Um, and you know we're using agent as we said before in a very broad sense. So um you know what do agents and users have in common? Well, they do have a lifecycle, you have to perform the CRUD operations. Uh, and most of in my at least in my experience most of the conversation happening right now is about connecting the agents, not about what happens next. And so that's why SCIM could come in to do this, um because we we aren't yet thinking about what happens when you need to disable that agent. Um, or I'm sure some people are, but um this is what we're talking about. So um when you think about the similarities, agents can be members of groups, agents may have to go through approval workflows. Excuse me, I'm sorry. talked too much and now my throat is scratchy. trying to recover here. So, uh so those are the things we think have a direct correlation. Beyond that, we think that there might be more. Um, we think there could be intersections with understanding um the status of an agent: has an agent been approved, um is an agent available but not yet instantiated? Uh, you know that so that question of publishing of agents may or may not be something that's a bridge too far in this spec. Um, anyone else, any of y'all want to... okay.
Ishmael: Yeah, one thing I'll add Pam that I typed out in the chat was that just in general as a group we've been aligning around kind of less is more, um that like the there's a risk to add more and more features to the initial specification.
Pamela Dingle: Yeah, absolutely. Um, and Ishmael, is Ishmael on online? Not sure if Ishmael... he said that he... oh, there we go.
Aaron Parecki: Oh, I see Ishmael's using the light client. Are you in the room or just in the wrong... you can't unmute in the light client, I think. So make sure you join the full one.
Pamela Dingle: All right, well in that case, Ishmael, if you want to just drop and join with the full client, I will skip this and then you can come back and talk to it. Um, oh, well, that's that's pretty well what we have as far as next steps. So, you know we can talk about the SPIFFE thing. I do think it's really important. Um, what we want to do is do this on the mailing list because we want as wide a contribution as possible. Nobody wants to make this thing as an as an academic exercise. Um, but because of, you know, the use cases that really are intersectional with um with existing SCIM implementations, I think that something will need to be done. It's just a question of how how wild we go with it. And I see Paul's comment um about us to go in and present I think at the in the OpenID Foundation, and if if that's what you're saying, then I think we'd be all for that. Um, we do have some additional discussion points so there are, you know so there are other points about MCP and A2A that we can talk through as well, they are in the deck. Um, but we'll just wait for a second for Ishmael to come back. And then hopefully, you know, hopefully folks can apply a good critical lens to this. Um, like we said, you know, I don't I don't think um we want to be super prescriptive about what an agent is here. What we want to do is allow for CRUD operations on... you know, and whatever definitions of metadata can be standardized about any kind of agent.
Ishmael: Hey, thanks Pam. Sorry about that. Uh, so one of the things that we are looking at in this specification is also support for SPIFFE provisioning. Um, SPIFFE is widely adopted workload identity system and we are increasingly seeing it used as a or in AI agent scenarios. Um, and on top of that, the relationship between SPIFFE and OAUTH is currently being formalized. I believe there's the OAUTH SPIFFE specification which is in progress in the OAUTH working group right now. So now that SPIFFE we know that it does an amazing job at the runtime: attestation, credential issuance, lifecycle management at the endpoint level, but there is a gap, and that gap is in terms of how um the workload identity metadata or the agent's metadata gets provisioned between systems, um, and and that is undefined um today. So the identity entry that SPIFFE attests against, who creates it, how does it get there, um um how does it get cross-domains... there's no specification for that today. So we're looking potentially to add that as part of this proposal. Um, and I also think this would be the real test to what was said before in terms of the extensibility uh beyond OAUTH, because SPIFFE has different works differently. So the SCIM would provision just the registration, but the the credentials of SPIFFE would be obtained separately. Um, so the use cases are there on the slide, uh but the overarching uh goal is quite simple here: one provisioning pipeline. So today if you're managing users, SPIFFE workloads, or agents, they're all done through separate systems, separate tools. Uh, we want or we would like that uh to have one SCIM integrated pipeline through the same IDP um that is currently already used as part of your infrastructure. Back to you, Pam.
Pamela Dingle: Perfect. Um, so I will put it back on the call to action. We can talk through the additional discussion, um if we have time and if there's interest. Um, but I would love to just have folks weigh in on whether this makes sense. Does it pass the spit test? I also don't really know what a spit test is, but I'm pretty sure I don't want to know. Um, I will say there are a couple of issues that we know are going to be sticky already. Um, one of them is durability. So there is a natural latency to existing SCIM implementations. Um, you know part of the part of why we had to do pagination was because of that, um you know because of the potential chance that something gets created or deleted before a given SCIM call can be executed on. So so the question of very, very ephemeral agentic presences or instantiations, that's, you know, whether those make sense to use the SCIM interface for, we don't know. The other one of course is the classic OAUTH class versus instance question. Um, you know, is what you need to represent via SCIM if it's an agent, the instantiation of the agent, the in, you know, the unique in time and space instantiation of the agent, or is it the class of agent that could be instantiated? I think that one is another you know, rough question, both for OAUTH and SCIM, in fact. So those are the things we're thinking about. Um, I won't take anyone's time after this, but we are very open for anyone who would like to participate or contribute or, um, and we will be bringing a draft for everyone to consider here. And we appreciate your time.
Bjorn: Uh, just as I'm listening to this, it's hard for me to differentiate between what's an agent and what's a work instance and a workload. So Pam, as you you guys are drafting your you're creating your draft, I think it's very crucial to define terms and what what we mean by an agent or in what what the use case is for for this effort as it applies to SCIM. That's all.
Pamela Dingle: Yeah, that makes great sense. And part of that is what use case... I mean, the use cases in theory should drive those definitions as well. Um, if if we are only talking about um agentic presences as equivalents to user presences for the purpose of governance and workflow and consumption of resources, that might be one thing. If we are looking at a much broader SPIFFE-based representation, I think that changes. So trying to find something um that we can either refer to or define you're right, will be important. Thank you. Any thoughts from our AD contingent?
Chris: Uh, from from the cheap seats and the newbie, um, I'm super excited. I want to kind of see what you guys are bringing to the table. I so you're hitting on a bunch of areas that I think everybody knows are really topical at the moment, right? I mean, these are questions that seemingly are unanswered and folks are asking the IETF, "What are we going to do here?" It'll be a question of how fast we can react on that, but I think you guys are feeling that pressure in your day jobs. So I don't need to do anything about that per se. Um, looking at your charter, you know, quick read versus, you know, kind of this conversation, um, this is kind of exciting to me, you know, obviously this would require some charter work. I would like to understand how it kind of all... you've mentioned SPIFFE, I haven't heard Whimsy, I don't know if that comes into play, I've heard OAUTH, um, I don't have all that put together yet. Maybe Deb has a better handle on that than I do, uh but I mean this is all positive for me. I want to help, um, but I'm I'm not an expert in this area. I'm looking for you guys to kind of um kind of at least have some notional path of what your way forward is. So, I mean, I want to help that happen.
Nancy Cam-Winget: Um, what he said. I told you this was going to be a trade up. Perfect, thank you.
Yaroslav: Uh, I just wanted to point out that there is quite a number of proposals right now being discussed about agentic AI discovery: DNS-based, new exciting protocol-based. Um, so yeah, we at some point I think we need to decide what is the IETF rough consensus way forward for this.
Deb: Don't go away, Yaroslav. Do you, um, how much of this stuff is related to the paper that you guys wrote? The draft that you have?
Yaroslav: Uh, we don't really go into discovery intentionally because we see that as a net-new problem. But when it comes to the way you do agentic AI identifiers, authentication, authorization, discovery is kind of orthogonal for the most part. So I don't see a choice between, let's say, using SCIM or DNS or something else is defining the rest of the framework building blocks. And I see Peter is in the queue, so Peter, maybe you want to jump in.
Deb: So I do think it's exciting to be able to handle a lot of this with protocols and work that we already have in flight and in process, right? So to not always required to invent something new for something like this.
Yaroslav: Absolutely. Though one thing I personally, and I haven't spent as much time as I probably should thinking about if SCIM is the right way for agentic AI discovery, but I mean some people anticipate that AI agents will be spawned dynamically, live very shortly in certain environments, so we might have a very robust mechanisms to signal that. And today in my experience, SCIM is typically used for more long-lived things like users and groups and things that that live longer typically than seconds or milliseconds.
Ishmael: So, I I can just respond to that quickly. I think we absolutely agree. Um, and I think the other piece is schema, right? I don't think uh I think lots of different places will be writing schema, and if that we can all harmonize on that schema, everyone is happier. You know, I don't think um I don't think we would want to invent our own special sauce here. And so yeah, I think making everything uh agree on the types of metadata to be sent and then just using different transport mechanisms to achieve certain goals would be a you know the best outcome.
Yaroslav: Peter, would you like to add something to what I said or is it something completely different?
Peter: Yeah, so this is actually something, um at least as I got an echo, so I'm going to stand back from my mic. Um, I think this is I think there is in terms of the AI authentication and authorization draft, um there is a section that talks or also looks at provisioning, and maybe there is sort of I've been thinking that there might be a space there specifically to talk about SCIM. Currently the spec doesn't talk basically talks about like runtime provisioning, um you know, but there is sort of this other component around, okay, where does all that metadata come from for that attestation management, the identifiers, and so on? And so I think there's kind of a a nice little slot where SCIM can fit into. Um, I think one of the premises of the paper or of the draft that we wrote is we're really modeling agents as workloads, and so um I think in that sense and that's been a very helpful construct, right? Because the moment we you think about a workload, suddenly there's all these tools that you have that you can use already. And maybe that's something, you know, as Pam as you and Ishmael and others are working on this, is to just sort of keep sort of that mapping in mind so that it's going to be easier to be compatible with with that authentication and authorization draft.
Yaroslav: Uh, one one thing that I would add to that is uh provisioning, the way it applies to workloads, is typically quite different than provisioning that applies to users. Uh, provisioning workloads means that the workload is born and it is typically provisioned only once. And uh in terms of SCIM, I think again translating that to some somewhat like agentic AI language, it's really more about discovery. Um, so SCIM is not used to create well get users born, right? They're born typically in different ways. It's used more about again terminology's tricky, but it's more about discovery of users.
Pamela Dingle: Yeah, that's great. I mean, we need to tell the difference between I mean just having a definition of what a durable asset would be versus an I call that an ephemeral asset, right? It's born, it dies, it lives once, um it it may be rubber-stamped from a some kind of or cookie-cuttered, and maybe it's the cookie cutter that has to be the subject of the approval workflows or governance. Um, but I mean, I think we just don't know what we don't know, uh but we're open to learn.
Peter: Uh an observation maybe on that, Pam, like I think even ephemeral workloads, there is persistent data that's associated with that, right? You mentioned schema, things like that. Somewhere you have to store all these things around, okay, how am I going to construct the identifier? What's my policies around this thing, and so on. And so maybe that's a space and maybe that's just a conversation that we need to continue having.
Bjorn: Uh, I just quickly, um, I just adding I think the key here again is defining the use case, right? And that's where this work is going to fit into SCIM. Uh, also mentioning that there was a similar conversation in the OAUTH working group in our special scenario email kind of highlighting that instead of trying to find a solution, defining what the problem is and defining the use cases is a way of defining what the problem is they're trying to solve. That's all.
Pamela Dingle: That's a big ack on that one, absolutely.
Aaron Parecki: Thanks. Peter, I think you're... that's an old hand in the queue, right? Going to take that as a yes. Justin, go ahead.
Justin Richer: Yes, that is an old hand, sorry. Um, so yeah, just a um a really big plus to everything that people have been saying. I think one of the biggest challenges here for this is that we don't really as an industry have have a good handle about what we want an agent to be, or an agent entity to be. Because maybe it makes sense to provision a class of agents, like Pam was talking about, um maybe uh that's the thing that we want to explicitly push along and then we recognize them as part of subclasses or something like that. Um, I am skeptical, quite honestly, that SCIM is the right protocol to handle this kind of thing, but I think that it will be a valuable exercise to try and see what's there. Uh, because this is something that the identity industry as a whole is really, really struggling with right now. We don't know whether to treat this as software, as people, as something that is software that is like a people, uh we we really don't have it. Like, uh I've seen in the field implementations that are like remind me of uh Active Directory service accounts, which is a software that is pretending to be a people because that's all that Active Directory knows how to do. Um, and I've seen other systems where it gets treated closer to a workload. Um, because, oh, it's an autonomous uh system, it lives in a context and that's all well and good except that it's also on behalf acting on behalf of somebody eventually somewhere up the chain, and that's not even getting into some of the more complex scenarios where agents are creating other agents and agents have to call software that calls other software that calls the thing that actually needs to do the thing for the user, where the user's rights actually live is also somewhere else. It's it's saying it's turtles all the way down is doing a gross disservice to turtles. Um, I think that it is ultimately, like I said, a good experiment to try and see how this fits. Because having a schema, having a common language to talk about it, would be super, super useful. What I expect, though, is kind of the blind men and the elephant all over again. I think a lot of people are going to want different aspects of this and they're going to want it to look a different way and do a different thing. But I also don't think that we quite have all of those all of those perspectives written down yet. So yeah, roundabout way of saying, let's give it a shot and fail spectacularly.
Pamela Dingle: Very cool. So what I'm hearing actually is that before we bring a draft in, we should bring in some use cases. That seems like a couple of people have mentioned that. So we will I will take that back as feedback.
Aaron Parecki: Okay, Aaron, I think we can pass it back to you unless any of the other group members wanted to add any final points.
Nancy Cam-Winget: Yeah, uh Grace, do you want to uh come to the mic with what you dropped in chat?
Grace: Sure, um, so I'm Grace. Um, so yeah, what was pointed out in that last comment as well, like if you think about um what China Mobile is doing right now, um that they demonstrated, it's like, okay, we've got all these agents within our network and each agent is deployed by us China Mobile to do network optimization. And then it really does look like a workload and it is controlled centrally and so you're not like it's a very different situation whereas you've got this open claw model where it's like a person and China Mobile and China Mobile was looking at that. Like and they were saying and again these are more proprietary organizations, but they were saying, "Well, every person is going to have their little army of AIs." And in that case, if I as a human being deploy the AI to do a task on my behalf, you really have to think about like who's the owner of the AI, what did the AI have authority to do, and, you know, what task did I give it to do? And so then AI looks much more like individual decentralized identity. And so these are completely different ways of thinking about what an agent is, and I think that the architectures are going to have to look very different. Because in the case of a telecom using all of their own AI agents within them, you don't ask the question, "Oh, who's responsible for deploying this thing, and who has to pay for their airline ticket if the AI agent made a mistake?" It's just a complete different thought process.
Yaroslav: Um, I would respectfully disagree with that assessment. I don't think workloads are defined by centralized management. If I have a piece of software running on my laptop doing something, it's still a workload. Um, it still doesn't necessarily have human identity. I might have authorized that workload to act on my behalf uh to book me tickets or transfer money away or doing something, um but it's not it's not me. I think that is the fundamental difference between how we identify agents versus humans. Now again, the question of ownership, the question of um control, the question of human um bound human identity is again more of a question of authorization claims and delegation rather than the nature of identity of uh AI agents.
Aaron Parecki: Great. Well, uh sounds like we're wrapping up the discussion. I did only ask for 90 minutes for this meeting, but they gave us two hours instead, and it looks like we needed about 90 minutes, so that was well-timed. Um, any any other closing thoughts? Otherwise it sounds like we have a good list of next steps for various folks here. Uh, appreciate everybody who volunteered to review documents, um, so looking forward to seeing those on the list. If there's nothing else, I think we can call this early and give people back a little bit of extra time for the break. Sounds good. Thanks everybody and see you in the next session.