**Session Date/Time:** 24 Jul 2026 14:00

[00:00:04] **Nancy Cam-Winget**: August 15.

[00:00:06] **Aaron Parecki**: Or do you switch and do that?

[00:00:08] **Nancy Cam-Winget**: Yeah. No. I I just wanted to get the time so that when we set the timer. You know? Okay. You want me to close the door? I'll close the door. We need a notetaker.

[00:00:29] **Aaron Parecki**: Is somebody willing to take notes before we get started?

[00:00:34] **Nancy Cam-Winget**: Yeah.

[00:00:38] **Aaron Parecki**: Thank you, Pam.

[00:00:39] **Pam Dingle**: Thanks, Pam.

[00:00:44] **Aaron Parecki**: Welcome to the last session. The

[00:00:48] **Nancy Cam-Winget**: last session of the last day of

[00:00:50] **Aaron Parecki**: yeah. Yeah. Last night is yet? No. Wait. No. No. No. No.

[00:00:54] **Danny Zollner**: We've got a little more time.

[00:00:55] **Nancy Cam-Winget**: No. Let's not get too overzealous there.

[00:00:58] **Aaron Parecki**: Okay. Welcome to scim. We are your co chairs. Note the note well, please. I'm sure you've noted it well by this point in the the IETF week. This governs how we operate here at the IETF. Please behave professionally, and the rest is on the screen. We have a we have an agenda today, a couple of slight tweaks compared to this slide. They're posted on the on the data tracker, though. We're going to move the interop profile up, after use cases, and we're gonna save some time at the end to discuss rechartering. So other than that, we have a few drafts from, looks like a couple of local and a couple of remote presenters. So if you are remote and presenting, make please wear a headset. It helps everybody hear you better. And, if you are local, make sure you speak very closely to the microphone so the remote people can hear you.

[00:02:06] **Nancy Cam-Winget**: But I do not see Paulo.

[00:02:08] **Aaron Parecki**: That is a problem.

[00:02:11] **Nancy Cam-Winget**: So we can just skip.

[00:02:13] **Aaron Parecki**: So if we don't have Paulo here If we don't have Paulo on the line, then

[00:02:22] **Nancy Cam-Winget**: We can just start will

[00:02:23] **Aaron Parecki**: start and get by minutes in the back unless he shows up, and then he can jump in in the middle.

[00:02:31] **Nancy Cam-Winget**: So this is the end of agenda bashing. So I'm just gonna count to three, make sure everybody's okay with the agenda. We went through it quick. And thank you, Pam, for being the notetaker. I encourage those who can to also help Pam out. Going once, twice. Alright. So we will skip oh. Oh, I guess we forgot.

[00:03:00] **Aaron Parecki**: We should

[00:03:00] **Nancy Cam-Winget**: we should officially introduce our our now fully indoctrinated AD, Chris. Welcome.

[00:03:09] **Chris de Looze**: Hello. Thank you. Continue.

[00:03:13] **Nancy Cam-Winget**: Well, you you will get a dialogue with us at the end.

[00:03:16] **Chris de Looze**: Exactly.

[00:03:20] **Nancy Cam-Winget**: Okay. So with that, Danny

[00:03:23] **Danny Zollner**: Jenna is gonna present this one.

[00:03:25] **Aaron Parecki**: Jenna's gonna present. Alright.

[00:03:27] **Jenna**: And No. No. Danny, you're gonna present first. The

[00:03:30] **Nancy Cam-Winget**: Yeah. I thought Yeah. Sorry.

[00:03:32] **Danny Zollner**: I'm I'm going off the old slide.

[00:03:34] **Nancy Cam-Winget**: No. That's why pay attention. And

[00:03:40] **Aaron Parecki**: if you if you do have questions, make sure you're logged in to the MeetEcho platform and use the raise hand, and we will manage the queue that way, both online and remote.

[00:03:51] **Pam Dingle**: Introduce yourself so they're describing this.

[00:03:59] **Aaron Parecki**: Okay. And we give the slides clicker control.

[00:04:02] **Nancy Cam-Winget**: Let me do the timer. Fifteen minutes. Ready?

[00:04:13] **Danny Zollner**: Yep. Okay. Good to go.

[00:04:15] **Aaron Parecki**: You're good

[00:04:15] **Nancy Cam-Winget**: to go.

[00:04:16] **Danny Zollner**: Okay. Hi, everybody. Vienna and remote. For the first of quite a few times today, I'm gonna be presenting on a thing. So first up, talking about a draft that I wrote earlier this year. I presented on it a bit at the last IETF in Brisbane. So this is a, we'll call it, a protocol interoperability profile for SCIM. So I guess well, it's like a little bit of, like, recap slash just what is it for anybody who hasn't seen the draft already. So, okay, cool. Have a nice confidence monitor right there. So is SCIM is really powerful in a lot of ways, but it's also really complicated, and that makes it hard to implement, especially interoperably. And there's certain areas that are, like, the most painful there, among them being the incredible power packed within the SCIM patch functionality because there's a couple of spots where you can do, like, filter and, like, logic expressions, and it's really, really hard to write good code that can handle all the possibilities. And that creates interoperability problems. So I've written a draft to try and help with that. It doesn't exclusively focus on patch, but, a lot of the focus is on bringing the, I guess, the realm of possibility of possible, like, some tactical variations of how a certain action is requested down from roughly infinity to, like, two. And then it also spends some of the time in the draft either, I guess, establishing new normative requirements that are usually somewhere between interoperability, maybe a little bit of, like, security motivation behind why they're being added. And there's also some content in there that is, stuff that is actually already normatively required in, like, SCIM two point o, if you look at 76, 43, and 44. But it's, sometimes a little hard to realize that it's, you know, that whatever the thing is is required because you don't actually realize it's required unless you, you know, you might have to, like, look at one line in, let's say, section four and another, you know, two paragraphs in section six. And if you read them all together and, you know, put the context together, you realize, oh, actually, this thing either, you know, is or is not allowed or possible, but it it's more interoperability problems. Click. So in the draft, it, you know, has a service provider config addition just an actually it says it's like a self attestation that the service writer can say, I, you know, have I attest that I have, as the service writer, am compliant with this interoperability profile. This slide here talks about things like case sensitivity and uniqueness, which for the most part fall under that realm of things that are actually already required in SCIM, but people mess up a lot when implementing. So it, you know, takes all the stuff and puts it together neatly. And, yeah, the slides are available for everybody to download and read. I'm not gonna, read them off to you. One of the big things with the logic, I guess, the the other, like, restricted requirements around patch is it, we'll call it, I guess, prohibits using, what we can refer to as a pathless patch, which if you see in the, like, top right box on the slide, that shows the syntax as essentially, you know, opera place, and then it just it skips the path Actually, it would normally have the name of the attribute that you're modifying. And instead, you get you have, like, a key value pair thing going on where you can, you know, potentially patch, add, or replace or remove, I guess not remove. Just the first two. A whole bunch of attributes at once. But it creates more, like, I don't know, like problems and, you know, parsing the JSON and whatnot. And I it's a thing that I've seen cause a whole lot of interoperability issues. I won't, like, read off the full, you know, bit of this table, but it yeah. The essentially, for any given scenario, let's say, if you're, either adding or replacing, an attribute to, let's say, a simple so, you know, something like a a string, single valued attribute or simple multi valued or a complex, which, you know, when schema is like a it's a JSON object with sub attributes. I can say either either a single or a complex multi valued attribute or single or multi valued complex. All the right words in the wrong order. The interoperability profile, prescribes specific syntaxes to be used. I'm reasonably sure that I've achieved a 100% coverage in, like, possible scenarios of like, essentially, given thing that you're trying to do should have, like, a bucket that it falls into. If anybody reads through the rules that I've written on patch and sees gaps, let me know, please. There's some rules around requiring things like, you know, pagination, declaring what your, you know, maximum page size is for pagination through the service provider config endpoint, and what the sort of minimum bar for filtering support is as well, has requirements, that you must support, certain endpoints. And, you know, some some of the stuff that's also on their side is, again, either things that are already prescribed in SCIM, but just not very clear, or there there are new requirements, to solve frequent problems. And then, yeah, there's requirements for, you must expose the, we call them the discovery endpoints, service rider config, schemas, resource types. And then, the interoperability profile also, I guess yeah. This is one of those things where it's already technically, like, prohibited in SCIM, but we've so I I've seen it done or I've seen it implemented incorrectly where, yeah, if you, like, do a patch to active the active attribute on user, set it to false, they're like, oh, well, we don't really have a disabled state. So we're just gonna treat that like an HTTP delete instead, and that creates, like, really weird kinda experiences. It's like, if you don't support that, you should just return an error and make them send a delete. So it's one of those things like calls out. I think that's already not allowed. So, yeah, there's two real questions for the working group, and we may just need to do these on the mailing list if not enough people have, let's say, read the draft. But the first question would be so as best as I can see it, I I think this sort of, like, essentially, you know, it's like profiling implementation of the protocol of SCIM. I believe it falls within the scope of the working group's charter. I'd like to know if anybody, you know, chairs or anyone else, disagrees. And then if they don't disagree or sort of, like, if they do what they think we should be charter, I don't know, are there any topics that should be either treated as in scope or, you know, things that should be out of scope for this sort of document? And I'll, I guess, pause before going to the second question. Yeah. So I guess if anybody has any feedback, thoughts, comments on the first question.

