System for Cross Domain Identity Management (SCIM) with Phil Hunt & Pamela Dingle

Vittorio Bertocci: Buongiorno everybody, and welcome. This is Identity, Unlocked and I'm your host, Vittorio Bertocci. Identity, Unlocked is the podcast that discusses identity specs and trends from a developers perspective. Identity, Unlocked is powered by Auth0. In this episode, we focus on System for Cross- domain Identity Management, better known as SCIM. Today, we are chatting with Phil Hunt, founder of Independent Identity and editor of the SCIM Specifications. We welcome our show's first ever returning guest, Pamela Dingle, director of Identity Standards. Pam has been contributing to conversations about rechartering SCIM. Welcome, Phil and Pam.

Pam Dingle: Hello.

Phil Hunt: Yay.

Vittorio Bertocci: Thanks for joining me today. Pam already shared her story in episode three of Identity, Unlocked, so I'll leave her be this time. But I'm very, very curious to learn how Phil ended up working in identity. And as is tradition, let's start with how you ended up working in this field.

Phil Hunt: I got started about 25 years ago on the customer side of things, working for one of the world's largest mining companies. They needed to get a million documents online very quickly, so that people can access the information. Of course, we needed to know, who was accessing? What were their access rights? What documents could they have access to? We were almost doing things that US Diplomatic Service was trying to figure out, in 1996. So very quickly, we started deploying one of the first meta- directories out there. You may remember Kim Cameron and Zoom It. We were one of their customers, and later became Microsoft customers.

Vittorio Bertocci: Oh wow. Fantastic.

Phil Hunt: After that, you may remember Don Bowen, who was at Sun, and before that Caterpillar. He and I were colleagues. We joined a company called TidePoint. We spent a year spending a lot of money building almost, now that I think about it, what is Amazon Web Services today, except this company was based on deploying meta- directory in 30 seconds. Too bad the economy collapsed and that one didn't go forward. Darn it.

Vittorio Bertocci: Darn.

Phil Hunt: Then, a couple of us then started OctetString, which was, if we were going to do this again and make it scale, how would we do it? Then we came up with virtual directory, which was a proxying and mapping technology. We found ourselves solving LDAP interop problems, LDAP schema problems, consolidating active directory forests, things like that. We got the attention of Oracle, who acquired us. After that, a bunch of customers were asking, " What's this open authorization thing? And is it secure?" Well, I got roped into the OAuth working group, and ended up contributing to the OAuth Threat Model and Security Considerations document. From there, Chuck Mortimore, who you may recall, and a bunch of people, were putting forward this idea of a REST API for identity management, called SCIM. Simple Cloud Identity Management, it was called back then. So, I joined in with the cool kids, and we thought, " Let's formalize it in the IETF." That was a chore, bringing it into the IETF, and we got that done. And I ended up helping to herd the cats, as the editor of the spec, to get things decided and get things done. It was actually interesting, because REST was not as simple when you want to make it interoperable and implementable by many service providers, and not just one. So, that's something we can get into later. So, I helped bring those specs forward to their current state. And we've all been implementing them and doing other things. I've since left Oracle and started my own company. One of the things I wanted to do was build an open schema independent version of SCIM, that would be configured just by JSON. And you could do anything you want with it in a cloud native implementation. So I'm working on that, and that's done as an Apache open source project called i2scim. io as an independent identity SCIM. That's available for people to access and help contribute to, if they want.

Vittorio Bertocci: Very nice. That is definitely a wild ride. I can see how your background just conspired to get you at the center of a maelstrom of the SCIM work. So, fantastic. Thank you so much for sharing that. Anyway, you already forward declared some of the things that we're going to touch on, but now let's formally actually get into the meat of the episode. I would start to explore, as is classic for Identity, Unlocked, what is the problem that SCIM really solves? It's like, why didn't you, Chuck, and friends got together and you started doing more fun activities? You ended up discussing specifications? What is your problem that SCIM solves?

Phil Hunt: I think first off, it was a question of, everybody was coming online and building REST APIs, and this, and this. Great. But I think the product managers were figuring out very quickly that, if everybody implements it, we'll have a thousand different APIs to support, and a new connector every day to write. That wasn't going to fly for very long.

