#222 - Identity Standards with Justin Richer of Bespoke Engineering - podcast episode cover

#222 - Identity Standards with Justin Richer of Bespoke Engineering

Jul 17, 20231 hr 30 minEp. 222
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

On this episode of the Identity at the Center podcast, Jim and Jeff are joined by Justin Richer, Security & Standards Architect and Founder of Bespoke Engineering. Justin shares how he got into IAM and his book, "OAuth2 in Action". He also introduces "Cards Against Identity" and discusses how OIDC would be different if it were written anew today. The conversation turns to GNAP (Grant Negotiation and Authorization Protocol) and closes with a question from listener Markus about “trust in HR” and implementing automation being more of a political issue than a technical one. Tune in to hear this fascinating conversation!


Connect with Justin: https://www.linkedin.com/in/justinricher/

Learn more about Bespoke Engineering: https://bspk.io/

Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces - https://www.cs.uml.edu/~holly/teaching/91550/spring2012/p85-grudin.pdf

Book - OAuth2 in Action: https://www.manning.com/books/oauth-2-in-action

GNAP: https://oauth.net/gnap/

Cards Against Identity: http://www.cardsagainstidentity.com

Gridlock Boston: https://bspk.io/games/gridlock/

Checkout Psycliq: https://psycliq.com/

The Precious Cinnamon Roll: https://www.theonion.com/beautiful-cinnamon-roll-too-good-for-this-world-too-pu-1819576048


Authenticate Conference: Use code IDAC15PODCAST for 15% off your registration fees.

Learn more about the Authenticate conference: https://authenticatecon.com/event/authenticate-2023/


Connect with us on LinkedIn:


Jim McDonald: https://www.linkedin.com/in/jimmcdonaldpmp/

Jeff Steadman: https://www.linkedin.com/in/jeffsteadman/


Visit the show on the web at idacpodcast.com and follow @IDACPodcast on Twitter.

Transcript

This is identity at the center. If it has anything to do with I am, This is the go to podcast now your hosts Jim McDonald and Jeff Steadman. Welcome to the Identity of the Center podcast. I'm Jeff and that's Jim. Hey, Jim. Hey, Jeff, how are you? Oh, not so bad. Yourself doing great. I wanted to bring up the call that we had the other day, Megan and Adrian from over at the Authenticate Conference of Fido Alliance and that we're going to be on the Mainstage on the first day. Scary.

And what it Well, it is a little scary, believe me, it's a little scary. But what I thought was really cool about or what I thought was like hilarious, I thought they were pulling our leg because I said. You know, how long, how long of a session are we looking at? And they're like, oh, like an hour and a half. And I thought, oh, that's funny. That's really funny. But it was serious. So who knows how long it'll be?

Yeah. Because, you know, the more I give it thought after after the fact, I was like, you know, we could we have a lot of fun with an hour and a half. What do you think? We definitely could. I I don't think we've actually done an hour and a half on this podcast. I think the closest we've got maybe is like an hour 10 hour 15 even that we feels are really long like most people I think. Prefer us to be around 45 or 50 minutes, but sometimes we just go on and on.

We just can't get enough of our own voices, apparently. We try to make it sound natural too, but we could have a lot of fun. I think we'll probably settle probably on just under an hour or something. That probably makes the most sense, but. Yeah, it'll be interesting. We'll be up on the main stage and I think we're, I think technically we're a keynote, you know we're looking at doing like a live.

We haven't figured it out. So this is obviously all subject to change, but I think the idea is to do almost like a live. Podcast episode in front of people, Try to get some guests to come on, maybe talk about different issues and things that are going to be referenced throughout the conference. But yeah, it's very cool. Yeah, the Authenticate conference is coming up. We'll be there. We've got discount code ID AC15, podcast ID AC15, podcast. Get you 15% off of your registration.

So definitely use that. That's a good way to show support. You know, for the for the podcast itself, it's October 16th to the 18th. It's in Carlsbad, CA, so nice on the beach, a little bit north of San Diego. I think it's on a golf course. So yeah, kind of a nice deal situation. I've got to say, I'm not, I'm not proud of this, but I do kind of judge conferences based on where they're located. 100% that

and their cookies. Yeah. So I looked at, I was doing it a meeting we had today and there was. You were on it. Few other friends were on it and we jumped on Google Maps and I brought up there's a four drop conference way back in the day at the Asilomar Conference Center. I was like that was probably one of the coolest conferences. I was at this one also and they also had another one at Half Moon Bay. This one, this location looks just as good man. I mean it is like Primo

location. So if you're on the on the fence. I'd say the location should put you on the other side of the fence. Yeah, for sure. I mean ideal location, good time of year, October, I mean it's great. It would be great weather. It's California, so it's always pretty good, but that's a good time of year. But yeah, so that's our, that's our plug.

Come visit us, come visit the Authenticate Conference, come support Vito, come support us. We'll have links in our show notes, Authenticate Con Co, n.com is where you can go to find more information, make sure you get that hotel booked so you can stay. You know, at the resort that it's at, you don't have to like take an Uber that's always, that always sucks man conference. And you're like, it's not

convenient. It's just it makes a world of difference to be right there rather than having to commute in every day. Absolutely, yeah. And it's also not like Vegas, where you can just walk from hotel to hotel. Right. But even that could be like a 45 minute walk just to come from. Hotel to another. Yeah, a. 150 degrees outside too, yeah. We're going to talk a little bit about identity standards and stuff.

You were talking before we get started that you wanted to get provocative with it. I don't know how you get provocative with an identity standard, but I think you're going to try. If the podcast just cuts off unnaturally, we went too far and we said that was not family friendly. Yeah, or if you hear like awkward edits of me trying to like carve out, like, yeah, we probably shouldn't have gone there or something like that, so. Maybe I think we'll be okay, but

why don't we get into it? We're going to talk identity standards today as a guest. We've got Justin Richer. He's the security and standards architect and he's the founder of Bespoke Engineering. Welcome to the show, Justin. Thank you so much for having me on. Thank you so much for joining us. We're going to talk a little bit about your identity background and just start peppering you with a whole bunch of standard stuff, cuz you've definitely been a major player in this

space. One, I'm going to compliment you again on your audio setup. You've got the nicest mic I think we've had yet on the show. You've got your whole audio setup. I know you do music. We're going to talk a little bit of that later. But I really appreciate it and it and I mentioned this before, we hit record the breath control and the mic technique.

This is an audio podcast, but we have video that we run behind your the scenes just to kind of you know, help us kind of coordinate who's talking and stuff like that and for those who aren't familiar. You know, when you're talking into a microphone like we are, you want to try and get away from, like, mouth noises, right? And breath sounds, like, right. That kind of thing. And we were like getting prepped and like going through our preflight checklist, right?

And all this stuff. And I noticed that as you were, as we were talking, you like, put your head to the side and like, did your exhale so it would go around the mic. Chef, kiss my man. Thank you so much. Happy to help, but yeah, I did radio back in high school and in college and we didn't have nearly as nice a gear at the little College Station. So in order to not completely trash the on air sound, you learned a few things about how to clean up the signal. Yeah, for sure.

I go back and occasionally I listen to the first episode of this podcast. It's on a condenser mic. It was a blue Yeti, I think it was very echoey basement, no sound treatment. I mean it sounded fine for you know, we had no idea what we're doing. And then you Fast forward now it's like okay now we we still don't know what we're doing but at least it sounds a little bit better. So gives us a little more