[00:12:58] **Pam Dingle**: Can I just put my hand up and not go in the queue? Is the last thing to

[00:13:01] **Danny Zollner**: Go for it.

[00:13:02] **Nancy Cam-Winget**: Just go for it. Just so I don't have to

[00:13:08] **Pam Dingle**: Hey. Pam Dingle from Microsoft. I think it's pretty clearly in scope. I think sorry. I took it off the stand, now it won't stay on. Oh, that looks bad. Excuse us. Alright. Technical difficulties. Alright. Nobody touched the mic stand. That's oh, there we go. Thank you. I think it's definitely in scope. I think the question is, I'm assuming that everything in there I mean, I looked through it, but, I mean, it's full of mostly musts. Right? Because why would you Yeah. Adopt this interoperability profile if you're not going to be very opinionated? So I I you know, the only thing I could think of is if it should get split. But, again, I think we could adopt it and make that split if we need to, and I I certainly would not call it out of scope.

[00:13:59] **Danny Zollner**: Thank you.

[00:14:00] **Nancy Cam-Winget**: Well, okay. So speaking as chair, I'm looking at the at the charter. So we could potentially call it in scope if we look at the goals. The goals in the charter says it's to incorporate implementation experience, errata, and interoperability feedback. So under those, I think it would be okay for us to to get to that adoption, but we can't do an adoption call until we get comments and feedback. Right.

[00:14:32] **Danny Zollner**: Yeah. There's been, I think, maybe, like, two reviews on the mailing list since I published it, which is I don't think is enough. But yeah. I think if you sort of tilt your head as you're looking at the charter, there's maybe also the there there's some lines about, like I I can't remember if it's, like, updating or something 76, 43, and 44, and it's you could sort of be like, okay. Yeah. This sorta does that in a roundabout way. But yeah, so I guess to the second question then, I'd ask, are there any changes that the working group would want to see to this happen in this draft before a call for adoption. Not that their draft wouldn't obviously be subject to as much, like, future, you know, updating and iterating as needed.

[00:15:28] **Nancy Cam-Winget**: Yeah. I mean, the process is you're bringing the draft. We discuss it. There's feedback, and then you ask the chairs to do a call for adoption, right, once we deem that it's in charter, which we have. Any other comments, feedback? So are you requesting that eventually you'd like to see this adopted?

[00:16:02] **Danny Zollner**: Yes. Okay.

[00:16:03] **Nancy Cam-Winget**: So for that, we need to request feedback. We could ask for volunteers. So do we have any volunteers? So we did last time, and I did have somebody at Cisco review it, not as an adoption, but in the general trend. And they said that it was helpful from an interoperability standpoint. Sorry. Not speaking as an individual. Okay. Hat chair back on. Mike Kaiser, did you mean to put yourself on the queue?

[00:16:40] **Mike Kaiser**: Yeah. I mean, I'm happy to to review it and give feedback.

[00:16:43] **Nancy Cam-Winget**: Okay. We need at least three reviewers. Your name? Did you get that, Pam? Yep. Thanks.

[00:16:54] **Pam Dingle**: Thank you.

[00:16:57] **Nancy Cam-Winget**: Alright. So we've got Mike Kaiser, Matt. Okay.

[00:17:05] **Danny Zollner**: Max Gerber.

[00:17:07] **Nancy Cam-Winget**: Oh, Max. I think

[00:17:09] **Aaron Parecki**: think Pam's got it in the notes.

[00:17:11] **Nancy Cam-Winget**: Yeah. Okay.

[00:17:14] **Danny Zollner**: Cool. Should we try to

[00:17:18] **Nancy Cam-Winget**: out of time.

[00:17:18] **Aaron Parecki**: Oh, yes. You are out of time. But we, should we try to pick a deadline to do this before November? Can people commit to doing this before the next meeting? Yes. So review, post notes to the mailing list, and we will take it from there.

[00:17:39] **Nancy Cam-Winget**: Okay. Okay. We're running out of time, and we don't have enough. I just Yeah. We're we're

[00:17:44] **Aaron Parecki**: good. That was the

[00:17:45] **Nancy Cam-Winget**: No. We don't. I did the math. We only have ninety minutes.

[00:17:49] **Danny Zollner**: K.

[00:17:50] **Aaron Parecki**: We're we're we're we're

[00:17:52] **Nancy Cam-Winget**: So we if we wanna have the rechartering discussion, we need to move on. Yep.

[00:17:57] **Aaron Parecki**: That's great. Are you getting like, next to Danny?

[00:17:59] **Nancy Cam-Winget**: No. We're I thought we were doing Jen

[00:18:02] **Danny Zollner**: Jen. Okay.

[00:18:03] **Nancy Cam-Winget**: On Etsy. Okay. So, Jen? Hello. Hey. Welcome.

[00:18:10] **Jenna**: Hi, everyone. So oh, good. I have slide control. It's my first time presenting remotely, so bear with me. I'm gonna be sharing about the IPSIE SCIM 2.0 profile, which is a conformance profile for SCIM two dot o. And IPSIE stands for the Interoperable Profile for Secure Identity in the Enterprise. And this is done kind of in collaboration with the OpenID Foundation IPSIE working group where different protocols like SCIM, SAML, OIDC are profiled for, security assurance. So I'll chat for about five minutes on the profile, and I'm gonna pass it over to Danny who kinda can lead some discussion in the room, which I think will be easier. So IPSIE really is broken down into three assurance levels, a l one, a l two, a l three, a l being account life cycle. And it's meant to solve the problem of how do we assure that, different SCIM IDPs and vendors adhere to a certain level of security that is really, like, required in, any interoperable communication. Oh, so I'll briefly mention that, a l one is all about deprovisioning when you're suspending, deleting, archiving users. AL two builds upon AL one and, is all about syncing users and, also membership, and then AL three about roles and entitlement. That's still in a bit of a draft mode on our end. So I also I already mentioned kind of what IPSIE solves. It's Interop plus security. And in this slide so the Danny just presented on the interoperability profile. So IPSIE kind of requires the interoperability profiles plus some opinionated prerequisites on things like authentication and different user group operations that you must support. These just kind of describe the provision deprovisioning requirements and the group management requirements. I don't need to go into this. If you've read the draft, you would have a bit of an idea. And then the shared pre reqs, which I think is the interesting part, we require o f two client credentials and JAT client auth for these endpoints. And then, there's sub rate limiting and scale requirements. And lastly, error handling and auditing. So things like you must use the SCIM error format on failures, and you have to log all creates, deletes, and modifications. So I guess that was quick. Hopefully, that gives you all an idea on the SCIM it the IPSIE profile. But I will pass it off, I guess, to Danny to see first of all, we have, like, a couple next step questions whether this is in scope for the charter, or for the group and, yeah, whether there are any questions about the the profile itself.

[00:22:04] **Aaron Parecki**: Thank you. We have six and a half minutes left for this discussion, so it should be plenty of time.

[00:22:17] **Danny Zollner**: Yeah. Hi. It's me again, Danny. So, yeah, I think the real like, the the only question at this point is so the there is an IPSIE working group within the OpenID Foundation, which is where, I guess, the, like, larger IPSIE motion is taking place. And the current of I guess, opinion of the IPSIE working group is to try to put any of these, we'll call them, like, conformance profiles to submit them into the standards bodies that the whatever, like, protocol or standard is being profiled already exist in. So SCIM is part of the IETF, so submit it here. And I don't like, SAML has an interesting problem, but that's not my problem. But the question then being, I guess, in particular to the chairs, do you feel that this sort of document is in scope for the working group or would or potentially should I guess, should be in scope maybe if we're considering a recharter?

