So good afternoon and hello again to the ones that were here in the beginning of the day. Hope you had a great lunch and now we are going to have one of the interesting panels that I at least have been looking forward to with everything that's going on in and management today. So have you ever wondered if it's time to just get rid of all the old ID protocols and get some new ones? Oh, for not recent? No, not yet. Not yet. Hold on a second. And familiarizing yourself with all the different protocols can be a huge challenge. And the confusion is really growing as there are more scenarios and, and technologies coming up as technology evolves, as it overlaps as there is more than one solution to the same problem. And, and this is a huge challenge.
We are talking about Sam, oof, skim SAEL and as adoption levels, they increase of these technologies. We are starting to see use cases where there is some technologies or some protocols that are better fit for, for the others. And with me today, we have the panel here of Craig Burton, our distinguished Analyst from Coco, Darren rose CTO from SalePoint, Dr. Michael Jones standard architects from Microsoft. We have David za solutions architect from axiomatic and Dr. Paul Masson, senior architect from ping. So welcome to you guys. And let me start off by asking if you guys could explain the pros and cons in your own words between these four different standards. So take it away.
I'm gonna let these guys do that, but I'm gonna set the tone by telling the, the story that I told this morning. I, I don't know how many of you attended that this morning. So a few of us, so it won't hurt to say it again. There's a movie by the word Chesky brothers that did the matrix that came out recently called cloud Atlas. And in that movie, there's a, this intergalactic network of planets that you can travel between and communications and so on. And for some reason, one day that network Schutze down and all the people that are visiting those planets are stuck there. They don't know why, and they don't can't find out what happened and so on. And in this one particular planet, there's the people from earth that do the traveling and they're inner spaceship. And then there's the goat. Harders now there's the cannibals too, but that's not what my point is about. That's the goat Harders and the travelers. And there's an Emissary played by Hailey Barry that goes and meets with Tom Hanks, the head goat hurter, and they talk and ask questions. And there's trying, they're trying to, you know, create some community between these two really disparate cultures and Tom's Hanks is narrating. And he says, finally, one day the elders in the goat hurt tribe decided to ask. And so they asked Hailey Bailey said, how do you do intergalactic travel?
And she says, well, fusion drives. And the, all the people in tribe said, oh, fusion drives, fusion drives. That explains it. And the, he goes on to explain that nobody had the courage to look bad enough to say Zal what is Z Mo fusion drives? I mean, so, you know, I want to, these are complicated things and, and the, we we've gone through some technology shifts that have put everything that we've the way we used to do protocols and be a protocol from end to end and complicated and require the, the priesthood of John Bradley to show up. So in order to do the Zach Mo connect to your, to, you know, man, anybody ever sent a check to John Bradley, this is not cheap. So you want, you wanna, I'm just kidding. You wanna follow John Bradley's new philosophy and that is that we wanna make this simple, so everybody can do it. And that's, I'm, I'm really excited to see that happen. And I think that's where we're headed is to morph these things to a more simple, simpler metaphor. So anybody can use them.
Well, obviously that's a tough story to follow, but I do love it, but I, I I'm in a hundred percent agreement with you. And I think to some degree, we're each here to represent a different standard. And I was sort of slated behind skim. Now skim is an acronym for, it was originally an acronym for simple cloud identity management. That was when it was under an O WF activity. It's now under I ETF and has been renamed the system for cross domain identity management. Oh, that's complicated. That's exactly, to my mind, the, we, all, those of us that have an engineer on my team now sits on the, the, the committee directly, but in its founding simple was the drive simple was the requirement. I, myself very much involved with SPM L I dunno if anybody remembers service provisioning, markup language, right. It was very complicated.
It was very comprehensive. It, it really was a fusion drive. It was a fusion drive. It tried to capture the entire object model of provisioning and slam it down into an XML DTD. Now, as soon as I said, XML, DTD, I've lost half of the people that want to buy and care about this solution in the first place. So it was really a move to try and move a move, to move a move toward a rest based approach and a simple prescriptive schema, and to create a model for remote access to accounts that was friendly, friendlier, and easier to use, whether we will achieve that in skim, it was yet to be seen, but is certainly a step in the right direction using the right protocols, using the right data representation.
So, hello, I'm Mike Jones from Microsoft, where I work on identity standards. One of the standards that I have worked on is OAuth 2.0, which is my appointed place on this particular panel, O two oh, came out of something called oth one that was pretty universally agreed that it was too hard to do. And so a number of people got together on the side and said, well, we can take the core of this authorization protocol, but not require complicated signing mechanisms. And let's just use a security mechanism we already have, which is TLS or HTTPS. Use that for content integrity, move tokens around that, give permissions. And we can give access to things like APIs or web resources and I cloud services. And when people ask me about, well, what library do you use for OAuth? Part of the point of it is that it's so simple that you're typically not gonna need a library.
An OAuth call tends to be an HTTPS get or post with a simple Jason data structure and a small set of query parameters. And so the examples in the spec end up being effectively the whole spec to the way most people build it. Now that being said, you still gotta read the security considerations, so you can end up in the New York times. But the idea was to build something simple enough that people would actually use it. And market forces seem to be saying that they are, I'll put on another hat that I wear for a moment, which is we've built the open ID connect, single sign on and claims release protocol just as a profile of OAuth, too. One of the good things and the bad things about OAuth is that leaves enough decisions open to the implementers that you can do many things. It also means that if you want anything interoperable, you have to decide what those many things are and I'll, and, and then test it. And I will save further comments for later.
Thanks. I'm David. I'm the lucky Z one guy been doing Z Mo for quite a few years. I think it's pretty simple. And to go back to the analogy that you made with fusion drives, I fly quite a bit for customers and conferences, and I don't really know how planes work. I know they have a pilot, they've got wings, they've got fuel. That's the extent of my knowledge. I don't need to know more, but it's the same with my customers and Zack Mo they know the architecture. The architecture's not a, sorry, it's not a Zach Mo invention. It came from other standards. They don't need to know the language itself. They just need to know how to ask a question in plain old English. They need to know how to write policies in plain old English. And that's it, the technicalities, the tidbit, the details and language details. Don't focus on them. Focus on the architecture, focus on the English.
Hi, I'm Paul to, to represent SAML. So Darren highlighted that at least initially the S in skim meant simple. So the S in SAML is security. And that, that says something about the trade offs and the priorities that went into SAML. The focus in designing SAML eight, nine years ago, was security more so than simplicity. And because of that, you know, we love to talk about the 800 pages of spec specs that is SAML. I, I actually don't believe it's 800, but it's, it's up there. It's a big spec. It's a framework like for OAuth, you can do multiple things with it. And I don't think it need be ashamed of its functionality and the fact that you can do many things with it. There's a price to pay, be paid. You know, as, as David pointed out, libraries can insulate people from the specifics of that, but SAML for all its complexity is deployed. It's out there. It's useful. And so I think, I think Sam sets a bar that some of these other specs, you know, may well achieve, but it's a bar that they have yet to achieve. And SAML, I think, defined that, excuse me, for the pun standard.
Thank you for that guys. So let's open up for questions. I know that we have one here in front. We can start with that. You had a question from the beginning. No. Okay. Any questions to the panel down from the back? Yes.
Just a repeat
The question. So the question was, if I heard correctly, perhaps initially there was in SAML support, both for authentication and for authorization, you referred to them as profiles. Technically they, I don't think they were profiles. So some six, seven years ago, Sam recognized that, that the authorization functionality within SAML could be better addressed by Zamal and made that decision to focus on authentication statements or attribute statements as opposed to authorization statements. So web SSO, the, the most famous most deployed profile of SAML focuses on delivering into an authorization engine, such as one, perhaps with Zamal under the covers, the necessary identities and attributes to inform that decision. So it's, it's identity attributes and authentication more so than direct authorization.
I'll I'll just add with Zal, it's extremely easy to consume those attributes that are Sam assertions within your Samal token and make decisions based on those where the information comes from, whether SAML or another authentication protocol. It, it doesn't really matter. And indeed SAML and Z will do play well. And we like to think in his Zal community, that we're Sam's kid brother,
Okay. Brother, we in the Sam community
Cousins,
We're not even related. Let's see. There's another great movie metaphor that I want to use to get to my point here. And that is in Prometheus. I don't know if, how many have you seen that, but in one of the opening scenes, there's this gorgeous alien. Who's obviously on some quest and he's standing in front of the oceans of a, of a, a planet. And he disproves from his robe and he drinks the elixir and his, his being breaks down into DNA and populates the ocean. Of course, the Ridley Scott's idea there was to make you believe that somehow the CBRN explosion of everything that happened at 150 billion years ago was initiated by an alien race. And that's what, how the planet became populated with plants and animals from, you know, the single cell organisms we had at the time. So my point with that is that I think we're at a point in time given with the clout, the computing Shikha that I call it, the cloud computing, social computing, mobile computing, that the number of identities that we're being faced to deal with is a Cambridge explosion of everything on the internet. It's not, it's not thousands. It's not hundreds. It's not millions. It's not billions. It's bigger than that. And how so I'm interested in asking each of these protocol representatives, I guess, how are we going to scale to deal with trillions of identities and federate them and match them to the services of each other without, you know, 2 million administrators
Or more than 2 million administrators as it'll probably work out. I think we are gonna see a lot more dynamic. And we often use the term just in time creation or management of accounts at local endpoints to that, to that point, this view of command and control, where there is a long running enterprise like life cycle behind every single account or identity will not be maintained in that level of, of explosion. But I do think there's always gonna be a set of reflections of identity and accounts that do need to be managed our, our company we're in the identity and access governance space. And all we care about are things that people care about. They care about how many accounts they, they have to know what the attributes are. They have to know what the inferred access is from those. And so for, for us in that world, skim represents a way of very, very simply and very, very natively transferring an account or a set of attributes, which is more meaningfully what it is between two domains.
So skim tries to make it as simple and, and to, to Mike's point, I mean, it's a, it's, it is get, put, get, put post elite. It's a very, very restful approach to a set of resources. And very importantly, it has a defined base schema. Those of you that followed SPM L could we produce a base schema for, for, for a person? No, I mean, there's one out there. I know old person, I mean, how can it be? But skim takes that step and says, look, here's a base set of attributes that represent this, this identity. And here is a, you know, almost idiot proof way of expressing that in a simple, in a simple get to retrieve or in a simple put to create. And so it tries to make that simplification to try and help. I give you, we're not gonna use, I don't imagine in the trillion identity world that will need that for every account. But when we do, when it's triggered by a policy or by a control point, we're able to issue a very simple rest based push to push that account somewhere, to create a control, to create a billing, to create something of meaning.
So if I'm at a party with people who are not geeks, there are such parties
I'm sometimes asked, well, what do you do? Fusion drive? And I will often say, well, I work on digital identity and I wait till their eyes start to glaze over. And then I'll say you usually experience that as all those usernames and passwords, you have to have everywhere on the internet to do anything. And almost universally at that point, people nod and say, yeah, that's really bad. And I say, I'm, I'm trying to make that better so that you don't have to have all of those. And it goes from they're ready to glaze over to, oh, I'm really glad. I hope you can do that because people know that this is not how it should be. And this goes to Craig's trillions and trillions and gazillions of accounts. In fact, we're at a sea change point Federation used to be this hard to configure largely only attainable by a priesthood tightly coupled connection between consenting enterprise administrators
N never really got broad social appeal. Now, if I go to event bright or lady gaga.com, or Lord knows whatever sites there are, I can use my Facebook account or my Twitter account or my live account, or my Google account generally, and interact with it that way. And people like that better. They don't know they're doing Federation. They just know that they didn't have to create another username and password and life is better. And so, you know, like many technology evolutions, it's not coming out exactly how the master planners envisioned it, but the need is there. And simple solutions are being deployed by sites and by applications, cuz it makes life better for their users. And because people were, are more willing to use their site. If they do go with this federated approach and guess what? Once you do this simple connect like experience, you may get these, you know, OAuth access tokens, which are, you know, simple Mr. Fusion kind of devices that give you access to APIs, but all that's happening in the app for you. You're not having to be aware of it. So we're trying to manage the gazillions by eliminating most of them.
So I'll take a side step. Zach mole is not about identity per se. It's more about access control. So whether there's one identity or million or gazillions, it, it doesn't change a thing for Zal it, it just scales. If anything Zal will thrive from the growth of those identities online, cuz there will be a greater need for better access control. I don't really go to parties. At least not the non nerdy ones. I go to the nerdy parties. But when people do ask me what I do, I used to say, I work in security and then they thought I, you know, did antivirus. So I changed my story and last time my niece asked me what I do. And I said, well, I'm I, I do authorization. I, I get to say what people can or cannot do. And she goes, oh, so when mom says I can have ice cream, that's you? I was like, yep. Zal does ice cream. So the point is very efficient,
But
Very efficiently. Yes. Yeah. Can I have ice cream? Well, let check, how old are you? Yeah, you can have ice cream and to Darren's point skim will help spread attributes and standardized attributes. And that's beneficial to Zal because Zal is an attribute based access control language. It's not so much about the technicality of how Zal is written. Forget that it's about attribute based access control and dynamic access control. Deciding when you can do something based on attributes that you trust based on attributes that have been distributed across the different systems. So if anything Zal will thrive from the growth of identities and from ski.
When, when people ask me what I do at parties, I, I say I work with John Bradley and that pretty much kills the conversation. So, so to the, the fundamental challenge, I think that that Craig highlighted is scale and more critical to solving scale is not the particulars of the protocol or the nature of the tokens by which an application is accessed. I mean, web services in the soap world assumes a Sam assertion is, is the token by which a client authenticates and, and gains access restful APIs say, well, no, that, that token is an OAuth token. That's fine. More critical to solving the scale of trillions of clients, calling trillions of apps, whether they be toasters or microwave ovens, whatever the, whatever the, the axis is, is mechanisms by which you can discover those apps and those clients by which you can scale the trust between them.
So that trust isn't a pair wise decision, but rather can be based on, you know, a broader trust framework. Those are, are more important than the specifics of the protocol. Mike highlighted, you know, that old school Federation was relatively static and that's true. SAML historically has relied on a, a relatively static trust model. Admins got together, exchanged metadata, exchanged some keys and that worked and that wasn't inappropriate given the nature of the relationships between those two actors. These were businesses, they had legal agreements. These were schools and libraries. They had agreements nowadays they're enterprises and SAS providers. There are legal agreements. There wasn't that existing contractual relationship between the actors in an open ID world. It's very ne necessarily was dynamic. So historically SAML was a relatively static trust and connection model, but even that is not scaling. So, so we are seeing, and, and others in the SAML community are seeing the need for a more dynamic model where the decision to connect to a SAML IDP, isn't driven by the lawyers getting together in a room, but it's, it's driven by being able to obtain trusted metadata about that IDP and making your decisions based on that metadata rather than a, a priority business relationship.
We have a equipment
Here and that's true for other protocols as well. Okay.
My name's Andrew Ferguson. I of, you know, me, some of you date, I've got a three point question that I'd like to post. I'd like to ask David to give us a little bit of a, an update on what's what's next for exactly more three, three. What, what are the, some of the other interesting things that are happening in the exact world? David's a key key guy there in terms of the, the standard. I'd also like to ask David and perhaps even the panel to, to comment on, there's been a bit of a press written by a colleague of ours. I think Andrew SAR from Forester saying exactly whats did. So maybe, maybe David and others can talk to that particular thing. I've got a particular view of it. Anyway, that that's, that's something that should be asked. I'd also like to ask Michael, I I've recently found out that a Azure ad is not going to support, not currently supporting and no plans to support skin.
I think this is a dreadful piece of news. And I think for Microsoft not to be playing in the Ossa space with skin, I'd like to hear what Microsoft are, are planning there. My big concern is that, is that they're only supporting the graph API. I think that, I mean, it's great idea, but why aren't they using, why are they joining party with the rest of the industry? I mean, the work that's going into ski is actually delivering what graph API is setting out to. And yet you should be supporting the, the Oasis process. I'd like to get the, the Microsoft viewpoint on that. The, so that's, that's how I suppose there's a pointing question. And then I'll Darren, what more can industry do? What can we more do the industry and, and the, the community out there to drive more usage of skin? I, I think, you know, having lived through all the kind TML, I, I take my hats off to the work guys are doing with skin. So, but what more can me as the industry do to actually make Mike get back,
Thank you for that.
So I'll, I'll start with the work being done at thesal technical committee. Few months ago, another Analyst said that we needed to kill off identity and access management so that it could be reborn in a better shape. And, and E and the Analyst in that video said that we needed to drive adoption of standards in order for those standards to succeed. And I think that's what we're focusing on right now at the Zal technical committee and that's adoption Zack one, three was ratified as a standard back in January, and now all the parties involved and there's more parties than ever before. UDS is a fairly new member to the Zal family. So it's a growing family. And now we're focusing on developers, we're focusing on profiles to make it easier for the industry, the likes of Boeing to work with Zol, but also for developers to have interfaces, they're more familiar with raise cinema of EMC, developed a profile to be able to exchange authorization decisions using them now using rest.
So instead of using soap, which some folks believe is pretty heavy duty, at least it's clean. You can use rest. That makes it easier. That makes it much quicker to integrate. It also means that you can do Zac Mo and more languages than you could do before. And Zack will tended to be for perhaps done in a Java in the past. Now that you have rest, it extends to Pearl Python, Ruby, and all these new languages. The other profile that we're actively developing is a JS O profile. Actually, I'm actually writing that profile and the idea is to make it lighter weight. So to Craig's point, a lot of people and you to be part of these people, don't like XML. I fell in love with XML. I'm still in love with XML. Anyway, I decided to do the JS O profile to make it much lighter to use.
And, and Paul and I were exchanging ideas on how to make an authorization request, which at the end of the day is just a question. Can I do this to make that question even lighter? Because to some extent we don't even need JSUN to ask those questions, we can make it, you know, just an HTTP get request with parameters in the URL. You send that off and you get a yes or a no back, or maybe you get an HTTP 200, 2, 200, which means yes. And a 4 0 3, which, which would mean no. So we can make things simpler. Then the second question, I don't Andrew, I forgot what the second question.
Speaker 10 00:30:01 The second question.
No, there was, there was another SK question.
Oh yeah.
Oh right. Oh right. That's why I forgot it. So obviously I'm gonna be biased. I'm, I'm, I'm work for one of the vendors, but one of our customers this morning, who's actually at the back, commented on the fact that Z will had been pronounced dead for, for dead standard. It's pretty dynamic. It's about dynamic access control. And also we, we see more and more customers than ever before. We see more competition than ever before. It's, it's definitely growing, but we do need to drive for adoption and adoption will happen through developers and through the right tooling and, and, and through making Zal easy. And, and as Sebastian was saying this morning, you wanna hide it away from the developer, the developer, shouldn't worry about security. The developer shouldn't worry about Zal or SAML or wealth. It should, it should be done automatically for the developer, for those folks, writing your apps. It's not the business of the developer.
Let I would be one of the vendors that would make a comment like Sam is dead or ZMA is dead. And it isn't because I think they're dead protocols it's to get your attention, that that things need to get simpler. If we're going to deal with the Cambridge explosion of everything. And, and when I hear David say that they're getting it restful and doing JS, that's what I want to hear. That gives access to the kinds of environments and coding and people that make it scale. And I that's, that's a good thing. So I'm really happy to hear that to now, before Mike answers, the last time I met with Microsoft and Kim Cameron and John shuck who were doing Azure active directory, there definitely was no refusal to support skim from them. So I don't know who you're getting that information from. They basically said, if that's what we need to do, then we're definitely gonna consider it. But the Azure, the graph store doesn't need schema. So I don't, we don't have to go right code to support schema in order to support, skim as a protocol, working in the graph in the Azure active directory. And that's was their thinking, do you wanna say more than that?
Sure. I'll, I'll actually first speak to the X's dead kind of assertions. I, I, I know that, you know, people who contr panels often want con controversy, but I'm actually going to fail to give it, at least in this case, you know, for decades, they've said that the mainframe is dead and yet mainframe sales are larger than it is a niche part of the computing environment. But it's a very profitable business. People have said, oh, Sam is dead. It's being replaced by this and that. Some of which I work on, I am sure that Sam adoption is going faster right now than it's ever gone. That doesn't mean that I'm not committed to building things that are simpler to deploy that internet developers using Ruby and Python and rails and.net will just have tools to do federated identity. Not because they're identity geeks, but because they wanna solve a problem. But you know, Sam's not very dead. If it continues to grow in adoption, people will use it where it makes sense. People will use new protocols where it makes sense for their business. I was talking to Jerry Gables about, you know, ripping him about the exact mil is dead thing. He said, I'm not gonna speak to that. I'll let our customers speak. And they're not saying it's dead for them
For,
Yeah.
Yeah. Maybe I'll just, there you go. Ice cream cone. Now I may as well. Cause I was gonna say to come back to your reference about mainframe, I think that's quite pertinent here. I don't think anyone's saying that it's, it should be killed. It's saying it's where something should be focused. And that doesn't mean that, and the point is for an right, there will be a lot less authorization engines there. Aren't gonna be trillions of authorization engines. There's gonna be a lot more service points than there are today. And I'll wager a good number of those service points that want to make attribute based access controls will define their policies using exact more it's down here. It's kind of it's it's in the infrastructure. And I think we're pointing at is the simple point is where do you, where would you point a new developer right now? Where would you point a new process? I think that's, and that's what you were saying. We're in agreement, we're in agreement. I think it's also to talk to the skim thing for a hundred back over. I mean, Microsoft is participating. I mean, let's be quite clear in the I ETF process. Microsoft has folks there, the fact that it's not being committed in their product is only something perhaps that you can change vendors, do what their customers, hopefully what their customers ask for in some instance. So I think
That's the reason I asked the question through Microsoft enterprise customers to and Microsoft came back and said, sorry, we're not gonna support every single app has to use. And that was very strong message. We got Microsoft. Now that to me is a great, now maybe the plan is at some stage in the future. I think that's the thing to the app vendors that they have to only support API for doing what is really a very simple thing. Get close to the, sorry. So that's, that's, that's why I asked the question.
So I'll speak for Microsoft for a little bit, I guess, but first I'll return your question with another question. I'm a standards professional, which version of skim it is presently a moving target. It is a series of ITF drafts with substantial numbers of large open issues that go to the core schema that go to how you authorize access to the skim end points I could go on. I'm not our immediate skim representative, but my colleague is right. Tony Naline who's in my group, who is in the Azure active directory team. As I am is not just a lurker in the skim working group. He's on the design committee. So take from that. What, what you will Microsoft like many of your companies is one that there's pretty tight control over. Who's allowed to pre-announce features. I'm not in that set today, but you don't have that authorization.
No, I do not have that authorization. It's not dynamic and it would be consequential. Should I violate my, my authorizations? But you know, it's, it's clearly the case that it's something that we're investing in Mark Wall from LDAP fame. Who's now in a partner group with us wrote an OAuth profile for skim saying how to do authorization to skim endpoints as OAuth protected resources. So I don't think in, at all, you can characterize that we're disengaged or disinterested. It is often the case that until we believe that a standard is fully baked, we won't implement it until it's baked because unlike many companies, once we build an API, the default posture is we will support exactly that API in a compatible way for 10 years. So we don't jump into stuff. That's a moving target.
I mean, I'll come to your rescue perhaps as well say
I don't need rescue, but speak as you will. Okay, well,
I'll speak cause I'll, I mean, I was, I was on a speaking platform a couple years ago in Amsterdam, here in Europe from Australia and Ronnie S was immediately following me. And he, he, I actually almost fell off the chair at that stage when he stood up and said, by the way, I'm pleased to announce that Microsoft is now gonna support Sam too. And of course to that period, the only thing there was supporting was Ws Federation. And I think that absolutely shocked the audience, but cause for so many years, you know, it was Ws Federation. Cause the only way to go, this is the way the Microsoft way. And I was, and I was so pleased that they decided that gonna support someone to, so I applaud the work that's happening. I thinks doing a great job or whatever. I just like to see some move forward where Microsoft not insisting that the way to integrate is
So, so, so, so my takeaway to you is finish the spec.
Well maybe, maybe I can address that. Is there a Microsoft now? No, not anymore. Not anymore. Maybe I can talk a little to the, to the standards process. I would, first of all, say that ski 1.1 under an O F license is implementable and has been implementable at implemented by several it right now, if you have a dev instance in, in salesforce.com, you can make a, a skim request and create an account. So it's very, very doable. But I think to an I P question, the licensing model for web foundation doesn't work for everybody. So it's moved to, in this case to I ETF to take that forward and to Mike's point, it is a moving target in, in, in I ETF. So maybe if I fold that over to answer, your second question is how would we push forward adoption? And I'd say, that's partly is connected to that.
I'd say one is from a vendor perspective, don't make us try and boil the ocean. That's where SPM L went wrong. It tried to be everything. It tried to capture an entire domain model, which was not necessary. Keep it simple, which means it won't do everything everyone wants it to do. And that standards process is very complicated to achieve that. It's a, it's a matter of consensus. So to the vendor community, I'd say, hold back, you know, that's, let's get a 2.0 in ITF done very, very, as quickly as we possibly can. And then, so that will help adoption cuz then the core vendors. I mean Google force ourselves ping others are, are very actively involved right now. But then the second side of the adoption is back to the user community. Those of you that are in that side of the, the coin, again, put, ask as this, gentleman's just done. Ask, push, push your vendors for the support cuz that's the, the way you'll, you'll get it to happen.
I have a rule of thumb about how long it takes any committee to agree on schema. And for one element of schema takes one year. So if you take 10 schema elements, it takes 10 years. Now. I, I don't remember exactly how many schema there elements there are in skim, but it's more than 10. So if it's moving faster than that, guess what they're beating everybody else previously, anytime you add a schema element to a standard, you, you, you basically, you know, put nails in the road and if you're gonna try and get a committee to agree on schema and publishes it as a standard, you know, it's very tough. And if they do it faster than that, and this is probably one of the reasons you're getting pushback from Microsoft to say, you know, go use the graph story and that's not a bad answer. I'm sorry,
Going, going back a few minutes and a few topics Darren made a comment about where
Are you guys doing?
So we're implementing, yeah. We're contributing, participating. We were involved in the formation early formation and part in the last. Yeah. So Darren said something about, you know, where would we guide customers? What protocol would we guide customers if they were starting now? And, and we would, we would make that same analysis and decision and it would depend on two things. What's the use case Sam was never optimized for mobile. So we won't push SAML for a mobile use case. And, and second, we can't forget that the nature of these specs necessarily involves two parties. So, you know, no app is, is an island. What you do has to work with what your partners do. So open ID connect, as an example, might be optimal from a functionality point of view for a given use case. But if your partners don't do open ID connect, then necessarily you've got to look at alternatives and until open ID connect achieves the same sort of ubiquity in quotes that that SAML has there's necessarily gonna be a transition period and an overlap between those two.
And just to the, to quick the mortality meme, I think there's two ways you can measure the vitality of a standard. And one is the amount of creativity going into defining new features. So currently skim open ID connect OAuth to, to a certain extent Zima with 3.0, they're all enjoying relatively high creative contributions. The other way you can measure the vitality of a spec is deployments. So the more deployments there are is another metric that you can look at. Unfortunately there inversely correlated, the more deployments there are, the more inertia, if you will, to prevent the type of creative feature addition that a younger spec can enjoy. So I think it's just a typical normal life cycle that as standards become more stable and more mature and more deployed, you can't touch them. You can't do backwards. Incompatible features. That's what Sam is now.
All right. I think we have a question
Just to be unpredictable. I'm gonna ask a skip question. The a couple you've mentioned that there has been a skim, often people are deploying, but aren't there. In fact, two versions of skim as sometimes occurs in the industry. We have the facto standards and we have standards, body standards, and some people up there have been more guilty of the back standards than others. I'll I'll bring you, but should people be wait, actually be waiting for the I E TF skim two standard? Or is there practical, real world benefit that people can get with the pre I E TF skim one
Standard? Yeah, I think the, the 1.1 specification, as I said, very, very, very deployable to answer that question is, do you wait, I think move rapidly towards a rest Jason model for your API layer that I think that is, does anybody question at this point in time? So if you move in that direction with skim one, one, and then refactor to a 2.0 specification as ratified by I ETF, they are one in the same compass direction, without a doubt, the differences will be minor. And there is a commitment on the vendor side to continue to support the one, 1.1 specification. So I think if it were a questionable direction, I would say move down that direction. But I mean, I dunno, this is a pretty technical show. I gotta say, you know, who, who here considers themself a, you know, a, a spec reader and a technical person at that level.
Okay. Surprisingly small number because the contention I would give is the, the customer, the person using the end of what, what we end up creating really doesn't care about protocols. They really don't care about standards. They care about the user experience and they care about the rapid deployment of their services. So, you know, it's an interesting question as a technologist, they say, yeah, you're very deployable in one, one, the two OPEC is actually moving forward very, very quickly. And if we keep that meme to let's just keep it simple. It's very easy to stop a standards process, right? It's very, very easy to stop it on the schema. The reason people love ache to be in there, cuz it's something we can argue about for years, but how hard is it to create a mapping? Paul provided one for a mapping between Sam attributes and skim attributes. It's a document it's barely a page. It's very simple. So there's no reason to be stopped on schema.
We have another question from the gentleman here first. Just
Yeah, I, there is another cause I developers they'll not move.
So if I understood correctly, the question was that indication of vitalities the number of implementations, open source implementations of good quality. Was that the question or the statement is
Number, but they
Existence. Right? Right. And then the question was, are there any for Zamal three? Oh, I don't know specifically about three. Oh, but in terms of two, there are quite a few open source implementations, a few good ones. And there are at least two companies that are selling open source implementations. One is for rock in the Netherlands, sorry, Norway, same direction. And the other one is WSO two out of Sri Lanka and there are two pretty good implementations and I'm sure that they come pretty often in, in, in different RFPs and RFIs. So yeah, it's an indication that Z was here. And same question for, for se.
Yeah, I agree. I think that's a relevant third metric. Historically. Sam has had those open source libraries and vendors such as paying of interrupt with them.
We have,
I was just gonna answer that specifically, perhaps for ski, there is a, a 1.1 server implementation that's available. That's been open sourced by Unbound ID, but I would come back to say it really is that simple. I mean, my wife's completely non-technical she? Where are you going this time on the standards thing? What is all this about? I was able to get her to understand, you know, the simplicity of the method flow and the simplicity of what it's trying to achieve. The spec is pretty slim. Is there a need for an open source library? Are they sure was for Sam? I don't know is there's really a need for it with ski.
I'll pick that up as well. And in terms of Z will and open source, the same could apply. Z will engines are gonna become a commodity. They're gonna be so easy and cheap to implement that. You're not gonna care where they come from. You're probably gonna have them in your software anyway. And as for the SDK side of Z, well the, the enforcement side, they're so easy to write, especially with the, with the JSUN and the rest coming out. That again, you might as well just write an example and give it to the open source community. There's no need for a big project out there anymore.
All right. We had one question from the lady at the back. Yes.
Speaker 11 00:51:33 Yeah. I guess I mind if, if it's that standard or don't do anything that makes you guys, I'm just, I think all of these standards have been employed production by at least one company. Yes.
Yes.
Speaker 11 00:52:01 Okay. Well then
That's probably to good request.
All right. Sam skis. O all right.
Speaker 11 00:52:33 Sam wins.
It's I think we've, it's two win. Sam is not dead. We can declare it just
For the record. Sam won the last time we did this panel too.
Alright. We've got time for a final question. If anybody has one, that was a gentleman right here. Just
A quick question. John Bradley keeps getting reference point that that standard is that as implemented. I think Mike touched on this. How are these standards? A so could quickly of a owner they're, they're buying into a certain standard. And even though yes, it provides an assertion that gives you your identity. What risks have you addressed in standard don't need to go into, but I think that's question to ask
Speaker 12 00:53:59 You start.
I, I would just say that I think LOA historically has been discussed in the context of standards like SAML one party asserting to the other. What does LOA mean in an OAuth use case where the as, and the RS are typically co-located what does it mean for skim or Zal? I think it becomes relevant again, to talk about LOA for open ID connect, open ID connect is notable because it can stretch to those higher LOA cases that open ID two couldn't and that historically SAML, you know, if you tweaked it right, could which, which highlights, you know, attention, I think between Sam and open ID connect in the future.
Sure. So speaking for OAuth, you can go to blogs and press articles right now and find all kinds of OAuth exploits against real sites that are really bad. It's not that that protocol per se, isn't capable of being deployed in a secure fashion, but like many things it's certainly possible to deploy it in an insecure fashion. If for instance, you don't check your signatures or you don't verify things, you don't make sure that you're not doing cross domain scripting. There's many ways of doing it wrong, a, a critique in the industry of the SAML or the SAML, the OAuth standard, as it eventually emerged was it was a lot bigger than the input document it is. But if you look at what's bigger, it's almost all security considerations. The core messages are other than, you know, changing some names to protect the innocent are the same as the messages that came in. There's a heck of a lot more said about things not to do, or you will hurt yourself.
Yeah. To echo Mike's comment, it's in the implementation. It's very easy to make mistakes. And it is the job of the specification to pull those out. A very good example in skim 1.0, we don't mandate a bear token. It's a recommended model to use, you know, off Tolbert token, boy I'd like that to have been mandated, but you know, so that that's, that's, that's a door big enough to drive a truck through as they say. Right. So, so for sure, that's, you know, there's, there's always the case, a young specification. I'm sure we will have to address the same issues.
And I think that we'll leave that final word down to Darren. So thank you very much time. Three o'clock we just gonna do a quick five, 10 minute rele. So we get the next panel on where we are going to be saying it's not all about route. It's about integrating privilege management into your entire IM ecosystem. Thank you very much.
Speaker 13 00:57:15 Okay.
