Welcome back to Protected Trust Live. My name is Steve Goodman, Training Coordinator at Protected Trust. Joining me today, Javier Pereira. And Javier, your job title here is Project Manager, but you actually do a lot more than planning projects. In fact, you're the guy we go to when we have to explain technical things to technical people. But today we're gonna explain technical things to non-technical people. All right. Are you up for the challenge? I'm up for it. Perfect.  And we spent a great deal of time talking about multi-factor authentication in that one. And so instead of talking about it, I thought it would be a great idea to use this live stream to demonstrate multi-factor authentication. Sounds good. There's a lot of, I think, confusion that goes on when you introduce a new element into people's lives, like multi-factor authentication. And it's really simple when you just use it. Yes. Is what I've found.  Do you have any feedback from our customers once we've deployed it? Like all security, it's really kind of, it's like a sliding scale, right? So as security goes up, so does administrative overhead. And as long as the expectation is set, this will make you more secure. You will have to do one more thing. There is one more widget that you'll have to press to get through this particular step. Now the concept of multi-factor and really kind of the widespread adoption of it is nothing new. Really 2010, 2011, it was almost required for a lot of the banking industry. If you were a financial industry, you really did it a lot when you interacted with the bank and you'd like check scanning and whatnot. So the concept of I have this fob, I see this little number, put the number in, that's kind of already ingrained, right? So now it's not so foreign, but a lot of people will still see it as kind of an obstacle because the one thing is, I'm willing to accept it here in this banking thing. Why should I do it for email? Why is it so important? But as technology advances, right? What has value is our information. So Microsoft has done a pretty good job of making it pretty painless to get yourself through there with some backend stuff, some finance stuff, lots of options to choose from. So that's kind of the high-level analysis of multi-factor, but giving the customer a choice and just kind of walk into them through different steps and going through it with them really helps. I never, ever advise you to say, well, we're gonna move to 365, we're gonna move our email, we're gonna start and then multi-factor on the first date. Unless you're a technical professional, that's not good for you because you're already gonna be timid about, am I doing it right, I'm doing it wrong, I can't get in, what if I can't get in? So yeah, definitely adoption and setting expectations.  And then adoption is pretty good. Yeah, we rolled it out internally last year and we made a written document for people. And what happened was the steps were so easy and so intuitive that they skipped over all the language that was in the document. All the words that do not do this. Right, well, so the purpose of the document was to say we have a preferred way that you use multi-factor authentication because as we'll see in a second, there's different ways using your mobile device or using your desk phone that you can use to use that second factor authentication. And so people would just use the first one that they saw and it's actually the most difficult when you have to re-enter in your password because it involves getting a text code and then you have to re-enter that text into something and what if you're on your phone while doing it, then you gotta switch out the apps. So we have a preferred way to do it. That's the way that I wanna show today. So if we go to my desktop here, I'm signed in as an admin for a test organization that we have. And so what the admin sees when they go to turn on multi-factor authentication for a user, first they go, they find the user and they'll click on manage multi-factor authentication.  They see everyone who hasn't enabled and everyone who doesn't have enabled. So before the stream, I enabled Alex Wilber and you'll see some people, it says enabled, some people it says disabled and then some people it says enforced. Disabled means obviously multi-factor's not turned on. Enabled means that it has been turned on but the setup's not complete. And then enforced means the person's gone through the setup and everything's working fine. That's right, all right. So for Alex, and I think what we'll do later is show a fresh setup, I just didn't wanna enter in my phone number for everyone to see. So that's why we did it ahead of time. Call you for a good time. Right, so we'll sign in as Alex, right? And this is what people would do. They would receive a prompt and outlook once we enforce it or once we enable it, they'll receive a prompt saying additional steps need to be taken in order to something. I forgot what the exact language is. There is a little backend step there. So that concept, the being prompted in Outlook, in Skype, SharePoint, those are attached to something called Microsoft Modern Authentication. Right, yes. And that must be turned on in the tenant beforehand. If not, you will get the app password experience, which I guess we'll talk about. Yeah, we'll go at that at the very end since that's so bad. All right, but back to my computer here. When I click sign in, it's giving me this new sign in experience and says we've sent a notification to your mobile device. So on my phone, I have the app installed, which we'll go through. I'll click view and I'll click approve. I don't know if anyone can really see it from that far. But I just, the app automatically opened and all I had to do was click approve. And now I'm signed into my account. So for any application that's installed on my computer that requires me to enter in a password for Office 365, I will have to go and do that for each one. Yes. And so that's what some people, they find that to be a nuisance. However, there is a 30 day option where you check a box that says, don't do this for another 30 days. But what it still does is, I think Anchorm touched on it in the last one, it says advanced AI, depending on your license. And it will know your behavior. And if it knows that you're not logging in from Canada, let's say you spend most of your life in Winter Haven, Florida, then it's gonna, you're getting an alert on your phone saying, do you want this to be approved or not? And so it's running constantly. So even though you haven't turned it on for this specific device to run until 30 days from now, it will still prompt you for any other device. And any kind of improbable logins and logging in, what if I am in Canada? So I'm logging in Canada and I've been logging in Canada for four days and then I suddenly log in in San Francisco, then Canada again, it's improbable. There's all kinds of factors that would trigger it to say, I'm just gonna ask them to do it real quick. And so what I'll do now is I'll enable Christie Klein, who I believe I reset the password for. And if not, that should be fun showing everyone how to reset passwords. So I'll check her and I'll click enable. And it'll give me another box. And let me copy her email address since it's so long. I don't think it will. I'll have to type. Sorry, Seth, I'm gonna have to type this. Now I don't know how much of a deep dive we wanna do on what the options are and kind of what the admin's perspective would be. I guess we're gonna be the user then. Well, why don't you talk about that while I try to sign into this account? Well, let's sign in and we'll see you from there. All right, what was that? Christie Klein. I think I actually went to the next page. There we go. Christie C. But I think it gives you a lot more options than many other multi-factor services in terms of where you can do it from. Cause most people I think will give you a cell phone. I like that it's all there already. And you have a few options, right off the bat, there's really nothing, no third-party services. It can be enabled user by user so you can enable it in a high-valley targets. You can enable it on a pilot group and just really no pressure. It's not an organizational change if you don't want it to be. Okay, so yes, I reset the password. All right. All right, so back on my desktop, if I entered in my email address, I entered in my password and so now I have this new login screen and I'll click set it up now and it'll redirect me into the setup page. So what we ran into was, I'm not sure if these were the same order, but people would not choose. Our preferred method is to use the mobile app and use verification, or no, sorry, receive notification for verification. So all that is is when you're prompted to sign in, your phone will buzz or it'll alert you and all you have to do is click approve or deny. And then you're good for the next 30 days on that app. But what people were doing was they clicked on the first option, authentication phone. They entered in their phone number and then they were right. So they were getting phone calls. So they had to get a phone call and they had to press the pound symbol and they had to do all these other things instead of just clicking approve. Right. And so people would start yelling at me saying, hey, this is too hard, I can't do it. I said yes, but if you would have read the directions, which they didn't, so we made a video which shows how to go through this in the right way. Now, one of the reasons that's there is having multiple methods of authentication is one of the things that Microsoft likes and one of the things that I like, I don't like being kind of tied to one method. And you can, for example, let's say you don't have the app or you've lost your phone and you can't generate whatever necessary text to generate that code by having that recovery number or recovery email or like a recovery landline phone number put in, you can still get in with another method. It doesn't have to be the method that's preferred, but it can be preconfigured. Right. So as an admin, you can collect all kind of cell phone numbers for folks and pre-populate before your MFA rollout and pre-populate them as the recovery number. So when the user gets to that step instead of having to select that number's already there. So it's meant boom, boom, boom, bring your text number, now I'm in. And so at that point, you can walk the user through changing methods or you can change the method for them if you're gonna do it with them. But I like having both methods simply because what if you're, you know, what if you're somewhere where you have phone signal or you don't or you don't have data or I don't wanna be in a bind. You know, I don't wanna be in a bind where I can't get in. So I use the Authenticator app notification as well. Or other organizations, we use the phone call. It didn't bother me all that much, but it really depends on your preferences. Well, when you're trying to set it up on your phone, that's where it comes in. Because the guide happened because I tried all different ways and I found the most complicated way was, and it sounds like the easiest way, oh, I just get a phone, I pick up my phone and I press the pound sign. But while you're trying to get that on your phone, receive the call on your phone and do it all from yourself on, it's very difficult. So one thing I kinda missed was setting up the actual app on your phone. So that's the one kinda gotcha, the one additional step that we find people, you know, the big issue people have with this step is, now I need to remember the password for my iCloud account, or my Android store account, right? So you do have to download an app from Microsoft, the authentication app, in order to get this to work. But after that, you literally just scan this. That's included with the app. And that's a pain point, that's a pain point that is encountered often. Which is, it takes me a little, I had to do four steps so that I only have one step from this day forward.  Right, exactly. But you know, it definitely becomes an obstacle sometimes when like what's my iCloud password, I don't know. I don't know, my signal's terrible, I don't get on the, what's the Wi-Fi password? I mean, it can have its drawbacks. Right. And so like you said, you do have that secondary method that it makes you choose. Cause, you know, if you lose your cell phone, then you're out of luck. So it does give you that second option. What it also does is it allows you to change your options. Correct. So, you know, even though you may like using our preferred method of downloading the app and using the app to authenticate, maybe in the future you may not like that. So you can always go back and in your account settings you can change your personal preferences on that. So if you wanted to ring to your office phone and set your cell phone or vice versa, you can make those kind of changes. You can figure all of them. Why not? Yeah, you can figure all of them. Yeah, or you could do, or yeah, that's right. You can check the box for every single one. So you're not just limited to two options.  So if everything goes haywire, you could still get into your, you can always get in there. So I think that brings us to the thing. Oh, the app password. The app password. So talk to us about app passwords and why they exist and why this is so much better than app passwords. Why so much better than app passwords? So, before the modern authentication concept, I think it's exchange, I mean, it's Outlook 2013 or newer, you know, SharePoint, Skype for Business, it, if it's activated in the tenant, there is some information that it says, okay, the user has entered their username and their password, their actual username and their actual password. Using this new technology, it's able to trigger the multi-factor and bring up the acknowledgement window during that process. But that's, it's very application dependent. So your application must be aware and understand how to utilize modern authentication. And that's relatively new feature. We really kind of just turned it on when we were doing our part of the project. Before that, we were just relying on app password. Now, this is one of the most complicated things to have to explain. App password is a one-time only visible, randomly generated password that can be entered into applications that do not understand modern authentication. So that's a lot of way of saying you press a button and you'll see a password one time and one time only. You cut it and you paste it into whatever application you're attending to configure that's gonna interact with your 365 data. Then you leave it there and you don't think about it again. What's gonna happen is you're gonna have your username and an app password. So up until recently, the native Apple mail client did not understand modern authentication. What it would do is you'd have to put in your email address and an app password. The reason it's only visible once is because it is best practices to keep generating one app password per device. And the reason you'll do that is I'm setting up a mail on my non-compliant mobile device, put in my email address and my app password. I am setting up my non-compliant tablet or other version of Office. That's two app passwords. And then down the line, whatever's gonna be interacting with that 365 account. Now I have four or five app passwords that are listed and visible within the user account. You can actually disable one specific device one at a time. But the gotcha is you have to go in, grab it. You shouldn't save it. You just copy it and get into that session and then move on. And what do people end up doing? They end up copying it and pasting it into a text file and using it one app password for six applications. That's right. That's right. And so very, very complicated because you can't remember what it is. You only see it once, that's right. You only see it once. And so you end up having to putting it in a text file and then looking at it later. And then looking at it later. Which is defeats the purpose of having it. It defeats the purpose of the app password, yes. And so if I could just show, if I can remember off the top of my head, do you remember where it is? I do, and it makes no sense where it is. It's security and privacy. Security and privacy. Okay.  Additional security. And then it's update your phone number. No. Yeah. No, it's create and manage app passwords. Click the top one. Click the top one? Yeah. So now here's where you manage it and then there's app password. Oh, I see. Yeah. It's great out. People think it's not an option. That's right. It's a different shade of black here. It's not great out. It's just a different shade. So if I click on that, I can create a new password. And so what's the purpose of giving it today? So again, ideally this would be a one time use for one instance. So let's say it's Android tablet, Office 365 supported third party vendor tool. And I would be able to have one app password per each. And then they can be individually deactivated. So I can deactivate one, but not break the other. So if a device you think it's compromised, you can go ahead and sign into your app password list here and delete it. And that way the person can't access it even though they have your device. And so yeah, there's the randomly generated password here. How many characters is that? It's gotten longer. Has it? All right. And so because I didn't copy it down, I have to delete this and start again. Right. So if you were to say, I've lost my surface and I understand that it's set to hold on to my authentication for 30 days. Whatever mechanism you've put in place to get in it, this could be deleted and now it stops communicating. Now it's no longer authenticated. Now I know at least a couple of months ago modern authentication had to be turned on by your admin. Is that still the case? It's still the case. It's still the case. That I've seen. Yeah. Which is upsetting because modern authentication, the thing that lets you use the apps for your devices and your apps is so much easier. Yeah, it is easier. And so I would think that they would just turn that on by default, but. There's a whole kind of web concept of how these work together.  Then you turn on, if you were to synchronizing your local Active Directory with 365, you can turn on what's called seamless single sign-on. And then the experience becomes really great. I'm a new user, I'm setting up Outlook, I launch Outlook, it sees my local Active Directory credential, I see a brief flash of the authentication. I do nothing. It's basically doing it all on its own as long as it's all been configured. It's got a few little switches that you have to turn, but it's really leaps and pounds ahead of where it was. It's much easier than, again, the app password, which until maybe middle of last year was how you were destined to set up your five devices. Right, and it also gets rid of the need of having that 90-day password policy where you're constantly having to come up with a new password. And I think that's where this all came from, is in order to have a secure environment you would have to have some sort of password policy where your password would be changed at some interval. Right. And... Well, password history then, so that kind of ties into the password history. So I change my password every 90 days and I have a password history of five passwords. That means every year, right, it's fall. This is my fall password. Right, and so people would, and Ingram said it on the last livestream, people would just add an additional character at the end of it. So it's not really making it any more secure. And of course, if that's not an option, if it makes you change it to something, something hardcore, people would just write it down and put it on the poster. Right, yeah. So it's definitely more secure just to use modern authentication and using the mobile app. Absolutely. So that's all I had to say today. Okay. Do you think we covered it? Yeah, I think it's good. I mean, it's a pretty simple concept. It's a concept that's been, like I said, it's been around for a while. You have so many options you can call your cell phone. It could text you. It could generate the notice on your phone. You can open up the notification app, the actual Microsoft app and type in the number. That's something that people are very used to in the banking industry. It's there for you.  You know, it can be enabled user by user. It's a great tool. It's available with every license site.  You can use it for your problematic targets, right? Right. The people who are prone to compromise, they can be enabled just for them. So it gives you a great deal of flexibility and added value as it's already there. Right, because as we saw in the beginning, not everyone was enabled. We got to choose exactly who it was. Exactly, exactly. So yeah, I think we'll end it there. So thank you very much for joining us today. Alrighty. And thank you all for joining us today as well. Join us every Tuesday and Thursday at 2.30 p.m. to see another live stream where we'll tackle another topic. And thank you to our clients who make these videos possible.