[00:23:32] **Nancy Cam-Winget**: Or charter as is written speaks to interoperability, conformance against one, not quite. So we would have to recharter if we wanted to adopt that part of it. So I guess having looked at full pun intended skimming both drafts, it does get to the question of for the interoperability pieces that you have in the Ipsy draft, can that be merged with the interoperability draft? And then we can discuss the separability of the conformance compliance.

[00:24:10] **Danny Zollner**: So the I guess, like, technical answer is yes. The the two could be merged. It was a very intentional decision to write them as two separate drafts, because the, so, like, the IPSIE SCIM Account Lifecycle draft, starts imposing specific requirements on your implementation of users, like the user's resource, you know, what, what the minimum set of attributes are that must be implemented. And the protocol interoperability profile, is resource agnostic. So regardless of whether it's a user, a group, a device, an agent, you know, the it's protocol level almost purely.

[00:24:53] **Aaron Parecki**: We have some people in the queue. Let's give

[00:24:55] **Nancy Cam-Winget**: Let's let's give the people in the queue.

[00:24:57] **Pam Dingle**: Maybe you could do Jeff first, and can you just summarize? So what what was the total

[00:25:01] **Pam Dingle**: of is it or is it not in It just

[00:25:04] **Justin Richer**: the chart.

[00:25:04] **Aaron Parecki**: It sounds to me like the interoperability profile previously presented is in scope. The specifics of the IPSIE vocabulary requirements are probably not in scope, And it is not really not really fair to say that those should be merged into one document because they're kind of fall in different families of things.

[00:25:27] **Danny Zollner**: Yeah. Like, as, I guess, the author of the protocol interop document and one of the authors of the IPSIE, like, conformance document, I would prefer that they were not merged together.

[00:25:38] **Nancy Cam-Winget**: Well, that's why I was saying you could separate. Right. Yeah. Okay. So we

[00:25:43] **Aaron Parecki**: So Jeff first, while Pam takes notes, then we swap.

[00:25:46] **Danny Zollner**: You're on mute, it looks like.

[00:25:54] **Jeff**: Definitely. So so maybe I missed it. Sorry. I joined late. But, usually, like, the the certification part is not an activity of ITF. It was originally an activity of open IT foundation. So so is is the work still done over there too? And if so, how does the synchronization between the the two STO will happen from to set?

[00:26:23] **Danny Zollner**: I only half caught that question.

[00:26:29] **Aaron Parecki**: Sorry. I I think he was asking how does how does how do the two groups stay in sync and isn't OpenID Foundation where the certification and conformance is done normally.

[00:26:39] **Nancy Cam-Winget**: Yeah. I interpret it as, you know, why is some of the work being brought here when there's work being done in the OpenID Foundation? That was my interpretation. But, Jeff, you you should clarify.

[00:26:52] **Aaron Parecki**: He says in chat. Yes. That was the question.

[00:26:54] **Jeff**: Yeah. That was the question. Thank you, Alan. Thank you.

[00:26:57] **Danny Zollner**: Bye. So So with the question being, why is some of the work being done here in the working group and some of it being done in the OpenID Foundation IPSIE working group? The the way that, I guess, I've been looking at it is the skim working group is more about, I will call it, like, how the protocol or how, like, you know, like, the the technical implementation. Let's say, what resources are defined, what attributes, and, you know, the properties of those attributes versus the, like, IPSIE side of it is more, like, conformance compliance. It's not quite like, I guess, is maybe not the right word, but it's, like, in the same family of vibes as circulatory. And so when when it starts just imposing these, like, requirements that are more about, like, let's say, business needs or whatever for, you know, the con like, consumers of applications that have SCIM or whatever, it didn't feel like the SCIM working group and the ITF was the right place for that.

[00:28:14] **Aaron Parecki**: Let's make sure Pam has a chance to

[00:28:22] **Nancy Cam-Winget**: Somebody needs to help take notes.

[00:28:24] **Pam Dingle**: Yes. Somebody was chipping in, so thank you to whoever that is. So mine is a different question, but I I think no matter what, you would be bringing those requirements back and still even if the work is done in IPSIE, you would still be presenting like this at future plenaries. Right?

[00:28:40] **Danny Zollner**: Yeah. I think if not just for awareness.

[00:28:42] **Pam Dingle**: Yeah. Okay. So, Jen, do you still have the slides? Are the slides still available?

[00:28:49] **Jenna**: Yeah.

[00:28:49] **Pam Dingle**: If if not, that's okay. I did wanna point out, yeah, in on this shared re prerequisite slide, the must enforce is OAuth two point o client credentials and giant and Jot client client auth. So that I mean, I feel like things are shifting as we speak. The best practice there is not yet set. So and that there could be multiple of them. To me, if it's a conformance type of testing, then what you know, are you willing to dictate one of three? Or is does it have to be this one or you're not IPSIE compliant? Because I I think that this is gonna be a problem, right, for us to be super opinionated about this now when people might be using a whole bunch of other types of, you know, like, if transaction tokens, for example, is how, all of the other resources are being instrumented and this requires client credential, then what happens?

[00:29:53] **Danny Zollner**: Yes. I'll I'll I'll take that. Very open to pretty much any requirement in the existing, like, IPSIE SCIM draft, being, like, I don't know what, like, molded or changed in shape to meet what makes sense. This is a sort of a a first shot of at least getting opinions on paper even if ultimately, you know, once more people take a look, we decide to, you know, either go narrower or go wider in, like, how permissive things are.

[00:30:24] **Nancy Cam-Winget**: Can I

[00:30:24] **Danny Zollner**: follow-up? Yes. Go ahead and follow-up.

[00:30:27] **Pam Dingle**: Yeah. I I mean, I guess the question is, is it instantly obsolete? No matter what you write, is it instantly obsolete? And is there a way to abstract it so that you don't have to worry about that?

[00:30:42] **Danny Zollner**: Think there's potentially a way to abstract it. I'm not familiar enough with the OpenID foundation, like, what standards life cycle to know if it's just, you know, put a new revision out every year or two or, like, what I'm sure there's a a way to engineer everything to be able to avoid that. But I don't The the, like, the intent with that specific requirement was to stop the need for a shared secret between like, from we'll call it the the same service provider, whatever, like, the downstream app, you know, is having to be, like, manually carried back to the whatever the SCIM client is. So it's, you know, identity provider, identity governance solution, which, you know, you're taking the the gold bars, whatever, out of the bank vault and moving them. Like, that's when the heist happens. And so the client credentials plus JotClientOff lets you just you know, the the an STS or whatever with like, on the same side as the SCIM client can go and mint assigned JWT, and there's never any exchange of secrets. Because, like, right now, I'd say 95% plus of implementations are using, you know, either, like, just a static API key or, you know, the like, the best case scenario right now generally is client credentials with OAuth, but it's using a client secret, which is it's, like, not quite as bad as a static API key, but it's also still has that same risk of somebody getting it and wreaking havoc. And all these, like, SCIM integrations are, like, god mode level permissions.

[00:32:22] **Aaron Parecki**: So we need to wrap this up and move on to the next topic. Summary, it sounds to me like I'm not hearing a lot of confidence that this is the right place for this type of the this part of the profile. So that that's what I'm hearing. Yeah.

[00:32:40] **Nancy Cam-Winget**: I mean, I I was trying to put myself on the queue to say, chair head off. This is not sounding like it's in charter or in scope for SCIM at the moment, meaning that it's not quite mature yet, especially given the feedback, Pam, that you're providing. With chair head on, we do need to move on. That's the guidance for now. But, I mean, chair head on, still encourage everybody who is interested to review and provide feedback. Right.

[00:33:11] **Danny Zollner**: Yep.

[00:33:11] **Nancy Cam-Winget**: Thanks, Danny. Okay. So, Paulo, I see you joined. Did you want five minutes to give an update on the use cases?

[00:33:25] **Paulo**: Yep. Yep. It's if possible.

[00:33:28] **Nancy Cam-Winget**: Yep. You got the call?