Vittorio Bertocci: So let me pause you here. Here you are saying REST APIs, but you are thinking about REST APIs for directories, I guess.

Phil Hunt: Not just directories, but any web application that needs to have users populated. So Chuck was coming from Salesforce. com, and I think they had the business challenge of, and I don't want to speak for Chuck, but this is the way I understand it. That if you have 100, 000 employees to provision, you don't want to first have to write custom code just for Salesforce, and then write out that code, you get it uploaded. And in the meantime, without an API, you would have administrators entering those users in by hand, and then having to manage them by hand forever. That becomes a pain for enterprise customers to maintain all that data. And the question is, how are we going to do that?

Pam Dingle: I would add just that, you're right. The world was run by CSV files, comma separated. I don't even know what the V stands for in CSV.

Vittorio Bertocci: Values.

Pam Dingle: Is it values? Sorry, Comma Separated Values. But the problem was, everybody was doing the same thing. Every website you go to, you have to do the same things every time. You have to add a user, you have to delete a user, you have to change the user's attributes and roles. And so people were writing these API interfaces, but they were never identical. They were always just that little tiny bit off. That meant that the same code couldn't be run for every single one. And so if you had 1, 000 APIs, 1, 000 different applications in the cloud, which seemed pretty unlikely I think back then, but now it isn't, so imagine all you have to do is be off by a little bit. You can have a slightly different username, attribute name, or you can have a slightly... First name can start with a capital F or have an underscore in the middle, and all of a sudden, even the names of the attributes that you're trying to manage with this API, can be just different enough to cause all sorts of pain. That's what SCIM addresses.

Vittorio Bertocci: Let me put in focus the scenario that you guys are talking about. Here, what I'm imagining as you guys are describing is, I have already a set of users, whether it is a directory or whether it is a store, it doesn't matter. I have a user population. And now, I want use one of those APIs or SaaS products that you're mentioning. And so now, somehow I need to make those users known to these new APIs, which is why you are talking about these web APIs. That's why you brought up these CSV files, because that's one way of taking all the users. So, am I understanding correctly the scenario?

Pam Dingle: You're trying to move... Essentially, the bigger problem is that you're trying to maintain a state machine of, what users work for you? What users might be your customers? Who those people are, how much entitlement they have, and whether they're active or disabled in any one of a whole bunch of different applications, across your entire suite of applications. And so, it's the idea of, you push the data out and you make sure it's accurate, so that when you make access decisions for example, those access decisions are based on the most accurate picture of who works for your company at any given moment. It's like accounting kind of.

Vittorio Bertocci: Perfect. The thing that makes this an issue is that, all the information that you've just described normally is just locked in a directory or a user store. And the applications that you're mentioning, your suit of applications, might not have direct access to this thing, because we might be implementing a different way, we might be a SaaS product, we might be a REST API. And so, you need somehow to extract or synchronize, make this information available.

Pam Dingle: Right. In fact, what you really wanted and what usually happens today, in fact, is that humans do it. So a human might go in and create a user in five different applications. And if they do that, a bunch of things can happen. First of all, they can make typos, so now the data's incorrect in maybe one out of five systems. Second of all, if that user goes away or is on vacation and then a really important event happens, then that data may not be updated in a timely fashion. The manual version of maintaining user accuracy of user data, is extremely error prone and time consuming. What SCIM gives you, is an API by which you can automate the process of keeping all your user data the same across all of your systems. So it's much faster and more accurate. And then the additional solution to the problem is that, you only have to write code to do that automation in one way, and you can maintain five, 10, 100, 1,000 systems, so it's highly scalable.

Vittorio Bertocci: Wonderful. So, that's the problem statement. Now, let's backtrack for a second and let's see what is SCIM. SCIM is more than one spec, and those specs define various artifacts. So Phil, can you expand on that? Tell us a bit, what is the meat of SCIM?

