 Oath Happy Hour. I'm Aaron and we're also joined by Vittorio. Vittorio here. Ciao. So it's been a while, but we are going to catch up on what's new in the world of Oath, talk about what's been going on with the specs and what's been going on in the community, any events that have happened since we last caught up, which I think was a while ago, several months, possibly six or seven. But if you are here live, watching live, feel free to drop in questions in the chat whenever you want, ask us questions. We will see what we can do. And otherwise, yeah, I'd be just hanging out in chat. So that's pretty unbelievable. Thinking that the last time we did this was October. It's crazy because especially in the last two months, there was something basically every week. Now is the first moment in which we're a few weeks in which there's still stuff. Like last week there was Identity Week, which is just two days, but it's a week in Europe. But we, I don't think, you didn't go, you didn't go, right? I didn't go. No, I don't know. I heard about it, people talking about it at the last IETF meeting in San Francisco, but I did not. I have not actually been. Yeah. I've been a few times and let's talk about it some other time. But as I was mentioning with Aaron earlier, like, I think I have an interesting prop. Like I recently started doing some order because you see the shodger here because behind me there is a horrible mess. And I was making some order and this bug is all my, all my bedrooms for the last few, so my plan is I just going to pour those on the floor and then we can start pulling them out and talk about the corresponding event. If it works for you, does it work for you? Great. I love it. Okay. Dropped. All right. So what do we have here? So did we have octane by that time? Oh, yeah. Octane was, I guess that was in the fall, right? Yeah. And it came to mind for the wrong reason because this thing was last week. It was two weeks ago. It was like an event in DC. But like, yeah, octane, is there anything spec wise that did you do anything for octane? I had a session, I believe, about, about OAuth. And I'm trying to remember what my session was now. It was, I usually do something. So for anybody who's not familiar, octane is octas conference that they put on every year. And it's a, you know, product announcements and stuff. But there's usually a developer track. And I usually try to do a talk about OAuth there. And I am trying to remember what my talk was, but it was so long ago that I have completely forgotten. Let's move to the next one. The next one was, I think it might have been TPAC because it was in November. Yeah. That is W3C's conference, right? Yes, correct. And it is in a particular conference. Like, there are like the various browser vendors and anyone that works in adjacencies. And it covers, as you can imagine, so much ground. But my angle in particular was the changes that browsers have been making for doing privacy protection. And so Apple and Google and Firefox, they were all there. And I think it's one of the special things about the conference is that Apple is actually very, very active. Like, often you go like, at a say, at a deniverse, and I suspect they are there, but they don't say much. Instead. Yeah. And they don't even put Apple on their badges either. I've had that happen before too. Right. Like, they are very, very secretive. But like, in TPAC and in Fido, they are the two places where instead they participate more. Interesting. There are lots of discussions about like, measures like various these FEDCM, which is this new API that the Chrome has been driving for doing authentication in a way that the browser can observe it. And then if a browser can observe it, it relaxes some of the constraints with third party cookies and similar. There were some early discussions about one new measure that is going to eventually hit us, which is bounce tracking protection. You know that now that browsers no longer allow third party cookies, trackers are using a different mechanism, which is when you follow a link to your destination, they briefly redirect you to a different domain, observe the context of your request, add it to your dossier, and then they redirect you to your destination. And now browsers, when they detect this, they want to disrupt this flow. And so in particular, there was this discussion about like when a domain is flagged and doing this, dropping the entire query string. And oh, wow, this scenario I just described, it will sound familiar to you and to our audience. It's pretty much what happens with authorization servers and identity providers. So the good news is that browsers, people are aware of this thing. And so they will do everything they can to avoid disrupting. But this is something that definitely needs to, we need to keep an eye on. And there were a lot of discussions about these in there. And then like, we have so many other things to cover. So I will not spend too much time. But I'd say that the other important part was where Boffin was there. Like, you know, for the past keys and similar, there are like these two bodies, where it's FIDO, that mostly works on a setup and actually how to talk to authenticators, abstracting away their details. And then there is how to invoke that capability from browsers. And that part is covered by Boffin. And of course, past keys, like again, so much stuff has happened since then. But then it was like early movements of like people starting to say, Hey, wait a minute. Now with past keys, there are things that I can no longer do that I could do before. There were still a lot of like, I don't think that Google released anything at that point yet. But then after that, they released a lot of support. So it was an interesting conference. And this year is going to be in Valencia in September. And I still like, I'll do my best to go and it will be coming. Okay, I see that we have some comments. Have you been following? Yeah, okay, let's take a look. This is a good question here from Roman, multiple part question. So you're building your own IDP should support both OAuth and OpenID Connect, uh, looking for guidance on recommendations in particular. OIDC has strict rules for exact matching redirect URLs. OAuth one does not, for example, the local hosts with dynamic port is allowed for OAuth to and not OIDC. Scope is optional for OAuth, but required for OIDC. So it's hard to find a way to build something as close to specs. Interesting. I would say they're probably, um, my first response to this is that building something that is a completely generic OAuth and OpenID Connect server is challenging because of exactly what you're finding of the different optionality, optionality is available. Um, that said, there aren't that many completely generic OAuth and OpenID Connect servers because in most of the time you need to do something a little bit more specific in order to actually get something working. And that's why OAuth is called a framework, not a spec, because it isn't actually a complete interoperable spec. It's a series of building blocks that you can turn into a spec. OpenID Connect being one. So I am surprised to hear that OpenID Connect doesn't support the dynamic port thing local host exception that OAuth does because I thought that was not further restricted in OIDC, but I don't remember that now. Yeah, it doesn't really ring a bell. Yeah. And also like, go ahead, go ahead. I wasn't saying on the scope one, scope is a, it's optional as in it's very possible that an OAuth application does not actually request any scopes because the OAuth server knows what to do without the client asking for it. OpenID Connect requires scope because OpenID Connect, you kind of turn on OpenID Connect by using scope. So if you include the scope OpenID in the request, that's how you tell the OAuth server that it's now at OpenID Connect request. So that's why it's required. It's not really like one's not required and one's required. It's just that like OpenID Connect uses scope to turn itself on on top of OAuth. So you have to do it. So I think the, I think the other thing you're running up against is the fact that these two protocols do do different things and they are for different purposes and you may not actually need both all the time. Like OAuth is all about this access token. It's all about getting the access token to the app, which is for protecting some other API that's not the OAuth server. And the whole idea is that it's a way to get the access to have the client get an access token. Whereas OpenID Connect is all about the client getting an ID token to learn about who just logged into the app. And those are completely different problems, which is why you're seeing some of these differences. And it's very possible that the use case that you actually need to solve isn't both. It's either one or the other. So this, I think, is the part of the problem of trying to treat this as a completely generic problem. You know, that if I can refabit them that it's not often the case, but you can think of OpenID as a profile of OAuth. I'm exaggerating a bit, but OpenID is built on OAuth. And so necessarily it's going to be different. Let's say that OAuth is a component, a building block, which is used in OpenID Connect. In particular, if you just look a bit of the etymology of this thing, OAuth is an authorization, delegated authorization framework. And people were using it anyway. They were abusing it for achieving signing. So if a particular entity exposed the ability to call their APIs as a third-party client, but people wanted not to call their APIs, but to just prove that the user had the valid account in there, they somehow used OAuth and used the fact that the OAuth flow work, the circumstantial evidence, to prove that, yeah, the user did have that account. Unfortunately, the way they did it was harder to generalize because every API is different and it had various other issues. As in, if your goal is to call the API, then the artifact you get just allow you to do that, but doesn't prove that you obtained the token as a particular client or even a particular user. So OpenID layered itself on top of OAuth to do that particular scenario right. And as Aaron mentioned, authentication and delegated authorization are different scenarios. So trying to do both, like when you are doing OpenID, you are indeed doing both, but you are necessarily using a subset and you are piling on extra requirements, such as, for example, they must use the scope, otherwise I cannot tell the authorization server that, yes, what they want to do is OpenID. So in other words, unless you are trying to build a product that then you sell as a genetic multi-form thing, typically you will not have a problem that you are describing. And even in the case in which you are building a product, take it from someone that has been for a while, typically you usually don't want to operate at the protocol level. Let's say that people will come to you with a problem as you have a website and I want to say, I have an API that I use for setting appointments in a calendar and I needed to call it from the secretary of these particular executives. So how do I do this? So probably people will think about scenarios rather than protocol features. So long story short, I think you'll be fine. Like find the problem you want to solve and the implementation constraints will just reveal themselves. Yeah, yeah, great. And David is in the chat. Greetings from Spain. Will this be available for watching afterwards? Yes, please stay up on the channel. So feel free to come back and recap all of our musings later. If you really, really want to, if you can stomach my accent again, yes. Whereas the perfect diction from Aaron, I'm sure would be music for your ears. Sure. Yes. Okay. Thanks for your answers. Thanks. Good questions though. Okay. Okay. Do you want to pull another badge? So like here, I was looking at the badges in the meanwhile and unfortunately it looks like people don't like to put the dates in it because I know that there was definitely stuff with Fido and there was an authenticated conference, but I don't know if these badges from this year or the year before. But anyway, doesn't that, there was like a month ago, right? No, a month ago was this one, which was the Fido plenary, right? It was only the plenary in Yokohama. No, sorry, in Taipei. No, wait, what am I talking about? It was in Dublin. This one was in Dublin. This one in February was in Taipei. But anyway, we can make one single thing for all the various Fido conferences, I guess, which were like at least point three. Authenticated just happens to be the public one and these ones are only for members. And the next one that is coming in October and it's going to be in San Diego this time, as opposed to Seattle, which is a bit inconvenient for me because Seattle is here, but on the other hand, having an excuse to go to San Diego, fantastic. Anyway, the main Fido thing is, as you can imagine, pass keys, pass keys, pass keys. Like pass keys have been like these exploding things. It's a great advancement, huge improvement versus passwords uses like originally when it was announced, pass keys were substantially what we were used to call platform authenticators, which are like using your phone or using your TPM on your PC as cryptographic sources to authenticate. But the challenge which limited adoption of this thing was that basically it was a very boring name. Say again, it was a very boring name. One, the name was not fantastic. But the other was that everything was tied to the device. So if you go on a website and you sign up using web offer and Fido authentication, you get like pre pass keys, you'd get your credential on your device. And then if you'd go like say that you did this on your iPhone, and then you get on your Mac, you go on the same website, now you need to re-enroll. Now, when pass keys were introduced, the idea was okay, let's have a new type of platform authenticator, but behind the scenes sync up your keys so that if I am using my iCloud account on my iPhone, and I sign up on a website and I do these using web offer, now when I sit on my Mac, I can just have access to the same credential. So I don't need to sign up again. And interestingly, on my phone, I can use my Face ID. And on my Mac, I have my little fumb check. So what ROMs is the key, but not the biometrics. I have an article on our blog about it, but can get it later. But the main point is like this was introduced first by Apple and then by Google, and it follows the standards by FIDO. And the idea of what these means evolved. At first, the term pass key meant synced pass keys, like things that are synced on the devices. And then it progressively got expanded. And so now it's basically a full rebrand of FIDO credentials. So now when you say pass keys and when you go on a browser and you try to use web offer, you'll see the thing that starts saying that you want to use a pass key. And even if you want to use a security key like a UB key, it's under the pass key umbrella. And so after the initial enthusiasm, which is still going strong, like lots, like almost every week, there is a new website supporting pass keys. Now there are like a number of interesting challenges. Like, for example, when us as relying parties receive authentication using pass keys, we don't really know from where those pass keys are coming from. And so, for example, if in the news there is a breach that some pass key provider was breached, now we cannot decide to only reject most pass keys, we need to reject all possible pass keys, which of course doesn't work all that well. So in all these three meetings, we have been discussing with the platform providers what solutions can be used in this particular problem. For example, the other is like currently all the pass keys sink across a platform. Before you do that, can we back up, have a question? Go. When you say you don't know where the pass key is from, you mean that the relying part of the website you're signing into can't tell if it's a iCloud synced pass key or something from Android OS or something from like a one password? Is that what you mean? That's the idea. So like the point is there is something in the request, like there is a good which hints at from where things are coming from. But this thing is not certified. It's not attested, let's say. There was these attestation idea which we had before where there was this idea of a synced pass keys that was largely like UB key, for example, as an attestation in which you can cryptographically verify that the authenticator that was used is a UB key. And so all the guarantees that come with that can be included with these. But right now, instead, basically the authenticator just says I am X, but you have no way of actually proving that's the case. So in theory, someone might craft an artificial authenticator and pretend to be one or the other. And also the other part is that there is nothing in, so this one is about the identity of the pass key provider, like where pass keys are saved. And then there is the other part which is how they are saved, like pass key in itself does this nice asymmetric crypto interaction. But then if, for example, the way in which you recover your account on that platform is using a non fishing resistant mechanism, people might buy a new device, steal your password, restore all of your stuff in your device and now they have access to your pass key. So some people would like to gather with the authentication, also some kids that some due diligence has been done or some certification of a sync fabric. So I don't want to take the entire hour on these, but there are some discussions about how can we do this? And should we do this? Like there is also the idea of like, well, actually, no, let me stop here because again, there is so much stuff that is happening. But the main point, the meta point is pass keys are gaining a lot of ground across the board as they gain ground and they get adopted. Some of those practical considerations start emerging. And so as those things emerge, Fido looks into it and its members try to solve. So that is the spirit. So if someone wants to learn more about pass keys and follow this stuff, where is the best place to go to keep tabs on these discussions? So I would like given that we are blue colors, in my case, yes, particularly blue colors, but we are technical people. I think that the pass keys.dev is the right place to do this because it's the place where you find pointers to technical documentation. It's the place where you find the matrix of all the operating systems and what is supported, what is not supported, like browser versions, and the various features, like for example, is Chrome on Android supporting synced pass keys? Yes. Is Chrome on Windows supporting synced pass keys? No, it will create stuff on the locker. So that's the kind of stuff you'll find. And then, of course, from there, you'll have links to the file alliance. And of course, as you see more vendors supporting this, you'll find documentation which is specific to vendors. In Okta, we do support pass keys in the management side. As in, you can put constraints about how your users use pass keys. And on what we call CIC, which is a customer identity cloud. So basically, we have experimental support in which you do a good flip and you use it. So there are a number of places where people can learn more about it. Great. Okay. So moving on from pass keys, let's talk a little bit about some of the OAuth specs and their progress. Because October was a while ago and things are moving along in the OAuth group at the IETF as well. I guess the most recent one was rich authorization requests is an RFC now, 9396. And that is exciting news. So that one, congratulations, everybody. Always a good milestone. Rich authorization request, been in the works for a while. And it's an RFC now. So now hopefully we'll start seeing more people start to pick it up and use it for things. You don't have to remind people what it is used for? Yeah, it is a way to do, I like to think of it as a way to do scopes that are structured. So scope is all about like requesting access to certain kinds of information and smaller amounts than someone's entire account. Rich authorization request is like that but even smaller. So like instead of saying I want, I'm logging into this app and the app wants people to transfer money, which would be a scope like transfer money. You could actually say I'm going to authorize this app to transfer at most $5 or I'm going to authorize a payment from this account to this account. And you can authorize specific things instead of more broad scopes. So tiny slices of things and in a way that is not possible really to represent with scopes. I mentioned payment because it kind of came from that world of the financial world of those use cases, but it's not at all limited to payment. It could be for anything. It could be for accessing specific photos in an album or it could be healthcare data about specific types of records or authorizing release of medical records from one provider to another. Yeah. I like your more granular scopes. The way in which they explained it to me the first time that I heard about it was you can have like a document.read with scopes. With RAR, you can say the particular document that you read. So very powerful. Very powerful. Roman says it looks like RAR is resource indicators 2.0. I don't think so. No, because it's more about it's both less specific and more specific. It's not necessarily talking about specific resources. It might be talking more about specific types of resources, but you could use it for a particular resource as well. So it's a little bit more broad than resource indicators, I guess. Yeah. I guess the thing is that if you look at a very restful word in which like everything is modeled as a resource and then you can put, get, delete and similar, then I can see how you might think this way. But I think that the RAR can be used in a more RPC by maintaining the analogy. Like you are not limited to those verbs. You can express anything you want. And so resource indicator is more of like statically, I want to identify this particular thing and not necessarily the actions that you can do on top of it. But as RAR as authorization in the name. So it's not as much about identifying is more about what you can do, what you want to be able to do with something. Yeah, which is why I like to think of it more like scopes, like fancy scopes. Yeah. And for me it's like I have a bit of an allergy of that particular stuff because like scopes has been abused for so many years. And there is like this thing in which like if people see a scope in the token, they automatically think, okay, I've been granted this privilege. And that's not the case. This thing is like if the user has this privilege, then you can use it. But there is also always these if the user has. And I have an impression. I'm not sure I have to admit ignorance, but I suspect that RAR could go beyond the sheer delegation stuff and actually make something happen on the fly and make the thing do a decision saying, oh, yeah, I'll let you do this particular thing even if it's not strictly something that the user could do. So that's my only hesitancy of putting the scopes together, but I think it is a good practical way of approaching it. Then as you double click, then maybe there is you know, the quantum level beyond the which you need to drop the analogy and use something else. But yeah. So actually, along these lines, I was reviewing some other specifications last week that was actually part of the US federal government proposed rule about healthcare. And there was a comment period that ended on Tuesday. And in that, it was a huge, huge PDF full of all sorts of requirements for electronic health records that anybody with a system like that's gonna have to follow. And one of the they were basically saying, you know, we want feedback on these new regulations. Part of that was about API security in the healthcare space. And part of that was saying how to use OAuth in the healthcare space. And that work had already been done by a different standards group. And that work is called the smart framework. And there's a whole whole bunch of history there. But one part of what the smart framework had done, which started working on this long before which authorization requests was even the concept was they had started defining scopes for the health industry. Because that's what that makes sense. Like you want to interoperate on exchanging data. And you need to agree on scopes, which is why, for example, open ID defines scopes that everybody agrees on so that we can interoperate on identity profile scopes. So this spec defined health related scopes in terms of like patient records and blah, blah, blah. I don't even remember what they all are. I'm not deep enough in that in that industry. But one of the things they wanted to do was to get to some of these kind of more rich or flexible scopes. And they actually do have essentially a query language built in to the scope parameter in this framework. And there's things like less than signs and full on URLs that get put in scopes to talk about specific documents and things like that. And it was a very good example of taking scope, which is essentially a framework of the because a lot doesn't say really anything about scope other than it's a string, it's going to show up over here show up over there and do what you want with it. And then turning that into a rich authorization framework. And one of my comments on this on this document was basically, this is a dangerous path to go down because rich authorization request, which is now an RFC has actually solved this problem in a much better and more interoperable way. And if you want these features, you should probably be doing this instead. So that is now a matter of public record. Nice. Well, we know that the future is already here is just not going to be distributed. So I am ready to bet that they did that work without knowing that the RAR was happening, which is very bad because I had an episode with Philippe Skokken on the podcast, which was about RAR, JAR, PAR, and these was covered, but I guess that we didn't manage to reach them. But anyway, the fact that they had open commentary means that they must have baked some of these into their process. So hopefully they still have time to roll back and or at least consider. At least consider. The good news is that the proposed role was specifically asking for feedback on that and not in a way that suggested they were going to require that particular aspect of it. There were other things that they were like, we require this and, you know, people can complain about it or whatever. But this one was more like, we would like feedback on this use of scopes. So they got feedback. And I suspect that apart from due diligence, they might have actually tried to do it. And it's not easy. Not only it's not great from a security perspective, not only it's not very efficient, but scopes are just not designed for that thing. Scopes were pretty broad strokes. I won't say naive, but like a pretty basic thing of pictures on a website. I want to print them on another website. And so I need the picture that read. They weren't designed to say, well, if you are in Leon, and it's five or five PM on Friday, then you are a French national. No, you cannot access your email. Otherwise, you can sue with a union because you did it in the weekend. And I'm using the French example, because I see Jeff Lombardo, Francophone, famous Francophone, in the identity space commenting in our comments. A scope explosion blog post by Victoria was still a good resource to read. You know what? I don't think I've actually read that. Really? Oh, wow. Like, if you Google on the nature of scopes, you'll find it. And here I have to brag. I've been told that a lot of people in the industry have been sending that thing to people whenever the conversation goes on scopes. Then it was my attempt to write once, explain every time, like instead of repeating the explanation every time. And it's nothing transcendental. It's more of a scopes, narrow what you can do and not the opposite. They don't add stuff. And if you think you can do everything, all your authorization in that thing again, because your tokens will be enormous and authorization server doesn't have all the context. So pretty well-established stuff. But at least it's in one single place. So hopefully easy to consult. Cool. I will have to give that a read. Thank you, Jeff, for the kind words. So, okay, rich authorization requests. Got an RFC. I think that's the only new RFC since October. Although we are so close. I know we're so close on a couple others. Deepop is like, I think it's officially in the RFC queue. Yeah. Deepop and step up off also, right? Almost, almost. At this point, I went through the II. I and Brian Campbell, my fantastic offer, went through the ISG purgatory, which is like for people not familiar with the space, are experts in the area, but not necessarily experts in the working group. So not necessarily all of experts, but security experts that we fresh eyes go through the spec and find all the smallest things. And the problem with step up is that it's easy for everyone to have an intuition about it. But as soon as you start thinking about it formally, it's usually the parts from intuition. So for example, step up is not always possible to save whether one level is higher than another. They just can be different. It's kind of like a lattice instead of an absolute order, if you think in mathematical terms. Should have been called step across authentication. Well, it should be called the step up of indication. Don't give people any ideas, please. Now that we are so close to this thing, it's more that we need to capture the intuition that people have. But once we capture them, we need to explain to them how it really works. If you double click and think about it for a second. And that's what we tried to do in there. But some of the people that commented were not part of the formal conversation. So they brought up similar points to which we looped them into those conversations. And we showed highlighted the things that we did in order to solve some of those things. But right now we are in limbo, in which I think the area manager needs to, area director, sorry, needs to look at this thing and decide whether all the comments have been addressed to dissatisfaction. And we believe they were, and if they weren't, we need more concrete feedback. But for the time being, we are in limbo. In the meanwhile, a number of people already went ahead and implemented it because it's not particularly hard to implement that was designed to be trivial to implement. So apart from these swords, which is hanging on my head, that suddenly I might have to go and visit the language, I'm not to worry. I'm just waiting for nature to take its course and eventually become standardized. Hopefully it gets an RFC number before 10,000. It would be very nice. Coming up on that soon, should be only a couple more years, right? Oh, yeah. Oh, yeah. Oh, well, my hope is that this stuff is measured in time. I will not say it. I don't want to jinx it. So, never mind. Okay. Speaking of things that have taken a long time, the security BCP and OAuth 2.1. So, Daniel Fett, who is the editor, one of the others of the security BCP and myself have decided that we are pushing through the last of the work on these documents to try to actually get them out of the working group this year. Obviously, we cannot say they're going to be RFCs by the end of the year because there's so many parts after it leaves the working group that take a long time, as we're seeing with a lot of other drafts. But we can say that we want the working group to be done with the drafts before the end of the year and have that as a goal. We've been so close for so long. We've been so close, but there's a lot there. The two of us have been working for the last several months now on making sure that both drafts are up to date and in sync with each other because the whole point of OAuth 2.1 is that it's consolidating a bunch of older drafts, including one of which is a security BCP. But since it's not actually published yet, what's been happening is that people will have discussions about one or one of the other drafts and both will sort of evolve and change and not necessarily cross pollinate again. We did a big push to make sure they're both up to date about talking about things the same way, using the same language and consistency and making sure that any decisions that were made about OAuth 2.1 by the group are also reflected in the security BCP and vice versa. I believe we have finished the security BCP on that. The new version is published a couple of weeks or two ago reflecting all of that in advance of the next meeting and I'm working on OAuth 2.1 now as well to do a bunch of that. It's already brought in and there's a couple more things that we're going through on that to finish updating that. Next month, I guess that OAuth 2.1 will have again a slot at the ITF in San Francisco where we can finally get, I hope, to their native clients, which is one of the discussions that I think will be more... Oh, actually, that reminds me. Wait, were you not there? Did you not come to one of the ITF meetings in the last two? So the last two, I came to Yokohama. I was in Yokohama. Yeah, where you were in London? I skipped London, but after that, I asked if that was discussed and I was told no, it wasn't. So I did put something on the agenda for... I think it was London and what I did was I felt like a lot of the comments in your write-up were about the fact that the native apps section or the native apps.rfc tries to talk about mobile apps and desktop apps as if they're equivalent and that they are just... It's the same problem and everything applies to both. And in practice, that has turned out to not be true at all and desktop apps behave in a very different security considerations and environment in many ways. But the native apps rfc still does apply to mobile apps and everyone generally follows that advice still with a couple of minor tweaks. But so what I did is on the agenda, I put in something that was like, let's talk about the native apps feedback and my suggestion was basically let's rephrase all this text in this whole section to just make it talk about mobile, not desktop. And since we don't have recommendations for desktop apps because no one's following the native apps recommendations on desktop, there isn't a best practice for desktop apps that we can even say. So we're just not going to pretend like it is desktop apps best practice. So I now remember the discussion and I remember that basically it was something to the effect of good to make the distinction. But I also think that we cannot leave people entirely alone on the desktop side. So at least telling people what are the dangers, what are the trade offs and all of that, I think it's important. So we might not achieve the same level of courage that we have for mobile, but still think of the effect of just saying you are completely on your own as opposed to still telling people, okay, the tradeoff between the using the system browser and using an embedded thing is embedded thing might be blocked because certain providers don't like it. If you're embedded thing, you will not be able to do single signal because the cookies are elsewhere. On the other hand, if you use the system browser, you might have a problem with Z buffer or your user might need explicit action to come back. So giving a bit of here is what you might expect without pretending that we can give complete guidance. But I also don't think that we can completely ignore it. That's fair. Yeah. Yeah. So that's, I think that is, I think everybody was pretty much on the same page about it. Yeah. I remember. Now that you mentioned these, I remember. So, yes, you're right that we spoke about it. I don't think it resolved the entire thing because the other part is even when you say all of the stuff still applies to mobile, you know that one of the methods that we talk about in mobile, I think is the custom URL, which now some browser are looking at completely disallowing. So there might be, for things like the port, like some people we know in practice, they don't want to use it, but the existing guidance says must support all three methods. So I think that there might be some things that need to be modernized in there. Yeah. That's definitely a tricky one. It's a bit of a bit of a mess right now. Gonna be fun. So that's probably the biggest chunk of text to update in OAuth 2.1 still. Other than that, we're getting down to some of the pretty minor stuff. And you get a fantastic job. I remember that when there was the discussion about should we do OAuth 2.1, my answer was like, no, there's gonna be so much work and in the end, marginal. But I have to say, but yes, it is a lot of work, but the fact that you guys are doing it makes it really light for me. And it's like you have been doing steady progress, apart from like some yaku's at some point, like I've seen steady progress on this. So yeah, now that it's such a good point, such good progress, I see that there is a lot of that. Yeah. And I do think that even though it isn't yet finished, I think that even having these conversations has helped things in general about getting people on the same page about best practices and what we actually mean when we say OAuth 2. So I think overall it's been a positive thing. Yeah. So we have only 10 minutes left. And there's so much stuff happening in here, like there was a two veteran of IW, there was RSA, there was a Gardener, which I did not go to, there was EIC, there was Identifers. So I don't know, like in these nine minutes, what do we want to do? Like clearly we cannot do everything. So what do we want to do? Yeah. That's all that's a lot of stuff. Most, let's see, what was the most relevant OAuth discussions that, did you see any themes across the different events that are related to OAuth? I'm thinking, like one of the things that is most buzz-worthy, I'm looking at my my little three reports, which I had recently do. And also I had the same problem, like I had one entire quarter, so I had to refresh my memory on what happened. Like I think that there is like the top themes, which now you tell me what is most relevant to OAuth, one is authorization, like both last year's Identifers and this year's Identifers and EIC to some extent. A lot of talks about authorization, a lot of people excited about the opportunity of authorization, lots of new companies that are making their raison d'etre authorization. So for them, it's important for this thing to work otherwise, we don't make any money. So there are a lot of conversation about this. And there are talks, I don't want to go into the details yet, but there are talks about creating new working groups that would cover it. I think OAuth might end up playing a role, but I think that the role might be limited to like the same role that OAuth plays when you do skim, which like skim has an API, you need to secure calls to this API. So what do you use for securing calls? Well, and authorization has like these different roles, various with policy, decision point, the policy enforcement point, and how do you communicate policies between one and the other, different solutions. Somehow, you know, the famous XKCD comic, which like, oh, there are 10 competing standards, we should do something about it. Results are now 11 competing standards. I suspect we are now at this magic junction in which we might end up doing that. But who knows? Maybe it will be there. So that's one trend. The other trend is all the stuff about the verifiable credentials. And given that we go back all the way from October, one thing that happened in the OpenID foundation is that they open ID for verifiable issuance and verifiable credentials and verifiable credentials and verifiable presentations have been restructured to be built on top of OAuth rather than on top of OpenID. And so now they do a lot of things that are similar to what OpenID does. Like for example, the wallet is both an authorization server and a client. But now if you look at the specs, the specs now build on top of OAuth. And together with these, not OAuth itself, but in the OAuth working group, you know, selective disclosure jot, which is actually the magic version of a jot that can be, can selectively disclose its claims without going back to the issue, is now being very widely accepted in many scenarios and in many initiatives. And so now there are like new specs that, for example, use like SDJots as the basis for a format for verifiable credentials. So I think that you definitely keep seeing a lot of activity in there. And whether these will feed back things into OAuth, it might like a client ID until recently was an opaque concept. And then OpenID, OpenID Federation changed it to be structured. And now verifiable credentials are moving it even farther to define formats for the client ID. A client ID is something that was defined by OAuth. So does it get fed back into any of it? So I think there's potential for interaction, but there is also pretty strong layering. So I'm not sure how much of that is going on there. And what else? And then there's AI, which to me is not yet a trend. Like so far, all the things I've seen about AI are people that are trying to catch the wave and say, oh, there's a wave, like it will raise all boats. And like, for example, during a deniverse, someone, we just say someone suggested that the solution to the authorization problem is maybe to have an LLM to actually like a large language model to actually be the oracle to which you talk to saying, I would like X to happen. And this thing somewhat translates into authorization. And I can see how that actually this might work. But if you have played at all with ShadGDP, you know that that thing can sometimes, yeah, I can once ask, why are the keys called the keys, you know, the Florida keys? And this finger applied to me because they are key shaped. What? So I wouldn't delegate to a generative AI, your authorization strategy just yet. But who knows? Maybe in the future. You know, I will give you another reason to not delegate that. That reminded me that over a year ago, actually a year and a half ago now, I was playing around with an early version of one of those AI tools. It was not ShadGDP. It was before it was way before that. But it was similar where you could give it prompts and have it generate stuff. And I started asking questions about OAuth. And it was coming up with some pretty fun fun sentences. And I'll drop a link to the Twitter account in here. I completely forgot about the Twitter account. I was reminded of it recently. But it's a collection of these completely wrong and inaccurate things about OAuth. And it's amazing. Go read through some of these tweets. AI is not quite there yet. Although now a year and a half later, I should give it another try and reboot this Twitter account and see what it says now. I suspect that it might be better. I did this thing in which I asked the ShadGDP to tell me why I shouldn't use ID tokens for calling APIs in the voids of Cookie Monster. And it did a hilarious thing. And it was actually accurate. As accurate as Cookie Monster can be. But the main point to me is hit and miss. Let's say that you can't, for the time being, delegate important things. You can definitely do things like say anomaly detection, in which you can catch weak features and say, hey, this thing is worth a second look. And so it narrows down the things that you needed to give a second look for. But otherwise, if you would entirely rely on that today, probably not yet the time. Yeah. And speaking of time, Speaking of time, I think that takes us to the end. Thank you for all the questions, everybody. Thanks for the recap. We'll do this again sometime. Hopefully not in six months. Hopefully a little bit sooner than that. Let's commit to do it as we come back from ITF. At the end of July, first week of August, let's have one of those. I think that's a good every couple of months, then we'll have something to report on. There will always be interesting discussions at the ITF meetings. And the European people will not show up because August is a black hole in the calendar in Europe. At least it was when I lived in Italy. But there are recordings, so our Euro friends can always watch the recording after the beach. Yeah. All right. With that, we will see you all next time. Thank you for watching. Bye.