credence of that. Let's talk a little bit about your I M background because you have definitely been really. At the ground level of a lot of the stuff that a lot of organizations use for authentication, potentially some authorization stuff, but we always like to have a little bit of the origin story when it comes to identity. For our first time guest, how did you get into the Identity and Access Management field? Is it something that you chose

or did it choose you? It definitely chose me, so my. My research background back when I was in undergrad was actually in collaboration systems. So getting people to work together to talk together a field that eventually became known as sort of, you know, social computing. And that led into the whole web, 2.0, blogs and wikis and everything else when all of that was new.

But in working with all of those systems, you know, obviously you need to be able to identify people, you need to be able to connect systems together, You need to. Have security on all of these things or else it just you know

stuff doesn't work. And I was finding that through all of these projects, you know as a you know an impetuous young engineer I would build the thing put it out and then our info set group at the place where I work to be like, yeah, no, turn off all of the functionality and that's that makes it secure. And it's like that's you know you're you're missing the point like that's the the point is to go do all of the things that

we're doing and. After going through that experience a few times, I realized that, you know, I really should learn what the security side is looking for and sort of get involved in that space. And that's how I got involved with kind of looking at things with a security and access and all of that mindset. But as a consequence, because I kind of fell backwards into that space, I tend to approach a lot of security architecture in a

way of looking how can we get. The most functionality possible and still make it secure. So focusing on that functionality side of things and it's like okay, this is what we want to do, this is what we need to do and how do we actually, you know, make that function secure As opposed to how do I shut off as much as I can in order to make it as secure as possible Because at the end of the day, a system with tons of security and no functionality is useless.

But a system with tons of functionality and no security is the most popular app that everybody has ever used, right? And then this is this is just true time and time again. Yeah, and I find also to like bad security is like a rock and a river. People will just find a way around it. And Oh my gosh, yes, it's the in the workarounds often tend to be much worse than the thing that you were trying to prevent in the 1st place.

You know, we tell people like. You know, come up with a complicated password that means people are just going to write it down because they're not going to remember it. And all of these things end up working counter towards the goal of the security engineering, like what you were actually trying to do, because it gets in the way of people actually doing

things. And I think that that kind of disconnect is a real problem in our industry on the security side, on the identity side, people aren't often looking at. Sort of their little slice of the world in a bit of a vacuum and trying to figure out, like, OK, so how can I make my little bit the best that it can be without looking at the larger context of where everything comes together?

In my opinion, there's a there is an academic paper that should be required reading for everybody, and that's it's from 1988 and it's Gruden at all. Why collaborative? Computer supported collaborative work systems fail, and in this paper they look through a digital calendaring system that was bought by the management of a company and then handed to the admins. And as far as the management was concerned, it had all of the features and everything that they cared about. It was brilliant.

But the admins who would actually manage all of the calendars and that were like putting things in for these executives. It was atrociously bad. And this disconnect between the people that are sort of designing and selling the system and the people that actually have to use it to do something at the end of the day was just

insurmountable. The entire system was a massive failure and led to the writing of this paper and and in in my in my opinion this paper should be like day one reading of anybody getting in to really any type of. Human facing computing at all. You know, just as you're talking about this, I'm also thinking of kind of the security architect mindset almost has to be creative in a way, right? It goes beyond just, you know, it's not like a type, a personality type, a personality kind of.

I don't want to say it as excluding people, but really you have to. Be able to use that left half of your brain mm. HM Yeah, Because you need to be able to think in sort of all of the weird ways that people are going to use the system or apply it to things that you can't expect and be able to adapt to that. And, you know, that's. Because, you know, fundamentally, identity systems are all about where this stuff starts touching people, where it starts dealing with people.

And people are weird and squishy, and we do things that are, like, really unexpected. And so when you're designing a security architecture, you have to account for that weird and squishy stuff. Yeah, two of the things that I used to do when I was doing some software engineering. Courses and having to write some programs was I'd find that sometimes my brain was very active and I had to have like a

notebook nearby. I had to keep a notebook next to my bed because I could wake up in the middle of the night with the solution or be going, you know, drinking, you know, a lot of caffeine. And my mind would just become so active in the ability to kind of solve some of these problems. I'm wondering, is that what you experienced as well?

Yeah, I find that the the ability to kind of background process hard problems is really important when especially when you start getting up into sort of the architecture level of stuff, when you're looking at systems and systems of systems and how stuff comes together, there's there's a lot of stuff that you're not going to notice right away. But. If you engage in with the problem space, you're going to kind of keep thinking about it. You're going to kind of like keep percolating on it.

And then you'll come up with sort of these, you know, interesting and creative approaches to things that you wouldn't have if you were just sitting at a desk saying, I am solving this problem right now. And so for for my part, you know, I'm, I'm an independent consultant. I have worked from home for the last eight years.

So for me the the whole switch to virtual meetings meant that everybody else was also working from home during all of these meetings that it didn't really change that part for me. But what I've found personally helpful is I I ride my bike a lot. I I do, you know between 10 and

20 miles a day. To just get out there, clear my head and let things just kind of background process and that type of contemplation I think is not really valued enough in the technology industries nearly as much as it should be because that's that's where creativity happens that's where this kind of like. You know, I got an idea of a way that I might be able to approach it.

I don't know if there's something there yet, but when I get back to my desk, I'm gonna, I'm gonna try this thing that I hadn't thought of before. And you see where that goes, See where that lands us. You know, I think this is this is really interesting topic because I feel like we scheduled. We get so busy during the day, right? You're jumping from meeting to meeting to meeting and there's no time to think. It's just I'm reacting all day long, right?

Absolutely. Yeah, I think it's important to to, I hate to say it, but schedule time to think, right? Maybe if you it's bike riding for me, it might be playing video games you know, whatever it may be, right? Inspiration can kind of come wherever. But we don't. I I feel like it's a trap that a lot of us get into is we don't actually take the time to think about something. Yeah, absolutely.

And it's something that I've had to explain to some of my clients over the years is just like, well, you know, I am, I am going to basically, you know, get up to speed on this project, which means I'm going to go and read a bunch of stuff and think about it and that takes time. That doesn't seem like that

would be a billable activity. But me actually writing a document for you or developing software or, you know, giving you guidance on how to engage with something, none of that can actually ever happen unless I can get to the state where, you know, I have had a chance to think about things. I have had a chance to start to piece these things together and

be able to bring that forward. So yeah, if you need to schedule time to think, absolutely do it. I like I I encourage it Back when I had, back when I had a real job, I used to block out parts of my day to to just not be in meetings constantly and highly encourage people to do that. You know value your own time. And the other thing that took me way too long to figure out in in sort of the corporate space. That you don't have to go to every meeting you're invited to.

Sometimes you can just not go, and it feels wrong. But you know what it Sometimes you're more valuable not being at the meeting. And that's a really hard lesson to learn because we're told like, oh, you have to be there. You have to be in the room when it happens. The thing is, like most meetings is not where things happen, right? That's that's not really what meetings are, are. Are good at meetings are not

about getting things done. Meetings are about sort of getting a direction, getting some cohesiveness and then you get out of the meeting and get things done. And so you got to make sure that you have the time to get things done and that's that's really, really important. Yeah, I I I think we probably just end the show right here. The the sound clip it, you know, sound bite is meetings are not where you go to get things done. Yeah, There we go. Done. Thanks for listening, everyone.

And yeah, we'll go for the next one. No, no, I think you're totally right on. You know, I think a lot of people don't understand that they control their own schedule, right? And you need to be able to control it. Or they're told that they don't control their own schedule. Right. And I think sometimes can be challenged, especially for maybe people who are newer in their careers, newer with an organization, you want to make a good impression and blah blah, blah, right?