Phil Hunt: Yeah. So there's two specifications. There's first of all a protocol specification, which is really what REST thinks about, is how do you profile HTTP verbs, which would be post, get, put, patch, and delete, to perform the create, read, update, delete, life cycle of resources on a server. But what we have to do is, for SCIM, is marry that with a data format, which the group chose early on as a JSON structure. And you have to move these JSON documents on and off the server. So what are we creating? We're creating a user, which is expressed in a JSON document. And we just specify in the JSON document, what are the attribute names we're going to use? We ended up calling those schemas. That was quite a controversial subject, because we were trying not to reproduce XML schema. We're simply trying to say, " These are the data elements, and more importantly, this is what an email looks like. This is what a telephone number looks like," and reference all the standards for each of those, so we get some consistency between platforms. Because, we're trying to avoid errors. So if I write a SCIM client to provision to a SCIM server, we're hoping that all the SCIM server implementations will work the same, and they'll have the same behavior semantics. A few things that naturally crop up then is, if I specify a username at Salesforce and then I go to Auth0 or Okta, will that same username work? And it depends on, what are the requirements for uniqueness? So we talk about these issues that come up in the documents. And then, what are all the failure conditions that can result from formatting errors and things like that? So that's really what the SCIM specs get into. That really was the problem we had from SCIM one, which was an informal document setting. We learned a lot of experience about what were the interop issues in corner cases that spring up. We formalized it all inside the IETF, while trying to maintain backwards compatibility. But we actually laid out all the corner cases and failure conditions, which led to a spec that was larger than I would like to see. But I think it's proven to be fairly clean, in most cases. I'm laughing right now. But I think we did pretty well. A lot of the cases I'm running into now are the same life cycle we've seen in OAuth, where people actually want to use it now more as a directory server. Before, the criteria was, " It's a provisioning endpoint. I just want to create and update accounts." Now people want to talk about new cases that are directory, and that's still up for discussion. But it's really new use cases and new ways of use that the original working group hadn't considered.

Vittorio Bertocci: So before we go too far in that direction, let me summarize a bit what we said so far. So first, you mentioned SCIM 1 and SCIM 2. So tell me a bit more about that. SCIM 2 is the one that was ratified by IETF. What year was this?

Phil Hunt: I think we finished it in 2016.

Vittorio Bertocci: Yeah, I think 2015 and 2016.

Phil Hunt: 2016, yeah.

Vittorio Bertocci: And SCIM 1, that was something like 2011, is it possible?

Phil Hunt: 2010,'11 timeframe. So, it took us three or four years to get through certain things. There were some issues like we needed a patch function. We learned quickly that groups can be very large objects. If you have a million members, you don't want to have to download it just to change one. And also, that object changes frequently. If it's got a million members, it's changing frequently. You need to be able to patch that so I can say, Vittorio's in the group or not in the group, and I don't have to actually take the whole object, lock the record down, and hopefully put it back, and it says, " No, you can't put it back. It's already changed. Your data is not up to date." So if I do a patch, it's easier to do.

Vittorio Bertocci: I can see how that can take five years of IETF, for it to discuss. But okay, great, fantastic. So that's the timeframe. Now for the items, I heard you talk about schemas. As in, you mention the entities and the schemas for those entities. I heard you talk about protocol, as in ways of actually provisioning, no pun intended, all of those things. And then I also heard you mention endpoint. So, did you also define an endpoint as part of this?

Phil Hunt: Yeah. It's just, how do you define a server route? We had envisioned, but it hasn't really come up with, how would you deal with versioning? So, if God forbid, a SCIM V3 comes around, what would be the format of that endpoint and how would the difference between V2 if you only know V2? How do you talk? I think there was enough of a change from V1, that it was pretty much a hard transition from one to the other. The nice thing too is, if I know the server route, then I can query for discovery items like, what features does the SCIM server support? So, in the spec we say patch is optional, search filters are actually optional. Some servers are very rudimentary. You can only get a resource and put a resource, you have to know its identifier. Other servers support that, and there's a few other features that are currently optional. So a client needs to know, what capability does a server have? And more importantly, what data does the server support? Is it just users and groups or is it more? Some people are storing session information in SCIM, some people are storing OAuth client information in SCIM. So how do you discover that schema so that you can understand it and manipulate it?

