We have Victoria here as well. Plan for today, we're gonna talk about, catch you up on what's been going on the world of OAuth. That's been, it's been a while since we've done one and we've since had a, our first in-person meeting with, of the OAuth group in like two years. So, yeah, that's been, that's exciting. So, yes, what do you, and what do you wanna talk about today, Victoria? Well, Elon, I'm hearing, is about to buy Twitter. Yeah, we'll worry about the identity implications when and if that happens. For the time being, I share your excitement for finally, finally, after two to five years, we've finally met in these special flavor ITF. Like ITF normally is pretty large events like 1,000, 1,500. Instead of this time, we wear 400, 300, but still the spirit was there and it was such a breath of fresh air to be able to keep flogging dead horses of identity, even at dinner, instead of just a zoom and it starts and ends and then you just go on with your day. So, it was fantastic. Yes, let's talk about it. Yes, exactly. All right. Yeah, I know the last time we met in person, I believe was Singapore 2019, is that right? November? Which I skipped. The last one I did in person was in Montreal. Yep. I did go to the one in Singapore and did not know that was going to be the last trip for so long. So, yeah, it was nice to be back. And it was a smaller group in person in the meetings, but I felt like we had a really good turnout of the OAuth group anyway. Yeah, yeah. For OAuth, it clearly, people had pent up things to talk about. And in fact, not only we had like decent number, but the agenda was packed and we used all the time available and then we had over age time and then we had all the social moments in which between laughs and drinks, we stalked shop the entire time. So for Identity Geeks, it was a fantastic five days. For Identity Geeks is very good way to caveat that, yes. Yeah, so this was the few days we had. We had two formal sessions on the schedule and two official side meetings, which are the way this works is the groups get one or two slots, usually two hours, two hour slot on the schedule during the week at the ITF. And that's actually one of the reasons that not being in person, the OAuth group and a few others I heard kind of switched to just doing interim meetings and not trying to cram everything into the one week because it's hard to schedule that many meetings across that many different groups and a lot of people have overlap in multiple groups they participate in and with everything being virtual, there's not a lot of benefit to cramming everything into a week. So a lot of the groups were just switching to interim meetings, just doing it throughout the course of the year and that worked really well for virtual. I think it worked a lot better virtually, frankly, but there is a lot of value to being in person condensed into a week. So yeah, we had two slots on the schedule of the two hour meetings and then we had two side meetings which basically meant there was a room booked for a certain time and it was not necessarily a planned agenda and it was not recorded and it was not necessarily minted in the same detail but it was a time that was published on the schedule and people knew that there were going to be conversations happening there. Those were also very cool. And the caller for that room had microphones for like there was like these horse shoe-shaped table and there were microphones for each place and those microphones had like a sequencing in which when you would take the mic you would proactively disconnect anyone else who was talking and so it was funny to see the various different personalities that would actually forcibly interrupt people so that they could get a little bit in. I will let you guess in which category Aaron and myself belong to. We are not going to do that. It was a fun moment of color that you would not get if you'd be online. And it was fun. I thought that was a, it was interesting. Honestly, that room was too big for the group that we had but it was really funny. It was, yeah, it was the mics you see at those like government panels and stuff where it's like everybody has their little box with the little stick pointing up and a big red light showing you who's on. And yeah, I think, I don't think anybody realized what was happening at first, but like as soon as you would press the button to say something, it would shut off wherever else was talking. It was just, and because the room was so big you could only really hear whoever was miced. So it was a very effective way of just being like, my turn. Yeah. So, yeah, let's, let's jump into seeing what was on the schedule for the first session. We had four topics on the agenda. So chairs update, that was, that's just administrative work, right? Nothing significant really. I think it was some status updates on some of the drafts in terms of where they are in the sort of post-working group life cycle of working their way through the rest of the machine. That was a mystery, yeah. A couple of victory laps for things that since the last time we met became RFCs. And it's not about accomplishments, so it deserves a moment of public acknowledgement. But yeah, most of the administrative work. Also true. Yep. I think your draft was one of those, right? It should have been, but I think that it was approved before the last virtual one. So it wasn't mentioned. It was mentioned during the virtual one. Like the sign we mentioned there. I think the issue, the issue draft, that was like the fastest that I've seen history. And there was another one which now escapes me. Well, it's probably in the minutes, right? That's possible, but we can follow up. 9207, that one is issuer, right? I think it's the issuer, yeah. Yeah, and then JSON token response is in the queue. Thumbprint URI, rich authorization request, security, BCP have consensus, but are pending write-ups by the chairs. So there we go. And also in particular for the security, BCP things did happen during ITF. Yes. I feel like this is a draft that just keeps going. It just keeps giving. And at some point, we have to just draw a line and finish it even though it's not like the security of the space won't keep evolving. So, but yes, we'll get there. Yeah, you're right. We needed to get a snapshot of the state today. And I think at this point we are reasonably close. Let's say that there was this one last controversy, which I believe had been ironed out. Also thanks probably to the high bandwidth conversation we had in Vienna. So I'm confident that Daniel Fett will soon be able to rest and have this thing finally out. Yeah, yeah. So the first draft we actually talked about was D-POP, which we have mentioned quite a few times on this channel before because it has also been around for a while and gone through quite a number of changes. Yeah, this has been worked on since 2019. Yeah. And I think in 2020. We were both in the place where it was born. It was in Stuttgart. And we were doing the OSW and someone came up with the idea. And then these uncommonly numerals group of offers decided to put it together and here we are. Yeah. Oh, that reminds me of, I think one of the first items on the agenda for this document was a comment about the number of authors of this draft. Correct. It was unusually high. And so Roman mentioned that, Roman is the area director, mentioned that it's unusual and some people may frown at it, but that he was willing to make the case for all those offers if everyone felt that they should have been all those offers. And I think that Brian was presenting Brian Campbell and basically complying to it. Yes, they all had significant contribution. So they should all be in the offer. And so we are keeping the plan of record and they are still there. However, I'm realizing now that we are doing a classic mistake of identity people. Like we are just assuming that everyone that is tuned to know what the D-POP is. So my suggestion is let's use one sentence to describe what that thing is. And if I might suggest one, D-POP is an extension to off, which allows you to use tokens by proving the possession of one particular key, which eliminates many of the shortcomings that you have in classic off in which tokens are better tokens. Better tokens are tokens that can be used just because you own the bits of the tokens. Hence, they are vulnerable to many of them. Hence, they are vulnerable to many of the middle attacks or any attack that leaks the token. But with D-POP, you have a mechanism for negotiating a key and using a key to protect part of the message so that if a token and the message you get intercepted, the best you can do is to replay exactly the same message. But if you want to use that token to send another message, you can't. That's the most concise way I can think of. What do you think, Aaron? I think that's a great description. I will just add it is one of a couple of different attempts at this problem. So it is specifically created for being able to be used by single-page apps, whereas some of the other options are not necessarily possible or are very difficult. So that's the specific thing it's targeting, but it can be used by any app that can handle a private key. And she has plugged it. We have one episode of the Identity Unlocked Podcast in which Brian Campbell goes into the details of D-POP, of MTLS, and this space in general. Yeah, yes. I remember that one also very good. Oh, it looks like Brian is also here. Do you have a comment, Brian? Do you want to say something? Other than just the general sigh of exasperation. Anyway, yeah, so what happened with this draft during the meeting? It seemed like it was mostly a status update. There were a couple of little details to be worked out, but I don't remember there being a lot of discussion. Yeah, it was quite a controversial and I remember being very happy with it because the last few times there were some discussions at the fundamental level, like should we be able to use symmetric keys or should we be giving guidance that assumes stuff inside the token rather than just being genetic in respect to how the access token is encoded. But none of that happened this time. This time it was a smooth sailing. And in fact, at the end of the meeting, the chairs made the working group last call on the board. So usually a very good indication that we are within a line of sight or a finished line. Yep, yep. I think, yeah, I think that's great. That's right. And I remember that it was scheduled for 45 minutes. And if I remember correctly, finished well under the amount of time scheduled for it, which has been unusual for that draft in particular in past meetings. Very true, yeah. Yeah. So here's a question about this. Great question from NoName, who ironically I have seen on this channel before. So NoName is a name in itself. Single-page apps without a backend can't handle private keys, but if we have a backend, why not use it as a proxy combined with the code flow? So good questions, two things. Single-page apps can handle private keys, which is a, I guess relatively recent development in browsers, but there is the web crypto API. And that API lets the browser generate non-exportable private keys that the browser can then use to sign things with. So that's the idea is leveraging that mechanism in the browser to be able to do things with private keys so that we can have a lot better security and non-exportable being the key there because no pun intended, the key. The non-exportable meaning that then if you have an attacker who is able to get JavaScript into your app for some reason, that attacker's JavaScript also can't extract the private key because your code also can't. So that's great. More things should use that. However, there aren't a lot of good well-established patterns for using that yet, which this is supposed to be one of them. So I'm excited to see that happen. And on the second part of that question, which is why not using the backend as a proxy, that is not always trivial. Let's say that it depends on what you're doing on your backend. For just having the backend is not like a zero one. You can have a backend, but not have a full control over the code that runs over it. Or you might want to limit the amount of computation there because it's expensive. Or you might have APIs that are geo-located and having to go through and if your backend would force you to embed that advanced logic to deal with that considerations in general. And also you might have your workforce which mostly work with JavaScript. And so proxying everything would be expensive both from money and from the functionality, performance perspective. And also it might just not be the way in which your developers operate. So there are a large number of practical reasons for which just the fact that you're running some code on the backend might not allow you to do everything on the backend because everything you do in there has implications especially at the large scale, which is one of the reasons for which we have a Brian a couple of years ago. We suggested the thing like a hybrid between doing everything in JavaScript and doing everything in the backend. It's a bit of a back burner, but eventually it will come back. Yeah. And then I guess one other thought on that is yes, a backend is generally less risk of a token leaking from some sort of server side system compared to a single page app. So that's why it's very common to use bearer tokens from server side apps, both as an access token, but also a client secret where it's a shared secret. It's very common because there's a much less risk of a token leaking that way compared to a mobile app or a single page app. However, there's not no risk. And sometimes that risk is still too much for someone and they still want to use a sender constrained token even though it's server side code. And there's, I believe the security BCP talks about some of the more concrete examples of why you may want to do that. But like one example, and obviously these don't apply to everybody because it's very much dependent on your architecture and how many different things you have moving parts you have, which is why not everybody cares about it. But one example would be if you have a bunch of different resource servers and one of them maybe you don't trust as much for some reason. So a client is sending an access token to a resource server. The resource server then has the bearer token and that resource server could use it to go access things in other APIs because it has the token. And if you want to prevent that from being possible you can't use a bearer token anymore. You have to do something else. So that's another reason to add in that sender constraint. You're laughing. Do you have an example of this? Nothing is more of like I'm having traumatic memories that are coming back as you on this from this. Cause like this is at the core of the controversy about the audience of access tokens because there is like the camp that suggests that the access tokens should be like wide spectrum artifacts that can be used with multiple resources. Whereas there are others and I mean that camp that suggests that the audience should be as specific as possible. And then whenever the client needs to call a different resource server, it should just be able to use a refresh token to ask for a different token on the fly so that you reduce the blast radiance. Now the thing that you are describing is a potential justification to be more on the other camp because at that point, even if you don't have an audience that protect you with a specificity or a use of a leak access token, you can just prevent the leak or make the leak non actionable from the attacker. So potentially you can reduce the traffic and have less tokens in your cash and less needed to hit the token endpoint with a refresh token. So this is another way in which having a viable sender constraint mechanism is a game changer. Cause like ready today, there is MTLS which is already an RFC and things like FAPI, they financial APIs demand it and say, if you want to be compliant with our stuff, you must do it. But it's hard, like it has a lot of considerations about the edge SSL terminators, all of that stuff. Once we'll have Deepop, we'll be able to use it in ways that in the past, we've been solving differently like with the audiences. So I'm really looking forward for this thing to be officially done and published. Yep, yeah, great questions. Let's move on to the next one. Let's see, that was redirection attacks. This was something that Rafat brought up who he is the chair, so we get to step away from his chair duties to present this. This is not a draft, it was a topic of discussion. So looking through the minutes, he did present some slides, but the core of it, I remember correctly, was the idea that there are several places in the OAuth specs that say to redirect if an error has occurred of some sort. And there is a very clear mention of if the redirect URL of a request is wrong, don't send the user to that redirect URL because that's a very clear problem. But there are some other cases that are less obvious about why they might be problems. And this was an attempt at describing and capturing those other situations that you may not want to send the user away from the authorization server in the case of an error. Yeah, the way I understood it was that this is basically a trick that can be used to bypass spam filters and similar, or like lists of known battery directors. Because you can, as a malicious developer, sign up for one OAuth development service, register your app and register whatever redirect URL you want legitimately because you own that particular application. And now you can send it to someone, a link to that app that errors out on purpose. So that there is no gateway that will, like no verification step. Like if someone clicks that URL, they will be redirected to the attacker redirect and given that this thing, if a redirect comes from a domain, which is the identity provider domain, which is very likely not a block listed by the browser, so by any mechanism you want, now you bypass the filter because if a filter would start blocking that stuff, then it would also block legitimate logins. And so this is basically a flavor of an open redirector, which is not really a security thing, like no one is stealing any tokens, no one is doing any elevation of privilege, but it is a very handy trick for skipping spam filters. Yeah, interesting problem that I believe this has been seen in real life, like people are using this actively, which is why it's being brought up. Not gonna name any names, but it's not really anybody's fault either. It's not like anybody's doing anything wrong here. And that's the question here is, like these OAuth servers are doing what's documented in the spec today, and is that something that maybe the spec shouldn't be recommended because of the possibility of being able to be used in this way? So this, like you said, it only applies to authorization servers that have a sort of more public way for developers to create apps on. So like it does not apply to your own organizations, private OAuth server where your admins make apps because the only people who can make apps are your admins, and if your admins are getting tricked into registering redirect URLs for attackers, that's a different problem. But it does apply to things like Twitter or GitHub where they're just public identity providers and anybody can show up and make an app on them. And there's very little approval process, if any. And then, yeah, then you can use those URLs to in emails or SMSs where they don't get caught at that stage. So, interesting question. And if I remember the resolution on this was to document the situation and Daniel was okay with adding it into security BCP if it was relatively straightforward text that was being added. Rather than recommending totally different behaviors, it was more just pointing out the fact that this is a concern that some maybe should be aware of, that was. I think we left it. Thank you. The thing is the reason much that can be done that we don't break things without out there, like the reason for which this thing is structured that way is that typically the authorization server doesn't have enough context to emit an experience that would make sense for the user. So, if we were to say, you know what? We are not gonna do these anymore. And now the burden would be on the authorization server to say, hey, these happened. These happened would probably be impenetrable from the developer perspective. And also returning an error so that the client could see not a 200 but an actual error or not a 200, not a 30 or two but a 400 class error. And then at that point, it would be on the client to do something you'd still have like a pretty significant breaking change. Like people would need to start managing that particular circumstance explicitly. Whereas today, whatever, you just come back and maybe you can resume the existing flow if they redirect, the return URL is not, it's a neutral one. So, I think that the solution that the working group came to which is documenting it is a valid one because the authorization server can always decide to do that anyway. And then at that point, if the circumstance apply if the authorization server is like the ones that you described on public one that decides that they don't want to do this, they can do whatever mitigation they think is most appropriate. You mentioned the curation, they might start saying, okay, before you can publish the app, some human need to look at it. I believe that's what happened with Facebook today. Like you actually, what happened claims you need to ask for in approval process. Of course it's expensive, so we cannot mandate it from the spec but I think it's good that we remind people, hey, if you are worried about this particular circumstance this is something that might happen. Yep, yep. So I think that was a good discussion. Good discussion of that went pretty well and we'll see what comes out of that on the mailing list. I haven't seen any discussion of this yet, so. I haven't seen much of a couple of repos from the D-POP last call, but in general it seems like people got an indigestion of interaction and so now the mailing list is a bit slow, so whatever. Yeah, need some time to recover from that much social interaction after two years. Yeah, especially for us IT people we tend to be introverted, introverted extroverts so like any combination, so. Yeah. Yeah, so then the last one for the day was OAuth 2.1 and we had more than 30 minutes left by that point so got a nice good long chunk of discussion in on that. That was fun. Yeah, it was some good stuff. Let's see, these are the minutes. Idea, so the way I usually do these is I try to give a recap of what changed since the last time we've met and then try to pull out a few discussion points worth. Worth talking about in the high bandwidth situation where everybody is that are easier to do there than the mailing list. The mailing list is open all the time for discussions, but some of these things are just easier to knock out in person. One of them was bringing in the ISS response parameter since that was previously not an RFC and didn't seem appropriate to roll in, but now we agreed that it is appropriate now that it's an RFC to at the very least point out where it's relevant and reference out to the RFC so that is on my list. The nice thing is that that one again, it flew through the RFC process because it is just such a simple mechanism and solves a specific problem that is not necessarily applied to everybody either so it was very easy to sort of be like, this is a little box, here it is, you're done. Yeah, a couple other good issues that we talked about. This one was interesting. I found text in the original OAuth spec that says access tokens have to have a limited lifetime, bear tokens must have a limited lifetime. And it's in the core RFC and I know for a fact that there are implementations of OAuth2 that do not do this, that issue unlimited length access tokens. So that was my question was, how do we reconcile this? Because the real world does not reflect the document. So what do we do? Now it was a very good one because I think that people conflated the need for something that verifies whether an access token should still be accepted. Without like granting that thing as a given forever versus one tactic of enforcing that which is to limit the expiration time of the access token. And the one thing that I said back in the day and I still stand by it is that today we have countless examples of continuous authentication in which we continuously assess the risk associated with a particular transaction and we decide whether we are still okay with whatever the user or the caller did in order to prove their point that they have the right to access this resource or whether instead we decided for any reason like location, time elapsed, clear circumstances, time of the day, whatever we don't know yet. This thing might decide, okay, I'm no longer okay we have accepting these credential as something for giving you a service I need you to do X, which can be something else. And you can actually do these with a token that has no formal end to its lifetime. Let's say that if for some reason people before using the token always does something that revise the session then this is like a paper plane with people with a blower sander that keep this paper plane flying forever. Then the moment in which someone doesn't use the blower it will drop down, but it doesn't matter like it's not like you need to intrinsically place an expiration like I don't need to put a timer that makes the paper plane explode at some point because they've been in the air for too long. So then I think that these kind of resonated with a room, like people came from different angles but the substance was that like we have other ways of deciding whether a token should be accepted or not and the expiration is not the only way and enforcing it would only result like constraining people to have tokens that must expire will result in many non-compliant implementations. So that was the substance of the discussion I think. Yep, yep, I agree. So I think it was turned out to be more about clarifying the intent of that statement in the spec because if you read it quickly it sounds like tokens have to have a scheduled expiration date in the future which as we discussed was not the only way to have tokens become invalid later. So that was a good discussion, yeah. It was, it was. And I think that it's going to be a good clarification. This is one of the places where having off 2.1 is objectively a good thing because it gives us the opportunity to clarify something for which very strong consensus are. Yep, yep. So the biggest part of the discussion here was around the credentialed client. Yeah. This was, so, oh, right. Okay, I remember how this happened in the meeting. I had my list of issues that I pulled out to talk about with the group that I thought were relatively bite-sized chunks that we could have a good focus discussion on and come to a resolution of some sort. And it worked, it went great. We got through my list and we still had like 15 minutes left during the, of meeting time left because we had kind of breezed through all that stuff in the beginning too. And Brian was there and pointed out that there was a discussion on the mailing list about credentialed clients and then the discussion kind of just stopped and nothing actually happened with that discussion. And honestly, I had completely forgotten about that entirely. So I was like, yeah, please bring that, pop it back up on the list. And then we were like, well, why not just talk about it right now since we have time? So we did and that ended up being another good discussion. So linked out to the, pull up the mailing list thread about that that happened previously. And yeah, so quick backing up really quick. The idea with credentialed client was introducing a new term for a concept that already existed in the core spec, which was something between confidential clients and public clients. Confidential clients meaning you can have credentials public clients meaning you can't. And then however, there's other properties of confidential clients that are mentioned more often than just whether they have a secret. It's things like it's pre-registered, it's known, it's all these little, all these ideas tied up in it. And then in several places, there's this thing in the middle, which is an app has credentials, but you don't necessarily trust it with the same level of confidence as a confidential client. So the idea was to capture that as a name, but I think it ended up causing more confusion than it solved. So, scrolling through the minutes on this is a treat because I don't remember who took notes, but they took very good notes. And there's a lot of discussion that happened with this. So, I like this one. David provided feedback from remote, which was inaudible. It's very literal. Yeah. Also, it beat concerns. No, I'm very concerned. But anyway, so here like there's my summary of this thing. I think that some part of the group wanted a very simple clear cut definition, which says, if you have credentials, you are a confidential client. There is no doubt. And the thing is that from the off perspective, I think that works. Let's say that if you're thinking as off as like algebra, that thing is a good operator, a good predicate on that algebra. But the thing is that for me off is a tool that people use and they somewhat model reality using some of the primitives in this space. And the reality has many other considerations that go beyond that particular detail. And in particular to me, the main issue I have is that when off was first conceived, the native and public clients were kind of like afterthought, let's face it. Like the main thing was I have a website which he wants to talk about to another website and it's gonna do it on behalf of my user. So something with agency that it has its own independent identity and all the little tricks were devised to support this flow so that this thing can do stuff on behalf of the user even when the user is not present. Then like many other things in identity, we took that thing and somewhat tortured it to also model scenarios with native clients, for example, situations in which distributing the key is complicated, protecting the key is complicated but here is the part that people usually miss. The main difference between what we commonly think of as public clients and confidential clients is that there are many instances of the public clients. The public clients are things that like run on my machine, on your machine, on your phone, on his phone, on my watch, all of that stuff. And so when you use the client ID in there, you are just pointing to a set of configurations. You aren't really like doing anything serious from the security perspective. Anyone apart from tricks on iOS for claim the domains and stuff like that and Android, anyone can use that client ID. And so now if we bring back, we say, okay, if anything that has a credential is a confidential client, now what happens is that if you have those flows in which you have multiple instances of apps running on different devices and you somehow add the ability to provision a key afterwards, now all the machinery that was built for confidential clients might not work. Let's say that a lot of the assumptions there are, that's a website, it's a singleton. I have a list of users, it's a shared resource, whereas the native client is, I'm the only one running it, apart from small situations like how to look on a shared computer. But in general, there are many other considerations that are baked in the tools that people use for implementing off in practice, because the goal is never to implement off. The goal is to implement the scenario. It just happens to use off. And so if now we bring back these consideration, I think that we owe to the world to explore what are the potential implications as in like, now am I gonna have a lot of features about the concurrent users, which are useless when I'm building a native client? So maybe we just needed to find the stronger way of the coupling application types from client types, because they have different properties, but good luck with that. Because if you ever landed on the off-zero page for developers, we have like a list of technologies like Angular, React, React, NetEven, similar, people click on the technology and we have them in the path for actually getting the right choices from the off perspective. If now you decouple client types from the application, it becomes very tough. Like people need to be experts in identity. We can no longer make some of the work on verbal health. So I think it's a good discussion to have, but I'm worried about the long ranging implications. And I'm worried that a lot of people involved in the discussion live at the protocol level as opposed to actually seeing perfect. That's the stuff that you're showing is exactly right. Instead of working with people that know nothing about this and helping people to be productive and effective when using those technologies. So I'm scared of this discussion because I know it's gonna be difficult and I'm worried that if a developer is not shielded by some of this stuff, we might end up making identity harder rather than easier. Whereas my hope is that we get to easier and easier layers rather than the opposite. Yep, and we have the same thing on the Octa developer site as well of what kind of app are you building? It's common. And I think for me, one of the things that I've also been trying to help guide the Octa product and is decoupling the idea of whether the client is authenticating from the concept of Pixie and from the concept of application type because those traditionally like in the older way of thinking about OAuth all kind of came together as a package like you're building a single page app that means it's a public line. There is no way it can authenticate and it means you're doing the implicit flow. And then if you're building a mobile app it means you can't authenticate you're doing Pixie and there were these sort of bundles and a lot of what we've been doing in the OAuth security space in the spec is to simplify that whole thing and what it's doing is it's removing those bundles. And now it's just, if you're building an app you should use the authorization code flow with Pixie. If you can protect a secret, you should be using a secret. Those aren't related concepts. They're different concepts. So I've seen so much documentation in so many places that are like Pixie or client secret and those never were difference. They never were opposites. They just happened to often be bundled in different types of apps historically. So I think that's all kind of getting wrapped up in this idea too. And yeah. It's very hard. It's very hard also because like we make security considerations and if a customer does too of course but depending on the nature of the business depending on the type of users and similar there are a number of different considerations that also come into play. So sometimes when you're working with consumers they funnel is the guard of that particular company which if users don't go through a funnel the company dies. And so that's where they have a different tolerance for like whether the user session is a fresher not fresh whether they use the web often or whether they just use username and password versus a company which instead as like employees or like a big value like in which to do financial transactions and similar which the tolerance is different. And if we operate on the protocol level and project these to the customers then we somehow flatten everything on the most secure side of the house where unfortunately the effect sometimes is that people completely opt out. As he says, okay this is impenetrable it's just way too complicated for me. I'm just going to do something like completely custom which completely like break like we lose when that happened like when our stuff is so secure that no one can use it, we lose. So it is a difficult compromise. And I think that we have yet to crack the right angle but the application type is one of the best defaults we can latch to. And although it's good to give optionality like the classic have a spa, do I have a backend? Do I not have a backend? Can lead you in very different directions for what we said earlier but sometimes that question is enough to turn off a lot of people that will just leave saying I don't know what you're talking about. So I think that as we work to make the stuff usable and consumable by users we'll need to maintain some flexibility that is not always the way in which we operate when we do all standards. Yeah, definitely a challenging balancing act. Oh, Justin is here. Justin was at the meetings. Justin says what we need is a clear idea of what a client ID actually means and because it means like three or four very different things. Yeah, I think that's part of why this is becoming a difficult conversation because yeah, it means certain things to different people certain people have grabbed onto particular meanings of it and hard coded that in their systems and what that means everybody doesn't isn't always the same. So that's why we're getting these different differences of opinions of oh, but a confidential client is just something that has a secret versus oh, we made a bunch of assumptions about confidential clients that have credentials that maybe you didn't. So you might be able to say that but we can't. So there's all these, yeah it's it does mean a bunch of different things. It is tricky, we'll definitely need more clarity. If anything so that at least we can classify things as in like given that those meanings were reverse engineered from practical use and people just took different angles and similar, we just needed to bring back some guidance as in okay, if you made these assumptions just know that those are the things that might go wrong. Like one of the classic most frustrating things I have is that occasionally people, someone discovers that they can reuse the client ID of a native client and then they make a big deal saying, ha, ha, I hacked this. I can look at this and it's a dude is by design but it's surprising how many people think that the client ID is a secret or it's kind of a secret. So yeah, clarity in there would be very useful. Yeah, last thing on 2.1 before we move on because we're almost out of time. We need a second episode. Yeah, maybe we do. Because we covered only half of it so. Yeah, maybe that's a good plan. Do you have any plans to add the device flow to the 2.1 draft? Right now there are no plans to actually like bring it in in the same way that we brought in like actually incorporated a lot of the other documents but there is a reference to it. So in the draft there's like here are the grant types that defined by this draft and here are like you can make extensions to make other grant types. For example, the device grant. So I think that's probably where it's gonna land. I don't think anybody is gonna be very interested in actually bundling it in. Yeah, I'd go even further and say that I think the future of the device grant is not as certain as it was until recently. Like in the second part, like in the second part of the meeting at this point I can maybe mention but then pick it up in the next episode anyway. There are a number of constraints that come with doing these dual device flows that somehow are intrinsically vulnerable to phishing and similar attacks. And during the second meeting that we had that week with the off working group, Peter from Microsoft and Daniel from Yes and Philip from of Zero, all presented various circumstances in which device flow has been abused and some general attacks for which like this thing is intrinsically vulnerable to. And it's kind of common to all the two device flows as they exist today. There is also the open ID PSYOP2 that has some of those characteristics and SIBA might have something to that effect as well. So there are various thoughts about how some of those things can be mitigated. There are new things that are coming up like the multi-device credential in FIDO in which you can use like cloud assisted Bluetooth. And so there is really no user interaction and various enforcing of co-location of the devices in the same volume of space, but the feature is unclear. And so although I don't think device grant is going anywhere because it's so incredibly useful, but it does have limitations and there might be better technology just behind the corner that might make it obsolete. So I think it's why is the course of action not to enshrine it enough to that one because of all of those considerations. I think that's a very good point, especially because again, OAuth 2.1 is supposed to simplify, but also capture the best practice for OAuth. And if there's already concerns that this thing may not be the best, then we shouldn't package into the thing that we're saying is the best. So very good point. And that I think is a fantastic lead-in to the next episode of this because that topic was one of the major blocks of time we spent on the second day. Really fascinating problem. And a lot of the side discussions were about that topic as well. So definitely deserves more time than we can get through right now. So Brian is telling us to step up and do another episode. So we will plan on doing that. It's a pun because one of the things that was presented was the step up of indication that Brian and yours truly call for it. Yep, there it is. So yeah, this was the agenda for the second day. And as you can see, lots of interesting topics there as well. Not to mention the side discussions we had. So yeah, we will do this again in the near future and talk about some other things that happened at the meeting. Yeah, and we should do it actually pretty soon because in a few weeks, then we will have conferences galore because actually the last week of April is IOW in Mountain View. The first week of May is the off-security workshop in Trondheim in Norway. I never know if I'm pronouncing it correctly. But then it's true for pretty much anything that comes out of my mouth. I never know if I'm pronouncing it correctly. And then the week after, there will be the European Identity Conference in Berlin. Oops, I forgot to put that one on here. Bless the three weeks of the pause to try to get some work done. And then there will be RSA in San Francisco in another week and then Identiverse. So I think that our carbon footprint is gonna be interesting. Agreed. My schedule, I'm not going to all of those, but I am going to, I should put EIC on this list, but I am going to the security workshop the week after that is the EIC. So going to that, and then I will also be at Identiverse in June. Yeah, it's gonna be a busy time. And then just right around the corner after that is the next IETF meeting in Philadelphia. So we have to make a lot of progress in three months to have more things to talk about there. Oh yeah. All of us doc authors. Or the opposite. As in so that we can just pick up saying, well, we didn't have time. Let's debate the same stuff again. No, of course, we needed to find a way over to make progress for sure. All right. Sounds like a very good starting point. Unless there's some questions, do we have questions in the pipeline? Nope. Nope, I think we cover everything. So yeah, thanks. Yeah, we didn't talk about Elon buying Twitter at all. So, you know, whatever it is. Oh yeah. All our insider information that we didn't share. All right. I forgot to have the little graphics on the screen. This has been the OAuth happy hour. Thanks for joining. We will post again the link out to the next one on events.oauth.net and the octodev.events website. I'll drop a link to that in the chat. And that is where you'll be able to find us in the future. So thanks everybody and we will see you next time. Ciao a tutti. Ciao, ciao.