[00:33:31] **Paulo**: I'm sorry. I had some problems with connecting, so it took me a little bit longer. Okay. So can we go to the next slide? And it should be only five. So we had a great feedback from Danny. Unfortunately, we didn't have time to review and to have the conversation. So it was a very extensive from him, and we need to have a conversation to discuss a couple of topics. But one important topic, and this it's already built on top of what we did before, the feedback that we had from Eliot Lear. If you remember, and we have this slide almost for the last I don't want to say five years, but it's at least three or four years that we have been discussing this. In the beginning, we started with data models, and we had the resource object and resource attribute. That was what we consider the two things that are the most important component there. And Eliot Lear provide the feedback that I review, and I don't know if it was in IETF 114 or 115. Not sure that I review saying that, okay. So they Eliot provided the feedback on calling it scheme resource object. Because from a readability perspective of the document, it was easier to differentiate from the resource creator, resource operator, so on, so on, so on. So at that point, we took the decision to change it to resource object and resource object attribute. And now the feedback that we have from then is that it's the it's redundant, and it does not make sense. So I want to open to everyone to give to give feedback on here if we need to go back to the original idea that me and Pam have and calling it resource object and resource attribute, or we keep it as it is since the last suggestion and discussion from a data model perspective. This was mainly the main object question to the audience, to everyone, to tell us what is the best way to proceed because we are a little bit confused, and this is a topic that is coming back and forward for a while in couple of IETFs. And you don't need to speak all at the same time, but we need some feedback in here. I don't know what is the best way to gather feedback on this one so that we take a decision. Because, see, the terminology is the most important part of this use case. Right? We need to arrive to the right terminology so that from now on, we always talk about same terminology because it's really difficult most of the times to have conversation on scheme because everyone talks about different terms.

[00:36:36] **Nancy Cam-Winget**: Okay. As chair, I'm gonna make a harsh statement. The use cases draft is supposed to drive the work that needs to happen in this working group. I feel like we've gotten apathy on this document. Is it that the participants don't care anymore? Is it that it's way off?

[00:37:03] **Paulo**: Should we just Or maybe the 42 is good enough, and we don't need to Yeah. Do another one. Right?

[00:37:10] **Nancy Cam-Winget**: That was the last part. Or is it just good enough that we should just be done? And then the next question is, do we even need to go through the whole publish? Okay. We have we have a taker. Go ahead, Justin.

[00:37:26] **Justin Richer**: So I have long held that use case documents are pointless to actually publish in an archival format. They are meant to be a rallying cry to make sure everybody is able to point at things. And then you walk away from them, and everybody forgets that you wrote it.

[00:37:45] **Nancy Cam-Winget**: Well, I'm I'm kind of asking that question now.

[00:37:47] **Justin Richer**: And I'm saying that's my answer.

[00:37:49] **Nancy Cam-Winget**: Okay.

[00:37:49] **Justin Richer**: Is that I think the skin working group should just declare it as a document that we will never publish. There is a button in data tracker for that now.

[00:38:01] **Nancy Cam-Winget**: So it's a two part, Justin.

[00:38:03] **Danny Zollner**: Okay.

[00:38:03] **Nancy Cam-Winget**: Are we done and we don't publish?

[00:38:09] **Justin Richer**: Are we done? What is done?

[00:38:11] **Nancy Cam-Winget**: Just ask.

[00:38:12] **Justin Richer**: Are you ever done with something you don't intend to finish? That is my actual answer. I'm sorry, but it's I I don't think it's a yes or no answer. I think that the best intent is to never finish and to just

[00:38:29] **Aaron Parecki**: But your answer for do we publish is no.

[00:38:31] **Danny Zollner**: Correct.

[00:38:32] **Paulo**: K. K. Can I ask something before you leave, Justin? Sorry. Sorry. Can I ask something? So are you just talking about the use case of the terminology? Because I think that in this document, we are trying to achieve both. And I really struggle every time that I have a conversation in the market to get the right terms to have the conversation with my counterpart. So I think maybe what you are talking about is just the use cases, or maybe you are talking about both terminology to address the use cases and the use cases?

[00:39:09] **Justin Richer**: I'm talking about use cases. Okay. I have a softer position on terminology being published. It will be out of date the moment that you publish it. And the moment that it veers into ontology instead of terminology, you've gone too far and it's you're, yeah, you're asking you're breaking into jail.

[00:39:31] **Aaron Parecki**: Danny, one comment, and then we need to also move on from this.

[00:39:35] **Nancy Cam-Winget**: That's why I said you were optimistic.

[00:39:38] **Aaron Parecki**: I was optimistic. Yes.

[00:39:39] **Danny Zollner**: Yeah. I'll just limit my comment too. I think I agree with everything that Justin said. Like, keeping this as more of a, like, almost a living inspirational document makes more sense to me than trying to, like, publish something that then, you know, withstands the test of time. And the I don't know. I guess it's the terminology, specifically, what they, like, orchestration roles concepts in doing the review of this that I need to send to the mailing list still. The terminology made it so much more, like, complex than I think it would have been to just use don't know. It's either, like, what either colloquial industry terms or the terms in the SCIM specs. Like, this was probably the most cognitively taxing document to, like, fully analyze and process that I've read in years.

[00:40:36] **Nancy Cam-Winget**: But I think the conversation needed to be had. Okay? It it it allowed everybody to level set. So all I'm putting into question is, does the group believe it's done its job? Because poor Paulo has been pulling his hair trying to get feedback, and so I'm trying to just give him that direct feedback, right, from the working group. Is it time for us to just say, you know, our extreme gratitude to Paulo, and it's time for us to move

[00:41:07] **Danny Zollner**: on. Should

[00:41:12] **Nancy Cam-Winget**: I do a poll? I'm not awake enough.

[00:41:16] **Aaron Parecki**: Can do that really quick. Should we

[00:41:18] **Nancy Cam-Winget**: So we're gonna start a poll. And yeah. I mean so we're gonna start to pull, and the implication is that we no longer have to continue. It can continue to be a living document, but it's not a prioritized item. K? I don't know why I'm looking. How many do we have? Twenty twenty eight. Oh my god. Really?

[00:42:15] **Pam Dingle**: Okay. Some of you know opinion people. We need your

[00:42:18] **Nancy Cam-Winget**: help. Apathy. How can the no opinion win?

[00:42:27] **Justin Richer**: I think that's your answer.

[00:42:30] **Nancy Cam-Winget**: We have apathy.

[00:42:31] **Danny Zollner**: Yeah. Yeah. I think that

[00:42:33] **Nancy Cam-Winget**: don't care. Okay. So I I think we're just gonna call it.

[00:42:37] **Aaron Parecki**: I think if there's if if there's no opinion, then that means effectively

[00:42:41] **Nancy Cam-Winget**: I mean, Pablo, we can we can talk to you offline, but I think you're not gonna get much more from this group given the feedback.

[00:42:51] **Paulo**: Okay. Okay?

[00:42:53] **Nancy Cam-Winget**: But I do wanna thank you profusely because you've put a tremendous amount of effort and have rallied this group to align to where we are now. So for that, we thank you. K?

[00:43:08] **Danny Zollner**: Okay.

[00:43:09] **Nancy Cam-Winget**: Alright. Moving on. How are we doing

[00:43:13] **Aaron Parecki**: on time? Danny, I'm going to steal some minutes from your large chunk. We're good. We're only about seven minutes behind, so I think you will still have time.

[00:43:24] **Danny Zollner**: I I can go past them.

[00:43:25] **Nancy Cam-Winget**: Let's put it this this way. If you guys wanna talk about rechartering, you're gonna have to give us some time back. K?

[00:43:34] **Aaron Parecki**: And we're talking about

[00:43:35] **Nancy Cam-Winget**: group members group member first and then