Vittorio Bertocci: Actually, now I'm going to take my host hat off for a second, and I'm going to put my spec author hat on. I want to complain. I've been working on this specification for defining how to use JWT as encoding format for access tokens. One of the things that I wanted to do there, was to stop people from abusing scopes with authorization information. And so we added in that specification, a couple of claims that are used to carry access tokens authorization information. I did not want to reinvent the wheel, and so for the claim names and the claim schema of these, I borrowed from SCIM. In particular, I have groups, I have roles, and I have entitlements. But when I was almost clearing IESG, the people at IANA, that I added to ratify the name of the claims, they complained saying, " Hey, if I go on SCIM and if I look at schema for the things that you are using, like for roles, groups, and entitlements, actually there is no interoperable schema that I can use. SCIM is underspecified for those entities." They almost sent the spec back. Luckily, we managed to push through. Because the main point was, at least now we have a place in the token from where you know that information is, and then the schema, we can't rely on a common schema, but it's true because such a schema does not exist. Can you talk a bit to this balance between being very prescriptive and giving a schema, or leaving it somewhat under specified, and then years later, someone with a strong Italian accent and long hair, complains with you on air.

Phil Hunt: I think there was such a pushback when we were writing the SCIM schema, that we didn't want be too formal. So, we recognized that some people were going to add schema informally, and we didn't want things to be broken. So we talked about something called, now I've forgotten the reference, but that SCIM would be a robust specification. Which means, we're not going to get panicked like X500 World was, and even LDAP was. If you say something that's undefined, the whole transaction gets thrown out, and suddenly everything's breaking all over the place. When TCP/IP was written, the philosophy was, if you understand what's happening in the data stream that you're getting, you're okay to proceed. You don't have to reject it because somebody dropped a bracket or something like that, or somebody didn't quite say it right. You can take what you want out of it and do it. So, somebody expresses a bunch of attributes you don't care about as a service provider, you're free to just ignore them. But what you are obliged to do is, say what you accepted back in your response. " Here's the final representation that I as the service provider accepted." And the client should not get cranky about that to say, " No, you didn't set Vittorio's name the way I wanted it. I'm going to keep telling you to set Vittorio's name with this accent, and you better accept it." Well, that's the kind of problem we used to deal with in LDAP, is you would see clients and servers arguing about data values, and the client saying, " Until I see that the server has accepted that value verbatim, I'm going to keep pestering the server to change it." And you would see these loops and memory loss circuits. The idea with SCIM is to say, " There's always going to be some mismatch between domains. The standard is never going to be perfect." So, I would say SCIM schemas are almost more guidelines, and that's why we have a schema's end point. If you want to know how the server will treat the data, go and look up their user object under the schemas endpoint, and it will tell you. But that allows for some decoupling between Microsoft, and Google, and Oracle, to actually be a bit different. And that's okay. So I don't get hung up on it. A lot of people do, they want to see that this is the way it is everywhere, but I don't think the real world is that strict. So, we'd hope to make the SCIM protocol a little bit flexible. We also provided an extension point so that you could say, " I want to tag, add a bunch of enterprise data, or this application data to a user object." So SCIM does have a formal extension point, and then you can go to IANA and register those extensions that way. That's the way the SCIM world works. You also, Vittorio, got into something that's also interesting. That the SCIM world evolved in parallel with OAuth and JWTs, JWT. So why aren't they fully in alignment? I have to apologize for that, but it's mainly because they evolved independently. And really, it's not a bad thing. I look at it as, SCIM is really identity data as it sits in a data store or an API, and JWTs and OAuth or authorization server conclusions that they've made about that data, to produce scopes and rules. So, it's not always true that you're going to take a SCIM record and it's somehow going to show up in a JWT token. I think a JWT token is a highly processed assertion that says, " These are the set of claims that matter to the end points," and we're not going to bring all the SCIM data with it." But it might give you a reference to the SCIM end point, and that's something we've talked about in OpenID Connect, as an alternative to the user info endpoint, as a reference to SCIM.

Vittorio Bertocci: That's wonderful. Thank you. Now, my objection has been completely defused. And once this episode will be online, I'm just going to take all the people that are complaining about this and say, " Hey, here is what Phil has to say about it," and just send them to the exact minute. So, thank you for that.

Phil Hunt: I'll be ready for the arrows.

Vittorio Bertocci: Yeah. That's my deflection technique, my 302 patented technique. So before we move to today, let me ask one last question about SCIM classic, let's call it, to both of you. Which is, clearly SCIM is extraordinarily useful, and it's been around,SCIM 2, at least for six years. So what do you think about adoption? Is SCIM adopted? Is it doing its job? What do you think the state of SCIM is today?