Hey guys, this is Catherine Ross. We are in Amsterdam at Money 2020, the biggest fintech event in the world. There were dozens of speakers and panels, a lot of discussions including major innovations in the fintech world and blockchain and cryptocurrency. Steve Wozniak, co-founder of Apple, expressed his point of view about artificial intelligence and cryptocurrency. He said that while blockchain might be a bubble, we're still heading into the right direction. With yet a lot of uncertainty about regulating the crypto market, central banks express their point of view about issue national cryptocurrencies. And while they say it is possible, it could only happen if the public expresses its interest. Former US Federal Prosecutor said that we need to get rid of negative connotation surrounding the emerging crypto industry as there are a lot more crimes involving fiat money than crypto. MasterCard has built a blockchain that can run the whole of its network, set its vice chair and currents during the conference. She also claimed that the company had deliberately opted to develop a blockchain integration at scale while stating the need to identify real use cases. The traditional financial market still feels skeptical about the crypto industry, but one thing is for sure, everybody's talking about it. Don't forget to like this video, subscribe to our channel and hodl. Cointelegraph Like, subscribe and hodl.


Good morning, Hank, it's Tuesday. I'm wearing a suit jacket, which can only mean one thing. It's time for the Bank of Nerdfighteria's quarterly report. Or that I'm at a funeral. But I'm not at a funeral. So the Bank of Nerdfighteria has three branches. There's the executive branch, which probably has too much power, the judicial branch, which literally believes that corporations are people, and then there's the legislative branch, which presumably was named ironically since it hasn't passed meaningful legislation in nearly a decade. Wait, no, I'm thinking about a different institution. The Bank of Nerdfighteria's three branches are the giving branch, the lending branch, and the spending branch. Let's start with the giving branch. The Foundation to Decrease World Suck, our actual real-life charity, has finished paying out well over a million dollars in grants from the 2015 Project for Awesome. The money went to all the organizations listed here, and it's doing lots of good all over the world. For instance, I recently heard from Water.org that Nerdfighteria has just funded a capped spring water well in Northern Ethiopia that serves over 2,000 people. So far this year, the Foundation to Decrease World Suck has just over $73,000 in the bank. Most of that money comes from Vlogbrothers ad revenue. Right now, half of the revenue from this channel goes to the Foundation to Decrease World Suck, and half goes to sponsor online education projects. So thank you for watching the ad before this video. Hopefully there was an ad. Okay, let's move on to the lending branch. The Nerdfighter Kiva Group has now loaned more than $7.4 million to entrepreneurs around the world. Also, more info about this in the doobly-doo, but Kiva's made some important steps to improve outcomes with their partners lately. And then, Hank, there are two very exciting updates from the spending branch of our bank. So in 2016, four Crash Course videos have gone up each week. Like, currently we're discussing literature, the history of games, physics, and philosophy. But starting September 1st, all the Crash Course Patreon money raised for the remainder of 2016 will go to fund an expansion of Crash Course in 2017. This will mean five videos a week by the spring of 2017, and hopefully six videos a week by the end of the year, including our first forays into higher-ed topics like advanced physics and anthropology. And we're really excited to be growing. We're also working to systematically translate Crash Course videos into multiple languages. By the way, if you happen to have the talent and time to volunteer to help with that translation project, please let us know via the form in the doobly-doo. So yeah, thanks to everyone's help on Patreon. More Crash Course videos next year available in more languages. And lastly, for more than a year now, Joe and Stan in our office have been working with help and funding from Bill Gates's BGC3 organization to build out educational materials around Crash Course videos. Like, as you may be aware, textbooks are ridiculously astonishingly stupefyingly expensive, and we've always felt like maybe a better price for them would be, you know, free. Because if high-quality curriculum materials were available for free online, it would allow schools to save money on textbooks and invest that money in their most important resource, which is teachers. So last week Crash Course released its first full curriculum, which covers AP World History with readings and primary sources and assessment tools for both students and teachers. Hopefully it's like a textbook plus worksheets and writing prompts, except it's easily downloadable, frequently updated and free. You can find it all at thecrashcourse.com, or there's a link in the doobly-doo below. We're really looking forward to getting feedback from teachers and students so we can continue to update and improve the curriculum. This is just the beginning and it's only one course, but we're very excited about it. So please check it out, share it with your teachers, and hopefully we'll find funding to create more full courses in the future. I want to again thank everyone at BGC3 and also everyone who supports Crash Course on Patreon. You can find Crash Course's Patreon by clicking here. There is a link in the doobly-doo. There are lots of great perks available to patrons, although by far the biggest perk is knowing that without you, Crash Course literally would not exist. So thanks. So that's the update from the Bank of Nerdfighteria. Nerdfighters, if you have questions, I will be in comments. Hank, DFTBA. I will see you on Friday.


