 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. And there just are a bunch of ways to use it poorly. 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? I don't know anything about I'm just making a shit up but it's mostly saying those are the kind of things that we might see discussed. 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. And finally enough of the browsers are trying to go in that direction. 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. The last thing I will say is I guess what's happening next. 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.