[00:43:38] **Danny Zollner**: Yeah. Yeah. This clicker already live probably. Now it is. Okay. Hi, everybody. It's me again for, like, the ninth time. So, yeah, there's another draft I presented back in Brisbane. There's been a handful of changes to it. I'll do, like, a quick run through gauge opinions. So this draft attempts to solve the we'll call it the really, really, really big group problem that exists in pretty much any sort of, like, identity management of what API or protocol, and it exists in SCIM as well. SCIM in particular has a problem because membership is a like, group membership is each member is currently a value in an array on a like, the multi app valued attribute of members on the group. And SCIM only has the concept of pagination when it comes to resources. So a group is a resource, but the list of members is not a resource, so you can't paginate it. So if you have a group with a million members, you have to jam that all into one single HTTP response. Or what most implementations have done is just, like, not return group members or only return the first 50 or other really jank and inconsistent stuff. And then, you know, I did some, like, napkin math, and if you have a group with a million members, it's probably 200 megs in an HTTP response. So the what's proposed in this draft is, stolen from a bunch of other REST APIs that exist already. Why reinvent the wheel if you don't need to? It elevates the concept of group membership from being a value in an array on a attribute to being a, like, a first class resource. And the resource is pretty basic. It has its own unique identifier because every SCIM resource has to have one. What that is is opaque. It doesn't matter. And then it's essentially made up of what is the group and what is the member. So it's like group dot value and member dot value are the only things that really ever get, like, written. The rest of it is all just like, I don't know, stuff that the service provider can spit back if it wants to make it easier. This here, I'll go back to the other slide for a second. But this helps because when we elevate the group member concept or, like, a to a resource, it just immediately gains access to all of the, like, protocol level functionality that exists for other resources such as pagination filtering. You can use the SCIM slash bulk endpoint and update group memberships without having the atomicity concerns of, you know, patch, add, or remove, whatever, a thousand members where all of it has to either succeed or fail and you can't have, like, a partial success. And it scales really well because it's pagination. This slide shows the schema. It's not really anything crazy. It was just exemplified on the previous slide. I'll stick back here for a second. The HTTP methods that are supported would be post to create a new a new group membership, get to your you know, list a bunch of them or specifically, you know, like, try to find certain ones and delete, which to that endpoint is, you know, essentially, it's the equivalent of, like, patch remove to a specific member of like, specific membership on a group. Patch and put do not work because with the membership, like, once it exists is effectively immutable, either, like, it exists or it doesn't. And so you post and delete, not, you know, patch, add, remove. There's also a small schema extension that's in the current version of the draft that goes onto the group object, like the group resource that helps to sort of, like, point the SCIM client to whether or not the membership is going to be shown in the members attribute on the group resource or on the group members resource endpoint, the the new thing for us in this. There's a couple other concepts as well. Policy, which essentially, like, is is the membership in one place or both places, and a reference URL that just allows the client to very easily jump from, okay. I'm looking at this group and, you know, everything except memberships, and here's the endpoint I go to to go look at the memberships because they're not part of the group object. And then now you can see the other one's allowed member types, member count. It's all flexible, like like, no. They can all potentially change as well. Like, it's some ideas. This slide touches on those different policies. You can read it if you want. I'm gonna move past it in the sake of time. So, like, examples of how to create and manage memberships, post, delete, queries. This as far as interoperability goes, the way the draft is written now at least is generally, backwards compatible. There's also a requirement that's probably not particularly well worded in the draft that says that, like, if you're do if you're querying slash group members or if you're looking at a group and the members actually on the group, you should get the exact same results because it's the same data just being shown from a different endpoint. That wording can almost surely be improved. It's probably, like, not great right now. Here's an example of using SCIM bulk to do a whole bunch of group memberships at once. I already talked about the atomicity stuff. The draft has certain things, you know, like advertising that you support this with the slash schemas and slash resource type standpoint. Nothing really crazy here. And there's two open questions. We'll we'll just skip the first one. Like, we can do the mailing list or whatever. And then the second one would be, like, I I think from past discussions on the mailing list, even before I publish this draft, I know that there is interest in the working group for solving this problem. And then there's been a couple of reviews of this draft on the mailing list, like this specific draft since I published, the first version earlier this year. So of the drafts that are out there, this is one that, like, I most strongly would like to do a call for adoption for sooner rather than later. And with that, I see the clicker.

[00:50:41] **Nancy Cam-Winget**: Okay. I guess I need to do a poll. I was gonna ask who's actually read the draft. Let me run the poll.

[00:51:03] **Aaron Parecki**: Do you want me to take it?

[00:51:04] **Nancy Cam-Winget**: Yeah. Why don't you do the poll?

[00:51:07] **Aaron Parecki**: Adoption poll?

[00:51:08] **Nancy Cam-Winget**: No. No. No. We're not doing an adoption. Draft. Who's has anybody read the draft? Because I Danny, I don't think you've gotten sufficient feedback yet.

[00:51:16] **Danny Zollner**: Yeah. That that's fine.

[00:51:19] **Nancy Cam-Winget**: Yeah. So yeah. Okay. So we're running a poll. Who's read the draft? Just because we have a lot more participants on the

[00:51:44] **Aaron Parecki**: Okay. No opinion is not an option, by the way.

[00:51:47] **Nancy Cam-Winget**: Yeah. You you're not allowed to have no opinion. Oh, look at this. Go to us. Why don't you?

[00:51:54] **Danny Zollner**: I would say I moved to no opinion because I probably don't I shouldn't count for Fair.

[00:51:59] **Nancy Cam-Winget**: Yeah. But but whoever the other person is, shame on you. I don't remember. So It

[00:52:08] **Pam Dingle**: should be two. I just haven't voted yet because I was typing it.

[00:52:11] **Aaron Parecki**: Okay. So we need some

[00:52:14] **Nancy Cam-Winget**: We we volunteers? We definitely need feedback. So we need at least three volunteers again. So let me look at the chat. K. We need three volunteers. We need more energy in this group. So Jeff Jeff and Pam are volunteering. We need one more. We're not gonna be able to adopt this if we don't get enough reviewers. You can't you can't review. Your name?

[00:52:52] **Aaron Parecki**: Hans York. Thank you.

[00:52:53] **Nancy Cam-Winget**: I'm glad you know the names. I'll find you on the I sent you a message. Okay. I can cut and paste it and put it in the notes, Pam.

[00:53:09] **Pam Dingle**: That's good. I mean, as long as I have a first

[00:53:14] **Nancy Cam-Winget**: Okay. I put the name in.

[00:53:17] **Aaron Parecki**: Thank you. For the volunteer. Yep.

[00:53:21] **Nancy Cam-Winget**: So, again, we'll follow-up based on feedback. Okay. So who's doing AI Agent?

[00:53:28] **Aaron Parecki**: I believe it's also Danny. And, Danny, you got your five minutes back for this draft from the other one, so good job.

[00:53:39] **Nancy Cam-Winget**: While he's bringing that up, the roles draft has expired, my friend.

[00:53:44] **Danny Zollner**: I am aware.

[00:53:47] **Nancy Cam-Winget**: Is that not gonna go anywhere? It's an adopted draft. All you need to do is just hit resubmit to keep the draft alive.

[00:53:56] **Danny Zollner**: We can re I'll I'll get the little paddles out. Okay.

[00:54:01] **Fleming**: Like

[00:54:04] **Nancy Cam-Winget**: See what I mean, Chris? Yep. Okay.