But I think I'm with you. It's like, you know the. The the older I get and yes, the higher I go up with an organization, I feel like I do have more control over things. Sometimes I don't. I have less control because sometimes there are things like, no, you have to be there. And 100% it is going to be a waste of my time, but I need to be there, so be it, right. Those are there will always be those. But yeah, I think this is something I talk about with my team.

Jim knows this as well as you know, you control your schedule. It's okay to say no. I had a manager once, very long time ago, my food service career. The customer is not always right. Absolutely. So it's it's funny that it, it's fascinating to me that you brought up that phrase because one of the things that I did learn, so I previously worked for a company called Miter for 15 years. They're a big systems engineering company, do a lot of research for the US federal government.

And one of the things that I really got to learn while I was there at Miter was that the customers that we were talking to, it was. They would come and tell you what they wanted you to make, right? I need you to build this system. But the thing that the customer says, the thing that the customer wants and the thing that the customer needs are three very, very different

things. But it was really impressed upon us, in my group at least, that it was our job to be able to figure that out and be able to articulate to the customer that like, well, hey, OK, you, you said you needed something that did this. But your actual problem that we're seeing is actually more like this. And so we're looking at doing this type of thing.

And because we were a research arm, we could be a, you know, a little bit more like, hey, here's a weird thing that we, we think is going to address something and here's why. And our customers were a little, little more accepting of that. But you know, you you need to be able to at least tell the difference between those things and be able to tell that story. A diplomatic customer friendly. Absolutely, absolutely. One of the other things that I that I'm really grateful for.

You know, my my department head at MITRE taught me that it doesn't matter how right you are if nobody's listening to you. And that as a you know, hot headed young engineer, that was a really hard lesson for me to learn in my 20s and it took took me a long time and I'm still learning it, I'm sure. It's a but it is absolutely a journey.

It is absolutely a journey. But, you know, you need to be able to bring people along on that story and be able to sort of engage with people that it's not just hi, here's the solution. Shut up and do it. It's hi, here's the solution and here's here's why I care. Here's why you care and figure that out. Especially especially in cases where. You're going to be wrong in some way or another and you just

don't know how yet. And so being able to have that conversation of like yes we need to do this and have somebody be like but that's going to break my database and it's like okay, why is that going to break your database. Let's let's figure that out and and it it may upend the entire set of you know. Poorly defined requirements that you were working with in the 1st place. Or it may just be a little tweaked to something you don't know until you have that conversation.

I wanted to throw out a couple since we're all sharing Nuggets. I think some of the one of the early career Nuggets and it kind of goes with the you don't have to be in every meeting is that it's better to be known for one really awesome thing instead of a couple of mediocre things you know. So if you get so spread out it's like, yeah, you're on every project and. We all go okay, that's not as good as like, hey, you're on this digital identity project

and it was awesome. Like it changed the way the organization works. That's my experience. Anyway, #2 later in your career is kind of, I guess, know thyself, know what really gets you. So for me, digital identity if I focus on digital identity though. I'm probably not going to be the CEO of a major corporation, right? Probably not even going to be the CSO or the CIO, because I love digital identity so much. I want to focus on that.

I want to talk about that. I want to have a podcast on that and nobody. Will listen to. That, but that's what makes me happy. Right. Right. And I feel good about what I do. And I I'm able to get up in the morning and have energy for work. But and here's the third thing, this is not a career thing, but this is the life thing. Is even though we talked about like okay, you have to be able to have this time to think. You're also at some point need to shut off.

I had a friend his his sage advice was everybody's got to waste some time. Maybe it's you know the the video games or whatever it is, but you you've got to have more interest than work and maybe everybody knows this. But if you're in that mode where it's like you work all day and then you plan your weekends around how you're going to get all your work done. Then your life's not going to be something you really look back on and you're like, yeah, I

actually did something. You've got to have some some time. So you're building a a life. Anyway, I'll stop. There. No, I I absolutely agree. I have. I have three young kids and they definitely help keep me grounded. I've been lately been playing through the new Legend of Zelda game and my middle kid, they're ten years old. And they will just sit on the couch with me while I'm playing it and be like, oh dad, let's go that, oh, we need to go get this thing.

And and like, they're not actually playing the game, but they are so engaged with it that that's like, you know, that's something that like it'll be getting towards the end of the day and I'll, you know, come up upstairs from my Home Office and they'll be like Zelda. And and it's just like, all right, give me 5 minutes to go deploy this thing and then yeah, then we'll then we'll go play and then 10 minutes later get a knock on my door. Dad, Zelda.

And you know, it's it is absolutely important to be able to to do that kind of thing. 100% agree. It's definitely not a waste of time. We might think other people might say you're wasting your time, but it's actually well used time. Absolutely. And it all, it all comes down to how you measure value, right? What? What value are you getting out of the time? And all of your time shouldn't just go to creating value for somebody else's company. Boom mic drop.

There it is. I no this I do not want to drop this microphone. I'm. Sorry, no, that's a very nice microphone. All right, let's get back a little bit on track because I love that conversation. But I do want to get a little bit more about some of the stuff you worked on and as a. Multitalented individual right? An identity. And Speaking of articulation, you've written a book in this area. It's called Oauth 2IN Action.

It always fascinates me when someone can put pen to paper and actually have the, I don't know the the work ethic or whatever it is, sit down and write any set of book. But what was the impetus for creating that? And I guess for people who want to check it out, give me like the 32nd, like back cover synopsis for it because we'll have a we'll have a link in our show notes for this as well. Man. So yeah, the book creating it was was sort of an interesting story.

I was actually approached by my coauthor, Antonio Sanso, who wanted to write this book, didn't want to do it himself. He's a security researcher at the time, he was with Adobe and he's working on Ethereum now or something like that. And but really, really, really smart guy, really smart security

engineer. But he approached me like, you know, hey, there's there's kind of a hole in the market for a book about Oauth that actually takes things from start to finish and explains all of the different parts of it and why they work that way. And and I kind of at that point, I kind of looked around and I was just like he was, he was absolutely right. You know, the, the books that were out there were how to build an Oauth client that connects to GitHub, how to log in with Google.

How to use the Facebook API. All of those were books that would teach you parts of Oauth but weren't teaching you Oauth for its own sake. And that's what we set out to do. So going through the reader learns, learns how to build a, you know, because I'm, I'm an engineer, I build things, you know, it's not real unless I'm building it. And so going through the book, you build an authorization server, you build a couple of different flavors of client, you build a resource server.

And you connect them all together and they're all actually standards compliant, That we do have a banner in the book that says do not use any of this in a production system, please. And I have mostly held to my own advice on that. That's another story though, but we wanted people to be able to. Sit down, and even if you know in their day job, they're only using one tiny little bit of it, like they're just writing a client or they're just

protecting an API. We wanted them to be able to know what all of the other moving parts were that were that were out there and why they were moving that way. Like, why do I have to do all these redirects and all of these backchannel calls and all of this other stuff? Why do I have to deal with authorization codes and Pixie

and all of this other craziness? Because the danger is always somebody looking at a protocol like Oauth and seeing all of the moving pieces and going, you know what, that's really messed up. I can come up with something that is just as secure and way easier to build. And the truth is that it's like you can't. You know you're you're going to come up with something. It might be really, really clever, but it won't have had the kind of scrutiny that an international standard like this

has and all of those. Bits and pieces are there for a reason. Is it always the best reason? No. But there is a reason behind it. And So what we wanted to do with this book was to bring people through everything that was there and sort of show them what the reasons were, that things worked the way that they the way that they did. So if I don't know anything about a lot too, can I put pick this book up and and have a an appreciation for it? Or is there some prerequisite