Phil Hunt: I think SCIM still has the same... It's well adopted. The major players are supporting it, and I'm ecstatic about that. I think there's still a problem in the application space, but I don't think it's unique to SCIM. I think it's something to do with the identity management, identity access space's relationship with application developers. It's the classic problem I see in OAuth where an application developer says, " I want to control the user experience. I want to do the log in. I want to do everything. I want to manage my own identity. It's just a database function. I don't need you guys." I think it's the same discussion with OAuth people and developers, as it is with SCIM. SCIM does have its appeal for enterprise managers who want to control and make sure that the data is provisioned consistently, as Pam was talking about, that's the key driver for them. But for the applications developer, they're like, " Yeah, maybe I'll get on to SCIM." Really, they have to get to the buy- in point that says, " If you want all those enterprise customers to load their data, and you want your user counts to grow, you really need to look to SCIM as one of the ways to do that." But if they're at the stage of MySQL database and we're done, then it's the same problem as with OAuth. Where OAuth can offer fast conversions and registrations of users by using federation, SCIM does the same thing with enterprise customers, as far as getting users into your system quickly and consistently. That's the value to the app teams. I think we've got a lot of work there as does OAuth.

Vittorio Bertocci: I hear you. Great insight. Pam, what's your take?

Pam Dingle: We work a lot with partners on SCIM. And generally speaking, a lot of people come to us and say, " Hey, we want to do SCIM. Can you help us?" That curve is high right now. And I think you can see it, because if you look at any application gallery of any vendor out there, you compare the number of federated applications to the number of SCIM enabled applications, it's about a 10th, I would say. And that's probably a generous estimate of federation enabled applications to SCIM enabled applications. There's a barrier here and there's a learning curve. Some people say they read the specs and don't understand, some people say that they don't have the library that fits their particular software. So I do think that there is an issue, but I think we rarely hear people who say that they don't see the value proposition. They need to do it in a way that's not going to break their bank. Everybody has a certain number of developer hours, and they have a certain number of budget dollars that can go into implementing a feature. It's software 101. And so the trick is, how can we as the industry that wants to make identity ubiquitous, make it cheaper and faster for everyone out there who doesn't know anything about identity, but is a developer with a task to make that the easiest way to get identity provisioning working?

Vittorio Bertocci: I think that sounds like a fantastic segue to modern times. So, I know that you've been contributing to discussions. Like there was a recent virtual Birds of a Feather, I don't know how to use TH in English, in virtual IETF, discussing whether it's time for SCIM to expand its scope, and start tackling new scenarios. Can you tell us about that?

Pam Dingle: I can. Just so everyone knows, anyone who wants to contribute or be part of this conversation, there is a SCIM mailing list at the IETF. I hope I can give you some links, Vittorio, that you could, I don't know, broadcast or screen in some fancy way. There's a SCIM mailing list at IETF that has been running since 2014 I want to say, Phil. Does that sound about right?

Phil Hunt: Mm- hmm(affirmative).

Pam Dingle: So, it ran through the entire history of creation of SCIM 2. 0, and is still running today. And through that mailing list, we've coordinated biweekly meetings, where we have talked through what exists today. The other thing that you should know is that, there are the SCIM protocols, which are RFC7642, 43 and 44, those are the actual IETF approved documents. Fancy, fancy. And then, there's a whole bunch of drafts that have been proposed around SCIM. Many of them have expired, but they're all about how to either improve, or profile, or extend the SCIM family. And so, our conversations have been around, where are the paper cuts? Where are implementers of SCIM, either as clients or as servers? Where are they seeing the pain? What of those drafts are valuable, and what would we change, and what are the business problems behind them? And then now, we're in this rechartering process, we had a successful Birds of a Feather. We have the ability to now go and convince the area directors at IETF, that we have the momentum and the consensus to the groups of people who would like to actually write better and improved documents. So we're now in that process of saying, " What would we do if we could have a working group? If we could create either errata on the old documents or new documents altogether, which things, which problems would we focus on first?" So that's where we are right now. That interest group is only informal, but we've now moved towards the IETF- y way to do things. Is that a word? Can you say IETF- y?

Vittorio Bertocci: You most definitely can.