Today's farmers face many challenges. In our global economy, farmers face competition not only from neighboring farms, but from farms halfway around the globe. Catfish farmers in Mississippi, Alabama, and Arkansas are feeling the effects of this competition. Catfish is a mild-flavored whitefish that has been a favorite of southerners and others for many years, but its rain is being challenged by other imported fish like tilapia and the Vietnamese catfish BASA, which have similar qualities but cost significantly less in the marketplace. As a result, United States catfish production has dropped nearly 50% from 660 million pounds in 2003 to only 300 million pounds in 2012. In addition to increased competition from imports, the catfish industry has also been challenged by increases in the costs associated with growing the fish. Fish feed prices have nearly doubled in the last five years, and fuel and energy costs are also on the rise. In order to remain profitable, farmers must find ways to grow catfish more efficiently. Scientists from several universities have attacked this problem by developing what they believe are two production systems that are superior to current open pond culture, the in pond raceway system, and the split pond system. For those of you that may not be familiar with standard catfish production techniques, perhaps a little background might be helpful. To put it in the simplest possible terms, there are four things a fish needs to survive. They need water, they need food, they need oxygen, and they need a way to get rid of waste. Most catfish farmers today use what's called an open pond production system. This means that all the catfish in the pond are free to roam wherever they like, much like free-range chickens would do in a pasture. The ponds are typically anywhere between five and 20 acres, and they range from four feet deep in the shallow end to six feet deep in the deeper end. The food for the catfish is provided via a floating pellet that's distributed out across the surface of the pond by a blower. They put it over a large area with the hopes that all the fish will have equal access to the feed. The problem with this is that most farmers run multiple sizes of fish at the same time, so we suspect that the smaller fish may not have as good access as the big fish to the feed. The oxygen in the water comes primarily from the algae that's present. These microscopic green plants during the daytime through a process called photosynthesis produce food and then oxygen as a byproduct. So during the day when the plants are photosynthesizing, the oxygen levels are rising, but at night when the sun goes down, those same plants start to respire and use up the oxygen. So what you'd see if you measured the oxygen levels throughout the day and night, what you'd see is that it goes up during the day and then once the sun goes down, it starts going down and then goes back up and down, so what you'd have is a wave. At times, the biological oxygen demand from the fish, the bacteria and the algae that require more than is produced during the day. At these times, farmers use mechanical aerators to supply extra oxygen. These paddle wheel aerators throw large volumes of water just a little bit into the air and break it into small droplets. That way the oxygen from the air can easily diffuse into those droplets. Those aerators create quite a current also to help move the oxygen around the pond and mix the water. The waste in the pond that's produced by the fish is primarily taken care of by the bacteria that's in the pond as well as the algae. The fish produce ammonia, which is broken down into nitrite, which is still a toxic product, and then into nitrate through a process called nitrification. The algae can make use of nitrite as a fertilizer, so it works very well as a system. We feed the fish, the fish produce waste, and the waste fertilizes the algae, which produces the oxygen. So it works as a very nice cycle and provides all the things the fish require. In an open pond system, all of these processes take place in the same space. Scientists have found that by separating the fish management area from the waste processing area, it is possible to improve both processes. This separation technology is not new and has been evolving for several decades. In the mid-1990s, scientists at Clemson University predicted that, quote, future pond aquaculture will move from farming the waters to true production systems in which manipulated ecosystems, the ponds, are redesigned into a series of more controllable fish production and waste treatment processes, unquote. The first pond-based examples of this separation technology occurred in the 1980s when farmers in Arkansas began to experiment with separating the fish growing area from the waste treatment area. Kelly Farmer at Arcat Fish Farm linked several ponds together and placed a set of concrete raceways between them. The water flowed from the upper pond, through the raceways, and into the lower pond. The water then circulated through several other ponds where the fish waste was assimilated before being pumped back to the top pond where it could be reused. This innovative approach was embraced by researchers at Clemson University who developed what is called a Partitioned Aquaculture System, or PAS. The basic premise of the Partitioned Aquaculture System was to physically separate the fish culture unit from the wastewater treatment unit to facilitate better management of both fish production and waste removal and treatment. The design turned the pond into a long, narrow channel that coupled high-density fish culture raceways to an algal growth basin. Only 5% of the total area was used to contain the fish, while 95% was used to treat the waste. This long, narrow channel was similar to that used by sanitary engineers in wastewater treatment plants. The water was moved through the channel using a slow-moving paddle wheel. The shallow algal basin, combined with continuous mixing, allowed the whole water column to be exposed to the sunlight. This allowed for greater oxygen production and waste removal. A second-generation PAS system was designed for scaling up to commercial levels. This version used a wider and shorter algal growth channel which reduced the cost of construction. A second set of large paddle wheels were added, so the water velocity in the algal channel could be controlled independently of the water flow in the fish raceway. This addition meant that not all of the water had to pass through the fish raceways. When the oxygen levels were high, more water would circulate through the raceways, but when oxygen levels were low, less water would pass through the raceways, and additional aeration would only be required in the small raceway section to maintain the fish. The second-generation design that was ultimately patented in 2001 also included computer-controlled gates within the fish raceways that could direct or divert water between the raceway cells. The idea was to have a filter feeding fish, like tilapia, in the center raceway that would feed on the algae and provide an additional income stream. The designers also thought that the continual harvesting of the algal bloom by the tilapia or a mechanical harvester would help keep the algae bloom healthy. A healthy bloom would minimize system crashes, help suppress blue-green algae that can cause off-flavor, and ensure that there was a net oxygen gain from the algal growth area. Trials with research-scale PAS systems showed that it was possible to produce significantly more pounds of fish per acre than traditional pond culture. When non-fed tilapia were added to the production figures, total production reached 15 to 20,000 pounds per acre. This was substantially more than the 3 to 5,000 pounds per acre produced in open ponds at the time. Unfortunately, the complexity and cost of the PAS systems prevented them from being adopted by mainstream catfish farmers, but they provided the groundwork for future systems that would be more compatible with the existing pond infrastructure, both the split pond systems developed by researchers at Mississippi State University and the Thad Cochran National Warm Water Aquaculture Center, and the in-pond raceway systems designed at Auburn University incorporate the best elements of the PAS technology. In the next two segments of this video, we will take a more in-depth look at both of these systems. For more information about PAS technology, please refer to the Southern Regional Aquaculture Center publication number 4500, Partitioned Aquaculture Systems.