knowledge that I need? No, I think you can. You can basically come in cold. We tried to, we tried to write it to an audience of people who had either heard of Oauth or we're told that they are using Oauth and needed to needed to start making sense of it. It used to be the case that the publisher put the first two chapters online for free. And honestly, I would say go go read those two and to give you an idea of how how the protocol sort of fundamentally works the

way that it does. I do like the cover of like a pirate or I'm not sure what that's supposed to be. It's like he must be here or something. He is a. Croatian Rifleman, so this is part of the. Part of the branding of that particular series of books from this publisher is that they get very localized period costumes for people.

And when Antonio and I were looking at the different options that they were presenting us with, well, the first one that we picked was this amazing illustration of this guy in LIKE. Full chainmail armor with like a 4 1/2 foot sword out in front of them and we're like, yes, yes, that that's that's going, but apparently apparently the like the head publisher came back with no, that's the wrong historical period for this security book and we're like, we

don't know why what. Does it even mean I? Know exactly. So we we went with a second option which was this guy and he's. A Rifleman from a village in Croatia. I'd have to, I'd have to go back through my archives to to get the information of where. But yeah, that was, that was apparently the sort of the the local dress for like you know the militia and guardsmen and and stuff like that at the time. I like it. I dig it. Check it out in our show notes. And the mustache.

But it is, and like the bandana anyway. The the next thing I want to ask about is Cards Against Identity, which is probably the opposite of serious Oauth 2 talk, but has taken the Identity Identity industry by storm I would say. A very small storm, but yeah. What is Cards Against Identity? Well, I'm sure a lot of your listeners will be familiar with the game Cards Against Humanity. It is a party game that. Really kind of came to prominence about a decade ago, I

think at this point. And the the conceit of the game is that one person basically lays out a prompt and everybody else that's playing provides an answer to fulfill that prompt. And it became famous because it took that basic game mechanic and just made it really raunchy and funny and just. It's with the right group of people. It is absolutely hilarious. Raunchy is not even approaching the level of. That's. Hilarious filth that is part of this.

I have played some some third party expansion decks that make this one look almost kid safe. Try explaining to your stepmother what certain things are. In the middle of the game. I absolutely have a story about that, but I don't think it is appropriate for this podcast, so maybe I'll catch you guys. After right of that game, absolutely. Regardless, that's Cards Against

Humanity, the base game. And so one of the things that they do with copies of this game is that they will send you a bunch of blank cards so that you can basically put in your own house rules and things like that. And there was a group of people that were floating around the. You know the identity conference circuit that had started to collect a bunch of these house cards that had identity themed

jokes on them. And so one of the answer cards was the entire, the entire WS Star documentation, which is a horrifying, you know, answer to anybody who's ever had to touch WS Star and so. I got invited to one of these card games at the Cloud Identity Summit way back in the day, the predecessor to Identiverse, and it was an absolutely hilarious game or like people were dying laughing.

It was it was amazing to just be in a room with all of these brilliant identity nerds making horrible, horrible jokes with each other and and it was a great time. So Fast forward a few years. And I was actually working on publishing a board game I had run a I think at that point I had just started to set up a Kickstarter for it was going to launch it. That game is called Gridlock Boston and it's you can find it under the bespoke website or I'm sure we can drop a link in the info bar too.

But as I was working on prototyping that game I realized that the. Small publisher that I was using could just print cards. And then I had the idea one day, like I could make Cards Against Identity an actual real deck. And so I got out my draftsman's ruler and, you know, tried to calculate the font pitch and the spacing from the margins and all of this other stuff to get cards that could match as closely as I could get them to the base Cards Against Humanity game.

And then I. I came up with a bunch of cards, some of which were from that house deck that I remembered, like the WS Star documentation is in there in the initial deck, and then added a bunch more of my own that I thought was hilarious. Like one of Ian Glazer socks is one of the favorite ones from the first year and really just tried to try to just have a lot of fun with it.

And to me it was going to be just this is a oneoff project, this is ridiculous and we're just going to we're going to do that and. Whatever I brought it to, I think it might have been identifiers at that point. And somebody who lived in the area was actually having a a party the day before, a house party the day before the conference started. So I was there with my box of cards, and I sold out my box of cards that I had printed at that

house party. Now I'd only printed like, I want to say like 30 copies or something like that, 20 or 30 copies. And so, you know, it wasn't that many, but I was just like, wait, people actually want that? I figured I would just be like, shuffling this around to A to like a couple of my friends and I'd be going home with half of this box. But yeah, no, it it it sold out before the conference started. And I realized like there, there might be something interesting here.

And so almost every year since then, I've tried to. You know put together a new deck that I release each year and with jokes that I find interesting and topical. Some people will write to me with an idea or you know I I get Dms on the ID Pro Slack every now and again of like hey, this would be a great card for next year and try to try to work them in when when they make sense and. Yeah, I've been I've there have been 4 editions. Now I'm planning on doing another one next year and it's

it's it's a blast. My favorite experience with the game though has to be at the Oauth Security Workshop last year because I brought at that point the three decks that have been published of Cards Against Identity and somebody brought their base game of Cards Against Humanity, which allows you some wonderful combinations, like you know the question card of why is mommy crying? And you can answer that with SAML, right? It just amazing bits like that.

And so here, here we were, a bunch of drunken security engineers playing this game and just falling over, laughing at ourselves because it was just so absurd, so funny, and probably one of the best times I've ever had at a conference. It was, it was a great time. I can't believe I'm going to do this, but I'm going to waste one of my questions. Definitely lets me ask so many questions per episode, but I'm going to ask what is WS Star for people who didn't live through that? Oh my gosh.

So imagine that you're trying to solve security by writing documents that only can be read by automatically generated document readers. So you actually have to write code that writes the code that reads the code that your code wrote. And in a nutshell, that's that is security based on WS Star. It's the web security family of standards and there's a lot of great concepts in there that

live on today. Oauth in a lot of ways is is a, you know an actual functional and usable version of some of the delegation patterns in WS Star. You know and Sam will take some of the the. Assertion patterns and stuff from WS STAR, but WS STAR itself is just one of those things that is like so complex. End to end. It is, it is nearly inscrutable. And so with with the joke card being the WS STAR documentation, it's it's a terrifying thing to ever be handed to read.

So I know that you are a musician. A game designer? An author? A security and standards architect? So what's the common thread there? I get interested in a lot of things and I've been very lucky to be able to pursue a bunch of those. A lot of the common thread though, I think is these are things that that encourage a creative approach and like we were talking about earlier, I believe with. You know, architecture, security, architecture really kind of takes a takes a creative mindset.

You know that that ability to contemplate that ability to think of how things might go wrong or might go right and what does that mean in that context? You really need to be able to to create those worlds in your head and also share those worlds with the other people that you were working with. And that takes a certain amount of creativity. The other thing that they have common is that they all work

within constraints. So you know, a book has like a technical book, especially you've got chapters and indices and examples and things like that music, you've got scales and modes and forms and timbre and all of this other stuff. Game design is literally all just math and spreadsheets under the hood, even if if you don't realize it. Like writing a board game is sitting down and doing a lot of weird math to make sure that nobody playing your game feels

like they're doing weird math. So it's kind of like the creative side of like, I wanna create this cool thing and I say, wait, how do I create it exactly? And then figuring that out. Within the constraints of the system that you're applying it to, yeah, absolutely. That makes a lot of sense to me, so I wrote this next question last night. Now, it kind of sounds a little weird, but I'm going to ask you or state it anyway. Have you have you seen the movie The Godfather?