Good to see everybody here. Thanks for joining. I am Aaron Perrecki, and we also have Vittorio here. Hi, I have no surname. It's just Vittorio. Just Vittorio, the one and only. Actually, I'm not sure there was. But I can tell you a story later. OK. And I just remembered that little incident. Anyway, welcome to the OAuth happy hour. We are back. It's been a while. It's been a couple of months. I think the last time we chatted was April, which is like three months ago. And that is, yeah, time just flew right by. We were heading into a bunch of events, and all the events happened. And we've come out the other side. So here we are. Yeah, indeed. I think that of all the year, these three months are actually the ones with the highest density of identity-related events through entire year, both in terms of numbers and in terms of weight, like the heavy hitters like Identiverse, RSA, European Identity Conference, those are like the big ones. And they just happened. So that's why we are so tired. Look at us. We're pale. You are not pale. I am pale. I am a nice and- It's part of your arm. Don't worry. Nice and pink, yeah. So let me grab my little browser window here so that we can take a look at what's been going on. We were way down here last time we chatted, and now we've got a whole bunch of stuff happened. So I think we were about to head into Internet Identity Workshop right before we last chatted. Yeah. Although I did not go. I think you went. I did not go, though. I did go. I did go, and it was the usual IOW as it has been in the last few years, which is mostly focused on decentralized identity. Like a lot of people go there with this. Because, actually, it's the valet. And frankly, not like steal the people that build the tools, but not really the alleged customers. Their customers aren't really there. But good discussions, like it's a good opportunity to meet. And it wasn't just about that. Like, for example, that was my first time, face to face, with some goto from the Chrome team. And I've been working with him for the last two years on the changes that browsers are introducing that interfere with identity. And we've been meeting, like, weekly for two years. And for the first time, I finally know how tall he is. And we had, like, some really good discussions. And another big topic, which has been a life motive for also the other events, was an open ID for verifiable credentials. So there were lots of discussions about it. And then PASCII was another good topic. This was way before Apple talked about it during the WWDC. But still, the identity people are on top of it. And so there were a number of interesting discussions. So in general, like, good event, again, for my personal tastes so much, decentralized stuff. But I guess that's the way we do identity today, at least among us. When customers still appear to like the traditional stuff, but who knows? Yeah, I haven't been to that event in a while. I may try to go to the next one, or the one after that. But I do remember it's been a very heavy focus on the decentralized identity side of things. I do think it's at least useful to have a place for the more experimental bleeding edge stuff to happen. And that tends to be what's happened at IW, even as far back as when OAuth and Obrandi were bleeding edge and experimental and fringe things. That's where those discussions happened, so. It's true. You never know what's going to come out of it. Although I think that the big difference is that back in the day, people were already using doing OAuth without calling it OAuth. And then there, we had the opportunity to somewhat say, OK, lots of people are doing this. Why don't we do it in interoperable manner? Whereas in here, it's a bit of like, I wrote the rules, the grammar for the Klingon language. Now let's see if I can convince a cohort of people to speak a Klingon instead of speaking whatever language we are using. Which is a bit different from the ontological perspective. But then again, I'm notoriously biased, so don't pay attention to a man behind the curtain. Yeah, well, I mean, I've got some thoughts on that whole world too, but we don't need to go into that. We don't. Right now. We've got more productive things to talk about. So yeah, that was April. And then there was the OAuth security workshop in Trondheim. Got a nice trip to Norway. That's a nice little town. I had a great time there. Could not bring my drone, unfortunately, because the local regulations do not allow recreational flying in the way that I wanted to do it without going through a bunch of extra hoops. Anyway, it was a very nice town, though. Very, very pretty. Gorgeous. Absolutely. And a good time of the year to visit, I felt like too. Although, I actually ended up in the middle of the blizzard. Like, I had one day which was free, and we took a little walk with Michael Johnson, Tim Capali from Microsoft. And once we got to the TV tower, we just saw a blizzard coming from. And it was snowing horizontally. It was amazing to see. And it also ruined my wonderful Italian leather jacket, which I've never seen in water. And there, instead, it got the horizontal snow. But it was wafersaw, all good. The rest of the week, it was beautifully sunny most of the time, so yeah. But yeah, there was wind there. You had like a few sessions, right? We had a very, very busy schedule during that. There were multiple tracks. There were a lot of pre-scheduled sessions. And then there were also a bunch of these unconference sessions which were decided on that day. So yeah, a lot of interesting stuff. There was, let's see. I think that the one thing we can say about the OSW is that it's the king of the formal because there is no recording, there is no streaming. Either you're there or you miss out. And the other is that, and that's like mixed feelings, but given that we were lucky to be there, good. And also like the people that are really committed when we go there. So it's a very, very, very productive event. Like the smart people that work on open problems really do everything they can to be there because it's very productive. The other is that it's one of a few, perhaps the only event in which there is both academia and industry. Like it was a pretty significant presence of people that basically instead of producing SDKs and services, they produce papers and they work for universities. And so there was this entire track in which we presented these academia aspect of off which I'm personally not familiar with and it was interesting to see the play out. Definitely interesting. I do think that maybe like literally opening the conference first thing in the morning with a presentation about a mathematical proof maybe wasn't the best ordering of the sessions, but yes, it was very interesting. The, yeah, it is a good mix of things. And I also like that it's not, obviously a bunch of these talks were prepared ahead of time, but they're very different than like going to a regular conference and watching conference talks. Cause these are things that are like pretty much none of the things that get presented here get presented anywhere else cause they're not meant to be like repeatable things to learn from. They're like, it's a discussion, it's happening. Like this is the discussion. So it is working through the problems. Some would present something they found or something they are interested in and then it happens or it doesn't or it changes. And then we hear about it later in a different form. And it's really how a lot of stuff got accepted. Like the first time that I ever presented my research on JWT access tokens was OSW Institute Guard, the last one in person. And now it's an RFC. And if these OSW Daniel Fett presented they selected disclosure JWT ideas, which I think is a fantastic idea. It's a relatively simple way of packing the Cartesian product of all the claims that you can have in a JWT so that then the client can choose what combination of claims to disclose instead of having to disclose everything all the time. And normally in order to do this, you need to do really weird advanced crypto. And instead of this thing is relatively simple and he presented the idea, I got a lot of feedback and now there is a draft. And he is going to present a draft together with Christina Yazuda from Microsoft next week at the ITF in person. So you are absolutely right. Like these discussions happen in there and sometimes they actually become a thing. Yeah, I think that one's a really interesting idea. Definitely looking forward to hearing where that one particular goes. The, it's a fascinating concept. But yeah, so what else happened? There was a lot of other, there was a section, a couple of, actually there were a few, there was one theme that kept coming up which was OAuth is difficult or OpenID Connect is confusing and it's hard to get it right. And I feel like this actually came up in a couple of the different sessions. One of them was the literally called Wise OIDC Confusing. That one was by research, two researchers, was that correct? I think that, yeah, they were either researchers or borderline researchers, yeah. And borderline researchers. I have a long opinions about that particular session, but. But another one was Joseph, Joseph Heenan presenting top OAuth mistakes found in mobile apps in production, which was a really good analysis of how bad the state of some of the mutations are. And I believe he presented that again at Identiverse. He did, it was in my truck. So I'm bioflecture and I'm proud. And he did a fantastic job. Like the, it was one of those rare sessions in which both of their hands on people and their big picture trend people had something really useful to bring home. Like he presented so many interesting misuses. Like for us, it's like, it's even hard to imagine how people will do torture or for both ways. But he did his research and he presented both the details of those mistakes, but also the trends as in like, if you were to design buckets in which you have to put the stuff in so that we can try to prevent it, he also identified the buckets. So that was really a good session, both in intimate settings at OSW and in the big room in Identiverse. Yep, yep. And then, oh, and then the third one in that theme was Brian Campbell's talk about Jot or Not about sort of going through the history of why Jots are kind of a mess of a spec and hard to get right and why people get them wrong all the time and things like that, so. So I wouldn't go as far as saying where the Jot is a mess. More of like, there are things in the way in which we designed this thing that could have been done better. And some of those could potentially be fixed. Some others are just a function of the fact that that thing was designed a geological era ago. And like, we learned so much in the manual and Jot still powers a boatload of things in word and it mostly works, so. It is a useful technology that you can use in a perfectly fine way.  So, like everything. Yes, and one of the messages that I think is important enough of that I feel I want to echo in here is that a lot of the issues that were found in Jot have been solved. Let's say that a lot of those issues were implementations which were naive or that had to say overlooked some particular details. And a lot of those things were found and never emerged again. Some of those things keep coming up from time to time like the Alg non-none is like a in main state. But many of those things were just the process of a technology being used and weeding out the issues which now are no longer there. So, using Jot today is way more secure than it was five years ago, seven years ago, and so on and so forth. But it doesn't mean there is no room for improvement which was another message that they think Brian gave which was a very good message. I think that at these ITF there will be discussions about whether some of those things should go back into the spec. Like for example, is it conceivable that we have a new version which says no, we want to take away Alg non-none?  Then whether it will ever happen, different matter. Yep. Micah is here. Micah used to do the OAuth happy hours with me. He says I wanna make an Alg non-none with a circle and a line through a T-shirt. I have that idea. I might have to wear that to the next ITF. So, for my presentation of this ITF I just received right now, I made a rush order. I don't know if you watched Solar Opposites. It's a cartoon from the same guy that does Rick and Morty. But anyway, one of those characters always have a quirky T-shirts and two episodes ago it had a T-shirt that says Alexa stop all of the kids, which I loved. So, I had it printed and I'm gonna present my ITF session wearing Alexa stop. And curious to see what happens. Probably not. That's hilarious. Oh, comment from earlier. Top mobile app mistake resource owner credentials flow. That one isn't that one. Because if you're a first party, as in it's your app, talking to your own authorization server, then sure, I think it would rather better because you can do unlimited detection for the nation but it's not as big of an issue as in other scenarios. So I would only half agree there. I think it's only acceptable in the most simplest cases when you really only have one app. And that's it, end of story. Because as soon as you have multiple or if you have a website that corresponds to the app, then it just starts to get more confusing. And the example I like to give is Apple, ironically, is one of the worst examples of this which is, and I can pick on them because they're big enough, or they can handle it, they can take it. They should be doing better. And the problem is try to explain to somebody, anybody how to identify a phishing attack of your Apple password. Try to describe how to identify if a particular password prompt that you see on your screen, whether it's in a browser or in an application is a real prompt that Apple is asking you for or if it's some malware or a fake website that's asking for your password. And I challenge you to actually do this, like actually try to write this down because the list is extensive and you may have an inherent understanding and maybe you personally wouldn't fall for a phishing attack but try to write down the list of instructions of how to identify one, because it's nearly impossible. And then do the same thing on mobile because it's different on mobile. And that's an example of by putting a password dialogue into your app natively you have created a new place that someone has to be able to recognize as a legitimate password prompt. And it's from a, in general, it's just a bad idea and ecosystem wise even more so, but it kind of like becomes tragically common as in people like to have a direct relationship with the users. And in the particular case of Apple, I think these, I can hear in my head, the people responding that for those things your app should use auto field. She's like these API that you use on username fields which happen both on websites and the native apps which is associated with one particular domain. And when you put the focus in there, then there is Chrome from the operating system that pops out. And in there, depending on what the developer decides to show, you can have either choice or the password that you saved in iCloud or sign in with Apple for that particular domain where you're going or now Paskey. So if you do the auto field, you'll never see any affordance in the app either mobile or like web app or actual native app that ask you for credentials. It always comes from the pop up.  You heard about FEDCM in which there is an attempt to create, specialize the Chrome for the identity providers to prompt users. But lots of practical challenges, but yeah, it's an, there is no simple answer in that context I think. One last on this point since there was a follow up question here. Mobile app can't store the client secret in a secure way, correct? I mean, you can't deploy a mobile app in an app store with the client secret, correct? For the vast majority of the cases, this is a true statement. That said, there's no need to use a client secret for the password credentials grant. There's that's not, those are not linked together. The, this is actually something that I have been working on in the last week or so to clean up in the OAuth 2.1 spec, which is cleaning up the definition of confidential client, public client and when the client credentials are used and how because there is a lot of legacy language and thinking about it being tied to certain grant types which is just not true. And technically it never has been true, but a lot of the way it was done in 10 years ago kind of linked client secret to authorization code flow and no client secret with implicit and those were kind of linked together and then they don't have to be but that is kind of how it has evolved. And now we're just trying to say, if you can use client authentication if you have a client secret if you can deploy it safely then absolutely use it regardless of the flow. And if you don't have one because you can't store it safely you can't deploy it safely then you just don't use it but the flow is the same otherwise. And it largely depends on which side of the ecosystem you were coming from because like centuries ago when I was walking in Microsoft the very first SDKs that we had for native clients used the authorization code with no secret because in order for that stuff to work properly you can't rely on the state that lives in the browser because the browser might be there and then might be gone especially back in the day system browser in location was not an option. And so you had to have a different artifact to allow it up to the new access tokens and that was very fetched token which you cannot get with implicit flow. So we were using the authorization code without client secret from the very start like seven years ago, eight years ago, 10 years ago and I don't remember. Lost sense of time. Yeah, and I remember looking this up at one point in the spec I was like, is this allowed by the spec? And if you look closely enough absolutely it's allowed by the spec. It's just that most places didn't do it that way because they were assuming that a client secret is fine but yeah, it was absolutely always allowed and just trying to make that even more clear so people when people read the spec it is very clear now that like client secret has nothing to do with which grant you're using it is a thing that is separate from that. Unless the grant is the client. The client credentials grant. Yeah. There is one particular case which is as you know, I have one little thing. Oh yes. I have a little dice. I actually for the people are listening. If you are local, I have a bunch of those in the Balview office and occasionally I bring them I throw them a suitcase for events but now I no longer do it. So if you want one, just let me know and I'll find a way to give you some or more than one for your colleagues. Excellent. Kind of getting ahead of ourselves here but here's another good question related to this. Wasn't there a third client type in 2.1? So yes, in fact, why don't we, yeah, let's talk about this for a second. This was actually part of the discussion at the IETF meeting, which was very, which was, when was that? Not the IETF meeting. Yeah, what? It was in March. It was in March the 20th. Yeah. I have a big column back there. That's why I'm looking at it there for. It was part of the discussion in March and I actually have now just finished doing the changes in the spec to address it and the discussion in March was, let's actually roll this back. It was not a good idea. It wasn't actually useful to define a third client type. Instead of trying to define the third client type which is, it was a combination of confidential public. It was somewhere in the middle. Instead, it's, we're actually better splitting out the difference between confidential and public to not even have the concept of trusted versus not trusted. So. Although I think that the subtlety of a discussion deserves being brought to light. Like one of the reasons for which the credentialed client seemed a useful idea back in the day was that although strictly the definition of confidential client should be I have a credential associated to the app and I can prove my identity when I perform in a, for additional request. In common practice, what happened is that some of these divide have come also to mean multiple instances of your application as it happens for native clients, desktop clients which you have your Slack client on your laptop and my Slack client on my iPhone. That's, which is like a clearly public because of the things that we said earlier of the difficulties of associating a credential. But also it's the instance that it's important not the app in itself versus the singleton. I am the twitter.com website and I am calling the LinkedIn APIs. There is only one LinkedIn.com, sorry, like twitter.com in the world. And so that is a paradigmatic confidential client. Credentialed clients could have been useful for the case in which you have a instance-based client like something that runs on my desktop or my phone and similar. And somehow at some point we managed to assign to that particular instance a credential. Now, if you want to be strict and that seems where the off working group wants to go that's just a confidential client because now it has a credential, so it's a confidential client. The thing that I'm one of the most ardent proponents of these is from a developer perspective a lot of the stuff are details like as weird people like to think about those details but they come to a portal, they say I'm building an app for the iPhone and we decide it's a public client because we know we don't necessarily even tell you for because it's a detail. And there are a number of characteristics to these like it's an instance, it runs, so that like you won't offer eyes, you won't make authorization decisions on the identity of the app because you know that you can't really prove the identity of the app. It's like it says it's luck but it could be me using Telnet or KURL and pretending to be a slack. And now suddenly, if you add a credential somehow out of band you will send the key, now this app becomes confidential which in my portal might have had many other meanings associated to these being a singleton. So I think that we should have a discussion at the off working group in which we clarify whether we can actually just tell to people, you know what, just keep in account that every public client could suddenly become a confidential client and so design your products accordingly or if the design of a current products is far too gone then maybe we need to find a different solution. Sorry, I spoke longer than I thought I would. No, it's an interesting one. And actually that is one of the, that is directly related to one of the other conversations that I brought to the OS security workshop which is the idea of effectively turning native apps into confidential clients and giving them credentials. And yeah, this is exactly the idea. The idea was that credential clients can be built on top of dynamic client registration. So we're dropping the term credential clients but now effectively yes. So what I was proposing in the OS security workshop was a pattern of, and I have slides on this. I'll see if I can get the link in a second. But the idea of using Apple and Google's native APIs for they call it app attestation. Basically it's a mechanism that the operating system provides to create a signed object that can be used to prove that the code that's running is actually the code that was shipped in the app store and is running on a non-jailbroken device. So like in other words, there is a mechanism that Apple provides and Google provides for your app to send something to your server so that your server knows the app, the request did really come from the real app. And that is, that exists. And it's mostly used in game development right now for like high score APIs and things that are effectively public APIs but shouldn't just be actually on the public internet like publicly accessible. So I wanted to say, can we bring that to OAuth and basically use that to do a dynamic client registration call, which would then issue credentials to the native app that it can then use later as a confidential client. And there was generally support for this idea and actually one person had already done it before. And it was, it is certainly interesting. I don't know exactly where that's gonna go in the future. It is absolutely tied to Google and Apple's OS APIs. So I don't know if it's the best IETF standard but there's maybe something there that's at least a blog post for making this more commonly known that it's a possibility. Anyway, that's all to say that like the, yes, a native app that is downloaded from the app store by definition cannot be a confidential client because you can't ship a credential in that but it could do something after it boots up to establish credentials somehow and whether that is something that you then trust or not is a decision that you would have to make based on how it gets those credentials. And that's what we're trying to tease out of the spec because there's a lot of old language in the spec that assumes a credential, a secret is also tied to trust. And that isn't necessarily true. So yeah, yeah. And I think that for some of the stuff that they use cases become of paramount importance. Let's say that here is like a classic Jurassic Park. You were so concerned about whether you could do it that you didn't ask yourself if you should have done it and now that is our everywhere. So like I think that many of the use cases that people would like to use a mobile confidential client for, my intuition is that they will be solved by things like B-POP and similar. Let's say that a lot of the things that people want to do are to break out of the better jail. And when you are a confidential client and you redeem the fresh tokens presenting a credential you are in a much better position than a mobile client doing the same without using credentials. True, there are workarounds like rotating fresh tokens but if you try to use them you know that there are entire new categories of error situations that you needed to handle for rotating a fresh token. So I'm convinced that the moment in which we will have viable as opposed to MPLS, viable actual sender constraints that a lot of the problems there will be solved. Then it's great that there are both APIs. I think if you are onto something when you say it's Google and Apple and we have something similar in the past like when you want to call the system browser on iOS and on Android you make different calls like one is the Safari controller the other is the custom Chrome tab and at the spec level we just say figure it out call the system browser in whatever dialect the place where your application wakes up into needs to use. So maybe you can have your thing which you say here is what an API for these a high level would look like you do the last mile on your own but to me it's like I think at first you need to decide whether there is a use case and it's not just as identity people having all CD and saying those books out of different size and different color these cannot stand I needed to have my bookshelf all sorted. Yeah, I just dropped a link to the slides in the chat here so you can take a look at that presentation that is the only artifact from the workshop since it was not recorded so hopefully the slides make some sense on their own but we should move on because there was a lot more than just the security workshop in the last couple of months. But before we move on I have to mention at least one thing I did one little session in the unconference part about token revocation. Yes. And in particular this thing is from the point of view of the resource server like when you receive a access token and say that you validate this access token using Jot the validation for example so you are not calling back to the authorization server like you would if you'd use introspection. How do you know whether this token was revoked or not? And we had a bit of a discussion about it and basically the two things that emerged it was that people would be happy with having an API that they can call by providing just the JTI the identifier of the access token so that the authorization server can say yes, no. So way more lightweight than introspection. And also- Still a network call though, so it's still network time. Yes, that's a great would be network time which you can do at any time because it's not in the critical path of validation. It's more of like you can do it every five calls if you want to. And the other is to just have basically revocation lists. So as a resource server you can go and say, hey, I am a resource X can you please give me all the tokens that have been revoked? And then these could be a completely static file which gets generated like the discovery file which is not, there is no active CPU called is just and you can see the limit and everything. So- Just the JTI for the revocation for the tokens. Exactly. So be pretty small document. Yeah, tiny list of identifiers. And it's only the list of tokens that have been revoked that haven't yet expired because as soon as they expire then it doesn't matter. Then there's the point, except yeah. And so we have a lot of stuff to do. So I don't know if I'll do any of these stuff soon. And also when you talk about visa with experts the tendency is like, but what about introspection? And so there is usually a long discussion to get to a point of like saying, okay, introspection would send more stuff would get more CPU time. If you are already getting the dropped you can validate it yourself without doing the CPU time twice. But anyway, it's a long discussion and I will not bring it up to the ETF until I have a bandwidth for doing so. But eventually given that people reacted well, I will. Yeah. Great. Okay. So let's see. Oh, a security workshop in Norway. A whole bunch of us actually went and went over to Berlin the next week. So all found our way there through various modes of transport. I actually took a train, which was nice. Nice long train ride. Not the whole way I took a train from Copenhagen but it was fun. But yeah, European Identity and Cloud Conference. That was the first time I've actually been there. So the first time at that event, I heard about it a lot. I tried to get a talk accepted in there a bunch of times and I always heard about the call for proposals a week after it ended. So I was very excited to be able to go this time. Very nice, very nice. Well, I've been many times like I think at one of my first cat of the space presentations in 2007 was at the Cloud Identity Summit, which, sorry, at the European Identity Conference, which traditionally is in Munich. And I think this was the first year it was in Berlin. And that's one of the few events where they give me keynotes, which is narrow racking, but also a lot of fun. And in this year, then I did one about privacy and in particular the fact that the non-technical people in your life that you often absolutely don't care about privacy. And so I put together these 20 minutes of like how to make the non-technical people in your life care about it. And I was very lucky that it was well received and that kind of like set the tone for the rest of the week for me at least, which I just participated in various panels, but that was my main source of stress after a moment and joy after I was done. Yeah, yeah, that was, there was a lot of good sessions there. That one's definitely more on the, how would you characterize the talks there compared to a security workshop? Oh, it's a security workshop. It's a very particular type of talk and type of work there. And I feel like this one is completely different. Oh, yeah, like here, like there, I'd say that of all the values of identity events, the EIC, if you exclude the Gartner, like Gartner IIM is different, but EIC is probably the most business oriented in which you still get a technical like peaks. Like for example, there was like a, the morning of the opening of the conference, there was one entire half day of open ID foundation workshop in which the foundation presented the body as specs that are being worked on. And both sessions were technical, not as technical as OSW, because the assumption is that a lot of the people in the room are not protocol makers, or like people that are more like big enterprises that are consuming some of this stuff. So they care more about what can be done with both technologies, what new scenarios become available rather than they need to read it, how it's done. Although like you can always find a little bit of a mix. So whatever is your poison, you usually you find it at EIC. Definitely a mix. I do remember a broad mix. The talk I did actually was about, essentially it's about the OAuth device flow. I didn't call it that. It was about adding multi-factor auth and single sign-on for those types of devices. And my approach was, yeah, like I'm not gonna get into the weeds on how the spec works because that's not the interesting part. It's more interesting about what it enables and like what you can do with it once you have that tool. So I think it went well. I'm biased, of course, but yeah. Of course. Your session definitely went well. I remember the reaction, people liked it. And in general, it was interesting because the year before, there were some mentions of decentralized but not enough to satisfy the decentralized gods who complained loudly on Twitter. And so these EIC, there was a lot of decentralized stuff. And as usual, I was eager given that this thing is more about the business side of the house. It was eager to see actual deployments like people using this stuff. And I'm sad to report that this year it also didn't happen. There were lots of interesting sessions but with the deceiving titles. Like one was the business model of SSI. And then the presentation was like about the difference between the wallet that you host in the cloud versus the wallet that you have on your local machine. Which was like cognitive dissonance with that error. But in general, like they were also like really important things. Like the white paper, OpenID for verifiable credentials was presented for the first time at the EIC. And it's an important paper because the verifiable credential concept which is largely think about your existing plastic credentials and imagine being able to use them online. So that you don't have to go to the identity provider every time, you just go when you first get the card and then if you want to use it, you just use it with. And it's a very interesting concept but it's been worked in places that are not super plugged into the flows that we are used to like mobile apps, web apps and similar. And so you see a lot of work on the mobile driving license in ISO which is paying a lot of attention to how do I actually give a device in the hand of a police agent that stops you because you were going to fast and wants to check your driving license through devices. And taking that thing and moving it in web scenarios is more complicated or some of the concepts of the ability to use both credentials without calling home come from a decentralized word but it comes with a lot of extra stuff which is not strictly necessary for the verifiable credential scenario. So this marriage between the idea of the verifiable credentials and OpenID which is one of the most adopted protocols for all identity scenarios. It's an incredibly important moment if we are serious about having this is adopted. So that was an important thing that happened in there. They presented this thing and then there was another one which was the gain initiative paper. Are you familiar with gain? Only a little bit. I think this was one of the first times I've really heard about it. So like given that we are so behind just to the flash it game is an initiative which basically looks at some natural let's call it organic identity providers like banks and government agencies that already support OpenID and aims to create a federated network of those providers and have like a common profile so that the customers of one of those entities can actually take advantage of the entirety of a network. Think of it a bit of like visa and you can have a card from IOR Rural Bank which is a visa and you are actually working with that bank but you can use this visa anywhere. So there is visa attempt of doing something similar for identity with gain if it's not the first time in history that something like these happens. Scandinavian countries use BankID which is an identification system based on being a customer of that particular bank but it's fairly out to say totally coupled. Instead of gain it tends to be more open. And so there was like these mega panel with 11 people and those 11 people were all from different areas like governments, banks, identity vendors and they were all there to state their commitment to visa proof of concept which is trying to build visa common profile. So another important thing that happened at the EIC. Yeah, interesting. See where that goes. Okay, we are running short on time. We have 15 minutes and we wanna make sure we get through the rest of these events so we're gonna try to be really quick and we're gonna skip probably skip questions from the chat, sorry. Cause we do wanna give an update on all these different events. So EIC after that, you went to RSA, is that correct? Yeah, and I managed to get COVID. Wonderful, I did not go to RSA. Not that I didn't, they're going to the universe. This is your blog post about the event, I'll drop this link in so people can find it later. But yeah, give us a quick update on what happened there cause also I didn't go and I would love to know. So I went to RSA, I wrote visa trip report for IDPRO, which is like visa union of identity professionals. And RSA is an enormous, enormous event. It was supposed to happen in March, it happened in August. It's like it takes over one entire block basically. And lots of people, mostly security, identity isn't very covered, but there were a few selected sessions about identity. And I only mentioned one in particular, two. Like one was from Mike Kaiser from SailPoint and it was about bias in identity. So bias in machine learning models in facial recognition. So it was a very interesting session, which was half from him and half from his data scientist, which didn't pull any punches and went really low level. So it was like an experience. And the other one is one session with George Fletcher, which is an identity architect VP in Capital One, has been doing for a while. And George, from time to time, takes all the decentralized stuff and he tries with the best of intentions to build a real relying party. Like he takes, okay, say that I have this website and I want to do these decentralized stuff. What is available today? And the first time I saw him doing this was IOW in 2019-18, pre-COVID. Then it was impossible. And now at RSA, it's still very hard, but lots of programs, like a lot of moving parts that before was like, how am I gonna do this? Now they are actually in place. So RSA has a recording of the content. If you have a chance, I highly recommend checking out the session because it's really good. If you can't keep an eye on what George speaks about in various conferences, because I'm sure that it's not the last time that he presents on the topic. Yeah, okay. And then, let's see, in your post, you mentioned the other big theme was the Paskies. Oh yeah, you're absolutely right. Yes, Paskies, at the same time at RSA, there was the WWDC, like the big development event from Apple. And Paskies, for the ones among you that don't know what they are, are basically web-offened platform credentials, platform authenticators, that instead of being tied to one particular device, as it is the case today with Face ID, with Windows Hello and similar, they actually roam within one particular vendor. So say that I have my iPhone, I land on a website that supports Paskie, this thing does a web-offened challenge, which is basically just using the secure element on my phone for signing stuff. And so now the website just saves a public key. And normally when you do this with web-offened, I would have tied my iPhone to that website. Instead, now this key goes to iCloud, and now when I walk to my mini-mac here and I try to send it to the same website, I have the Paskie there available. So these solves the lost device problem, these solves the new device problem, those issues which were blockers for these. Now, months ago, I did a podcast episode exactly about this, and I called it multi-device credential, which is the official term that Fyler was using back in the day. And now once Paskie came out, now instead they're just calling it Paskie regularly. Importantly, Paskie is not a proper noun, it is meant to be a word similar to password. So it's lowercase p, it's not a proper noun, it's not a name of a technology, it's meant to refer to this idea. Absolutely right, it's like password, pass key, same stuff, better technology. But anyway, I'd say had a half day of workshop from the Fido Alliance, allegedly about everything, but it was mostly about Paskie. And it was packed, it was so full of people, and the podcast episode which I recorded months ago for various reasons I couldn't publish it until after RSA, but still is one of our most popular episodes because people, look at that. What happened? All that stuff on their face. Like, it really is in, of all the talks that people have about, have done, about Vizier, it's the death of password and similar, this is probably the first time that they see something like the, as good chances of doing that. They're like perfect storm because everyone has a phone now, whereas before it wasn't the case, everyone is connected like before, not everyone had the data. But anyway, one important part of RSA was accepted that workshop. It wasn't recorded, but here and there there are some interesting tidbits. Like for example, just two days ago, I've seen a tweet in which Tim Capali and Christian Brand from Google and Tim from Microsoft did the demo that they did during the workshop, but they did it in its own little video that now is available on YouTube on demand. So I'll find it and retweet it so you can get it. But the main point is the topic had a lot of interest and Vizier's interest doesn't appear to slow down at all. Tim did a session about that at Adaniverse and I have a tweet in which like half an hour after the end of the session, he still is surrounded by people. Andrew Shikar, the executive director of the Fido Alliance did a 50-minute session in one of the largest rooms at Adaniverse and it was standing room on deck, packed. Yep, speaking of Adaniverse, since we have about seven minutes left, let's talk about that briefly. So that was shortly after RSA, right? And that one was in Colorado. So very hot, very hot weather there. And at a really weird resort, it's in the middle of the desert, it's middle of nowhere, there's this huge building and the conference happens entirely in the building and you basically just don't leave the building for the week because downtown is like a 40-minute drive. So yeah, and packed schedule. So many sessions, so many sessions and a big expo hall. So what was your highlights from that? Wow, that's very difficult to summarize and in fact, before the memory waned, I wrote a LinkedIn article in which I used some of the highlights for me. But for me, the thing is I am together with Brian Campbell, the co-owner of the architecture, identity standards and developer topics. And so for us, the work started many months before with dealing with all the sub-emissions and the proposals and then helping the presenters to refine their decks. And so while I was there, I did a bit of a EMC function just to make sure that all the speakers in my topic had the right things, all of that stuff. So that was a lot of time. But the other thing is that, as you say, so many sessions and identity is on the scale of super technical versus completely business is somewhat between EIC and OSW. It's still business. There are some things that are business and trends big picture, let's say big picture and technical. And so you could really find the full range. And the other is like that there is also a vendor component in which sponsors actually have their own sessions which are usually training sessions. So if you are interested in a particular product you can go and learn something new about that product which is interesting. There was the expo area, which as you mentioned good way of going and discussing with the people that built the product that you're using. So you can really get unstuck, which is really useful. Or for us, the vendors, it's useful to hear what people like, what people don't like. Usually it's more useful to hear what they don't like because it's my thing that you need to fix. But it's of course, it's nice to hear also the nice parts. Again, a lot of variable credentials and similar, no customers inside. There was a nice keynote in which there was a a pretty confusing demo in which you could wear various wallets and then after the session I asked random people saying, can you explain to me what happened in the demo? And most people didn't know. But in respect to last year, it was progress because at least it was called, that was running from multiple vendors. So not there yet. Who knows if we'll ever get there, but progress for sure. And a lot of interest, like a lot of people interested in that. And one thing that happened is that that is just like we mentioned about the OSW and IOW being places where new initiatives are incepted. That also happens during I-derivers. And so this time, like we actually got like all big vendors and big and small and big customers inside the room. And we discussed the one thing that might become a new working group in the OpenID Foundation. Can't share much details yet, but once I will, I'll be able to say, remember that I have the IOW with Aaron back in July. That's what I was talking about. So that's like a very consequential event. Whenever someone asked me in Victoria, I can only go to one event for the year, which event should it be? I always tell them I-derivers because it has everything, something of everything. And usually the quality is really high and this was an exception. I say this despite of the fact that I caught COVID during that week. I arrived home and I arrived home on Friday night. On Sunday, I had a bit of a fever, but negative on Monday, I was positive. So, but given that luckily it was very mild, I'm okay. I would go again at I-derivers even knowing what happened. I saw a lot of tweets from people who caught it there. I thankfully skated by without it this time, unlike Vienna. So, oh well. All right. That was a good update. Let's, I guess we wrap it up there. It's been an hour, this hour flew by.  So, next up we are, you're going in person right to Philadelphia? For just one day, but yes. And you are coming as well, right? I am going for actually the whole week. I've got a couple of different things going on. So, that is ITF meeting. OAuth meeting is on Monday of this coming Monday, I guess, Philadelphia. And the agenda for the OAuth meeting is completely packed. It was about 10, 15 minutes per item and there's a whole bunch of items to fill the two hours. I can't wait to see what happens there. It's gonna be interesting. There's a lot of new stuff that's on the agenda that I didn't recognize. So, that'll be interesting. And we'll report back after that because it's gonna be a lot of stuff that happened. And we have a only two-hour meeting during the event, but three two-hour sessions in off-side meetings that are not part of the official agenda for time the group has set aside to discuss the inevitable things that come out of the main presentation when you have to speed through the topic in 10 minutes. So. And I'll do my best to connect there because I'll be in Italy. Like I come for one day in Philly and then I go to Italy for just three days. And during those three days, I'll try to connect remotely and not make you guys two envoys that that would be in a really beautiful seat down. Yeah, cool. Oh, and comment. I hope that one of the next happy hours will be fully about OAuth 2.1. I think that is probably likely because OAuth 2.1 is on the agenda for the ITF meeting. There is like a proper amount of time for it. And I'm sure we're gonna have a session, side session about it. And there's been a lot of progress on it. The turning the gears on it over the last couple of months. So new version will get published on Saturday. I'm still working on that. And then we'll have hopefully a bunch of new stuff to talk about it. So yeah. But you actually can't publish right now, right? The tool itself. Not yet until Saturday. It opens back up. Very nice. So I have to wait until I get there. And then Saturday night is when it opens back up again. So I'll hit the button then. Yep. Walk us through it. Yep. All right. Thanks everybody for joining. Sorry we didn't get to all the questions this time. But there's a lot to cover. We'll try to come back again more regularly than once every three months. So we'll try. We'll try. All right. Thanks everybody. Have a good rest of the day. Bye. Yep.