Pam Dingle: We have folks who are acting, helping us as interim chairs, and we're starting to pivot towards doing things on the mailing list, and trying to do the same consensus that everybody else would do. But you can actually see the videos for those interest group meetings. Often, we've taken drafts and then just done a breakdown of the draft, so it's a great way to learn about the spec.

Vittorio Bertocci: Thank you. This is great and very clarifying. But there's one thing that I'm not sure I understand. From the things like you just said here, it looks like that the activity is toward improving what's there. As in, not new problems, but solving the problems that their schema is meant to solve today, better. Like you spoke about profiling, and it's similar. Instead, I might just add a superficial understanding of the process, or just... I heard rumors that they were entirely new scenarios that were being discussed, as bringing them into a purview of SCIM. Did I hear wrong?

Pam Dingle: I want to know what scenarios you were thinking of, actually.

Vittorio Bertocci: I wasn't thinking of any scenarios. For the time being, I thought, " Oh, I should read about this." And I said, "Well you know what? I'm just going to have an Identity, Unlocked episode, and those guys will tell me - why would I need to do actual work to look up stuff." Great. So, fantastic. See? That worked already. You already clarified what is the intended scope. So if we double- click, if you're thinking about like one or two, the top two drafts that you think are the ones that deserves the most to be saved, and are actually to have more work, which two drafts would you call out?

Phil Hunt: I'll go. One of the drafts that's been stirring a lot of discussion is something called stateful paging. And when we get into why they wanted, I asked, " What's the purpose? Why do you need to do?"

Vittorio Bertocci: Can you tell us what is stateful paging?

Phil Hunt: Stateful paging is the idea that I could pull down... I want to carry the entire database, and I want to pull 100 entries at a time, and do reconciliation. So I'm stating that, which I'm jumping the gun, because I had to ask the question of, " What is stateful paging? Why do you want to do it?" And people said, " Well, what I want to be able to do is, go through the whole data set. I want a picture of the whole data set, so I want to create a state of the data set. I don't want to download it all at once, but I want to go through the whole data set. I want to have a picture of the data set, so I can reconcile it in my domain." And when I asked the question why, it's this notion of reconciliation. And we have to ask the process, " Well, is that the best way to do it?" And so that's the IETF process. Somebody's proposed a technology, proposed a solution, now we asked why, and we come to, " Is that the best way to do it?"

Pam Dingle: Right. This is giving me flashbacks. This is giving me huge, huge flashbacks because, in like 2004, I was running large scale data imports for a company in California, and I was using LDIF format, and I was doing LDAP imports. If you hit one error in the import, the whole thing stopped, and you had to go page through masses of millions of lines of data, to figure out where it stopped, and then delete everything in the file up to where it died, and then keep going. So, it's the resilience of being able to get data in chunks you can handle, without having to start from the beginning every single time.

Vittorio Bertocci: Makes complete sense in both cases. I really hear that someone comes with a solution, and the problem is implied. And then, trying to up- level the conversation and saying, " Let's talk about your problem, because maybe there is some trick where you can use that does not necessarily entail chunking." Or maybe it turns out that chunking is the best, but everyone should come to the same conclusion as opposed to just... Yeah, this is a classic thing. I normally keep technology out of the show, but having a product which is very, very flexible, people like to do things because they're like that. Sometimes they say, " Can I just add this parameter?" And I say then, " Why? Why do you want to add this parameter?" Sometimes it turns out when we're trying to do something you can already do, they just didn't know how to do it, but they thought, " Here, there's..." So, it's an eternal fight of a layering violations.

Phil Hunt: One of the things I think this also shows is that, the world of SCIM is changing. When we first started, it was very one way, from the enterprise out to the cloud. What we're seeing now is, the cloud is adding value, the cloud is maintaining its own data. So what's happening in Azure, is not necessarily what's happening on- premise. Or what's happening in Oracle is not what's happening in- premise. And you end up in this new world, where there are mutual changes that have to be reconciled. That's really the question the group has to deal with this is, how do we keep coordination between these across domains, and make it work? It's not just client server anymore. It's service to service. And that's really the evolution of the protocol that needs to happen.