Yes. And I guess who has, right. So I was going to say you're kind of like the Don Corleone of or Corleone of Open ID Connect and. Well, well, so OK, like I said. I'm curious to see where you're going with this one. So then I thought of this earlier today was do you remember the scene where Luca Bravi, Luca Brazi sits down with Don Corleone and he's very nervous. He's almost like reading from a piece of paper. Don Corleone.

You. Came up with many good standards for the Open ID Connect standard. Don Corleone, you've written many good aspects to the Oauth 2 standard, and so where I was going with it was this is terrible. I wonder where this is going myself. So This is why the pitch count. If you wouldn't edit it right to this part, it would be Don Corleone. If Open ID Connect was being written anew today, how would it be different? That is a great question. Because right there.

Well, no, I'm, I'm going to be honest, I'm struggling to see where The Godfather fits in with her, even though I did have a Godfather quote in the in the last presentation I gave at Idanaverse this year. The whole, you know what happens when standards meet the real world? It's like look at how they massacred my boy. But yeah, I I will say starting off, I, you know, I was part of a large group of very smart people who worked on all of

these things. I was very lucky to be in the right community at the right time to be able to work on this stuff. And you know, I'm, I'm far from the only voice and lost a lot of arguments in in all of that spaces. So that said, I think that if we were building Open ID Connect in Oauth today, it would definitely look different because it does look different today than it did a decade to a decade and a half ago when we started.

There are features that have been sort of grafted in to both of these protocols that weren't there before. So there's a pattern that's now becoming more well known called intent registration. And intent registration basically allows the client software to say this is what I'm about to do and do that, do that bit in a secure way so that when you then go and step and start talking to the users, then you can actually sort of deal with all of that sort of squishy user

space. Without having to worry about somebody mucking up that initial request of this is what I'm about to do. In the Oauth world, that and Open ID Connect to that is implemented with something called a pushed authorization request. If we were building these systems today, I honestly think that we would just always use that and that and that is that is in fact the advice of the Fappy Working Group. A high security profile of Oauth and Open ID Connect is to always

use that. Because there's a lot of benefits from doing intent registration and asking that question of like what would it look like if we built a system today That was a lot, a lot of the engineering behind GNAP, the grant negotiation and authorization protocol, which is in i.e. SG review in the ITF standards body, which means it's it's close to done. And what we tried to do with that project was take a step

back and say like, okay. Regardless of how how you do things in Oauth, what are the best practices and best patterns and things, and can we actually make this all kind of fit together? So another thing in the Oauth world is that when you're calling an API, you have a set of scopes. Those scopes limit what the resulting tokens can do. And it was brilliant innovation for 2010. Because previous to that it was either you get the whole API or you don't, right?

So scopes absolutely brilliant and work great. Well today we've now got an extra decade of delegated API access and people are realizing, like, I want this token to be able to spend $5 within the next month, but not more than that and at least $0.50 at a time. And being able to like really, really dial in that kind of stuff and be able to ask for that kind of thing and associate those kind of rights with these

access tokens. And so in GNAP, we came up with a structure that allowed us to express that. And then I actually worked with a couple of other folks, Brian Campbell and Torsten Loterstadt. To back port that to Oauth 2 and that recently became an RFC of rich authorization requests. And so in addition to scopes in Oauth, you can now say like these are the actions I want to take at this location with these

data types. And actually also just you know, customize that to whatever API it is that you're protecting and

so you can say things like. You know, I I need to do this amount of, you know, this amount at this time or or whatever you need to do. And I think we would have that kind of stuff just baked in from the beginning because we've learned more of sort of how this stuff gets used and and how people want to use it. I think that everything you just said there was, it's like, those are so many amazing concepts and

I also think like, okay. You push out a standard or you're working on a standard, it gets published. What if it doesn't get adopted? Does that indicate whether or not you were successful? Or are there other measures of success of publishing a standard? There are a lot of ways to measure success, and some of the, you know, some of the best things that a standard can end up doing is being an organ donor for something else.

You know, you get a concept and it might be brilliant and it might work right, but it might not be packaged in quite the way that people can actually use. Going back to WS Star that, you know, we were making fun of a bit earlier today, there were a lot of good concepts in that and being able to sort of talk about security in a in a systematic way was. Not exactly new, but the way that it was done was was kind of new. It was just an absolute disaster

to actually use. So a lot of people would say that, you know, because of that WS Star is a is a failed security system and by that measure it would be but and a lot of people have scars from that too. You know, by that measure it's also, you know, not successful. But The thing is we wouldn't be where we were today without that as a stepping stone. I don't think you know because we we have to learn these lessons somewhere. And so the ITF famously says that, you know, I TF doesn't

pick market winners. You know it's it's not, it's not out there to to steer competition in One Direction or another. It's out there to create the best technical standards that there are. And if there is a market niche that that fits things, then

that's great. If there's not, then you know the documents are there and their archive, they they may take life, they may take on life much later in a different space in a different way, or they may get sort of picked up, sliced apart and used in something else that you didn't anticipate. So I I think this could be a good segue into a listener question. So Mike Woodburn submitted the question. What are your thoughts on the current and future state of Uma? Are you seeing it being used?

Does the current incarnation of Uma have legs, or is there a need for UMA 2.0? So I was an editor on UMA 2.0, so that already exists for like 5 or 6 years. So modifying that to UMA 3.0. I would say that UMA was one of those things that it really pushed the conversation especially about user to user delegation and how we represent that in in systems. And it really pushed a lot of the concepts and ideas forward in ways that were not being

talked about elsewhere. It was packaged sort of together in such a way that was really hard to apply in a lot of spaces And so I would say by. By that measure, you know there are deployments of UMA, but they don't have the type of, you know, world reaching, cold boot capable distributed authorization promise that UMA is technologically capable of.

That said though a lot of the design tenants of UMA went into GNAP, a lot of the design tenants of UMA are being sort of picked up in. Different ways in different different systems. So you know something that's that kind of branched out from UMA is the ability to, you know, very dynamically connect a resource server and

authorization server. We're seeing some of that in in some of these, you know, more tightly coupled, more tightly regulated systems out there, not using UMA, not using quite all of that. Same tooling, but pulling a lot of the concepts in sort of new and different ways that that UMA introduced and did well with it but just didn't, didn't land in quite the same market kind of way.

So I want to do 2 more listener questions because I think it's it's fantastic when listener send questions our way and please if you're listening and you've got some questions. Send them over. This one was specifically you for you from Mike. Again, it was. I'm not sure what he was driving at, but I'm sure he had something on it. What's your favorite star back, I guess like our back about? Our back back things like that, so. Please say baby, baby got. That's that's that's a great one.

But I I actually have two answers to this. The first, the first, the more serious answer is is attribute based. Because I think fundamentally you can model all of these other systems using attributes. The problem of course is that attributes then have their own attributes and you get into attribute provenance. And how do I trust this attribute source and all of this

other stuff and. It very, very, very quickly spirals out of control to the point where somebody says, you know what, screw it, just give me a roll, just just give me tell me which of these attributes is roll and I'll just, I'll just go from that. And so I love the promise of the system. In practice it's it's a little harder to deal with. I think some of the dynamic policy engines and policy languages that we're seeing happen today, you know it's going to help with that a lot.

But you know, it's we've still got a long ways to go to make that really, really, you know, usable. I'm a fan of attribute based access control only as a starting point because I feel like a lot of companies, they're like, yeah you want to be role based and then they actually get into it a little bit and like wow, this is a lot harder than I thought it would be. And I feel like at least with the attribute you can get a kickstart and say okay well.