About a decade ago, the American Heart Association expressed concern that their 2020 target of improving cardiovascular health by 20% by 2020 would not be reached if current trends continued. By 2006, most people were already not smoking and had nearly achieved their goal for exercise, but when it came to a healthy diet score, only about 1% got a 4 or 5 out of their 0 to 5 diet quality score, and that's with so-called ideal criteria being like drinking less than 4 and a half cups of soda a week. In the last decade, they saw a bump up to like 1% of Americans even reaching this kind of basic criteria, but given their aggressive goal of improving that by 20% by 2020, they hoped to turn that 1% into like 1.2%. Okay, so how'd we do? Let's look at the 2019 update, and it looks like we've slipped down to as low as 1 in a thousand.  No wonder perhaps that for all mortality-based metrics, the U.S. ranked declined to like 27th or 28th among 34 industrialized countries. Citizens living in countries with a substantially lower GDP and health expenditures per capita have lower mortality rates than those in the United States. Slovenia beat us by three countries, coming in at 24th, in life expectancy to our 27th, and more recently we seem to have slipped to 43rd, even though we spent trillions on health care more than anyone else. What's the leading risk factor for death in the United States? What we eat. The standard American diet is just to die for, literally. Those trillions in health care spending aren't addressing the root cause. Look at some of these beautiful lung cancer death curves. It took decades to finally turn the corner, but it's so nice to finally see those drops. When are we going to see the same with diet? Approximately 80% of chronic disease and premature death could be prevented by not smoking, being physically active, and adhering to a healthful dietary pattern. But what exactly is meant by a healthy diet? Unfortunately, what we hear about nutrition in the media is often inconsistent and confusing. There's a pressure within today's competitive journalism market for sensationalism. There may even be a disincentive to prevent the facts in context to sell more magazines. And this paper was written back in 1997 before the lure of clickbait headlines. In fact, about three quarters of a century ago, it was noted that, unfortunately, the subject of nutrition seems to have a special appeal to the credulous, the social zealot, and, in the commercial field, the unscrupulous, a combination calculated to strike despair in the hearts of the sober objective scientist. The most important health care problem we face may be our poor lifestyle choices based on misinformation. It's like the climate change deniers. Healthy dietary vice is overshadowed by critics, diabetics, industry interests, and misguided information in the media. Maybe what we need is like an IPCC of nutrition. These days, no single expert, regardless of academic stature or reputation, has the prominence to overcome the obstacles created by confusing media messages and effectively deliver the fundamental principles of healthy living to the public. However, what if there was a global coalition consisting of a variety of nutrition experts who collectively represent the views held by the majority of scientists, physicians, and health practitioners? It could serve as a guiding resource of sound nutrition information for improved health and prevention of disease. Boom! The true health initiative was conceived for that very purpose. A nonprofit coalition of hundreds of experts from dozens of countries agreed to a consensus statement on the fundamentals of healthy living. Check out www.truehealthinitiative.org. Spoiler alert, the healthiest diet is one generally comprised mostly of minimally processed plants.