[00:54:09] **Danny Zollner**: Okay. For the last time, unless the chairs unless Nancy surprises me later or something, this is probably my last thing I'm talking about. Yeah. So we wouldn't be session at IETF nowadays without AI. So there's I guess back in or is it Montreal, there were two drafts that were discussed. One from Matt Peterson at Okta, one from Mark Wahl at Microsoft. There wasn't a whole lot of update for the last ITAP, which was Brisbane. But pretty much since Montreal and all through the spring for interim meetings, a group of people, including the aforementioned, have been working to converge those two drafts and, you know, also just get better than the first the two first drafts and make better. So there's a new draft that was published, I think, probably, like, six weeks ago maybe to the data tracker that tries to take the best of both and then also cuts off a bunch of the not best parts. But so, yeah, that that I'll just sort of talk this slide. So why do agents need a SCIM resource type? Like, what's the value here? So AI agents are entering production workflows, you know, automating tasks, all that. And they need a first class SCIM resource so that they can be managed, with a lot of the same processes that, are already used for, let's say, users are in, you know, the rare case for, like, other nonhuman identities. So I think think things like, you know, identity governance or even just, life cycle management processes. So, yeah, right now, SCIM only has user and group resources. There's, like, a little bit of stuff happening out there where agents are being, like, stuffed into a little hole or whatever that looks like a user, like a human or whatever, but it's that's not the right thing to do. And in the absence of a standard, all you get is a whole bunch of proprietary nonsense where everybody's idea of what is an agent and what does it look like and where the actuaries are different. So moving on. I guess what are the changes since IETF? I've already talked about them. Two drafts into one, cut a bunch of crap out. Oh, and I guess I'll move move back. So the last bullet point on this so I guess last two. So the intent with this draft is for it to define the actual, like, resource type, so agent, and a minimalistic core schema. So I took inspiration from the SCIM devices specification where, you know, really small core schema and then a whole bunch of other stuff can get, like, layered on using extension schemas in other drafts. So one of the biggest problems with all of this is what the question of what is an agent. If anybody actually has the answer, just please tell us. But, so, specifically, I'm I'm I care about, what is an agent in the context of SCIM identity lifecycle management and governance. And so the term agent is overloaded depending on sort of who you are talking to and what context. It can mean that sort of, like, the persistent definition that we govern. So that could you know, depending on where you're looking, it's called a template or a blueprint or, you know, if you think more like software engineering, like, the class. And so on this slide, have an example we'll call it, like, the travel assist agent. So when we think of, I guess, the concept of, like, a template of an agent or blueprint, it's, you know, a persistent reusable definition. There's like a it's not task bound. So it's not actually really doing anything itself, but it's just the, like, the, you know, pattern from which each shirt is sewn or whatever. And it doesn't have runtime credentials of its own, at least the way I'm looking at it. And so this, I guess, final bullet on that left box is not really in reference to anything in the draft right now because we're trying to say minimalistic, but more like how I think things will probably move. But the template sort of serves as the, like, the the base from which each, you know, like, runtime instance takes off from. And then looking at the right box, we have, you know, sort of the the the what? The the yang to the yin, yin yin to the yang, where so if we have the travel assist agent that is not task bound, it's just, you know, here's your overall goal. There's the the other side of it would be more of a like, the ephemeral task bound instantiation of that template or blueprint. So instead of just the travel assist agent, it is, Danny wants to book a flight to Vienna for IETF via the travel assist agent. So could be, you know, spun up for one job. The balance could actually be, hey, for the next twenty four hours, you know, triage things that come into this queue or whatever. Like, it's it's not persistent is really the key thing.

[00:59:40] **Aaron Parecki**: And then Danny, would you like to take questions? Or do we In the middle of this? Or Sure. Yeah. Okay. Flemming Andreasen first, and then Justin, do you wanna get on the queue?

[00:59:51] **Danny Zollner**: Sure.

[00:59:53] **Fleming**: Hi. Thank you, Flemming Andreasen. Yes. I I don't claim to to know the answer to this question either. This is something that we're all struggling with. And I think trying to come up with a single answer is probably gonna be problematic. So I would suggest that we probably need to support both because there are arguments to be made either way. Right? And different people are gonna have different preferences when it comes to deploying these things.

[01:00:19] **Danny Zollner**: So my, like, response to that is that when we generally look at how SCIM is deployed out there in the world, it's much more like, I don't giant, like, cargo ship than speedboat. The, like, time like, the, like, round trip time or whatever, like, for, you know, handling user life cycle stuff in governance, it's, like, at the fastest you're measuring it in minutes. Sometimes, like, you know, it's like hours or whatever, you know, the whole, like, ingestion from, know, let's say, like, HR or whatever through a provisioning stream. And the speed at which, like, agent y stuff can sort of, like, come into existence and then come out of existence is so fast that I don't think SCIM is the right mechanism to actually handle that versus something more, like, spiffy ish using, you know, let's say, like, signed jots and, you know, like, inherited, like, permission or whatever from the the blueprint that's represented. But each, you know, instance that might spin up for, you know, two minutes to go to one task doesn't need to be fully provisioned versus just like a, I don't know, like a a just in time or, you know, like, it it's authorized or it it exists only really in the construct of assigned to JWT, let's say. But yeah. I may not be right.

[01:01:45] **Flemming**: I I hear you understand what you're saying. I would say this is a complete new resource type. Right? It has very different properties, and I think it depends on how you wanna use it. You know, we're not designing a system. Right? We're just finding an interface, a protocol. And there are different use case scenarios where people wanna do these things

[01:02:03] **Danny Zollner**: differently. Point taken. Just.

[01:02:11] **Justin Richer**: Justin Richer. So I got to the mic, apparently, to repeat what I said in chat, is that the definition of agent that this is taking is going in the opposite direction of what Danny is saying, which is a lot of what Flemming was just saying. But now that I'm up here, I wanna say that's fine. What's important is that the term chosen in SCIM is understood in SCIM to mean something specific. I do recommend that maybe don't just use the word agent because it is become so semantically satiated. It is effectively meaningless in the world right now. Call this something else. Call this a software intention template or something. They're just made that up. You know? Because there's nothing really AI specific about what SCIM is going to do with this. It's saying, like, here's a bunch of software that acts like an account in your system kind of, yay. Like, there there's nothing AI about that. Don't don't call it that. I do think that the focus of SCIM on template

[01:03:20] **Danny Zollner**: makes a ton of sense.

[01:03:21] **Justin Richer**: I think that that is the where the sort of the core bit of this is. That said, it's a very short walk to, to say that I am putting something in here to say that there is a running process that has certain properties for some reason. I mean, sure. That that could be reasonable. And if we stop trying to say, like, what is an agent philosophically? I think we can start to actually answer the questions that would be useful about what we want out of something like this in a system. All that said, I don't see ever deploying this as an extension to a SCIM system because I think that mixing humans and not humans is a recipe for pain.

[01:04:11] **Danny Zollner**: Max.

[01:04:14] **Max Gerber**: Hi. Max Gerber. You just said a lot of the stuff I wanted to say. I think that there is a thing that we want to do with a feature like this where we want to say we have a ecosystem of apps that are talking to each other and sharing data. And my travel assist piece of software, which may or may not contain a spicy LLM inside, is trying to do things. And we should figure out what those things are and then design a system around that. And if it happens to be used by AI, that's great. You know, that's that's nice. But if we can pull the agent out, I think this will probably be easier to get through than arguing about what an agent is or not for the next, you know, two years.

[01:05:03] **Danny Zollner**: Yeah. Early this year as we were working on bringing the the two original, like, agent drafts together. There was some discussion in our, like, you know, small group about whether to, I guess, broaden out and you do, like, nonhuman identity workload or one of the other some sometimes vague and unclear terms. And there was some opinion, I guess, on, like, it's gonna get so hard to cover all of that that it'll slow down defining the hot or I guess, you know, and it'll slow down progress on addressing the the hot problem or that, you know, organizations using, I don't know, like, identity providers are are caring about. And I'll I as a, like, sort of I don't know if I don't I don't I wouldn't call it a counter to whatever to I think it was the last point that Justin had. It would be, like, there are already systems being built today to I'm I'm sorry.

[01:06:08] **Justin Richer**: I'm gonna cut you off there. I don't care if you're gonna use it for stuff. That's fine. I said I wasn't going to.

[01:06:13] **Danny Zollner**: Oh, okay.

[01:06:14] **Justin Richer**: Because I think it's a bad idea. You can go Mhmm. Deploy bad ideas all day. Have a great time. Prove me wrong.

[01:06:20] **Aaron Parecki**: Okay. We have a few more few more comments in the chat. Let's

[01:06:23] **Justin Richer**: It's more sorry for WIMSE.

[01:06:25] **Nancy Cam-Winget**: Yeah. Go ahead.

[01:06:25] **Danny Zollner**: No no worries. I

[01:06:30] **Pam Dingle**: oh, I did it again. Pam Dingle, Microsoft. I'm not touching.

[01:06:35] **Pam Dingle**: I I did touch, but I

[01:06:36] **Pam Dingle**: won't touch anymore. So it's interesting because I reviewed these slides with Danny before he he, talked, and it felt like it was representing the consensus of the group. But the interesting thing that has occurred to me while you were presenting it is just that it doesn't matter which of these a thing is. What matters is that it needs to be managed by a downstream SCIM receiver. Right? So whatever that is, if it's Pam's note taking instance and Pam's note taking instance needs to be a principal on the other side of this consuming entity, that's the value, and that's what matters. Right? So for us to say it only could be one or only could be the other makes no sense. It might have to be an instance in order to be that managing, you know, that principle with enough identity to be useful. So maybe we can just tune this a little bit.

[01:07:25] **Danny Zollner**: Yeah. And, like, for for me personally, it's just the the way that I have landed on the like, it needs to be the template and not the instance that's being represented is from I I don't know. What is it? Like, a a viewpoint of practicality and that the the same infrastructure that exists today, if, you know, if that's being extended to handle this additional use case, it struggles with performance with users and groups and, like, their group memberships, and that's a much smaller scale than, you know, what whatever the current number is, 45 to one or a 100 to one of, you know, nonhuman identities to humans. Hi.