Can you answer a basic question? Are you an employee or you're not an employee? Do you work in this location or somewhere else? Right. Those sorts of things as kind of a starting block only because I think it's easier to start there, but mileage may vary. Obviously the consulting answer is it depends. Absolutely. And you know, a lot of that comes with the sort of the nature of these computing systems and computing security systems. They're they're good at computing against these discrete

models. Where if value is this or greater than this, then answer is yes. Which gets me to my true favorite, you know star back type system and that is CRBAC, the Cinnamon Roll Based Access Control. So there's a there's an old onion article from I think 2014. Where somebody just has this picture of this honestly rather mediocre looking cinnamon roll and they they are saying that oh, it is just too good. It is too perfect for this world, too pure.

And it's it's this hilarious little bit of writing comedy that got picked up and sort of run with by the Internet at large. And the sort of the epithet of cinnamon roll is now being applied to people who are too good, too pure for this world. Like you're you're a good person. You're just you are a precious cinnamon roll. And so because of that, there that came to be, you know a bit of a joke in security circles that you know what, Why couldn't we have something that you know

that the system. Like it. It knows that, oh, you're a precious cinnamon roll. Of course we'll let you in. And even though that it, you know, it is on the surface, it is a joke. That's how the real world works. Like, I couldn't tell you how many times I've been able to just like, you know, somebody just like gave me their employee discount because like we were chatting and they're like, yeah, I'll, I'll take the 5% off.

You know, don't worry about it. And, you know, just nice little things of people being people to each other. Because we have the ability to kind of deal in that squishy space. I honestly think computers and computer security are going to have to address that space because that's how we model things in the real world.

There's a whole thing in identity proofing, saying that, like, we need to move away from asking people what their birthday is, because all I need to know is if you're old enough to drink, right? But The thing is like. So. So I should be able to hand the bartender something and they check that yes, is old enough to drink. That's tested and verifiable, and we're good. Oh, that's great and all except that in the real world, you don't always get carded all the

time. You don't get carded every time that the bartender you go back up to order a drink. If the bartender recognizes you or you fit the expectations of you're probably supposed to be here doing this thing then. You're probably not going to get checked. This is effectively Cinnamon rollbased Access Control. They're like you're somebody I don't have to worry about. I'm not going to get in trouble by selling you a drink. I get a good vibe from this and we'll be just fine.

We'll we'll we'll be fine. And you know, this can slew on one side or another of the should this have actually gone through according to the formal rules of the system. You know, and this is, this is a space where I think that a lot of a I based modeling is going to open some really interesting doors, some terrifying doors, because suddenly we have a potentially nondeterministic security system.

But we're already getting into that space with all of these risk engines that have all of these inputs that like nobody has all of that in their head at any given point. Like, nobody can tell me how Azure actually figures out when to prompt you for a password. Like, I guarantee you ask anybody on the Azure team and they're just like, there's the

risk engine has it in there. There's I can show you all the inputs, I can show you the math, but like, nobody's sitting there doing all of that because that's what the computer is there for. That's what kind of scares me about AI overall. I mean, if you had some major financial crime take place. You know, I broke into a bank and I was able to transfer $10 million and I never got prompted. And it's like, well, the system determined you didn't need to be

prompted. That's not a good enough answer. Well, The thing is like you go into a bank and ask to ask to withdraw $10 million as a person. That request on its own is going to raise the risk and that's where these systems I think can really start to be smarter about it. You know, it's because the banker is sitting there going like, this feels kind of funny. Like, so I do all of my banking with a local bank here since since you brought up banking with the example.

And the last time I had to go in to get a cashier's check for something, they were, they didn't ask for my ID like the bank manager. The bank manager knows me. She's just like, Oh yeah, how much do you want this check made out for? Yep. OK, you know, X number, $1000. Here you go. Have a good day. And she was just like Yep, no problem. It's in your account. I know who you are. This is fine. Which bank is that and where is that?

At right, exactly. And. And so The thing is like, yeah, if you could convince Maria, the bank manager, that you're me, you deserve that money. Honestly, go for it. There's not a lot in. There I'm trying. Not a great example. I'm sure we come up with other examples. I just kind of feel like. If we're going to have algorithms in a I, some human being should be able to explain

them. So in other words, like hey, what if I looked at your health insurance records or something and I didn't get, I didn't get prompted or something like that. So there is a scenario where maybe it does not fit that risk engine trigger. And and that's that is interestingly another space where I think that some of the recent developments in natural language AI are really going to

come into come into play. Being able to query a system and say that like hey, you've got this policy, explain it to me, what is this doing? Why did you make that decision? So if somebody went and asked the bank manager like, hey, why did you just write that check? You know, if the if the regional manager had been in that day and they were just like, wait, why? Why didn't you ask for his license? Like why? Why did you just write that check? The manager could be like he's

been banking here for 15 years. We know him. It's fine. You know, he used to live like walking distance from from the bank. Like you know, we we know this guy. Don't worry about it. It's totally fine. Just just watch and and being able to explain that is something that the human that made the decision does.

Right now we're at the precipice of having systems that make these decisions that they can't explain themselves and we're not requiring them to explain themselves Because in you know, in that scenario if the regional manager was just like, yeah, no, never do that again For these reasons. You can change behavior and even if nothing bad had happened from that incident, that can be a learning experience for that.

And then the next time that kind of thing happens, the bank manager could tell me like, Oh yeah, sorry, we need to ask for your ID because of, you know, such and such regulation or whatever. And it is, it's, you know, it's now policy that I have to enforce this. Yeah, sorry. I know it's annoying.

She can explain it to me. As much as she can explain, she can explain the change of policy to me and the change of behavior to me. Right now we've got systems, whether they, they're AI driven or not, are doing absolutely inscrutable things to users and just firing off results and expecting people to deal with them. We have no insight into the underlying models that are, you know, moving us about the Internet on a daytoday basis. And I would like more insight into that.

Personally, I I think that there's a lot of room for that type of thing. So one can even imagine a space. And I had a conversation with a with a colleague about this at a recent conference. One can even imagine a space where I implement a set of policy system a a set of policies in my system by just explaining to it what I want to get done and it will go and translate that to whatever policy language that I that I have. And execute that in the system. And then I say okay.

Explain to me what you just did independently of what I put in. Explain to me what that is. And I can read that be like okay, that makes sense. And then I can take that explanation over to another system with a different policy language and say here's what we want. Like this is what I want out of this system and go through the same process. And the underlying formal language and modeling can be completely different in both

cases. And we've got this sort of buffer of human language in between all of them. We're nowhere near there yet, but we're getting close to that in very, very interesting ways. All right, we got one more question. This is from another listener. This is from Marcus, who reached out to me. He shared this story and I figure this is a good one to get 3 identity consultants to weigh in on. So here we go. So I'm going to paraphrase it. So. Basically joined a company

recently. They're implementing automation was more of a political issue than a technical one. And the root of this is basically trust for HR. It sounds like to me there were issues with data quality from an HR perspective and so automating it joiners, movers, levers, right, that kind of thing based off of that suspect data.

People didn't really want to do and he and I think he's he's had some prior experience of this where you know like an HR feed failed and you know people got terminated incorrectly, right. Every once in a while you hear this kind of those horror stories right around identity management gone wrong. That's probably a book right there and they put extra text you know extra checks and stuff like that in there.