Hello everyone and amongst us we have Justice Hari A. Prashat and who is a former judge from Kerala High Court. Now a designated senior who is practicing not only the Supreme Court and the other parts of the state. We have taken a lot of sessions with him and today he would be explaining the nuances of governorship and thank you sir for accepting and I invite over to you. Thank you. Thank you my dear friend Gus. See the concept governorship is of great importance across the length and breadth of our country because questions relating to partition directly emanate from governorship. So we will see what are the the classifications and the different types of governorship that is conceivable in our country. Now before going into the subject I think it is better to understand the fundamental principle that ownership consists of a bundle of rights over some property. Now that is the concept called ownership. It gives to the owner some claims, privileges, powers and of course immunities and limitations. These may vary according to the nature of the property over which the ownership is claimed. So it depends on the nature of the property. The ownership is a bundle of rights having various privileges powers and immunities. Now going by the definition of jurist Austin ownership is a right over a determinate thing indefinite in point of user unrestricted in point of disposition and unlimited in point of duration. This is the definition. But this definition normally is applicable to the absolute ownership. It is not in respect of a limited ownership because as all of us know ownership is a concept which is of limited ownership because when two or more persons have ownership in respect of the same subject matter then only we call it a ownership. So the ownership in the going by the Austin's definition it is sold the ownership of a person sold owner of the property but there is a slight distinction in the case of ownership. Then the main facets or rather the predominant features of ownership are one right to possession. That is very important because there is a saying that possession right to possession is nine points in law. So right to possession right to enjoy and right to dispose. So these are the fundamental rights available to an owner of a property. Right to possession right to enjoy and right to dispose. So these are the this is applicable in the case of soul ownership as well as in partnership. Then if an owner of a property I'm speaking about the mobile property for the time being if the owner of an immobile property is wrongfully dispossessed or even a owner of a mobile property is wrongfully dispossessed he has a right to get it repossessed or recovery of possession possible but an absolute soul owner of a property if he so desires can share his interest with some other person. That is I mean suppose one acre of property exclusively belongs to one individual and he decides to sell half of his right over the entire one acre of property not 50 cents by partition. The entire property is half right is sold to a second person. Then he becomes a co-owner with the original app sold owner and that way he can create a derivative right. Then in other words suppose a person is the complete owner in the legal sense absolute owner property the expression absolute owner requires some clarification. There is nothing absolute in law but then for the time being let us assume that he has all the power conceivable in respect to all the powers conceivable in respect of the property. Then he can if he holds the property by himself he is this old owner. There is no question of partnership but he may decide to as I told you earlier he may decide to give away a portion of his right say half or one third or one fourth whatever it is.  In the other way round suppose he creates these mortgage license whatever it is that is called the derivative right because then there is a concept called a superior right and an inferior right. So if that is created it is not a corner ship it is actually another dual relationship of an absolute right on one person and the derivative right in respect of the other person. So the difference between corner ship and derivative right is that in the case of corner ship the the what you call the the interest transferred by one person to another person is a coordinated interest. Coordinate interest means at the same level not a superior or an inferior in the same level coordinate interest when it is transferred the transfer is called a corner along with the original owner and if a derivative right like lease mortgage etc. are created then the the the holder of the property is called having a superior right and the for whom it is transferred will have a smaller right or an inferior right which is called a derivative right. So that is the essential distinction between corner ship on one hand and derivative rights on the other hand. Then assume that a is the owner of a parcel of land he dies leaving behind his wife and children. The moment he dies the property right which was available with a devolves on the legal heirs. So that devolves according to the shares claimable under the personal law Hindus according to the succession act Muslims according to their personal law Christians according to the succession act whatever it is. So whatever personal law applicable to them the property of the deceased owner devolves on the legal heirs and they becomes the moment they becomes co-owners.  They are not related by blood or they are they are total strangers as you suppose three persons who are total strangers purchase property by contributing different sums going by certain the the sub provision the TP act you will find your type your this entitlement to property will depend upon the price the share in the price that you have paid. Suppose one person pays 1 lakh the other person pays 60,000 the other person pays 40,000 together all together 2 lakhs. And they purchase a property then their share interest may be different in the property. So the person who has paid the maximum amount will have a higher right then the middle man then the lowest person. So in that case even though their shares are different shares in the property are different. They are corners because there is no rule that each corner should have the same interest in the subject matter of the concept that is another principle. Then in theory every corner is assumed to be the entire assumed to be the owner of the entire property. Otherwise every corner has all the rights and privileges in respect of the property that can be claimed by the if he had been the sole owner of the property. That is why we go later there are certain extensions possible. I'm just telling you the principles for the time being. So fundamental test of corner ship is whether they have coordinate interest. Coordinate interest I will explain once more it is interest in the same level having the same nature. It is not a derivative right it is neither a superior right nor an inferior right at the same level. So the fundamental test is to determine whether there is a corner ship or not is to find out whether there is a coordinate interest. If the interest of one is subordinate or higher in degree than the other there is no corner ship between the parties. So that is why I again explain there is no corner ship between lesser and lessy. There is no corner ship corner ship between mortgage or a mortgage because their rights are at two different tiles. But suppose two brothers inherit from their father their interests are the same. So they are having coordinate interest that is the main incident of corner ship. Now generally we use joint property. Joint property is a loose expression where you can have corner ship and you can have this joint tendency. You can have co-personally these are all joint property but corner ship is a special feature of that joint property. Now straight away we will go to the forms of corner ship that can be conceived in our country. One that first one is joint tendency. Second one is tendency in common or corner ship in the normal usage. Then comes co-personally. So these are the three types of varieties of co-ownership or rather joint ownership possible in this country. First one is joint tendency then tendency in common and then co-personally. Joint tendency is a concept where the joint tenants form one body owning the properties. That is they are collectively they are one body owning the properties. Now actually joint tendency is said to be distinguished by four units. The characteristics of joint tendency is different from that of the corner ship. We will see what are the characteristics of joint tendency. Unity of possession. Unity of possession is essential because every joint owner is presumed to be in possession of the property. It's an extended even if one joint owner is staying away the other holding as in the case of corner ship. The other holding the properties presumed to be holding it for and on behalf of the other joint tenants. So unity of possession first thing. Then unity of interest. Their interests are also originate from the same source. Their interests are the same. So there is unity of interest. Then unity of title. They have unity. They have the same title. If it is not a derivative title or the joint owners have the same nature same extent right in respect of title. Then an unity of the time of commencement of such title because it's a legal fiction. So the commencement of title also takes place in respect of the joint tenants at the same time. So there are four unities in the case of joint tendencies. One unity of possession. Unity of interest. Unity of title and unity of the commencement of such title. I'll just explain. Suppose a person who is governed by Hindu succession act. Of course there is an amendment. I remember that there is an amendment to section 6 of the Hindu succession act including the daughters as co-personals and the co-personary. Assume a case before the amendment which was in 2001 or so. I don't remember the date of amendment. Anyway recent amendment within one or two decades. Before the Atlantis is 2005 if I remember correctly. Now before that suppose a person dies. A co-personer. Hindu co-personer dies. So if when the rule of survivorship was there. The property owned by the person. Will devolve on his persons. Entire persons entitled to the right according to the principles of section 6 of the Hindu succession act. As one unit. So suppose there are three persons claiming his right or rather entitled to claim his right. Then the right originally belong to the deceased Hindu co-personer. Will devolve on the three persons in equal proportion at the same time. So there is a creation of a joint tendency in respect of the right to the deceased person. So there are four unit is satisfied. One unit of possession. Then unity of interest. Unity of title. And unity of time of commencement of title. Because the title comes as the moment he dies. So these are the concepts relating to joint tendency. Then in the case of a joint tenant. They also have a right to joint possession. Every joint tenant is presumed to be in possession of the property for and on behalf of other joint tenants. But in the case of joint tendency. This as distinguished from the corner shape. Each joint tenant will have the same interest. Because if one is having one fourth all the other persons will be having one fourth right. So there cannot be a varied interest in the property. But in the case of corner shape the principle is different. And as I explained earlier the joint tenants right. Is the rights are accrued to them from the same source. The source is also the same. Because they derive right from a person. Or rather from from an happening this from the same source they derive. But in the case of corner shape. The right can emanate from various sources. That is the difference I'll explain when I deal with the corner shape. And lastly each one of them should acquire interest in the property at the same time. Because the evolution of interest in the case of a joint tenant in the case of joint tenants. Happens at the same time. Now coming to corners. Tenancy in common the difference is that. The corner shape does not require. As in the case of joint tenancy. Because possession is a common ingredient for both joint tenancy as well as for. Tenancy in common. But there is no rule or there is it is not required in the case of corner shape. That there should be unity of right or unity of title and sorry. Unity of interest unity of title and unity of. Time of commencement of title. These these three ingredients are not required in the case of corner shape. I shall explain. Suppose I have a property. Say one acre of property. I decide to sell. See one third right each to two different persons. So I retain my one third right over the property and I sell. One third each to two separate persons. Assume that I am selling one third right to be. Two A today. So I'll be retaining two third right over the property and. A will get one third right as on 2D then after say six months. I sell my one third right for again I sell one third right to be B. Then B will get one third right after six months. So there is no identity of time. Time factor is not there for either the commencement of title. Does not depend on single time it at different times it happens. So still there is a concept. I have a one third right the other two persons have one third right each. So there is no rule in the case of corner shape that the title should come at the same point of time. And as in the case of joint tendency I told you earlier the joint tenants must have equal right in respect of the property concern. But in the case of concept there is no room that everyone should have a same interest. Suppose I sell one tenth right over my property to a person. I'll be retaining 9 by 10 and the the Bendy will get only one by 10 still we are corners. So different shares possible in the case of corner shape. The other aspect regarding corner shape is that even if even if the the corner is not in possession of the entire property or even if he does not have the entire right of the property. He is presumed in law to be the absolute owner of the property for all practical purposes. For example, suppose somebody is trying to trespass upon the property. One corner can file a suit against the other the the the the apprehending trespass against the person who is likely to trespass upon the property for an injunction or other release as law may require in this case that the property should be protected. So he has a very right to see that it is enjoyed in a manner as if he is the full owner of the property. That is one incident of corner shape. Then before coming to other aspects of corner shape let me explain co-personary also. Now co-personary is a concept even available in English common law principle because we are we speak co-personary mainly in the context of Hindu law pristine Hindu law. But even in under English system co-personary is recognized but there is a slight distinction between Hindu co-personary and the English concept of co-personary. Co-personary arose in English common law wherever land descended to two or more persons who together constituted an air. As in the case of our co-personary also the entire right devolved on co-personers was originally belonging to one individual from one individual they trace their right to to claim ownership over the property. Co-personers constitute a single air and they occupy a position intermediate between joint tenants and tenants in common. So co-personary in English law is a position between joint tenants on one hand and tenancy in common in the other hand because tenancy in common we have seen a need not be under the what you call under the same interest at the same point of time the title need not comments there are distinctions in the case of joint tenancy also even there are four unit is required but English common law says that it is this co-personary under the English concept is something in between joint tenancy and tenancy in common. Now coming to Hindu Midakshava co-personary the principle is slightly different because as we know the co-personary is recognized under Hindu law when all persons the when the co-personers are linearly descended from a common ancestor then only the co-personary will be recognized under Hindu law and you know co-personary is actually it is a it is a statutory prescription co-personary is formed by operation of law it can be created by contract between the parties it is a natural thing happens under the under the the relevant law applicable to the parties. Then the expression Hindu joint family has to be understood in the context that it takes in not only co-personers but also all the female members minor members those who are removed three degrees away from the the acquirer of the property. So all the all the members in the family collectively are called joint family and the co-personers normally according to Hindu law being the sons grandsons and great grandsons of the holder of the joint property for the time being. So co-personary or three generations sons grandsons and great grandsons of the holder of the joint family property for the time being. So that is the distinction between joint family and co-personary. Then of course if you if anybody is interested in understanding these concepts please refer to AER 1962 Supreme Court 287 AER 1962 Supreme Court 287 AER 1985 Supreme Court 716 you will get the concepts clear regarding the co-personary because you will find a lot of litigations in the in the context of income tax loss. Then according to Hindu law there can be a joint family with a single co-personer provided there are other members entitled to maintenance from the estate because if soul person cannot be a co-personer if there are other females other members in the joint family though there are no other co-personers still a co-personary can be there can be a joint family possible please see 1970 AER 1970 Supreme Court 343 sorry AER 1970 Supreme Court 343 then even the death of the soul surviving co-personer does not necessarily put an end to the family because the co-personer suppose he survived joint family cannot be finally brought to an end while it is possible in the nature of law to add a male member to it for example if adoption is possible then if in the joint family suppose there is an adoption legal legally valid adoption takes place of a male then the co-personary can continue. So these are all some broad concepts may be not very relevant for the present context but I am just telling you the principles to understand what exactly the distinction between co-ownership and the co-personer then so going back to the subject co-ownership it need not be between the family members even strangers can be co-owners suppose a Hindu a Muslim and a Christian together by property by what you call pooling their resources then it's a co-ownership it can't be a joint family or it can't be a co-personary or it can't be a joint tenancy also because joint tenancy commences by devolution from one source common source so this can be a co-ownership it cannot be the other two concepts called joint tenancy or co-personary then what are the rights inter say between the co-owners let us see whether there is an agency possible one co-owner can be whether he can be presumed to be an agent of other corners the law says that merely as a corner one person is not an agent for other corners is not an agent for other corners but a corner maybe maybe an agent for others by any authority suppose there is an express or implied authorization given to one corner to act as the agent of other corners then of course an agency is created by either by contract or by this what you call act of the parties act of the corner who is authorized to act on behalf of others as I told you earlier one corner for protecting the interest of himself and of others can file a suit for preserving the property for injunction recovery of possession whatever it is required he can file it on behalf of others only thing is that in the plane he shall our that apart from him such and such other persons are also having the right because he can't file a suit or he can file a suit but then the other corners are not bound by his suit if he makes an argument in the plane that he is the sole owner of the property I shall explain because suppose there is a hostile assertion against other corners and he claims exclusive ownership of the property then the difficulty is that other the degree therein is not binding will not bind the other corners maybe even the stranger the defendant in the suit even can dispute that you are not the sole owner of the property that's it this is debatable proposition however in in other cases where the the the corner ship whether the whether the person the corner in position in order to preserve the property files a suit for and on behalf of other corners without negating their right such as who is maintainable and there is a kind of agency presumable under that situation then whether a corner is a trustee for other corners that question also arise and decided in very many cases you will find some decisions by the Supreme Court and other high courts a corner merely as a corner is not to be a not to be regarded as there is no fiduciary relationship as such as provided under the Indian Trust Act but chapter 9 of Indian Succession Act 1882 enumerates several cases in which obligation in the nature of a trust is created it is not a real trust in the in the in stuctose and so but obligations in the nature if you refer to sections 90 94 95 etc you will find the Indian Trust Act says a relationship in the nature of akin to trust of course those concepts may coming to play but there is no actual what you call express trust created by for the actions of one corner for a down be half of others the position therefore seems to be that as between the corners in a joint estate there is hardly any relationship of a fiduciary nature but if any corner by abuse of his position as such gains an advantage it is not only proper that he should not be allowed to enjoy the advantage to the exclusion of the others that this principle is called dis gorging the benefits suppose a corner by virtue of management of the partnership property acquires some benefits or advantages then he is liable to account for the say account the the profits or rather the benefit that he has derived to the other corners and there must be a sharing of profit that is the settle on this then if you speak on what you call adverse possession limitation and ousted that itself is a long subject large subject but I just make a mention that a corner's possession in law is presumed to be for and on be on behalf of other corners there is no hostility pres presumed by love unless it is specifically pleaded and proved in a litigation between the corners and one corner claiming absolute ownership over the partnership property by adverse possession limitation and ousted it is for him to plead and prove that he had excluded to the knowledge of the ousted corners that he is the absolute owner of the property so that's a different subject by itself so in principle there is that the law presumes that every corner is in possession for and on behalf of other corners it is for the person who asserts an independent right to plead and prove that is the principle then another right available to corners is that he is entitled to claim contributions for the improvement of the property that is the general principle but that principle is subject to certain conditions you can't suppose a corner voluntarily improves without the without asking permission or without the concurrence or without even informing the other corners he voluntarily out of his gratification he does it then probably he may not be able to claim it if there is a dispute between the other corner between himself and other corners but if in the following three conditions in a corner improving the property or doing good things for the property to increase the value of the property can claim reimbursement when three things are in existence one if there is an express contract for such improvement and then there is a decision for contribution to the person who is doing this for the benefit of the property there must be an express contract for contribution to if the money was spent the express are implied request of other corners there is a specific request either express or implied from other corners to improve the property then the improving corner is entitled to get contribution and three if the case falling under section 70 of the Indian contract act is made out then also he is entitled to get reimbursement or rather contribution for the proportionate contribution from other corners under section 70 of the Indian contract act there are three situations work done should not be unlawful 70 says you can't claim contribution if the work done is unlawful so it must not be unlawful activity then second one that he should not have intended to do the work gratuciously suppose the corner does a gratucious act then there is no question of claiming contribution then three that the other corners should have enjoyed the benefits of improvement suppose they have enjoyed the other corners by act of the improving corner have benefited and they enjoyed the benefit then of course they are morally and legally about to pay contribution to the person who caused the improvement so these are the situations so contributions generally if it is voluntary gratuciously and without either against the other corners or without asking them then the corner is not entitled to get contribution but in other situations he may be entitled to get contribution for improving the ownership property then suppose the corner discharges a common liability suppose there is a liability on the estate on the property and three owners are there one corner out of his pocket clears the debt so there is a revenue recovery proceedings or some liability on the property one corner discharges the liability certainly he is entitled to get contribution from other corners who are benefited by this man's act so these are the concepts regarding corner ship in the in the real practice life experience these are the these are the characteristics of this right and we have seen three different types of corner ship consumable in India joint tenancy tenancy in common and cooperation this tenancy in common is known as corner ship joint tenancy is as I told you earlier there are four units which is not required in the case of corner ship or tenancy in common and the co-personary and the English law is different from Hindu co-personary and Hindu co-personary of course the wider definition as of now because the act has been Hindu succession act has been amended and it takes in doctors also co-personary right is in respect of persons had removed three degrees from the joint holder of the property and these are the incidents because we will stop it here and if there is any question probably I can answer yes sir I think it wouldn't have been explained in a much better way than what you have explained just taking few questions have come on the whatsapp is there any concept of absolute ownership co-ownership okay I will explain that because I told you at the outside that absolute ownership if you go to any any this what the world says almond on Nourish Prudence or any standard textbook on Nourish Prudence you will find that nothing is absolute in this world the world is imperfect so the concept called absolute ownership is only a misnomer actually assume that I have one acro property I can't do it and I can't enjoy the property in my own way so with disregarding the entire laws relating to the enjoyment of property for example I have to pay municipal taxes I'll add to this respect the easements right available to the other persons if you read section 7 of the easements act you will find that natural rights that section 7 deals with natural rights no easements are restrictions not restrictions on ownership that is what the section itself says section 4 definition itself says so absolute ownership is a concept in law because you have a right to enjoy right to possess right to sell right to mortgage right to lease whatever transactions in law permissible you can do that and you can sell out the property you can make a gift you can create a will so these are all absolute these are all incidents of absolute right but still you have to follow certain other laws or rather other other conditions in enjoyment of property while you are enjoying the property so theoretically there is an absolute right but in practice your rights are controlled by other statutes and others rights that is why we say that absolute right is only a bit yes because yes sir next question is in what manner the tenancy rights of a deceased tenant devolves on his no see the tenancy right of a tenant tenancy right it can be in respect of a building tenancy or it can be in respect of a land whatever it is no tenancy right is as I told you earlier it is a derivative right owner of the property or the we call it owner of the property or a person having right title and interest over the property creates a lease in favor of a person who had no other right over the property prior to this creation so only by virtue of a lease the leslie gets a right over the property before that he had no right so such a person the leasehold right holder the holder of a leasehold right suppose he dies the leasehold right devolves on his legal years as one package because there was only one single person holding the right the moment he breathes his last that single person's right will devolve on the legal essay assume that the tenant has two children and the wife so the whole tenancy will devolve on these two children and wife as one package and devolution of tenancy right is a joint tenancy they are by devolution a joint tenancy is created in favor of the legal years of the deceased tenant so the devolution is not in the form of partnership but in the form of joint tenancy this is a classic distinction between partnership on one hand and joint tenancy on the other hand yes because now this is what are the differences between the adverse position and out still yes adverse position is a concept if you refer to article 64 and 65 of the Indian reputation act that the rights lost after 12 years adverse position means somebody holds your land with a hostile intention to exclude you from enjoyment so just one more aspect as Mr. Vikas already asked me a question regarding absolute ownership absolute ownership is a concept where you can have all the rights position saleability all things are there apart from that you have a right to exclude others from possession also that is also a right for some not only that you can possess but you can also exclude others from interfering with your position so but in the case of adverse position suppose somebody trespasses upon another man's property and retains possession of the property for this statutory period of 12 years without allowing the owner of the property to enter or enjoy the property then after the period of 12 years going by article 65 the limitation act you get right over the property so the right of the original owner is extinguished and that is given that is attached to the trespasser now that is called the concept of adverse position but in the case of ownership the essential difference is that every corner is presumed to be owner of the property for all practical purposes he can hold the property and enjoy the same as if he is the full owner in the case of ownership if you want to have a hostile right established against other corner or corner then the it is the burden of the corner claiming exclusive right to show that he has negated right of other corners he has denied the right of other corners he has rendered the property with a hostile animus to others and to exclude them and he has prescribed the right of title he has prescribed the title to the property for holding it in a hostile position for more time 12 years so the essential difference between a stranger trespasser claiming title by adverse position and a corner claiming right and title by adverse position against other corners is that in the case of a stranger there may not be a stranger because ouster is a concept which under law is that the fact that you are holding it with a hostile animus or that you are negating the right of other corners in the case of ouster has to be brought to the notice of the other corners so you can do it in a clandestine manner you can do it in what you call stealthily you can do that you have to by your gesture either by words of actions you must convey to the other corner that you are holding it as your own not on for and on behalf of the other corners and there must be an express indication going from you to the others that you are excluding them from your right so ouster is a thing which requires an a what do you call it which requires an express communication that you are negating is right but in the case of adverse position that is not required because everyone is under a legal obligation to consider to what you call the vigilant in respect of his property if somebody stranger proposes it up and you do not do anything with it 12 years your idea is lost but in the case of partnership since they have a dual relationship as equal owners the law requires that ouster which is a communication of your hostility to the other person in express terms which is not required in the case of strangers yes we will just take the last question because I know that you are pressed with time can a co-owner seek eviction of a tenant from the lease would yes no a corner as I told you is presumed to be the absolute owner of the entire assets entire property for for all practical purposes therefore he can seek eviction of a tenant from the premises for and on behalf of other corners but one rider is that he cannot claim that it is his exclusive property if he must recognize or respect the rights of other corners and he represents the whole body of the owners joint owners or rather sorry let us use the correct expression corners he represents the the body of corners and he can seek eviction and that is covered by a direct decision of the Supreme Court by Justice V.R. Krishna here in 1976 that is a very interesting decision please refer to am 1976 Supreme Court I don't remember the page now which is clearly laying down the law and dealing with the rights of corners in respect of seeking eviction from tenants so thank you sir for sharing your knowledge and those who are not subscribed to the channel they can do that and we will request that we have got all knowledgeful sessions of Justice a Harry Prasad you can watch them they are on the playlist and even otherwise if you google with beyond law so to take connected with us thank you everyone and thank you sir for sharing your knowledge and we keep on pressing you and you have always been kind enough to share your life thank you


Talk to you a little bit about what's called body percussion, and it's a way to ingrain beat, especially, but other musical elements into just your body movement, and it can be as simple as this, pat your legs, clap your hands, and there are different ways to clap with different sounds, different results, then you can snap. That's just three, you can stamp your feet. That way you have your hands at different levels, so you can indicate different ranges of notes, so you have low notes or medium notes. Here's a middle note, high note, you can do a beat that way. You can show different words of songs that way, you can flood them up, it's just another way to help the kids ingrain a beat, but it's also a good way to help the kids get ready to add instruments. So if you're doing a beat here, especially if you turn it this way, then when you start doing this with mallets on a xylophone, it's not too much of a difference.