[01:08:04] **Pam Dingle**: I'm Emily Lauber. I'll be very close as I've learned the lesson. I am in favor of this because in my experience, when people talk about agents, not defining the word agents, but when people talk about agents, sometimes they are referring to pieces of software's workloads, but sometimes it does need to be in systems that are on par with users. And so, emitting SCIM or receiving SCIM, it would be helpful for me as an IDP to be able to identify that this is an agent kind of in our human system or categorized with our other users. So I am in favor of at least this being a problem being solved. I don't necessarily have opinions on the specific semantics.

[01:08:45] **Nancy Cam-Winget**: Wait. Semantics or labels?

[01:08:48] **Pam Dingle**: Labels.

[01:08:49] **Nancy Cam-Winget**: Yeah. You care about the semantics?

[01:08:51] **Chris de Looze**: Yes. Alright. Chris, hat on. So isn't this really just autonomy? And so shouldn't this be a label that say autonomous?

[01:09:08] **Nancy Cam-Winget**: Are you trying to suggest a label here, Chris? Possibly.

[01:09:14] **Chris de Looze**: I mean, because that kinda captures all of them.

[01:09:18] **Pam Dingle**: So if Tommy is in spend with her

[01:09:20] **Pam Dingle**: economy as in decision making.

[01:09:24] **Chris de Looze**: As in it doesn't matter because it in my sense not knowing really what the data structure or the data model or information model of SCIM is, so all of this can work for me. So it's not a problem. But in my mind, I would think that you would want something that's kinda parallel in precedence level to user.

[01:09:46] **Nancy Cam-Winget**: An autonomous entity.

[01:09:47] **Chris de Looze**: Right? Because you could bucket it out. It could have a different lifetime way to think about them, but you'll need inheritance somehow back to users or groups or whatever, whoever it's acting on behalf of.

[01:10:02] **Nancy Cam-Winget**: So it's really an autonomous entity.

[01:10:06] **Aaron Parecki**: Peter, and then we're gonna give Danny a few more minutes to wrap

[01:10:09] **Danny Zollner**: this up.

[01:10:10] **Peter Kesselman**: Peter Kesselman. Humans are autonomous entities too, so I'm not sure it's helping. Is it sounded the use case that Emily had, what you really need is a flag that says fake

[01:10:24] **Danny Zollner**: user on

[01:10:26] **Peter Kesselman**: the user stuff rather than a whole new thing. Sure. I do think this is very useful for if you can generalize this to software in general or applications or workloads, whatever your favorite term is, I think it does become quite useful, this idea of templates that gives you metadata about the thing and then instance information. Very helpful. But I I think agent is gonna you're gonna keep breaking into details.

[01:10:49] **Aaron Parecki**: Let's give Danny the three minutes to to share what he actually wanted to talk about, which was the contents of the presentation Oh. Instead of the what is the agent question.

[01:10:59] **Danny Zollner**: That's okay.

[01:11:00] **Aaron Parecki**: I But but but really, you only have three minutes.

[01:11:03] **Danny Zollner**: Yeah. I'll take six. Yeah. The actual label of agent versus robot versus toaster, I don't care. I'm just gonna sort of speed run through these slides because if you really care, you'll go up in the draft. Very minimalistic schema, Representation of the resource in JSON, so sort of opposite of the schema. There's and, actually, we specifically called owners. It's an array. One of the questions I think at the end is, what sort of things should be allowed to be owners? Can an agent own another agent? Not gonna talk about that today because I only have two minutes and fifty two seconds. Probably the key card here, though, is that at least as written today, the owner's attribute is more of a governance and accountability thing. It has nothing to do with, you know, authorization, delegated rights. It's like, if the agent goes and does a thing, who's responsible for it? Or who doesn't go into a thing? This is just sort of like an exemplary slide of REST calls to do things with agents. It's all not new. And this slide talks a bit about just, like, what is in and out of scope of the draft that's written today. Out of scope would be things like how agents authenticate, how services authorize the agents, whether agents inherit group permissions or whatever. In scope is sort of representing the agent's identity, whatever that is, or should put accountability and integrating agents into group structure. So there's a a line or two in the draft that says, like, the allowed, like, object or resource types in a group should be extended to include agents. So, like, a group member can be a user or an agent or group. And then the why is often and also your implementation specific until we get people adopting standards a bit more. Service models differ. And by going with a tight scope, we increase the potential for adaptability, at least of the initial representation. Click. Okay. Cool. Then the ask, which I don't think we've had enough feedback on this one either.

[01:13:27] **Nancy Cam-Winget**: You've gotten plenty of feedback, just not to the

[01:13:30] **Danny Zollner**: Or or, I mean, like, on the mailing list, like, like, like, meaty reviews.

[01:13:33] **Nancy Cam-Winget**: And not I'm even gonna take the poll because I don't think anybody's read the yeah.

[01:13:37] **Danny Zollner**: Yeah. But I I I think we can use the slide more as a we would like to have additional people, you know, sort of taking

[01:13:49] **Chris de Looze**: a

[01:13:49] **Danny Zollner**: look at the the draft, the the problem space, contributing ideas, so that we can get to a point where we have, like, a draft rep about representing robots in SCIM or workloads.

[01:14:03] **Nancy Cam-Winget**: Absolutely. This is not a charter, which is why you have twenty seconds left. But, anyway

[01:14:10] **Aaron Parecki**: I I I do, though, think that this document has received more review than many of the other documents in the working group, which is, probably a sign that we should discuss the charter.

[01:14:20] **Nancy Cam-Winget**: Right. We can't adopt it until Yeah. We discuss charter.

[01:14:26] **Danny Zollner**: So, yeah, this is not a, like, can can we adopt it today more think of it more as a, an intent. We would like to see as to a point where it can

[01:14:34] **Nancy Cam-Winget**: be It also brings the discussion of having captured the appropriate use cases because m brought validated one. Right? But not asking the question because I know

[01:14:46] **Danny Zollner**: Yep. No. Don't don't ask the

[01:14:48] **Nancy Cam-Winget**: not read the draft.

[01:14:49] **Danny Zollner**: The Yep.

[01:14:50] **Nancy Cam-Winget**: Right. They'll have opinions as well.

[01:14:52] **Danny Zollner**: Yep. And then, yeah, there's one more slide that's like a fuller JSON representation. It's an appendix. We don't need it. Goodbye.

[01:15:00] **Nancy Cam-Winget**: You didn't have to run away. Okay. So just for the quick orders of business, we've already talked and thanked Paulo and Pam, didn't mean to forget Pam, for the use cases draft. We can now park that because it served its purpose. The rules draft, Danny, it is an adopted draft, so we need to make sure that progresses because right now it's expired. That said, we need to talk about rechartering, so we need to come up with new text. In looking at the charter draft, we we spoke to which is why the interoperability I call it the best practices, but interoperable draft is sort of marginally not marginally. We can put that in scope of the current charter. So it's a question of we could do a full rewrite. We could rewrite chunks of it. I don't know that we can actually tweak what we've actually written because the scope of work and we revising those, we're not doing that anymore is my read. And I'm not gonna take polls because I think given the I'm looking at my co chair. Given that we've been running this working group for over two years, we've had no interest in actually updating those drafts. I think most of the proposals have come in through extensions, like cursor pagination being one of them. Right? So my suggestion would be that we continue the discussion on the right work items that we believe we want to address, not enumerate them the way we did in the previous charter, but work towards something to the effect. And so our, hopefully, you're listening so you can provide us guidance to what could be approved by the ISG as well, right, as we write the new charter text. But, you know, going towards the new trends in the industry, the need to address these, you know, label, label, label, autonomous entity, blah blah blah, that needs to be life cycle managed because there's, you know, we can talk about whether there's a human in the loop, not human. I don't know that we need to get to that level of detail, but provide enough of the guidance to allow the charter to get us to get to that body of work. Does that make sense? Sorry. I was in the, nobody's in the queue. So this is the discussion, by the way. So if people have feedback comments, please come up, and put yourself on the queue. But this is more for us to start the discussion of given that we've got new drafts that are coming in that are definitely not in charter, given that I will bluntly say we've reached apathy on the current charter. Our choices are close to charter, which I don't think this group wants to do, But, I will say we need to pick up momentum if there's new work. K? I don't mean for this to be a monologue, guys.