And it's actually you know it was on a conversation earlier today where there was a very similar issue the the HR. Data quality and I, and probably it's not H R's fault per se, but the data quality and the authoritative source wasn't good enough, it was causing problems. So it boils down to do you trust HR to basically keep their data clean? Because if you're going to automate, you need cleaning to start with, otherwise you get automated garbage at the end.

And so I thought it was kind of an interesting topic to kind of say, well, you know, how does an IT team. And I am person whoever's in here go off and say, okay, well, we know a suspect data is coming out of HR. How do we address that in a way that doesn't alienate us from our friends over at HR, You know, diplomatic way. What are the right thing is because I think a lot of organizations struggle with this fact of look, this is just what we've been given and we just got to work with it.

I don't know, man, I don't buy it. I mean sometimes it's it's you have to keep knocking on the door and raising the arms like, look, this is a problem. This is a problem. I'm curious to hear both your guys's thoughts and Justin, we can start with you as the guest of honor. You know, this concept of trusting HR, trusting X with data quality. You know, where do you start with a conversation like that? So imagine you have a river. That river is your water source.

You're depending on this right now because you were told that this is the water source that you're depending on, and you pull water from that source and it's polluted. It might sometimes be more, might sometimes be less, but there's a problem with it. So then the question that you're asking is akin to all right, how do I? How do I deal with that polluted water source? And the answer is really similar in data streams as it is in physical streams. You can.

Address pollution at the source. You can filter it as you go out and sort of clean it up as best you can. You can augment it or replace it with a separate water source, right? You can drill a well instead of pulling from the river and hope that that's, you know, less polluted. The real answer is to do all of those you know. If HR is giving you garbage data, go help HR stop giving you garbage data. Like if you're on the IT and Identity team like they should

not like that system. If it's not directly in your in your purview, you should at least have a hand in saying what goes on with it, what goes into it, what comes out of it, how you use it, you know and how it's managed. And so bring that to the table being like you know we need this to be cleaner. And it will help you if this is also cleaner. But that's not good enough really. You cannot expect pristine data

anywhere. So yeah, still have the filtering on the way out, still augment it with locally collected attributes or roles or caches or any number of things. That allow you to deal with this because you know that an external source is not always going to be 100% reliable, but you in cases like this you really, I honestly think you have to try to fight to help make that source as reliable as possible. So clean up the river, get better filters and drill a well. Problem solved.

No problem not solved at all. It is an ongoing journey. No, we got, we got the water. It's perfect. We're good to go. Yeah, I mean, so you know, with the question Marcus said that is more of a political issue. So I don't really know exactly what that means is like if that HR doesn't care, you know, they're not willing to do things to address it. They don't have a communication path. I think if if it's not those

things like. You know, if you can sit down with the folks and try to address the issues because they don't know how serious the issues are, but when it you talk about people being terminated in the incorrect time frame, then I'd say is definitely something major, right? Something major is happening like this data is really bad. Not just people's names are being misspelled or things like

that. I was thinking about some kind of layer of abstraction, which I've seen a lot of clients do, where they create some kind of table. And database where they're precleaning the data prior to moving it into their identity management system. So that could potentially be the answer.

But you know the, the political side, I think, I think kind of to Justin's point, even if you do it a layer of abstraction or either even if you do say the HR system just can't, can't fit our needs, maybe the company has 40HR systems, right? Maybe that's what the problem is. Maybe some of them are good and some of them are not good and you just have to like figure out how do we exist in this environment where the data is a total mess.

But I do think you need to work on all these things, especially that political angle like if you have a broken down communication process or somehow like that team just doesn't care about your needs, that's dysfunctional for the organization and it's resulting in the organization's suffering so. You have to do something to fix that and in the meantime try to do the patchwork and you know, to make sure that you don't have

outages. Because I do think kind of stepping away from HR data holistically is not the right solution. But you know, in that 40HR system scenario, what I've seen is like okay, you might have this HR system and I don't want to pick on any particular country, let's say it's like really far from wherever your home corporate office is. And they just do things so much differently. They only update the HR system once a month or it's offloaded to some kind of third party.

They won't give you extracts, things like that. So you know, it might be that kind of scenario that just can't easily be fixed. And when it gets fixed is when the whole company moves over to, you know, work day to pick the HR system du jour. So yeah, fix your fix your governance process, relationship process, whatever, and then do a multitier technical approach. I poked fun a little bit Justin saying problem solved because I like. I really liked your answer. It was a great analogy.

I think people will really under will hopefully understand that it is a layered effect, right. It's it's almost like you're filtering the filter right? You're going to throw these different levels of of cleaning. To try and make sure you remove as many you know defects as possible from the process. Will it ever be 100%? Maybe not, but 50% is better than nothing and 75% is better than 50%. So it is a journey as you go along. So absolutely weighed in on that.

I mean, how many people are on municipal water in their houses that is perfectly safe to drink but still use Brita filters or you know, a refrigerator with a water filter? I know, I do. And. You know, I can absolutely drink the water out of the tap here. It's totally fine. I have no reason to, you know, be concerned about it. But it's kind of set up so that it's actually easier to get a cup of, you know, cold water by going to the refrigerator, which has this extra filter in it.

And maybe it tastes a little different, maybe it doesn't. I don't know if I would actually pass a blind test on that, but. You know, at the end of the day, the result is like. That's what I go to because that's what works. It feels good, looks good, it tastes good, whatever it may be. And sometimes that's all it takes, right? Exactly. Yeah. You need to navigate your identity systems by taste. That should be really the biggest take away from today's

episode. So Becky or Enrique, if you guys are listening, I'd love to see another dimension added to the the. Identity rankings for you know mouth feel almost like a fine wine, right? Like you know what does this would have legs, you know what's the coloring look like? Is it full bodied when it comes to identity? System viscous is for draw.

There you go. All right, let's start to wrap things up. Because this, you remember how we talked about, wow, there's no way we spent an hour and a half. Well, we're already at like an hour and 15, so let's wrap things up. You mentioned musician and I want to talk about this band called Cyclic. Tell me about the band cyclic. So first I will caveat to say that when you're 19 and an idiot, you should not be allowed to pick your band name and I really should have moved away

from that at some point. But so Cyclic is the name of a musical project that I started on my own and have been doing stuff on and off for gosh, almost 20 years now, 1520 years in one fashion or another. And I I grew up around music. I've been playing piano since I was like 6 or 7 years old, did classical lessons for a long time, selftaught on guitar and you know, synthesizers and all of the the things that I play now. And I also, you know, I just come from a really musical family.

You know, my, my grandmother had a, you know, regionally known. Band that like my dad and uncle played in and and all of all of that kind of stuff. I always grew up around music and so I just, you know, kind of just always kept doing that. And these days I've been really lucky that, you know, to live in a time where self-publishing, self recording and self-publishing stuff is within reach of kind of like average working people, you know, to be able to get decent quality.

Audio out of a system doesn't take a huge investment and I've got a decent studio set up now, but that's because you know, I'm I'm approaching my mid 40s. I've collected little bits and pieces over the years to like, you know, as as I've been able to, but I mean this whole time, you know, I could a lot of what I do, I could do it probably not as easily but I could still do it on. Just a little dinky laptop and a tiny little USB interface and come out all right.

And so anyway, I've just, I've always been around music, I've always had it in me, and I enjoy the process of creating and sculpting from sort of. The textures of the sounds and sort of the stories that you can tell with the music itself. A lot of what I write is instrumental. I do have some non instrumental, you know, some vocal tracks here

