ToIP: AI and Human Trust WG - 2026/09/17

Hey Joe. Oops. Let's get this. All right. Hello, Sally. Welcome. >> Hello. >> Let me put on the agenda for today and wait everyone to join us. Yeah, I thought I couldn't make it, but they moved my other meeting, so >> Oh, nice. >> I mean, I missed it because they moved it, but you know, [laughter] Hey, Eric. Long time no see. >> I'm back from Walkabout. Sorry. >> Did you take a long vacation? >> I Well, I had some things going on [laughter] and then Summer got in the way, but yes, I really apologize. I haven't been able to be here. [laughter] >> Well, great to see you back. >> Yeah, I've been trying to follow along. >> [laughter] >> progress. >> Uh yeah, we are checking along. Um let's see. But uh excellent see you guys here. >> We missed you in Geneva. >> I'm sorry. >> So we missed you in Geneva. >> Oh yeah. Um I guess a lot busier this year. So you can see a lot of less travel. >> It's uh time consuming. Um >> yeah. >> All right. What time is it? We probably should kick our kickstarter for the just the formalities uh on the notice on the antitrust policy and um trust of IP's IPR policy and specifically I think I want to always add a few things about the IPR policy is to make sure that our uh you know uh specs or any publications and there's no dispute who owns them. We want to be able to make these uh uh our uh deliverables eventually free to use and there's no con you know not too much um strings attached and that's why this policy is here. So uh we want to make sure everybody sign on to the trust of IP member and uh where you agree to those terms uh that's the uh the purpose of it so that our um publications are free of attachment there. Okay. Um so for today we've been uh going uh the past few weeks of rotating the two topics. So today we are swinging back to uh the trust you know the acronym still ta hub uh but I I've changed the t to trust rather than tsp because it's not entirely uh tsp is very important part but it's not entirely about that so um but otherwise it's uh it's the same uh enablement we have a trust and enables these agents to be you know to be able to do better things and behave better and be more responsible etc. And that that's the uh the term for it. So for today uh I thought we could go a little bit deeper. So we have a draft that's still sitting there uh waiting for me to clean up um and uh maybe revise and publish to uh to um with all the detail filled in. But the proposal we have reviewed several times is quite clear and uh the past few weeks I was trying to uh go over some uh requirements and I've been collecting as we you know go over different meetings there are things that pop up and so there are a few of them I thought we could actually concrete enough we could pursue essentially say take this example uh if we walk down the road what kind of a you know TA based um delegation and limitation constraints those I will call that a language so what that would show up in that language can we do it is it adequate etc so this is like uh taking some realistic example and then show what we can do about it so that's the exercise I thought would be very useful to validate that current uh spec look sound and you know reasonable. Um uh so that's the overall approach. I want to just pause here see uh if you guys have feedbacks and ideas where am I at attendance? So how are we saying tea now? Trust enabled agents. Yeah. Trust enabled a a agent or AI agent may you know it's a [laughter] yeah >> yeah uh it was called TSP enabled agent which it's true too but we >> I don't know it's a you guys have a better naming but this is the >> I think it's a good move. I think it's a good move. I mean it doesn't break it in any way. It's generalized. >> No, no, no. It's just a name. And we uh if you look at the spec, we say a lot about TSP of course. Um but then we introduced the language is based on ACDC which is also uh underneath of it we also use the the VIs all that introduced in TSP2. So you can think of them as combine the two together. Then we add our own essentially see this is just a container. So we want to add our own particular way of saying these things right. Um in the past we call policies but you know basically we have delegation stuff constraint or limitations uh obligations and what else are there? [laughter] So we have introduced a bunch of terms to mend some type of policy constraints and and anyway so that's the um the extension uh we added the the work of a TA is really to integrate those things together make it a whole consistent and then we can describe how to use it. So, I hope it's a, you know, looks like achievable and there's a draft that's reasonably complete already. Um, and if you recall, we um um for anyone that haven't seen this diagram before, let me see if I could make it bigger so you can see easier. This is the latest. Is that how it works? Yeah. So, this is the latest uh uh diagram and we walk through those numbered steps. um to illustrate how uh a TA uh based system or agent would work. Uh so in this case in right in the middle of it is our conception or you know one example of an agent and uh in this example so we started like a Eric you remember um travel and stuff like that right so suppose you have a some kind of application you're writing and it's really the heart of it is some agent doing things um and then the agent will need to go use some kind of external service or tool or however you want to do it and the way we constrain the agent is to constrain the use of that tool. So um and the example we give isn't you know >> pay for a airline ticket or book a t airline ticket if that's the constraint we want to say hey you must do it within these you know rules and and those rules will be called delegations or or authorizations right so the the the authority in this case says I want to you know you can use this particular credit card under $200 or whatever those limitations assumptions you can add to it and once you are done report back to me and so that's obligation after [clears throat] the fact >> uh and and and that will be a good example and that will follow through this and >> okay >> yeah yeah uh um and usually this requires more than you as the decider because it may involve uh the the critical company may involve um I don't know if uh if the the website want to uh check whether your you know email is the right one etc or the phone numbers correct so may involve others too and so that's on the left side other authorities quote unquote right >> so the prime like the one prime is that does that mean it's happening in parallel or possibly a um >> yeah Yeah. So one and one prime are two concurrent um authority from different sources and so the agent sometimes need two different parties give them some piece of it and then the agent can combine those together and then go use a service and that's what I meant there and one way to use a service is is the MCP and if the agent want to talk to another agent like you are delegating again to another sub agent let's say and potentially that will be a example would it be A2A use so that is why you want to make sure we can sort of integrate with those protocols um and so this picture gave a more complete example that we've been talking about >> right and those um the capabilities obligations are um held by the agent the agent has they know what those obligations are. [clears throat] >> Yeah. The like what exact obligations all that is um so that means we need to you know dive down into some uh more concrete example. So uh the uh the the example I give is a hello world level simplest one. Uh this usually this thing will be in in the case of buying a ticket will be coming from the person right. So the person says um you may use this particular uh credit card and uh the amount is no more than you know 200. I don't know what kind of ticket you can buy today but um and the obligations after done within you know half an hour you must report back to me or something like that or I don't know what is the right good way to say it but those will be the obligations yeah >> okay and but those are held those are sort of preloaded into the agent the agent knows the preferences >> yeah that yeah that is a message or a we call a delegation so a delegation is a tsp message that's coming from whoever the authority to the agent and in this case you are actually giving it to the application and the application then delegate again to the agent. So delegation can be a chain doesn't have to be direct. >> Okay. >> Yep. Yep. >> All right. Let me Oh, how do I Okay. Um so there's a more detail into like how actually the message flows but today I'm going to stay in this level for the moment. Um and uh uh so this kind of explains what uh the TEA is designed to do and then the the details of TEA would be simply be what these things are right and uh so I would propose we for today we would uh uh assume that's the baseline the proposal sitting there and then we can walk through some examples um of uh of the ones I I recorded. Um so one of them is uh I think the more than one people said well I know of certain you know policy language such and such and I think last week um um I forgot who now u that mentioned ODI u cedar is a more procedural so some are very different purposes but there's a lot of so-called policy languages is that give you you know ways to express a policy. [clears throat] >> Yeah. >> And at the end of the day what TA is expressing is policy? Right. So we may say well we may ask ourself the question if you take one of those languages can tea express the same thing. So at least TA is as capable as those languages. We think it's more but you know at least and we we can go validate that that it's relatively straightforward to do. Ideally we you should be able to like take a uh uh ODIL written policy and mechanically translate into a TA. You see the point right? And so that way it's essentially whatever you are using ODL to express today I can express it in TA but it's much more hardened and uh verifiable. So it's a version of that um I we we can do. >> Yeah. Um so that's uh one example and I will very much welcome volunteers who can take you know I don't know you any language you are familiar with take it [snorts] and see if you can if this exercise is actually possible and it will be love to see some examples. We may have to wait a little until a prototype uh implementation show up which can be any day now. So it shouldn't be uh um so maybe wait a little bit longer but even mentally right we can take a uh you can you know just read use paper and pencil [laughter] take a policy a typical policy in cedar and say can I express how would I express the same thing in in in a ta way uh and what that means what are the implications etc so that would be a very good exercise. I'm going to skip this one for a moment and then we talked about uh accountability with a verified >> and now I just want to talk a second about where we can actually use this these policy uh packets here. >> Sure. >> And so we have two choices here. We can use them outside of the VTA or inside of the VTA. In other words, they can be trust tasks themselves. In other words, you check the policy as a trust task or you can just do it kind of through any other method. You see what I'm saying? >> Yeah. So, uh again if people are not familiar with the VTA, VTA is a uh application uh the in the other working group the sorry decentral trust graph right >> graph. Yeah. >> Yeah. Uh so VTA is verifiable trust what is >> agent >> agent but it means agent in the sense of a software agent in other words right something to which authority is delegated >> yeah yeah yeah in a diagram will be higher so maybe the applications what we call them but basically a higher layer so uh sorry I'm I'm going in the wrong way come back here okay so a higher layer yeah so in that case uh the VTA TA or the you know one type of application can uh you can decide to say I want to use ODIO that's perfectly okay right and then you you would then translate into these uh TA specific format >> yeah specific format yeah >> yeah yeah that would be the relationships so so the TA is in the lower layer and [clears throat] uh you can take whatever format actually translated and you can use native >> I think you're saying TEA but you mean VTA >> VTA is application to me to our topic so any application and so the VTA will be the my use word the U [laughter] so yeah a VTA developer can choose to use any language um as long as you can map into the TA format we are Oh yeah, yeah, yeah. Right. Exactly. Right. That's what I'm trying. >> The BTA is like a is a type of Yeah. Right. Exactly. >> Yeah. The VTA is a higher layer application, right? A higher layer that's using TA. >> Okay. >> And that's where and the VTA exists within a space that is governed. So they have policy as part of >> Exactly. Exactly. Because the TA is neutral in that. But VTA can you can say oh I'm going to govern a certain way and etc. So you can set a lot of rules meta rules you know which policy which committee to decide all that sort of things. Yeah. >> Okay. And then so when that VTA ex so that VTA exists um it's got it's it's in a governed space so it's got policy and then when it wants to interact with a tea or actually not interact with tea it wants to >> implement those policies you could then use uh tea to do it. >> Okay. So that those policies get sort of filtered or translated into tea which then allows you to interact with agents in a trust. >> Right. Right. So again come back to this. Right. So because this is a real application and VTA once it's all built up it will be like a a real application and this particular application you can have governance you can have rules >> uh you will have deployment. you know this there's a lot of complexity will come in and uh uh so you come up with a a particular way that's governed and then uh the then you can use tea for delegation and so that is the uh the tool is provides and so from there you can translate your policy in whatever way and shape and map it into a a TEA based uh delegation message and the message goes into the the agent and that's how you get enforced. >> Okay. So you guys are saying that you can't I mean you you you have to use delegation. There's no way to use TA without delegating, right? Well, the the delegation is if you we don't call APIs but this is a a message [clears throat] we define and in order to delegation you will follow this message. Yeah. >> Yeah. And yeah it's um >> that's the standardization part of it. So the delegation is a specific way you say it. So this is the language now is based on messages. Um so the application will format the policy into a ta message we call deleation. It's a message type >> and you send that message to to the agent and now agent has delegated authority >> right >> from you and you know and all the constraint attached to that authority. >> Yeah. Yeah. >> Yeah. Yeah. Yeah. >> Okay. >> Okay. Um, >> and by and when we say you send that to the agent, you're not necessarily you're not sending it into the model itself. You're sending it into another type of code which is handling that that key securely from the point that it's, you know, it's issued from the the the uh the TEA exchange and then you have to still securely handle that. You're not just handling it over to the model. I just wanted to make sure. >> Yeah, exactly. Well, model we will call model agent is the whole thing. So you're right. This is the the thing that is. So if you recall this overall diagram, this is what we define an agent. Agent is the you may say it's a harness [laughter] or something the the where the the model is contained within. >> Yeah. >> Yeah. Yeah. Yeah. [clears throat] >> Can you send can you send the link of these diagrams? Uh this the hardware or >> yeah or the whole PowerPoint the >> Oh yeah, >> it's possible please. Thank you. >> I think share chat. >> So I won't be able to study it. >> Yeah, if you can click it if it is uh working there. >> Request access. >> Oops. Can I let that go away? Okay, >> it's po. >> Wait a minute. It's restricted. Okay, now try again. So these are working diagrams and it just drafts that is being uh finished. So we will be continuing and eventually this will probably show up in this spec as well. But these are the diagrams I think um sort of explaining the specification itself. >> Oh sorry. Okay. Come back to this. All right. So um so I would use VTA is an example of a application. Okay. So that's the uh conceptual relationship between them. [clears throat] Um and again that's why we are we are interested in uh how VTA will use it. How a you know CEDA speaker OD Odil speaker etc. All these are examples of users or applications that would uh uh be able to you know leverage tea to do something to express our policy right and um and so that's the the the goal. So these are basically testing do we design right? Did we miss anything and and I think that's that's the exercise uh we trying to do. Um if I may continue on just just you know just sort of like uh spreading all the examples right um Nikki mentioned about uh terms and conditions and uh I don't think she's here today but uh she's uh interested in um uh defining certain ways to do terms and conditions. So terms and conditions are in a way sort of expressing policy between the parties and um and then people also say my terms and you I think you are all familiar with the is that ine right um the working group there uh which is saying instead of the service that express terms and condition for use of service um the user want to express the same thing and so those are the call my terms and it's basically uh abstractly it is terms and conditions but it's initiated by the user the other party is initiating it so those are called my terms and I hopefully we can also take some of their you know most recent um uh research and and and uh and uh um and see whether we could do exactly same exercise. Okay, so you have these terms and condition. Can I express them in the TA? Uh so that's uh another one. So maybe I should rump these things together cuz these are all similar in the property. Um the other one is uh the verifiable locks. Uh so the question is um the question is what to law and anything mandatory. I think there were discussion or questions like this and then um if I come back to this picture um all the parties involved right so every box here can have a lock and if you are doing auditing the auditing authority or whoever doing auditing may be able to obtain some or all of those laws and then do a check whether certain policies are being followed and those are the policies we we've we've separated two set of policies. Some that you can check ahead of time like they do payment uh you know under $200 that can be checked before you spend it because they know ahead of time. um to report this thing uh this transaction back to me within half an hour cannot be pre-checked. So this is a obligation that agent has to follow through but after half an hour you now you can check it by auditing. So those are the auditors and the auditing then um are rely on this verifiable locks and uh so the there are you know so we can talk about what is uh what this lock potentially can contain and do we need to mandate anything to be uh must be locked or something like that. Uh so that's a another line of discussion and again whether to mandate or not in some way it is really VTA's job it's not uh TEA strictly per se right TEA has to serve many different applications some may have want to log a lot of things others may not want to log you know too much and and depend on their needs um but uh We we we could have uh in the specification describe a methodology or a guidance. Um they are they are not mandatory but basically a best practice kind of a guidance which says if you want this kind of accountability you will need to lock these things. If you want you know another type of accountability then you may log less or something like that. Right? So that might >> when you say accountability, you're talking like a certification level essentially. >> Accountability is after the fact whether you want to put a a blame on somebody. >> Yeah. No, I I know it's already accountability is like >> you can say who's at fault. >> That's what accountability means. >> If you want a record to point to, >> right? Right. You can even like it's almost like a debugging. [laughter] So, uh that's why we the term accountability is a verification to to find out who's at fault because most of the verification for like credentials we always do ahead of time before any action happen you verify but these are verification happen after the fact. So Nikki's making a point that we have to separate liability from accountability. >> There is no liability. That's a entirely human thing. TEA has no idea what that means. >> So accountability is about provenence and detecting where the error occurred. >> Exactly. So if you don't like the humanistic terms, we could talk about that. I'm I'm not married to it but this is the term that most of the academic paper use for accountability >> the evidence a very strong evidence say you you know party a fault >> yeah the enemy in all my white papers is unaccountable systems that's like that term I use so many times so I like accountable a lot >> yeah so I feel this is reasonably human intuition understands it and it's also reasonably technical. So I like that it's basically and that's why you know this is in the end of the day it's just a log but we've added so much things in the law so that no one can temper with it or it's very hard to temper with it and that is a very solid you know piece of evidence whether how do you use it that's a human decision is a governance uh uh problem and VTA can go define it But in in in tea we simply mutually provide such a um [clears throat] a log that uh later I I think you can credibly use it for evidence. >> So the designing you know rules and governance um structures etc. So when the TEA is talking to on that diagram when it's when it's making all of these sending messages to the application provider or the service provider um we want to figure out which of those messages are logged. I mean how >> yeah well so if you are a VTA designer or any application designer you may have in your mind like you want like for example right a credit card payment you want a dispute mechanism right and so you can clearly know what you need for dispute resolution >> um today uh >> the order parties trust the um the credit card companies So the credit company essentially is the centralized party which has supposedly all these logs >> right >> and trust they are very honest they are in you know have strong integrity which most of them they are and then you between you and the merchant you all go to talk to critical company and they can resolve it and that's what these blocks are for >> if you could maybe very quickly I don't know I mean I don't know if this is what you want to do but if If I'm looking at that diagram and I'm looking at the agent going to the ser to the service to the service authority to the other issuers or authorities whatever um that's those are the only things that they could log are those messages that communication back and forth right >> there are a lot of things you uh not just the communications uh any actions you can log too so these are called certificates because all of them have signing authorities in Right. >> Right. So the issuer have keeps the log. I mean today's issuer keeps log already. >> We don't need to even go to new ones. So they they keep a log and the logs are signed. >> But I guess so the question is does that mean that we're trying to to say that the agent wants a copy of that log? >> Not the agent. It's a hypothetical auditor. So it's like a investigating committee for example, right? Can subpoena them for the locks. >> Yeah. [laughter] I'm just I'm trying to understand how that can be how that fits into this specification if it's not controllable. You're saying these are just sort of suggestions that >> uh the tea again do not vendor I mean we don't dictator what need to be because we don't know the application context >> yes >> like in a uh payment system these logs are probably mandated by some financial regulation right >> yeah so the those financial regulation whatever you know laws being passed uh essentially mandate you you must log these Right. So that's already happening. What I'm trying to figure out is that how does that work into what we're doing? I mean, >> oh yeah. So what what we are doing is essentially we are allowing or we are enabling the logs to be generated by agents by software by things that's not falling under financial regulation. [laughter] Um so any you know little piece of software you can produce logs because you have a a signing key. [laughter] >> So but those logs happen between the communication between these different elements and they can either be the messages or the signatures. >> They can be the messages they can simply be the agent logging it. >> Yeah. Okay. >> Yeah. Yeah. And you know any of these bots can produce logs and yes there is a for for real world you have the question of well then how do I get hold of that log for the auditor well that's a separate problem that I think out of scope for tea but for VTA yes you guys should think about it >> mhm >> and vice versa that for the things that you would do that TA is already doing I think you should basically you know, use what the TA provides, right? And then you can focus on like more complex issues like a humans have, you know, a lot of um real world issues that the lower layer does not uh deal with. And um these are governance issues like hey, who can ask for the uh the lock? who can, who cannot. >> And and there might be uses for the agent of its own logs. Don't get me wrong, the agent can do self auditing if that's the way you set it up. >> Oh, absolutely. >> It shouldn't be able to just go back and, you know, change the logs to be whatever it wants later. But yeah, >> it cannot change. So, this is designed that it cannot change. Um, but it cannot it can use it for debugging because the agent may honestly made a mistake and he can go back to the history and say, "Oh, that's what happened. I need to modify you know this particular step in the future. >> That's what I was trying to say. Yeah. >> Yeah. Yeah. Yeah. Yeah. Exactly. Exactly. Uh that's absolutely right. So um uh so it's it's not for accountability only also I would just make it more more practical for debugging learning um you know correcting future behavior. >> So Nick Nikki you got something to say? >> Yeah I've just got a question for you guys. So um logs are really powerful and uh therefore um I I just wondered you know that obviously there are concerns about data sharing around the log itself. Um, [clears throat] so is there a possibility a the logs could be kept locally and b the for example in the case of dispute resolution or a third party query, you could issue a verifiable credential, a proof or a proof of the of a statement in the log or >> um as opposed to in other words it's a signal that's rarely asked for externally and mainly consumed internally. >> Well when is that possible? >> Yes. I just want to say when I just want to say when it's concerning two agents interacting with each other, what I want to do is I want to have the the agent that's doing something that it wants to be have verifiably be verifiable later, sign that, but then it could then encrypt the whole thing and then put that in a shared folder and it becomes just a sort of a a personal log within the shared relationship folder. If that makes sense. That's sort of >> Absolutely. I mean there's always the a party B party question in any of this and and also >> um under for example sustainability directed uh you know and uh um integrated accounting you have the impacted third parties so um >> but it's just um >> you've answered my questions so I think >> [laughter] >> and and the you know you shouldn't be able to edit that log if you're then going to be able to issue a pro you know want to be able to issue a proof for as I say dispute resolution or or something else >> you should be able to >> um >> I mean these logs could be interesting I mean we always in product you always look for logs for monitoring and reporting as a key source and uh I um and for that reason you can figure out a huge amount just by looking at logs even if you don't know who the concerned parties are. >> Um so you just got to be a bit protective. So anything that obstificates the the detail but still serves as a proof and ensures that it can't you know it's tamper free um is is welcome in that on that side as well. >> Okay. So I want to I think I heard at least three things and Nikki I will get back to you on each one so we we didn't miss anything. uh one is you talk about this so-called I I don't know the better phrase for a negative loss of you know some uh for privacy for example a particular piece of information has been deleted for instance right um uh like the right to be forgotten kind of logs okay um to in in our design that is just regular logs so you basically logging it to say I took this action today now I delete this file today and you time stamp it and you assert yourself so say hey this is done whether true or not we don't know but this is a um um un uh this this is a statement made and cannot be tempered with later it's basically on that time I assert that I did this and that's a log so those are the locks that something got deleted >> now The deletion can even be of another different log entry as well. It's just that you can never go back and change a log entry. >> None of the logs can go back be changed. >> None. That's called it's called verifiable logs. >> They are. >> So So what do you mean by corrections? >> Yeah. Give me a second so we can go. >> Sorry. >> Yeah. Yeah. [laughter] Yeah. So So the first one is just general log. So this is nothing special here. Okay. The first one. The second one I think you mentioned about is provable because you want to say well I say it's I did it but how can you know you so those are called attestations and so you cannot prove yourself of course so you will need somebody else to prove for you and that's attestations so usually what this happens is this is another >> attestation by a witness I think the good word witness is good in there >> uh witness witness is not strong enough in the case that uh about privacy because of a deletion um a witness is not enough a deletion is the hardest thing to do essentially say all the information I learned it's gone it's almost impossible to do very very difficult but uh if you want to do it then that requires a testation by another party a witness is not sufficient a witness like a notary for example can only say I saw you signing it that's nothing >> yeah isn't it a sort of a level of assurance on that attestation so a witness is bre better than self assertion >> yeah a witness >> full attestation by a third party is uh is a a higher kind of assurance level >> right so a att a testation usually means that a piece of information you're referring to are actually contained somewhere else. >> Okay. So, I want to ask you a quick question. Is this >> an incorrect statement to say what we're looking for is something being attested to by a witness? Or is witness the wrong word there? Oh, >> well, if you are attested by a witness, uh, it is stronger than without a witness, but it's still not strong enough to prove that you actually deleted this file. >> So, a witness is like a notary, right? It cannot it's still not [laughter] the proof. >> So, so we would never call a piece of software a witness. See, I'm using a piece of software can be a witness. You're saying no. >> It can be a witness. But a witness is insufficient. >> Okay. So, so what is the sufficient one? >> A sufficient one is a attestation. >> Right. But but but what is doing the attestation? That's what I >> attestation has a custody of the asset you're talking about. So for instance, somebody give me a piece of paper and then uh ask me the neutral party to destroy it then I can destroy it and provide a attestation that's not witness. I actually did it. So it is a outside party and you will have to trust that. >> Oh I I I see what you're saying. Sure. >> Yeah. So like in any kind of a takedown or something you are relying on a party that you say okay because of other reasons that you know maybe there are a corporation that is governed by some strong authority uh for other reasons you believe they will follow through or maybe there's a court order that you believe they will follow through and that party can do attestation. It's more than witness. >> But you need a witness to the attestation. That's the strongest. >> A witness is cheap. So if you want all of this can be witnessed. So witness is easy to do. Yes. You you you may think of it as the the cheapest or lowest level of attestation. >> So the attestation sorry just the attestation means the one responsible for the act has to sign but they also have to prove that they've done the act right. That's where the atttor the the word attestation usually associated with a party an actor who can prove and some can. Yes. >> Yeah. >> A tester. That's the word I was looking for. [laughter] >> I'm trying to separate the two terms. A tester versus a witness. Um the two are uh um they in in very fundamental level they are different. They're doing different things. A witness they simply say I saw you sign it. >> Yeah. >> Right. It is useful. Yeah. A lot of time it's useful but it's better than like a tester. A bank could be a tester. So you go to a bank and ask the tailor to say your bank account balance is above this number and they will produce a bank note with that that's num you know sign it and you can take this to go you know do a lot of things right >> okay so >> so that would be a a tester the asset sits in the bank so the bank can know yeah >> a notary does not know that a notary simply say you sign that you have you know $10,000. Uh so those are the two differences but both of them can be added to the to the log. Uh so for our purpose the log can say both. Uh but if you want a witness or you want a tester then you need to go design the witness design the tester that's out of scope for us. We assume you have something then the uh TEA can uh make that into the lock. >> Okay. >> Okay. So the third notion is something about corrections. So oh I put something in the log and and then I made a mistake. I want to go back to the log and correct it. Um so the log allow you to do corrections but without with all the history in it including the mistake and your correction both are in the lock. So it is basically another entry in the log. The log never deletes anything. Uh but you can the interpreter the the one reading the log can say oh I should ignore that particular entry and then use the corrected entry. uh but the log is unmodifiable. So hopefully that that's what the meaning of a verifiable log that it cannot be you know basically that's what uh we are producing >> but you would you do have the ability to make verifiable deletions of of entries in the log. Correct. In other words, it will show the negative space where the entry was, but remove all of the information that was inside of that entry. You'll still have the original entry reference number and when it was made and then when it was deleted. All that stuff will be preserved, but there might be data that is redacted for some reason or another. Like for example, it could be, you know, CSAM or something like that where you really want that stuff off your system or, you know, I don't know what I'm, you know what I mean? There's something in there that that go. >> Yeah. Uh reduction, I need to do some work research on that. I'm not I don't have a ready um ready answer for you. So maybe uh so reduction is a bit harder to do but I see the point that sometimes you not only want to prove you want to basically keep all these properties except a particular entry cannot be read unless you have you know some key or somebody the reductor can always read it right. So reduction is by some person. So the the p the the the or so sorry I should say a party um and the redacting party should be able to um hide a some entry but the proofs still work. The rest of the proof still work. Is that what you >> Yeah, that's what I mean. Yeah. >> Yeah. Yeah. um I I need to research into like how people do reductions uh or you know what implications are etc. But yes, I see a uh a requirement that I have not thought about before a reduction. >> Good. Yeah. For example, you know, if I had data on my system, right? Yeah, >> that that I'm holding for another party and I have agreed with them to not share their data with any other party. But then I want someone to come in and audit my logs. I have to redact that data from my logs and explain to the auditor why it was redacted right in the logs because this third party does not allow me to share their data for any purposes including auditing. >> [clears throat] >> I I understand I I understand in that level um uh the I'm not answering it right now because I I need to do some research whether the log itself can accommodate that or it has to be some disclosure mechanism above the log because we only so far we only talk about producing these logs who can read them who have access to them. That's a a that's a separate question, right? Maybe that's a VTA level question, application level question. But I want to research into whether the log can natively support reduction. That would be the strongest because then otherwise you are yet another middle layer has to behave correctly in order to uh support this feature. And so I would like to support it natively but if not then this will be something that be added on by uh a higher layer. >> Now with even within the agent the agent may have different subruules and you may want to have this subruule which has its own logs share some redacted part of its logs with a with a different agent even within the the one agent. In other words just in their different functions. In other words, an agent might know something about me and it might know something about you, but I got to make sure that when it's trying to figure out how you and I should interact, it's not sharing my private information that I gave it with you, for example. >> Yes. Yes. Um, so we uh uh we provide only the mechanisms. So in again if we go back to uh the diagram, right? All the parties represented in the picture can produce local logs and um it is a uh a matter of uh you know uh governance policy to say uh these logs what need to be in there and who can have them. We're just saying these parties are able to produce this maximum set of logs and um the the question of who you share with etc. Those are all separate questions but the TA provides a way to sharing so because it's just another message and you can attach to it and send to somebody but whether that's you know mandatory it's required etc those I think is better answered in the context of of a specific known application because that application will have a right justification that why this must be uh required, why this must be public, why this piece must be private, etc. I think only the application knows. So uh it the TA spec simply stops short of going there. We can give some examples, but we would not mandate anything. >> Yeah, that makes sense. >> Yeah. Yeah. Okay. >> Wjing, there's just a a a quick question. If you could save, press save in Confluence. >> Uh, save in. >> Yeah. Or just update. >> Oh, sorry. Uh, you're not seeing it. Okay, I'll do update there. >> Thank you. >> Um, let me get back there. Okay, so we were just taking notes on that. So, reduction is something we should follow up and we can go through some of the examples. These are great examples because these are what the log need to be. Um without uh and also like from the uh TA specification itself it implies the maximum things you can uh well not maximum but you can imply a lot of things you can have proof of. So what are the things that's already attested? basically it's not my self statement but somebody attested or somebody told me so right and so all these messages TA message or TSP messages can are attested because they are statements made by another party and they told me so with this signature on it other laws whether I you know um delete this particular file at this moment are my self locks and you will have trust my word for it. Um and if you want that to be attested then we will need to introduce yet another party to be the attesttor. Um then they can attest it and we need a witness. We have witnesses in the system and these witnesses can then be the witness for you and we could also introduce a testers. Some of the information can be that way. But if you the file is attested in certain way then the attest has to be usually usually okay has to be the custody of that particular file and so there's a bunch of complexity comes in uh as we get more and more complex on that. >> Right. >> Yeah. >> So and this is just guidance. This is not part of the spec because you can't it's not deterministic. We can this is just the the logs as guidance right? >> Yeah. So the I thought the spec was tell you you can produce such kind of logs and what are the best practice to use these logs etc. But maybe that would we will end there. Um and this is the question right for for you for for feedback whether that is the right line to draw say beyond that then whoever setting the governance should say it. um underneath of it is the common uh infrastructure or foundation that tea should have saved and that I think that we're trying to draw a line somewhere there. >> Yeah. >> Yeah. Yeah. And and again I'm I'm asking for your input where we should draw that line. Yeah. Um >> I was kind of interested in the next topic. I took a look at it and it has a lot of analoges to what I've been doing the protocol of care >> versus duty of care. I mean, they're very >> um it's 10:00. So, I can quickly because I know that one is I'm very interested in go do that one >> and I just discovered recently that say somebody actually wrote a bunch of things about protocol of care for agents. >> Okay. >> Um so, I'm going to go to this tab. We won't have time to discuss it today. So we can come back and you'll have time to read about it. And so it's very much like what we say a care. [laughter] Um and um you know >> so why don't we talk about this next week? I mean it's pretty much >> Yeah. So we should talk about >> going back to duties. I mean this is essentially duties anyway. >> Yeah. >> Notice clarify question and it goes into I have exactly that same escalation like in >> and I love it because they even have a glyph uh of a a common um icons to describe these things. >> Well, this is this is you know Mitch that's exactly his work. >> This is the guy who does the >> Yeah. Amazing. Um >> yeah, that's the exact same concept except he's integrating it with ZPKs and all these other things. Yeah. So, anyhow, I uh maybe just uh >> You know who I'm talking about? You guys know Mitch? I mean, obviously most of you guys do, but Wjing, you know him? >> Um, yeah. So, anyhow, we uh I I will be very happy that we can uh come back and uh uh maybe uh next week um care. >> All right. And I'll I'll got a question maybe before we go. By >> by the way, can I Yeah. H >> yeah you have a wonderful diagrams to talk uh have been discussed about but one the other thing is I'm concerning about uh terminology part when you describe on the diagrams is there any pleasure to uh describe what it means is something like a delegation we can be uh defined in many different way But normally we consider as a standard terminology things. Yeah. >> Also these kind of things. Is there any papers written down? >> Yeah. All terminology is in the tea spec draft. So if you go to maybe I'll give you the uh let me see. So this is the main body. Uh >> so if I put this Um, let me see. I will put it in the notes so we don't just lose it right away. Um, back. Can I share the the file or because I'm working as a TC7 so I might be able to work it out to trace the terms what you guys used uh in the aspect of a standardization document >> uh diagrams um so I think these are the two that's most relevant Um uh >> because most of times when you guys discuss about we have really familiar but you know uh from the beginning we have to describe the specific you know terms what does it means? So from the beginning >> so if you read the confused it's very precise. Um we we can do a um maybe you join uh late but uh um maybe next week we can go through what is a delegation, what is the invocation all that uh one more time. So all these terms are defined in the spec and it's very precise. There's no ambiguity at all. It's a bit by bit precise. Um it's yeah so these are terms we've settled on um uh so we uh yeah I think everybody need to leave now but uh we can uh maybe next um week. So is there any poss I would love to to contribute about after look it up all of the terms you guys mentioned about it and then I can put it additional ones which we might need to discuss about. So review of the draft spec as an introduction so we can do these next week. Um, anything else I I didn't capture? >> No, I think that's good. It's um Sally, do you have access to the Confluence the the trust over IP wiki that Wining's showing right now? >> No, no, at this moment I don't know. >> Okay. >> Yeah. If you run to anything, one thing might be the trust of IP member. We used to have controls because they want to ensure you signed the member papers. That would be the reason if you uh hit something that you can, >> right? uh if that's the reason then I think you should uh >> I don't know who uh but uh >> ask the support people um or or you know if you haven't then I really strongly urge you to sign the member um agreement then they'll sort it out yeah >> then you'll be able >> yeah I have a look at it thank you >> all right >> and al lastly last meeting Steve mentioned about you know architecture about part maybe next meetings uh am I able to give a comment because last meeting I hadn't look at but he he has he had provide about that but there was some comment I might be suggested to change it >> um sorry what uh can you repeat that again I didn't quite capture what what's your proposal >> this one is not related to this meeting last week's meeting I think Steve was presenting the architect about layers in the agent and the relationship and the governance and the counterpart sections in the diagram but if it's possible then I don't know when it's going to returning back in that file to review >> uh if you were looking for a diagram the diagrams in the note and Yeah. Yeah. Exactly that. I would like to give a comment. Not this meeting. Next meeting if it's possible then. >> Uh yeah, you so next meeting we go back to care. So uh I think uh yeah so that will be a good time but you can also just ask uh Steve uh his document is public. So there's a link I forgot where. So you can follow the minutes. They have links uh pointing to the document. >> I'll do that. Thank you. >> Yeah. Excellent. >> Thank you all. Thank you both. Stick around. Okay. All right. Thank you. See you. Bye. Bye.