Benefits and challenges of being a volunteer teacher. Doing nothing for others is the undoing of ourselves. Horace man. Volunteering is one of the most satisfying human experiences. It gives one a feeling of relevance, of giving freely to those whose live those skills one, has will be of an immense benefit too. A volunteer has been defined by the business dictionary as a person that, that actively takes on a task, responsibility, or project on his or her own accord without needing to be assigned, bordered, or told to do so. Often a volunteer is not paid for the work that they provide. For example a volunteer may desire to work at a company's charitable events with or without pay, and may even request to do so without being asked or told to. Volunteers responsibilities. A volunteer teacher takes up a vacant teaching spot when necessary. His vacancies are not there by design. They always come based on at least two reasons. Lack of teachers qualified to take up those positions. Lack of sufficient funding for such programs. In the case of English teaching it is important to note that the business world is biased towards the English language. This has caused a disadvantage for countries where the language is not spoken officially. There is also a bigger issue for poorer countries in the sense, that they have a more difficult task of attracting talented teachers, and native speakers due to their lack of sufficient remuneration packages. This is why there are needs for volunteer teachers. Volunteering in Ecuador. Ecuador has foundations tasked with sourcing and convincing English teachers to come in, and help in the development of the language in the local schools or language institutions. Benefits of volunteering. Being confidence, for most volunteers this would be their first experience in teaching. Since they are just volunteers, it gives them time to work long enough without pressure in order to gain confidence. Make a difference, most communities in the bed of volunteers are poor. This signifies that whatever benefits they receive will go a long way to add value to their lives. Meet interesting people, volunteering can help you meet different kinds of people and make new friends. Be part of a community, volunteering in a community helps you build goodwill quickly. You end up having a new family. Learn new skills, if one volunteer in a foreign country, for instance, teaching in English in South America, the probability of picking up the Spanish language is increased. Take on a challenge, communities in need of volunteers often have social issues. Apart from the financial one, a volunteer may have to take on these issues in order to get across to the students. Have fun, well, enjoy yourself to the fullest. Challenges of volunteering. The most common problem for volunteers is a disorganized program. Volunteers show up and the event is canceled or understaffed. If a program is consistently disorganized volunteers will quit in discouragement. Change of personal. Too much work, when there are not enough volunteers the available ones will get overworked. Fordham, when there are lots of volunteers for teaching positions, the teacher may end up doing meaningless work. Being overtaxed emotionally, this has been known to happen if the students involved with have serious challenges. Getting involved with those challenges could put too much emotional pressure on the teacher. Ineffective administrators, lack of communication from the volunteer manager. Negativity from colleagues, staff and colleagues may not have the kind of zeal like you and may try to discourage one's interest. Lack of appreciation from staff. Lose of interest in the cause. It is of utmost importance to always remember the reason for taking up the role of a volunteer teacher because, even though the benefits are great for both oneself and humanity in general, the problems are also really enormous enough to change one's mind towards the whole idea. Volunteer teacher needs to always be mindful of the intention for taking up the challenge in the first instance and not allow for doubts to creep in. Do you want to teach English all over the world? It is better to opt out entirely in that instance because any negative feeling well eventually have a spillover on the good work is done already. Thanks so much for watching. We are ITTT, the leading provider for TEFL and TSOL training courses. If you like this video, please subscribe by clicking that button down here and click on any of the videos here on the left for more interesting teaching tips for getting certified to teach English abroad and online.


I enjoy riding the bus to work. It's less gas and it's just overall better for the environment. And also it's a great affordable option for me, I'm saving on gas. That goes for cost savings as well. You meet some nice people on the bus. I take the metro to work so I don't have to worry about parking in town. I've been taking the bus for a long time. It saves money on cars. My wife and I only have one car instead of two. It's thousands of dollars that you'll spend for an extra car. And it's not just the car payment, but it's the car insurance. It's the gas. It's all the things you put in your car. All those things cost money. And so I take the metro. It's a really economical way to get to working back. I think more people, if they would just think it through, they would take the bus.