and there. Most of what I do is instrumental and I really like being able to kind of bring someone on a journey without telling them what that journey is. You know, I want to show you, I don't want to necessarily tell you. And that's that's what I've always really loved about it. And you know for the last five years or so I've I've let other things kind of get in the way of of the music side of things. I've done little bits here and there.

I, you know contributed to a couple of indie film scores, little little bits here and there. But I am finally I I've made it a sort of a personal resolution to actually get back into proper composition and recording and and actually trying to get something new out. Maybe this year, I don't know. I'm, I'm not going to commit to that on on a on an international podcast here.

But you know, one one can hope that I'll be able to do that because I love doing it and you know, I just, I love the creative process and I love the creativity that comes with the constraints of sort of these music systems because not everything sounds good, not everything sounds pleasing. So how do you work with that? It always fascinates me because I love music, but I am not a musician. I cannot figure out for the life of me how you would even start

to create anything like that. I, you know, I listen to a bunch of your stuff actually, when we first heard about it, and I think it's great. I don't think it's really diverse. I mean, there's two songs that I kind of want to point out there. There's one called Snow Runner, and this is my this is my amateur take on it, right?

It's a very fastpaced. And I kind of mentioned before we hit record here, it's like it reminded me of something that I would hear playing in the game wipe out, which is like this futuristic racer on PlayStation from days of old. And I love it. Like that's that's my jam, totally. So funny anecdote about that song. I originally wrote that as an accompaniment bit to a video game, and that was that we did

in grad school. So we had a point in point in this little, you know, graduate class video game where somebody basically gets a speed boost and takes off. And I'm just like I I want more than just like oh, it goes and does a thing. And so I, I went home and wrote the Rift to that and recorded it in like an hour and like sent the MP3 to my to my teammates. And it was just like just just played, you know call MP3 dot play when when that event fires.

And and that was. That was the origin of that song. I eventually went and made it into a full song, but but that's that's where that originally came from. Okay. So I'm not totally crazy because it really did. It conveys like a sense of speed is the way when I was listening to it, the other one that I really liked was called Incognito Shuffle, which I don't know if it could be any more different than that other one because it's it's it gives me kind of like this vibe of like a Speakeasy.

It's a lounge. It's kind of like a very cool. Jazzy type of vibe to it. I thought it was great. Yeah, like my my music tastes are really pretty diverse. I'm I'm really all over the map and in the stuff that I write, you know, there's there's a lot of electronic rock kind of at the surface. But honestly, I've got a ton of like, jazz and Blues influence in what I write. And so sometimes it really, really comes to the forefront, like an Incognito shuffle. Like deliberately.

Like I'm going to strip out everything except like and just just do this. Can I actually write that right. Like that was that was the constraint. It's like can I do just this style of of song without adding all the piles of synthesizers and guitars and all of the other stuff that I usually hide behind. And other times it's like no bring bring the wall of noise. Bring everything in do all of this all together and.

But yeah, a lot of the different stuff that I listen to and I've been exposed to shows up in the stuff that I write. And you know, that's I I think that that's true with most of my life. Like, you know, just all of these different things that I've done as, you know, Jim Jim was talking about before, all these different things that I've gotten involved in. Like to me they're all, they're all just like connected by like that is interesting and I have

an opportunity. But there's a lot of commonality that does actually thread underneath them. So I'm going to try and play a song after this show ends. It's probably going to be a Spotify exclusive because it's sort of built into that platform. So if you're not listening on Spotify, you probably won't hear it. But definitely check it out. I don't have a link in our show notes right to cyclic.com. So you can kind of check out more there.

But it's got, I think the one that you recommended is called Every morning Orange in Blue, Is that right? Tell me about that one. So if people are checking it out, they can kind of get the story behind it as they're listening. So like with a lot of things that I a lot of music that I write it started off with me just playing around and coming up with kind of a a feel for a

riff that I that I liked. And I was just like where where can I go with this You know what kind of sounds can I can I work with this and the title of this. Like a lot of the titles in my songs are just kind of like that's what the music is kind of telling me that this is the story that's here. Like I don't necessarily go into write something named that. It's like I start to write something and it's like, oh, this is, this is what this is named.

But to me the in that particular song, the energy that it kind of, you know, starts out with and just kind of dives through the whole, the whole thing. To me it's it's always felt like, you know, you're getting up at sunrise and you're training for some, you know, big athletic thing like this is you getting up and just going. Like whatever you're whatever you're trying to tackle, whatever you're trying to get to, you are getting up and going and getting out there in the

world. And you know, sometimes it's smoother, sometimes it's more chaotic. But you're you're moving forward, you never stop moving forward, even when even when it seems like things might be a little bit slower. So to me that's that's always been the story of that song. So I'm going to try and play it afterwards. It might be a region based thing. I don't know how positive advanced people need to go check it out after fact, but. Digital rights are so strange. They are.

And you know, we've made it this far without a copyright strike or any of that crap. So I'm trying to trying to keep the streak alive, Jim. You know, an hour and 20 some minutes already. We did it. There's our show. That's our show and we started off, you know, before the show saying we've never hit an hour and a half. I'll never hit an hour and a half. Yeah, I'm sure with a little tweaks, I'll probably get down a couple minutes and stuff like that. But yeah, I think we've set the

record. Congratulations, Justin, now the world record holder for longest identity at the Center podcast episode. Well, at least for now, I'm sure you guys will will break that wall soon as sooner than you think. We're gonna go ahead and wrap it up for that one. I have like a laundry list of show notes and links. I've got your LinkedIn profile. Justin got the website for bespoke engineering. While you were talking about the the why applications fail, I

found a link for that as well. The book link Gnap. Sorry gnap. I keep saying gnap. So small anecdote on that. I know we're already pushing the links of the show, but there was actually a big debate in the working group about what the official pronunciation of the working group was. I strongly came down on the side of there is no official pronunciation. Because, like, we can't dictate how people are going to read this text without somebody reading it to them.

So I say nap, I've heard people say G, nap I've heard people say nap. I've with a soft G I've heard all sorts of things. I think they all apply. So yeah, don't. Don't apologize for it being different. All right. So I have, I have a grace period there. What? So I have a link to that. We'll have a link to cards against identity gridlock, Boston, obviously cyclic. And then?

You kind of told the story a little bit earlier during the conversation, but the precious cinnamon roll and so The Onion article that that's sort of like based on as well. So chock full of links. Yeah. So that's that's for people to look at. Yeah, we're going to leave it there. You know, we're on the web, idacpodcast.com. We're on Twitter at IDAC podcast, we're on Mastodon at IDAC podcast at infosec dot exchange.

No, we're not on threads yet. I don't know if you ever will be. Most of our engagement comes on LinkedIn and Twitter and that's probably what we'll stick for now. But definitely you can always connect with Jim and I on LinkedIn. If you've got questions, send them in right. This is our opportunity where we can get smart people, you know, on the line with us and get some real expert opinions of some of those stuff. So hopefully people enjoy that as well. And don't forget about

authenticate. So use our conference code it is. If I could find it here I DAC. 15 podcast, 15% off. Hopefully we'll see a lot of friendly faces there. Hopefully you'll help us figure out what that live show looks like, Jim, when we when we get up on the stage as we kind of go along. But yeah. So Justin, thank you so much for your time. Jim, thanks for your time and we'll go ahead and leave it there. Thanks for listening. We'll talk with everyone in the

next one. You've been listening to Identity at the Center. We hope you've enjoyed the show. Make sure to like, rate and review and we'll be back soon. But in the meantime, hit the website at identity@thecenter.com and find us on Twitter at IDAC Podcast. See you next time on Identity at the Center.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android