[01:18:43] **Aaron Parecki**: Danny. Yes.

[01:18:49] **Danny Zollner**: Hi, Danny. My okay. Danny Okta. Oh, boy. It's Friday. I agree that, like, a good chunk of what's in the current charter is, like, apathetic may even be, like, too positive of a term for some of the, like, stuff that's in there at this point. And, yeah, as I I think I've probably submitted more skim drafts than anybody else since the work group was restarted. Like, it it's I I found it very difficult to just be a very small population of participants in the working group.

[01:19:33] **Nancy Cam-Winget**: Well, that could work to our benefit, Danny. Right?

[01:19:35] **Danny Zollner**: Like But yes and no. But

[01:19:38] **Nancy Cam-Winget**: But we do need to have enough reviewers to be able to move the document forward. More importantly, we will be asking question of not just reviewers, but who's actually going to implement it and deploy it. Okay? Because unless we have two or three willing to do that, I don't think it's worth us spending the energy to work on documents.

[01:20:03] **Danny Zollner**: Yeah. But, like, some of the bigger ticket items on the current agenda, like, we'll call, like, just, you know, rewriting or, like, rep putting a new version in to, like, the protocol and schema specs are, like, long term things that I would like to see happen. I just need just speak my own opinion. But they're, like, not practical today because of the size of them versus the, like, the reality of all these, like, problems or gaps wherever that exist today where, like, that's been why it's everything's been, you know, solved it piecemeal in an extension.

[01:20:37] **Nancy Cam-Winget**: I mean, this is where I would ask the vendors who who are using Skin both on the server and the client side. Right? That there is enough momentum in SCIM two dot o if we really revamped it to a SCIM three dot o. Who is actually going to implement and deploy it when you have a large customer base? And those are the kinds of questions we're gonna have to ask.

[01:20:59] **Danny Zollner**: Yep. And it's one of those things where it's, it's gonna slow down adoption of SCIM two point o and, like, let's say three point o, you're looking at

[01:21:07] **Nancy Cam-Winget**: five ten Don't get me wrong. I mean, I'm not gonna relive radius versus diameter Yeah. That's as an example.

[01:21:13] **Danny Zollner**: Yeah. It's the thing that's happened before.

[01:21:15] **Nancy Cam-Winget**: Yeah. Thanks, Danny. Pam?

[01:21:25] **Pam Dingle**: With respect to that question of who would implement a SCIM three, there has to be something that's gonna substantially change. So we may need the forcing function for that. Before that. I mean, we're not gonna do it for our health. I don't think anyone I mean, does anyone disagree with that statement? I mean, we won't do it as a happy a nice, happy exercise for the sake of exercise. But I do think that there might be changes in the way the industry is dealing with various objects that that could mean we could we would actually want to have some rev occur. I I think that's the forcing function is we're not gonna do it for SCIM three. We're gonna do it because we have a goal.

[01:22:05] **Nancy Cam-Winget**: Right. So all I'm trying to say is the original charter please don't stay stay safe. The original charter was to go towards that, if you recall, and we said we would document. And all I'm saying is we reached apathy where we just didn't. Right? But there's appetite to do other work, and so that's all I'm saying is let's take all of that into consideration. And, as the co chairs, we are not going to do the work solo and make stuff up. So there has to be discussion on the mail list.

[01:22:43] **Chris de Looze**: Mike?

[01:22:46] **Mike Kaiser**: Yeah. Two things. One, I'm here for Pam versus the microphone. The, by the way, it's very entertaining remotely, by the way. Can't really see much, but it looks vicious. Secondly, I think that SCIM has is going to evolve and change over the next couple years to move into more real time approaches. I think people think of SCIM as this push pull batch processing vibe. And I think as that potentially involves, that may open up more use cases and embracing more architectures. I know it's very vague, but I think that might be a a wave of change that Skin might have to ride with other standards in IETF and elsewhere.

[01:23:30] **Nancy Cam-Winget**: Yeah. I mean, I I've seen in other working groups, a potential formula for success is when the proposals come in. And, Danny, you you have some of that, in the AI draft, where they're coming forward with the use cases that are the compelling reason, right, for the proposal. So maybe we cut people off too short

[01:24:04] **Pam Dingle**: because we

[01:24:05] **Nancy Cam-Winget**: we have six minutes left. We thought we would be, like, in this long discussion, so we're like, we need to make sure. Any comments from our AD?

[01:24:24] **Chris de Looze**: Okay. So what I'm observing is there could be some interesting work areas, but I haven't seen evidence of energy to tackle those. It would seem, especially in the AI and agent conversation, that there could be some some new areas it needs that might motivate, you know, sufficient commercial need to do updates. But at the same time, I'm kinda surprised. You know? And I think I think language to to go through, you know, kinda ISG and and such that really said we're going to, you know, focus on a set of extensions and updates to the protocol, including a possible, you know, revision to the protocol such that it supports, you know, autonomous workloads, agentic systems, whatever words make you happy Mhmm. Would not have any problems. So in that regard, I think you guys have a very wide berth in in which you can can do that. But, I mean, you have a bunch of drafts here that are struggling to get, like, reviews on lists, so I'm not exactly sure how to square those.

[01:25:45] **Nancy Cam-Winget**: Well, that's why I'm I guess, I was being, you know, politely blunt using words like apathy and Yeah. You know.

[01:25:54] **Chris de Looze**: Yeah. I mean, so you I guess, collectively, you have to decide, are you in this to do that bit or not? And I have to say, so far, I'm not seeing that you are.

[01:26:07] **Nancy Cam-Winget**: That's fair. Mike, did you put your comment before or after? I'm I'm trying to monitor the chat and failing. Go ahead, Mike.

[01:26:26] **Mike Kaiser**: You took out the last one with the the whimsy comment where I'm starting a fire right at the end. No. It's it's more just I can see if the move to real time is a thing, and there's a much longer discussion to have offline. But I can see it being a there's a lot of work in intent and in purpose and all that kind of stuff and not to get into that morass. But if SCIM has a placeholder for something to say, hey. When this type of workload, this type of agent pops up in the environment, we know it because it's attested in these ways, and therefore, the intent is is at least what do I call that? It is this reason why it matters to the organization, to the business that feels like something that SCIM could could provide a placeholder placeholder for for governance and, request and all those those those kinds of flows that might be in play. I'm not saying it's a certainty. I'm just saying it's a background idea.

[01:27:25] **Nancy Cam-Winget**: No. I I I think the middle ground there is we don't know what we don't know yet other than the gut feel is there's going to be some interrelationships playing between OAuth, WIMSE, and even Skim as we put labels, which is why I was starting to nod with Justin and Fleming when they were saying, you know, going the opposite way of WIMSE because if we put those labels and they need to be life cycle managed, that may be the interplay with SCIM. Okay. So I see Pam, you're on the queue and then George.

[01:28:14] **Pam Dingle**: I'm not touching it.

[01:28:15] **Pam Dingle**: I did not touch it.

[01:28:17] **Pam Dingle**: Nothing was touched. I think I mean, I what I'm taking from this is that we do need to talk more with the WIMSE folks. We should be I mean, if agent is the wrong term, I think that's okay. If we switch to, say, workload as a term, does that become a a conflict, or does that actually help? Maybe that's a conversation we can either have in an interim or just on the list.

[01:28:42] **George**: Alright.

[01:28:45] **George**: So this is a little bit scary for me since I don't know what I'm talking about. But listening to the conversation, it feels like it would be useful to collect at least some deployment patterns because I think that the way people are using SCIM then affect the way that underlying protocols and and mechanisms get used. And sort of having some common patterns would be really helpful in the sense of, like, moving things forward. That was it.

[01:29:14] **Nancy Cam-Winget**: Thanks, George. Pam, I don't know. I'm probably butchering the notes. I'm trying to help when you get up. Alright. We have a few seconds left. So any any other comments, feedback, quips and quotes, jokes, or not? We could close a few seconds early. How about that?

[01:29:45] **Aaron Parecki**: How about that?

[01:29:46] **Nancy Cam-Winget**: Crazy times. Don't party too hard. Thank you, everyone. Jeez, o Pete.

[01:29:57] **Fleming**: And

[01:30:00] **Nancy Cam-Winget**: we are now adjourned and closing IETF one twenty six. You may now rest.