Pam Dingle: Yes. I would say Vittorio that asking, are there new... Is there new stuff, isn't quite the right question. I think the industry has transformed underneath of SCIM. In the time since 2.0 was published, as Phil just said, we've moved to a world where it's not on- premises pushing to the cloud, it's now multiple clouds with multiple sources of authority, for multiple attributes, all trying to coordinate and also negotiate. And not only that, but to do so at such scale that we can't have the clunky administrator manual driven connections. We have to move to a world... If there's anything that's new, it's the focus in the industry on automation. And not just automation as in metadata, and reading a metadata, and doing discovery, but actual Devops life cycle interactions, where whole connections can discover what's possible, get oversight within it, regulatory flow or an administrator workflow approval system, and then execute. Completely make the entire connection unfold like a self- inflating tent, where the administrator did not have to type anything. They did not have to do anything, except double check it to make sure it's not fraud, or dangerous in any way.

Vittorio Bertocci: As you guys describe this, I'm reminded of one of the late episodes in season two with Darin, about FastFed, in which he was describing the use of schema in the context of FastFed, very much along those lines. So, interesting. Everything clicks. All right. That's fantastic. We've been talking for quite a while, so super interesting. If you were to issue a call for action, I know Pam already mentioned that we have those mailing lists, but what are the things that you are looking for? What are the kinds of contributions that you are hoping to get, like use cases, experiences? What are you guys looking for in the discussion?

Pam Dingle: I think we're looking for statements of pain. So we want people to actually document the things that hurt for them today. If they are either attempting to use SCIM, or if they are in the throes of using it, those documented cries of pain would be great to have now. We're also looking for people who are interested in editing these specs, or in participating in the working group. And yeah, it's work, but I will... You can't see the faces that Vittorio is making right now, but they're very funny. But here's the thing. If you're interested in getting into standards, this is a really good opportunity to come and be part of this SCIM working group, because it's an amazing mix right now people- wise, of people like Phil, who've seen it, and done it, and been there, and who are willing to support movement forward. But also, people who've never participated before and who are interested in learning how to do it. So it's a good, safe space I think, with lots of support and lots of interest. There's lots of interest, and at least what I can tell right now, is a fairly minimal political landscape. So, it's a really good opportunity to just come see how IETF works, and be part of a cool movement in identity.

Vittorio Bertocci: Fantastic. Phil, what do you want to add?

Phil Hunt: I would say the same thing. We want to know pain points. I'd love to also see draft proposals. So the IETF does have a format for submitting your draft. What happens then is, the group gets to look at your ideas. If you want to share an idea, there is a process that the IETF has mainly for IP disclosure rules. But once you get it out there, people can look at it and say, " Oh, this is interesting." Or, " What is the problem you're actually trying to solve?" But it starts the discussion. And what's great about that is, once the discussion starts, the group may say, " Let's run with this," or the group may say, " Let's change it a bit," or, " Here's a new proposal," just a bit. So there's a lot of sausage making, but there's some beautiful sausage that comes out. I like that process. It's a consensus building process, where we throw away the bad parts and we get to the good stuff. The editor has to suffer those, that work, to build the consensus, and capture that consensus in the document. That's the process the IETF is well known for. I have to say, the nice thing is that, all the IETFs documents stand for a long time. So it's a slow process, but it's a stable process. One of the great things is that, you can pair that up with your own development as the drafts iterate. Just like in Agile development you iterate your code, and when we get to, do we publish, we're really saying, the code is locked, the code is working. That's what publication actually means at the IETF. So it actually is an Agile process, just runs on a longer timeframe.

Vittorio Bertocci: Fantastic. I love the message that both of you gave, and I wholeheartedly agree. We need more people to come and work at the IETF. Thanks, Phil, for saying this last thing about the code, because it's easy to get frustrated with the glacial pace of some of these things, but you bring an excellent point, that this also gives you the chance for your artifacts, your code, your service, and so on, to actually catch up. So, wonderful. I think this was an incredibly interesting conversation, on an exceptionally important topic, which is both impactful and relevant. So, I want to thank you both for your time. I want to thank everyone else for tuning in. Until next time. Thanks everyone for listening. Subscribe to our podcast on your favorite app, or at Identityunlocked. com. Until next time, I'm Vittorio Bertocci, and this is Identity, Unlocked. Music for this podcast composed and performed by Marcelo Woloski. Identity, Unlocked is powered by Auth0.